3 ms·

Especially since avoiding n+1 query situations involves hand optimizing a lot of stuff anyways. In my experience it's not really any less work than just aggrega

by jrs95 9y ago

Especially since avoiding n+1 query situations involves hand optimizing a lot of stuff anyways. In my experience it's not really any less work than just aggregating stuff in a regular HTTP API, but it does seem to give a better developer experience on the frontend. At a certain scale, I think it could be worth the investment, but I don't think it really lives up to the hype.

merb 9y ago
well maybe on the frontend it looks good, but on the backend? meh parsing such a query is not painless. and maybe "simple" queries are looking good and simple, complex and bigger queries and big schema's are really really akward to implement.
- foota 9y ago
  Readily available packages in most languages can parse graphql queries for you.
andrewingram 9y ago
> 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 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 ago
    Mostly 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 ago
      That doesn't touch upon the N + 1 query problem at all.
      - andrewingram 9y ago
        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 9y ago
        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.

by jrs95 9y ago

merb 9y ago

well maybe on the frontend it looks good, but on the backend? meh parsing such a query is not painless. and maybe "simple" queries are looking good and simple, complex and bigger queries and big schema's are really really akward to implement.

foota 9y ago
Readily available packages in most languages can parse graphql queries for you.

andrewingram 9y ago

> 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 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 ago
  Mostly 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 ago
    That doesn't touch upon the N + 1 query problem at all.
    - andrewingram 9y ago
      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 9y ago
        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.