GraphQL might have started as a convenient way of delivering exactly the right amount of data from server to the client. But with the advent of tools that allow for automatic GraphQL schema generation from DB schema, such as Prisma, Hasura and Postgraphile, GraphQL is not just the better REST alternative anymore. It is a query language of universal and programming language agnostic ORMs. And probably more.
If you haven’t used GraphQL yet, the simplest way to explain it would go like: “It is like REST, but you get to tell the server exact fields you need from it, and you’ll get those and only those fields.” Which in perfect implementation (although I’ve never seen one in practice) saves both bandwidth and server resources because the server only queries DB for specific data in every case. This would of course be a correct, but not full picture of GraphQL possibilities.
That’s because GraphQL in a nutshell is a data exchange protocol, and therefore it has a very blurred definition of a server. More specifically, GraphQL understands that the data needs to be served according to a schema, but it gives absolutely zero fucks about where that data comes from. It can come from an API, from a DB, from another GraphQL query, from filesystem (this is exactly what Gatsby does), from a radio receiver, or from a human who is entering data by keyboard. This is different from e.g. SQL, which by definition implies there is a database, which has tables which have rows and columns.
This universality is why GraphQL is perfect for ORMs. Not one, not two, but three groups of very smart people figured that out relatively simultaneously, and now we have three great products, which I’ve already mentioned. I worked with two of these products, and their pros and cons relative to each other are another story entirely, but as a concept I find autogenerated GraphQL API’s from a DB schema just a better tier technology than conventional ORMs.
You can use the same generated API in any programming language, and you have to define and maintain models and migrations only in one place. Everything else can just take the generated schema and use it. One could argue that now instead of writing ORMs in different languages, you need to write GraphQL clients in those languages, and that is true to an extent, but:
GraphQL specification is quite strict, so there is a very high chance that a Javascript GraphQL client will be very compatible with a Python GraphQL client. Django ORM will never ever be compatible with i.e. Sequelize.
You still don’t have to define models by hand in another programming language. Although on a frontend this was mitigated long ago by REST, and on a backend by architectural solutions like microservices; painless reusage of DB schema is a thing again with GraphQL.
I described only one unconventional use case of GraphQL here, and people are finding more ingenious ways to use it (like Gatsby), so I’m betting on a bright and long future for it. If you’re a software engineer, don’t be surprised if GraphQL comes knocking on your door in near future. Embrace it.
