3 ms·
I think GraphQL is highly misunderstood. I wrote about it extensively [1]. TL;DR: it's not really a query language, like SQL. It's more of an opinionated RPC f
by acjohnson55 7y ago
I think GraphQL is highly misunderstood. I wrote about it extensively [1].
TL;DR: it's not really a query language, like SQL. It's more of an opinionated RPC framework. I generally don't think building out one's entire data model in their GraphQL schema is a good idea, in general, but it's also not the true value-add of the system.
[1] http://artsy.github.io/blog/2018/05/08/is-graphql-the-future/ http://artsy.github.io/blog/2018/05/08/is-graphql-the-future...
- jayd16 7y agoWell this is the conflict. If its just a way to batch dependent queries there are things like capnproto that do that too. Ideally though, you don't use dependent fetches and you have a bespoke endpoint that collapses the dependent operations possibly as tight as a single join query. If this is the case you're trying to solve, then why shouldn't we strive for something like a declarative query language?
- acjohnson55 7y agoI haven't looked at capnproto recently, but just because it solves a similar problem doesn't mean there's no room for a different system. The bespoke endpoint thing is a big part of what GraphQL avoids. It gives you something explorable, but as a team, you can decide how comprehensive you want it to be. If you have a monolithic database, you can use SQL to explore it, but GraphQL often sits in front of a service layer, which connects to my next point. GraphQL's mutations often map to entire processes, which might change a data store, like a DML SQL operation, but also have other sorts of effects.