GraphQL

This item was not updated in last three versions of the Radar. Should it have appeared in one of the more recent editions, there is a good chance it remains pertinent. However, if the item dates back further, its relevance may have diminished and our current evaluation could vary. Regrettably, our capacity to consistently revisit items from past Radar editions is limited.

Aug 2026

Hold

We have moved GraphQL to hold.

We have used GraphQL in a number of projects and found that in our context it tends to create more problems than it solves. The added complexity in caching, authorisation and schema governance has not paid off against the flexibility it gives us.

Hold does not mean we have stopped. We still actively run GraphQL in production on a current project and keep the skills to do so, so we can support clients who already have it or who specifically need it. What it does mean is that we would not choose GraphQL again for a new project. There we prefer REST for frontend-backend integration.

This is not a judgement on GraphQL as a technology. It is a judgement on how well it fits the kind of solutions we typically build.

Mar 2023

Adopt

GraphQL is a powerful way to expose an API for frontend use.

We generally prefer GraphQL over REST because it increases flexibility and agility, depending on the context (e.g. external APIs may still require REST for API clients' needs).

Beware of GraphQL misuse however. A mix of GraphQL and REST is also a viable solution.

Sep 2021

Adopt

GraphQL is a powerful way to expose an API for frontend use. We prefer it over REST APIs in most cases because it often increases flexibility and agility, depending on the context (e.g. external APIs may need to use REST for API clients' needs).

Beware of GraphQL misuse however. A mix of GraphQL and REST is also a viable solution.