GraphQL and the Beads on a String

If you need to request multiple REST resources for a single "operation", then you don't have enough REST resources defined. [1]

Just make another endpoint for getting the whole thing in one go and call it a day, don't try to overly generalise your API.

Going even further, your server requests to the database could be similar as well, one query to get everything needed, then you don't even need to worry about server to database distance!

[1] https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...

The problem with REST (or really, any current non GraphQL solution) is there is only an implicit link between the consumer of a field and the query declaration. So, REST queries are append only, especially at large organizations where incremental perf improvements are less good than accidentally bringing down the site is bad. That’s the failure mode of specialized REST endpoints that deliver exactly what a given view needs.

If the primary selling point of the new technology is something like GraphQL's "if your API doesn't have a good single route to get the data for this page, GraphQL can synthesize it"; frontend just doesn't, in general, iterate at a speed that is such orders-of-magnitude higher than how quickly a new API view can be built, such that a new structurally-different communications layer is necessary.

Additionally; GraphQL never got the community love it needed on the backend side to make things hum. Apollo is the only organization really pushing it, and they invest something I'd estimate as 10% of their time into thinking about Apollo Server, which is in any event JavaScript-only. It turns out, the problems GraphQL creates in a system are backend problems; there's some really freakin hairy edges in the domains of authorization, caching, rate limiting/complexity limiting, even just basic type safety, that can only charitably be described as "solved" if you consider "some ideas in a twenty page blog post" as a solution.

We also had constant problems educating our customers about GraphQL. "No no, you can use any REST client you want, here let me show you how to set it up" (two hour education session later).

There really isn't a perfect solution to the problem space. If your view is complex enough, synthesizing it JIT in GraphQL is just the frontend saying "its your problem now" to the backend, and whether the solution to that is "fixing performance bottlenecks" or "a new RESTful-ish view API for this screen" for the backend team, its still a ticket. If the view is less complex than that: making multiple requests isn't the end of the world. After all, those two highly predictable, optimized, even cached requests may end up being faster than one dynamic and extremely-difficult-to-cache GraphQL request.

At the end of the day, I think there's a reason why REST has lasted as long as it has, and why it still feels state of the art to me. Moving more API capabilities to edge platforms, including edge databases, shortens that string of beads quite substantially. Server-side rendering is back is in full force. There's other angles this problem is being attacked from.

> I'm getting a notification if you use the term "WunderGraph"

What happens if I say it three times in a row?

Will it summon you to appear in my geographical proximity?

WunderGraph WunderGraph WunderGraaaaaaAAAAHHH-

I like the RESTful approach taken by Graphiti:

Single request and response and with a graph of nested relationships. This approach lets one still use HTTP GET caching, whereas GraphQL hides everything behind a single POST endpoint.

https://www.graphiti.dev/guides/