3 ms·

But if you were fetching the same data with a REST API (one that doesn't allow inclusion of relation fields, such as the JSON-API spec), you'd be doing the same

But if you were fetching the same data with a REST API (one that doesn't allow inclusion of relation fields, such as the JSON-API spec), you'd be doing the same amount of I/O and have the same horrible n+1 problem just between the client and server rather than inside the server, so it's spread across numerous requests rather than just one. Tools like Dataloader solve the n+1 problem quite effectively, and they've been around for about 5 years, making it a solved problem for the overwhelming majority of GraphQL's open source existence. If you look at the examples I wrote in this article (https://andrewingram.net/posts/optimising-graphql-request-waterfalls/ https://andrewingram.net/posts/optimising-graphql-request-wa...), in the waterfall charts each "call" is roughly equivalent to one simple (and usually easy to optimise) database query. I don't want to unduly trivialise the work in getting Dataloader properly integrated, but I will say it doesn't take a lot to start seeing the fruits of your effort.

fogetti 6y ago
I think you are confused about what the parent comment said. The point is that the n+1 problem is usually solved on the database level in case of REST and the endpoint is also changing in tandem to reflect the DB changes. There is no client and server fan-out as you describe. And the second thing is that solving something by slapping an unknown library into the stack instead of using the DB tools which are readily available out of the box doesn't make much sense IMO.
initplus 6y ago
Sure, I'd have the same n+1 problem. But this time the frontend devs will notice it when they try to use the API. With GraphQL our frontend team doesn't reason about the backend performance characteristics of their queries until they kill perf on prod.
- andrewingram 6y ago
  At this point it's sounding more like you don't trust your front-end devs. Fixing that is going to be more critical than any technological choice you make.
akra 6y ago
Not quite. There is an advantage to being "chatty" that GraphQL proponents don't often mention IMO. You can load balance each of those join requests, cache those GET requests even if they make up only a part of the overall query, shard the storage to multiple servers, rate limit, etc. Spreading requests is usually a good thing; with HTTP/2 the overhead of those extra requests is extremely low as well. It allows sharded processing with approx equal load between nodes at the backend. Its much easier to define SLA's and manage your traffic profile/platform when the load of each "query" is definitely quantifiable and granular - unlike a GraphQL query. Then people come to me and say - well you can pre-can your GraphQL queries so that you know which queries are going to be run therefore you have known performance. At which point I say - why not just make a specialised REST endpoint with that query inside it? I see it as a good backend-for-frontend adapter technology where a bulk query can be sharded into individual smaller ones using core backend services for large use-case specific views. If a query uses too much resources then the GraphQL server and/or a client ID can be rate limited by the backend servers, etc. Which is why I think its mainly a JS thing to date IMO - it doesn't solve many core problems for most backends - it solves typical front-ender dev's issues who can't/don't want to write server side code.

fogetti 6y ago

I think you are confused about what the parent comment said. The point is that the n+1 problem is usually solved on the database level in case of REST and the endpoint is also changing in tandem to reflect the DB changes. There is no client and server fan-out as you describe. And the second thing is that solving something by slapping an unknown library into the stack instead of using the DB tools which are readily available out of the box doesn't make much sense IMO.

initplus 6y ago

Sure, I'd have the same n+1 problem. But this time the frontend devs will notice it when they try to use the API. With GraphQL our frontend team doesn't reason about the backend performance characteristics of their queries until they kill perf on prod.

andrewingram 6y ago
At this point it's sounding more like you don't trust your front-end devs. Fixing that is going to be more critical than any technological choice you make.

akra 6y ago

Not quite. There is an advantage to being "chatty" that GraphQL proponents don't often mention IMO. You can load balance each of those join requests, cache those GET requests even if they make up only a part of the overall query, shard the storage to multiple servers, rate limit, etc. Spreading requests is usually a good thing; with HTTP/2 the overhead of those extra requests is extremely low as well. It allows sharded processing with approx equal load between nodes at the backend. Its much easier to define SLA's and manage your traffic profile/platform when the load of each "query" is definitely quantifiable and granular - unlike a GraphQL query. Then people come to me and say - well you can pre-can your GraphQL queries so that you know which queries are going to be run therefore you have known performance. At which point I say - why not just make a specialised REST endpoint with that query inside it? I see it as a good backend-for-frontend adapter technology where a bulk query can be sharded into individual smaller ones using core backend services for large use-case specific views. If a query uses too much resources then the GraphQL server and/or a client ID can be rate limited by the backend servers, etc. Which is why I think its mainly a JS thing to date IMO - it doesn't solve many core problems for most backends - it solves typical front-ender dev's issues who can't/don't want to write server side code.