Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Graphiti?

graphiti.dev

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Why Graphiti?

#31

Post by BiteCode_dev »

onlydnaq wrote: post #7

When it comes to modern web development I’m more of an observer than a contributor, so my opinion might not carry a lot of weight. However for me all these abstractions seems to get closer and closer to querying a database using SQL directly. A carefully designed database schema would be able to support all of these use cases in a way that (at least for me) seems a lot simpler than wrapping it in new abstractions. In…

I wonder if the people at edgedb (https://edgedb.com/) have the right approach then. They used Postgres as a foundation, and used their experience in SQL to make a DSL that is similarly expressive, but but with less caveats and some helpers for very common use cases.

It's a very young project, and as a heavy ORM using I'm not the best person to judge, but I like the way they think.

Re: Why Graphiti?

#32

Post by jarjoura »

onlydnaq wrote: post #7

When it comes to modern web development I’m more of an observer than a contributor, so my opinion might not carry a lot of weight. However for me all these abstractions seems to get closer and closer to querying a database using SQL directly. A carefully designed database schema would be able to support all of these use cases in a way that (at least for me) seems a lot simpler than wrapping it in new abstractions. In…

This is exactly what Hive is. https://mapr.com/products/apache-hive/

It provides a full SQL query engine on top of unstructured data so you can assemble results.

Personally I would never expose the raw DB in any capacity to the front end systems for security and sanity reasons. DB schemas need to be free to change all the time and you wouldn't want to break entire services from a column type change.

Re: Why Graphiti?

#33

Post by BiteCode_dev »

notus wrote: post #18
onlydnaq wrote: post #7

When it comes to modern web development I’m more of an observer than a contributor, so my opinion might not carry a lot of weight. However for me all these abstractions seems to get closer and closer to querying a database using SQL directly. A carefully designed database schema would be able to support all of these use cases in a way that (at least for me) seems a lot simpler than wrapping it in new abstractions. In…

Doesn't work that well when your databases are distributed and you're using microservices. You don't want to be doing join's across microservices and most setups wouldn't allow you to anyways. GraphQL provides that orchestration layer for you.

Let's say it provides more like a standardized common interface for you. You still have to code the glue to make all those data aggregations, cache handling and permission checks.

In fact, because it's such a new tech, and since it's embedded into very few things, you have a lot to write by hands and perf on single servers will suffer compared to regular SQL + Restish.

The concept is interesting for big distributed heterogeneous systems though, especially when you have many clients.

Re: Why Graphiti?

#34

Post by bryanrasmussen »

siscia wrote: post #26
notus wrote: post #24

Earlier quoted context omitted.

That would require you to map the SQL to something else which would then map back to SQL or mongo or w/e. For example if you're trying to join data from multiple microservices you can't execute the join because most microservices setups are not going to allow joins. The joins would have to be mapped to service to service calls and at this point you're just rebuilding an orchestration layer which has already been solv…

So we invented a query language (GraphQL) to solve an orchestration problem? Sorry but I don't buy this reason. Especially not to the question: "Why we don't use SQL as a query language?" especially because REST was around way earlier than GraphQL. Your reasoning could be great to answer the question: "Why we like GraphQL where there are a lot of microservices?" BTW, there is nothing inherent in the language in itsel…

There is nothing about GraphQL that makes me think someone invented it because they were annoyed by SQL and decided to reinvent it, generally reinvention means a lot of similarity only badly done. You might argue GraphQl is badly done in comparison to SQL, but surely not that it is similar.

Re: Why Graphiti?

#35

Post by ameliaquining »

onlydnaq wrote: post #7

When it comes to modern web development I’m more of an observer than a contributor, so my opinion might not carry a lot of weight. However for me all these abstractions seems to get closer and closer to querying a database using SQL directly. A carefully designed database schema would be able to support all of these use cases in a way that (at least for me) seems a lot simpler than wrapping it in new abstractions. In…

I think the primary reason not to do this is security—and I don't just mean that letting attackers make Postgres queries directly is a bad idea (it is, of course, but you could imagine other ways to implement this). You want any interface you expose to the public to be simple enough that you can be reasonably confident that none of the messages you accept can cause bad things to happen. SQL is so computationally powerful that you can't really get that assurance.

Re: Why Graphiti?

#36

Post by dragonwriter »

ameliaquining wrote: post #35
onlydnaq wrote: post #7

When it comes to modern web development I’m more of an observer than a contributor, so my opinion might not carry a lot of weight. However for me all these abstractions seems to get closer and closer to querying a database using SQL directly. A carefully designed database schema would be able to support all of these use cases in a way that (at least for me) seems a lot simpler than wrapping it in new abstractions. In…

I think the primary reason not to do this is security—and I don't just mean that letting attackers make Postgres queries directly is a bad idea (it is, of course, but you could imagine other ways to implement this). You want any interface you expose to the public to be simple enough that you can be reasonably confident that none of the messages you accept can cause bad things to happen. SQL is so computationally powe…

> You want any interface you expose to the public to be simple enough that you can be reasonably confident that none of the messages you accept can cause bad things to happen.

Yes, that's why you expose a simple set of views as your public interface for each role, and apply the dirt simple RBAC that every multiuser RDBMS supports to limit users to the appropriate set of views.

> SQL is so computationally powerful that you can't really get that assurance.

The computational power of SQL is mostly irrelevant, because the dirt simple security model let you limit database effects, so that all the computational power means is that people can tie up resources with poorly (or maliciously) crafted queries, if you don't apply the simple mitigations every multiuser RDBMS has against those.

People not bothering to learn about the database engines they are using leads to putting (often poor) ad hoc security in the web layer in front of a database that isn't properly secured because the app in front is excessively trusted, making this less, rather than more, secure than if people just learned to understand heir DB and exposed it directly instead of trying to acheive security through cargo cult complexity.

It's possible to enhance database security with defense in depth and and additional layers, but none of that starts with misunderstanding RDBMSs so badly as to think that they are, in an app stack, one of the hard parts to secure.

Re: Why Graphiti?

#37

Post by siscia »

bryanrasmussen wrote: post #34
siscia wrote: post #26

Earlier quoted context omitted.

So we invented a query language (GraphQL) to solve an orchestration problem? Sorry but I don't buy this reason. Especially not to the question: "Why we don't use SQL as a query language?" especially because REST was around way earlier than GraphQL. Your reasoning could be great to answer the question: "Why we like GraphQL where there are a lot of microservices?" BTW, there is nothing inherent in the language in itsel…

There is nothing about GraphQL that makes me think someone invented it because they were annoyed by SQL and decided to reinvent it, generally reinvention means a lot of similarity only badly done. You might argue GraphQl is badly done in comparison to SQL, but surely not that it is similar.

Honestly I don't use it so often, but it seems that any query in graphql could be easily and automatically translated to a SQL query. Am I wrong?

There are definitely trying to solve the same problem, aren't they? What are the advantages of GraphQL over SQL?

Please, I really want to know the answer to this question.

The previous answer was "the infrastructure we build around GraphQL is better for microservices", ok I can see that. But it is the only answer? It seems like a little weak reason to create a language so that later you can create a new infrastructure around it.

Am I missing something?

Why you don't find GraphQL similar to SQL?

Re: Why Graphiti?

#38

Post by dsun180 »

tpetry wrote: post #8

The biggest reason for graphql is in my opinion the enforced schema. REST apis so often had a nice written document describing the api and its fields, but nowhere was stated that some attributes can be null in some rare edge cases. In graphql the spec states an attribute can be null and i will not get some code crashing in a few months because of some undocumented behaviour.

I also miss that in GraphQL. With swagger I can exactly define how an object looks like. Not only if something is null or string, but also what the minLength the string is or what enum-values it can have.

Re: Why Graphiti?

#39

Post by gboss »

onlydnaq wrote: post #7

When it comes to modern web development I’m more of an observer than a contributor, so my opinion might not carry a lot of weight. However for me all these abstractions seems to get closer and closer to querying a database using SQL directly. A carefully designed database schema would be able to support all of these use cases in a way that (at least for me) seems a lot simpler than wrapping it in new abstractions. In…

PostgREST is a project that does that automatically for PostgreSQL. It takes your schema of your db and creates an api based on table relationships and provides security through a database design pattern of enforcing row level security. Side effects are challenging. For instance sending an email on account creation requires creating a listener on the postgres notify event but it is interesting to think about even if not 100% practical.

https://postgrest.org/en/v6.0/

Re: Why Graphiti?

#40

Post by _8j50 »

onlydnaq wrote: post #7

When it comes to modern web development I’m more of an observer than a contributor, so my opinion might not carry a lot of weight. However for me all these abstractions seems to get closer and closer to querying a database using SQL directly. A carefully designed database schema would be able to support all of these use cases in a way that (at least for me) seems a lot simpler than wrapping it in new abstractions. In…

I am like you as well except the database might be mongo,elasticsearch,etc... Plus processing of the data might need to be done before the client gets it or the response might be based on db data but the fields might not be db mappable because they're dynamic (e.g.: 'baseItemCost' vs 'itemCostAdjusted' adjusted to item availability,demand,delivery cost,etc...)
Post reply on HN