What does this mean? Are these theoretical REST endpoints fetching information serially, or something?
Almost all of our REST endpoints fetch all of their information in a single hand-optimized SQL query. How is GraphQL going to run faster than that?
I think anyone with experience will realise that you can get pretty much all the benefits of GraphQL with just a more sophisticated RESTish API.
There is however, one thing that I think GraphQL backends have that REST backends don't, and that's the idea of introspection. Every GraphQL backend must be able to serve it's API data models and types. And I think the community tooling that leverages this makes it an amazing experience for app developers. No SDKs, any GraphQL client works with any GraphQL backend. Codegen esp for Android type apps to skip boilerplate of mapping APIs to POJOs. IDE autocomplete. I really think that the killer feature of GraphQL is that.
We built a JSON DSL over a normal POST endpoint. Most GraphQL advantages sound "not really true" to me because you can always achieve the same thing (almost) yourself anyway.
As you mention though, people often don't realize that GraphQL is just a way to tell an endpoint that you want information in a generic way, and a pattern for having that endpoint resolve information in a generic way. It's an abstraction on top of a normal service call, and like most abstractions, it gives you consistency and ease-of-use but not any new capabilities you didn't have before.
I did note recently while reviewing the Microsoft API standard guidelines they share on GitHub [1], that there is a non-OData standard, but OData like recommendation for working with queries across collections, which I find to be pretty good and pretty generic.
It seems like today you can do what you said - a sophisticated RESTish API without the model metadata piece pretty easily - but that metadata piece adds a lot of value.
[1] https://github.com/Microsoft/api-guidelines/blob/vNext/Guide... - see sections on sorting, filtering etc.
At the time there was also a compelling js library supporting OData.. [1].
> Breeze.js: Rich Data Management for the JavaScript Client
> Client-side querying, caching, dynamic object graphs, change tracking and notification, model validation, batch save, offline support ...
Unfortunately I never had the opportunity to use it for a real project.
[Edit formatting]
That Breeze framework was actually always super impressive. I guess there's a company behind it too. I've implemented some stuff with Telerik Kendo UI and OData (data grids, pivot tables) and it also is still working really quite well.
When you're hand-writing SQL for a specific client experience, you can make optimizations that GraphQL cannot make because you have knowledge about the constraints on the information in the given context that GraphQL doesn't have. This is a tradeoff that comes with querying information in a generic way vs. querying information in a way that is specifically tailored for the experience. As a result, you often end up with queries that are faster than can be assembled by GraphQL.
In the general case, I’ve found that GraphQL is slower even in the case where you’re fetching all of a page’s info at once. Not only is it not necessarily always true that one client-server round trip is faster all-up than more granular requests even when you discount the user experience, this pattern often isn’t good general-case behavior for the reason above.