The power of GraphQL: why we still often choose this technology

GraphQLSoftware Development

GraphQL is still gaining ground, but at the same time you hear a more critical note from developers who highlight the downside of this technique, precisely for the tool that is meant to make communication between front and Glossary · In briefbackendThe backend is the part of an application that processes data, applies business rules and communicates with other systems on the server. Users usually access it through a frontend or API.Read more simpler.

As a developer you constantly face that choice: which technology fits the project in front of you best. In this article we explain why we so often choose GraphQL for our projects. Even though articles that highlight the disadvantages appear with some regularity, there are enough reasons that convince us. It simply is our go-to. We embrace it. And if you do not yet have a clear picture of what GraphQL actually entails, you will find a general explanation here.

Why you would not choose GraphQL

We notice that there has been quite a bit of attention lately for that flip side of GraphQL, and honestly we find that a healthy development. It always seems wise to us to seriously ask, for every technique you use, whether this really is the most suitable solution.

One objection that keeps coming back is versioning. With GraphQL you essentially run one version, while REST-based Glossary · In briefAPIAn API is a defined way for software to exchange data or call functions in other software without needing to know how that software works internally.Read more can work with multiple versions at once. That is especially a headache with mobile apps, because you never know for sure whether all users update their app regularly. Still, we struggle with this much less in practice. Our APIs are usually not aimed at public use, or they are mainly web applications, not a thick client that lags behind. On top of that it is a pleasant side effect that Glossary · In briefcontinuous developmentContinuous development means improving software continuously in small steps. Automated testing and integration help teams deliver changes regularly and in a controlled way.Read more of those web apps becomes a lot simpler. That helps again.

With techniques you use it is always wise to ask yourself whether it really is the best solution for a problem.

You also often hear that GraphQL can expose too much data if you are not careful. When you do not think carefully about your Glossary · In briefdatabaseA database is a structured collection of data that software can store, retrieve and modify. A database management system controls access to that data.Read more architecture and how you configure GraphQL exactly, you can easily pass along too much data and suddenly leave sensitive information out in the open. We are of course well aware of that, and of the importance of proper configuration and locking things down neatly. What helps enormously is that we typically build internally authenticated applications. That security is then already in place at a much earlier level, so well before a Glossary · In briefqueryA query is a targeted instruction to a system to retrieve, filter, combine or modify data.Read more is executed, information is already protected at the root.

Why you would choose GraphQL

There are a few caveats with GraphQL too, but a solid number of advantages has truly convinced us that this is the best route. To begin with I find it strikingly strong how easily you can define types with it. Consistency in data structures improves and errors drop sharply. With tools such as NestJS, Apollo, Codegen, and React the supporting ecosystem is moreover overwhelmingly large. There simply is a ready stream of solutions a development team can draw from at any moment. Finally we appreciate the flexibility in separating backend and Glossary · In brieffrontendThe frontend is the part of a website or application that users see and operate, such as pages, buttons, forms and interactive screens.Read more, while both still live in one monorepo. Teams can work independently and in parallel, and coordinate changes in both layers at the same time.

Key takeaways

Minimising versioning With GraphQL we usually work with one version of the API, which makes ongoing development simpler.
Simple typing Data is set up with proper types. That locks in a fixed structure and forces errors down.
Flexible separation between backend and frontend Backend and frontend teams can work independently and in parallel, which makes collaboration more efficient.
No silver bullet GraphQL does not fit everywhere, let that be clear, but in many situations we are simply enthusiastic about what the team can do with it.