3 ms·
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 p
by meesterdude 9y ago
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 9y agoMostly i'm referring to the methodology I followed here: https://dev-blog.apollodata.com/optimizing-your-graphql-request-waterfalls-7c3f3360b051 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 9y agoThat doesn't touch upon the N + 1 query problem at all.
- andrewingram 9y agoCan 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 9y agoThe 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.