4 ms·

Notice nobody actually tackling the “performance issues” part of this, because that is the real problem most experience. A standard implementation gives you n+1

• quonn 5y ago
  GraphQL solves a frontend problem and also makes it possible to address the n+1 problem. REST only makes it possible if you add batch/specialized endpoints which is not very RESTful and is exactly the same optimization than for GraphQL. Whether the introspection is hard or not depends on the library. A good library provides you with a set of queries sub-paths and then it‘s trivial to pre-fetch those at an outer resolver.
  • collyw 5y ago
    Where does the idea that "nested objects in responses are not RESTful" come from? It seems very common from graphql enthusiasts.
    • quonn 5y ago
      Nested objects are fine, making a custom endpoint to provide what the client just needs is not what you will find in real REST APIs in the real world. So a lot of n+1 type of requests are made and much of the data is discarded. I wonder why this is even controversial now. APIs have been like that for about 15 years and GraphQL was created to address that and it does it very, very well. edit: slver has explained my point of view much better than I have here.
      • slver 5y ago
        Every REST argument: - REST is standardized, because look at all the standards for it (OData, OpenAPI etc.). - REST is easy, because I don't implement any of those standards. - REST is flexible, because I don't even understand the constraints of REST and violate them at will turning it into RPC calls, thinking that it's about pretty URLs and CRUD verbs. Honestly, it's pointless to argue with those folks. Let them believe REST is the solution. It's way above their paygrade to understand why GraphQL exists.
        • aniforprez 5y ago
          This seems so unnecessarily antagonistic. People violate all kinds of "standards" all the time cause they don't know any better and design stuff terribly. You could pretty much make a terribly designed system in a similar way with GraphQL except maybe less accidentally cause it imposes some constraints on the developer to follow what the library gives you. The benefit of GraphQL is the fact that there's very few ways of implementing it
          • slver 5y ago
            So it's unnecessarily antagonistic, but then you proceed to agree with everything I said. Look you can't argue REST is easy by defining REST one way, then argue it's powerful and has these features by defining it another way, and finally implementing it in a third way. GraphQL at least has a shape. It's a thing. It says "you gotta do this and this and this, and then you get that and that and that out of it". The original REST paper also has the same tit-for-tat proposition, but it was abstract, not a concrete architecture, rather it was an architectural style. And as such, it's been basically ignored. Oh, also the REST architectural style is NOT suitable for fine-grained data APIs (Fielding's words not mine). When you say REST API today, REST is not a thing, it's shapeless, formless, it has no smell, no taste, you can't touch it. So newbies can claim it's easy because you just slap some JSON and you call it REST API. No, GraphQL can't compete with that definition of REST. But also it's not trying to.
        • jrsj 5y ago
          My argument is that I know it’s worse, I know in practice it is your 3rd bullet point, but it’s easy for both the lowest common denominator of developer and manager to work with and understand. It’s technologically inferior but has less complications on the human side of things in my experience.
• millerm 5y ago
  A dataloader implementation is your first step. https://github.com/graphql/dataloader https://github.com/graphql/dataloader
• slver 5y ago
  > So how do you fix that? Well you’ve got to do query introspection to resolve certain queries in a more optimized way. Which tends to be more complicated than just…doing exactly what you want to do via a REST endpoint. You're talking about having a REST endpoint which has a "prebaked" aggregate query. But this is not plausible when you serve hundreds, or even thousands of heterogenous clients. Even big organizations like Netflix quickly gave up "prebaking" thousands of REST endpoints for every usecase they had across the organization and outside it. And aggregate query resources are an anti-pattern in REST because it denormalizes the resources. You're supposed to have one resource on one URL. Instead of one resource included in hundreds of ad-hoc aggregate collections at other URLs, each of which are cached (and go out of sync) independently. And if you have one resource per URL... this creates the mother of all N+1 problems automatically.
  • jrsj 5y ago
    Yeah I don’t mean REST in reality because as we all know, nobody actually fully follows that pattern and 90% of the time it’s really just vaguely REST-ish RPC over HTTP anyways. It’s still easier imo to deal with that than the equivalent in GraphQL up to the point where you’re dealing with a large number of heterogenous clients as you describe. And that’s a problem a small minority of GraphQL users are facing or will ever face.