[atombender]

I'd argue that GraphQL is starting to fulfill the conceptual promise of REST: A universal, discoverable, self-describing API protocol. Every REST implementation ends up being ad hoc and not interoperable. With GraphQL you can point a documentation tool at a live server and get reference documentation for that API, for example. You get a schema, the ability to join collections of data together, parameterized queries, and more.

[iovrthoughtthis]

Are we just turning our application servers into database servers?

[rhacker]

Yes. When we write carefully crafted services that manipulate data based on a set of permissions and rules that make up what Twitter (for example) is, you're basically doing similar things that Postgres is doing when it writes data, it is looking at it's own set of permissions, etc..

So yes that's the exact analogy. We're writing databases on top of databases. Only ours are no-SQL.

[masklinn]

GraphQL decouples the API and the database entirely. You can implement graphql as a direct DB access, but it's certainly not the intent. Quite the opposite really, it was designed in not small part to provide the ability to aggregate and re-organise data from multiple sources in a single coherent API.

[marcosdumay]

You are missing the point.

GraphQL is a relational query language, just like SQL but only less powerful.

Fact is that people always wanted a just database anyway. But with some graphical interface on the front. Once we moved the interface to the client in an SPA, it seems unavoidable that backend will turn database-like.

[iovrthoughtthis]

Could we not just move the sql interpreter higher up the stack? Implement tables, views, functions as application code and use sql from the front end?