[valw]

We migrated most of our backend (written in Clojure) from REST to GraphQL (actually a homemade alternative to GraphQL, but not relevant to this discussion).

It went well, it greatly simplified both our backend and frontend code. The backend code got simpler and more stable because it no longer had to deal with "data packaging". The frontend code became more transparent, because you can now easily read what data gets exchanged, and more decoupled, because different components can independently require the data they care about. One of the biggest benefits has been the degree of independence to evolve both the client and server.

We haven't had the performance issues some people have mentioned (N+1 query etc.), because of the server-side design of our homemade GraphQL engine - in which data resolvers are batching and asynchronous by default, unlike most backend libs which approach this problem more naively. Will open-source that soon.

The biggest limitations I see to GraphQL are:

- it doesn't really have a story for caching. I have some ideas for addressing that, but it hasn't been a problem for us really.

- it repeated the SQL mistake of exposing a query language based on text, not data structures. Now we have to write queries as templates instead of assembling them programmatically. This hurts both application developers and library authors.

- it doesn't really have a story for structured writes.

[UncleEntity]

> it repeated the SQL mistake of exposing a query language based on text, not data structures. Now we have to write queries as templates instead of assembling them programmatically.

Out of curiosity couldn't you just treat queries as a composable AST and "compile" the query text from that?

[valw]

> Out of curiosity couldn't you just treat queries as a composable AST and "compile" the query text from that?

You could write such a wrapper, but it won't be standard, which means that there will never be a robust library ecosystem and set of practices that arises from that. If GraphQL was to evolve, you also wouldn't be sure your wrapper can express all of GraphQL. Finally, this would add new practical hurdles, like a new dependency, additional runtime cost of compilation, obscured source mapping, etc.

Meanwhile, because GraphQL is just a text-based DSL, most people don't have a clear idea of the _information model_ of GraphQL queries - you have to read the spec to get this idea. If we are to build a robust ecosystem on top of GraphQL, this information model should be evident in the API.

All these problems are present, and very damaging, in SQL.