[013a]

GraphQL to REST is a more typical comparison. In this case: designing a GraphQL API is substantially easier to both make and consume; while REST just tells you "here's some guidelines, now go do it however you want", GraphQL enforces a much more consistent view of how an API should look, while allowing clients much more freedom in how they get the data they need.

Where you start running into issues is the surrounding tooling. Integrating a typical REST API into an APM monitoring solution is a cinch, because all of these tools know how to read the incoming requests, HTTP methods, paths, bodies, etc. With GraphQL, you might be left building glue for your APM tool of choice, or just using the highly limited, but at least specialized, Apollo Engine. Enforcing strict rate limiting is easy with REST; very difficult with GraphQL due to how complex and free-form queries are.

Optimizing your backend to support those free-form queries is also (I dare say intractably) difficult; I haven't seen a single backend framework which doesn't actively encourage an N+1 problem on any query which returns multiple objects of data. AppSync as well, my god is that an evil play from AWS; if you've got separate lambda functions serving all the different nodes in your graph, a single query could trigger dozens, or even hundreds, of invocations. Combine that with their guidance to use Aurora Serverless and any casual observer might say that they're actively exploiting the unfortunate ignorance of an engineer trying to jump on the latest trends.

I don't believe any of these things are problems with GraphQL. I think they're issues with ecosystem immaturity, and I hope they get better over time. Frankly, every single backend library I've used sucks; its designed to be awesome on the frontend, and it is.

I think you're right that, right now, its best suited to large organizations. Large organizations can engineer around all of its issues and extract a LOT of value from it. Medium organizations are almost immediately going to run into ecosystem immaturity and scaling issues. Small organizations are going to get the most value from an "all in one" solution, whether that's Firebase, or a simple REST API on App Engine, or something like that.

But I could be wrong in my analysis that its not a core issue with GraphQL, and there are subtle complexities with the API definition language which make scaling it for anyone who isn't Facebook intractable. Time will tell.

[ruslan_talpa]

> I haven't seen a single backend framework which doesn't actively encourage an N+1 problem on any query which returns multiple objects of data

Well then you haven't really looked :)

https://join-monster.readthedocs.io/en/latest/

https://github.com/graphile/postgraphile

https://www.prisma.io/

https://subzero.cloud/

These are all examples of tools/libs that implement a graphql api without a N+1 issue

[013a]

Those are great resources. But all of them appear to be tightly coupled with a SQL storage backend. That's valuable, but what I believe the ecosystem needs is a generic system which can "pre-compile" a GraphQL query into a backend language data structure which the developer can then transpose into a database query.

I think Facebook's Dataloader is more close to a solution.

[BenjieGillam]

PostGraphile is built on Graphile Engine which is completely backend-independent (like GraphQL itself). This is what we use in PostGraphile for the "look-ahead" functionality, allowing you to build a database/API/backend query that represents a full GraphQL query as one action. You can read more about it here, though it's currently not as well documented as PostGraphile itself. https://www.graphile.org/graphile-build/

[macca321]

Almost like a Language INtegrated Query (LINQ) in C#?

OData did exactly this years ago, and got heavily criticised for giving too much querying power to the client side, as (without expert usage on the server side to whitelist the query) a client could run queries that would overload the server.

You're damned if you do, and damned if you don't.

[tirumaraiselvan]

We at Hasura[0] use a GraphQL to SQL compiler approach[1] so its just ONE query no matter the size of the Graphql query.

[0] https://hasura.io [1] https://blog.hasura.io/architecture-of-a-high-performance-gr...

[hakanito]

Facebook released DataLoader [1] to help reduce the number of database invocations. As long as you write your queries to fit the loader pattern it's pretty straight forward. Been trying out a golang port [2] for a month or two and it really (really!) improves performance.

[1] https://github.com/facebook/dataloader [2] https://github.com/graph-gophers/dataloader