IMO, the main problem with GraphQL is that a query language isn’t much without a query planner. Without a planner, you end up with the backend picking a set of

IMO, the main problem with GraphQL is that a query language isn’t much without a query planner. Without a planner, you end up with the backend picking a set of queries that the caller can make (and with it, you probably want to restrict callers, anyways). I don’t see how that’s much different from writing N stored procedures and exposing those. If you give those consistent names, the caller has a clear list of things that can be done. With GraphQL, the API looks more flexible than it is. I think GraphQL‘s main innovation is that it allows the caller to specify what fields to return. That makes it easy to provide f! - 1 variants of queries that return up to f fields, cutting down on traffic significantly in many cases.