GraphQL, the cons …

Lately I’m hearing a lot of people talking about GraphQL as it was the silver bullet for all your problems. Then I have decided to write down this post to point some cons of this approach comparing with REST.

I’m not a REST evangelist and I don’t hate GraphQL, but I’ve been working a lot with RESTful APIs lately and I got lots of benefits from its principles in the backend and in the frontend. Oh, frontend, WTF, is it BFF? No! Just applying some basic concepts (listed below) on a RESTful API, you can help you frontend to avoid a lot of crap.

Ok, so let’s list some things that a migration to GraphQL loses comparing to REST.

Caching: you will need to implement a custom caching mechanism, which you had almost for free before.

Hypermedia: on RESTful APIs you can use hypermedia to allow the consumer to discover resource relations using the API response, which is difficult when using GraphQL.

HATEOAS: on RESTful APIs you have queried a resource and you want to know the list of things you can do over this resource. Using GraphQL it’s harder to do this, because as you have this same “endpoint” that queries everything. It’ll become a mess if you try to do something similar.

HTTP status codes/verbs: RESTful APIs provides more predictability and consistency with the use of HTTP status codes and verbs.

Documentation: GraphQL schemas are not an API documentation. In most cases, in RESTful APIs you can configure something like Swagger quickly and there is your documentation.

Of course GraphQL has lots of good things, but it’s also good to put on the table the cons, so then we can check whether it’s a good pick for the specific problem that you are trying to solve or not.