[andrewingram]

> Especially since avoiding n+1 query situations involves hand optimizing a lot of stuff anyways.

Rarely. Assuming the GraphQL server is using REST endpoints behind the scenes, i'm yet to find a request waterfall that required manual rather than automatic optimizations. I'm assuming there are cases where a manual path is faster, but they're less common that you'd think.

[meesterdude]

Not sure how magical your automatic optimizations are - but my experience does not at all mirror yours. i've certainly had to hand-optimize queries to improve performance, on top of the query already being automatically optimized. Removing unused data, tying across custom relations and moving things into different forms of caching are all quite manual efforts I've done plenty of. So, not sure how "less common than you'd think" holds up to scrutinization. I'm just one counterpoint.

[andrewingram]

Mostly i'm referring to the methodology I followed here: https://dev-blog.apollodata.com/optimizing-your-graphql-requ...

I haven't looked into optimising other types of architecture (eg GraphQL server talking directly to the database), but there seem to be plenty of solutions that people are happy with.

[Daishiman]

That doesn't touch upon the N + 1 query problem at all.

[andrewingram]

Can you tell me which particular problem you're talking about? When people talk about GraphQL and the n+1 problem, they're typically talking about the problem which Dataloader solves, and this is the problem this article builds upon.

[Daishiman]

The N + 1 at the database level implies that for every object's remote relations you have to do another query instead of subsuming the object in a large invididual SQL query.