Nice article.

Actually, the problem you try to solve using GraphQL isn’t really REST’s problem.

The real problem is lack of abstraction, like Domain Models, Service Layer, DAL (that can be implemented using DAO/Repository patterns) and representation layer, something like View Model for the JSON. It happens commonly when people start to use ORM objects for both database and REST request/response direct mapping.

If the system had a separate layer for JSON presentation, instead of direct mapping to the database (this is very common situation when NODEJS used with MongoDB), you can easy change your DB without breaking the interface.

For example, you can create another DAO implementation that will use a new database. You just promise to create the same View Model.

What GraphQL really brings here is a some kind of a standard way for querying the API.

Also, it doesn’t fit all projects. Imagine you just created a new GraphQL interface, that knows to return many entities. Now the frontend developers are very happy, and implemented a lot of features in the UI. The problem is that now the UI has too much business logic inside.

And then a new requirements from the product manager received: we want to implement a mobile clients for multiple platforms. A big chance that all the business logic should be reimplemented on each client again.

The most suitable case for using GraphQL, imho, is when you have provide API to 3rd party companies, and you have no idea about their business. In that case, you provide a standardised way to work with your API, and from other side your API provide a full set of entities, so your client can build anything on top of it.

In GO we trust. Software Engineer.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store