| > GraphQL just makes it so that you can traverse them with a single query. Yes. This is what I'm saying. GQL allows for a combinatoric explosion of potentially required queries (and in extreme cases, data providers) to fufill any request. And every GQL endpoint needs to be able to service all of them unless your request routing proxy can peek into body contents, which is more expensive than URL routing. > REST endpoints tend to force you to make multiple queries to go back and fetch information about the entities whose IDs you received in earlier requests A problem we can solve elegantly with HTTP/2 push using nearly identical underlying API servicing models. What's great about that approach is that it's totally transparent to the client; they just get better performance with less resources. Instead, folks have decided to discard a lot of really positive aspects of the REST model to make a client-facing DSL realized in the server. > In both cases, combinoratic explosions (and infinite depth) are possible But in the classical rest case, the client is aware they're doing this, as well as the server. In the GraphQL case, we've obfuscated this and said, "We reserve the right to reject your quest for any reason, and we've also made it harder for us to service your query (unless we go back to mandating every valid query as in rest), and we've also made scaling harder because it's more difficult to factor endpoints into different scaling groups." But hey, that DSL is great. It's like JSON without tall that predictability or syntactic validation. I cannot see any positive outcomes to adopting graphql other than that, "Client-side developers love it". If ya'll love it so much, why not maintain it on your side via service-worker query interception? I ask facetiously. The answer is: because that would be really hard, and we'd rather push it off to API endpoint devs. Devs who promptly put restrictions that basically render the best part of GraphQL (that it is a query language) impotent for performance reasons. |
How about one HTTP request often being faster than multiple requests? How about only retrieving the payload you requested rather than all the extra data the API developers decided to expose in the endpoint – bandwidth isn't free? How about not having to add new custom bespoke API endpoints because some new part of the website just needs a few little different pieces of data that would normally require several round trips, pretty please? These are just normal everyday issues that people put up with when using REST APIs.
> A problem we can solve elegantly with HTTP/2 push using nearly identical underlying API servicing models. What's great about that approach is that it's totally transparent to the client; they just get better performance with less resources.
Shouldn't you use push when you know the client will ask for the resources? How would you know whether the client will ask for certain connected objects in this case? Would you just always be pushing every connected object over the wire?
I don't really see why you're giving such special distinction to one HTTP request vs. multiple HTTP requests. That is an arbitrary distinction to make. You shouldn't be asking "how much strain can a client put on my server with a single request? but oh, they can make multiple requests…" but "how much strain is a client going to put on my server to get all the data they need, whether it happens across one request or multiple?"