[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...