5 ms·

> The need to do multiple round trips to fetch data required by a view: With GraphQL, you can always fetch all the initial data required by a view with a single

• ruslan_talpa 9y ago
  Like PostgREST does :)
• 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.
• adamnemecek 9y ago
  But you have to do it manually. GraphQL removes that pain (or at least that's my understanding:.
  • badlucklottery 9y ago
    It removes the API design, versioning, etc. pain which is probably huge in an organization as large as facebook. But there's still going to be a decent bit of backend tuning which in my experience is the hard part (unless the organization is so dysfunctional new API version design meetings descend into a hostage exchange).
• sametmax 9y ago
  You can but you have to write all the allowed query combinations. Graphql is more flexible. It's also declarative, so you can provide a widget with the schema it needs. Another benefit of graphql is that is a "lingua franka", you can use it internally, between microservices, etc.
  • t_fatus 9y ago
    Indeed, some of the points which I loved the most when I started using it was how it allows to avoid writing any serialization method, how it helps centralize permissions, and, as said in the article, the simplicity it adds if you want to add fields in your queries.
• rublev 9y ago
  I love me some complex async/await chains!
• infogulch 9y ago
  Right but then you have to build a custom http api for each and every new view. Oh, and now you altered the view a tiny bit and need some more fields? Add yet another api. Oh, you did a redesign and you only need a tiny bit of data now? Either add another api again, or deal with the fact that you're wasting bandwidth by sending a bunch of unnecessary data.
  • t_fatus 9y ago
    or you can pass the fields you want in your request, and then realizing it would be simplier to fetch all your data in only one endpoint to avoid multiple roundtrips, create a giant request-parsing-data-fetching logic to respond with some kind of nested data, yeah GraphQL is useless because we can build a new one from scratch for each of our projects ;)
    • pdimitar 9y ago
      ...at which point you reinvented the wheel and it's very likely that the GraphQL library for your language works better and maybe faster. <winks>
• jlg23 9y ago
  The difference is that in pure RESTful APIs you don't have that ability anymore. So, when all you know is RESTful design, GraphQL is solving a problem. But in the end you'll still implement a "plain old http" API when interfaces have stabilized and performance matters. Until then, what you gain is "only" a completely decoupled backend that will accommodate frontend developers work in exchange for more generic logic in the backend. Not necessarily a bad thing, if this is how your shop works.
• chiefalchemist 9y ago
  Yes, that's true. But I don't think that's legit within the technical and absolute definition of REST. Perhaps they used that strict definition in order to differentiate the product?