4 ms·

> 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 h

> 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://join-monster.readthedocs.io/en/latest/ https://github.com/graphile/postgraphile https://github.com/graphile/postgraphile https://www.prisma.io/ https://www.prisma.io/ https://subzero.cloud/ https://subzero.cloud/ These are all examples of tools/libs that implement a graphql api without a N+1 issue

tirumaraiselvan 8y ago
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 https://hasura.io [1] https://blog.hasura.io/architecture-of-a-high-performance-graphql-to-sql-server-58d9944b8a87 https://blog.hasura.io/architecture-of-a-high-performance-gr...
013a 8y ago
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 8y ago
  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/ https://www.graphile.org/graphile-build/
- macca321 8y ago
  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 8y ago

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 https://hasura.io [1] https://blog.hasura.io/architecture-of-a-high-performance-graphql-to-sql-server-58d9944b8a87 https://blog.hasura.io/architecture-of-a-high-performance-gr...

013a 8y ago

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 8y ago
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/ https://www.graphile.org/graphile-build/
macca321 8y ago
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.