Flexible data with GraphQL

Data is the internet's fuel. Over the last years we’ve seen an increase in the amount of data we collect, store, process and use online. Fifteen years ago organizations used technologies such as SOAP and xml to interchange data between systems and in the last decade web applications started to use web-services based on REST principles. Both technologies have proven great value, but also have drawbacks that not always work well with multi-channel architectures and the customer experience businesses want to offer to their clients. But there’s a change on the horizon, named GraphQL.

Facebook, as one of the largest internet companies, experienced the drawbacks of traditional REST-based APIs already in 2012 when they began rebuilding their native mobile applications. As current-state solutions weren’t delivering the performance customers asked for, Facebook’s engineers came up with a new way of data-fetching, from the perspective of designers and developers. They open-sourced the GraphQL specification together with a reference implementation in 2015, making it possible for everyone to build systems around this new technology.

Why use GraphQL?

Two of the most notable reasons to use GraphQL over tradition REST approach relate to client control en backwards compatibility. GraphQL works exceptionally well in an environment where different applications access the same datasource, but require slightly different information, or information in a different structure, such as mobile and web-applications connected to the same backend. The applications are in control of what data to fetch. This increases productivity for developers and improves performance for application users. Another major advantage is that GraphQL is version-free. It uses one endpoint and can support deprecated data fields. This helps to support different (legacy) versions of applications using the same data endpoint.

Is my business ready for GraphQL?

If it ain’t broke, don’t fix it. For most existing applications I would suggest to stay with REST instead of migrating to GraphQL. A reliable data layer is essential in a good architecture. Proven methodologies, knowledgeable developers and technical support are essential in a business context where your data drives critical systems.

But if you operate in an environment where data is frequently changing GraphQL is worthwhile to explore. Its implementation can be gradual, without rewriting all existing code, thus reducing upfront risk and complexity. After some time you might even migrate all your APIs to GraphQL and never feel the need to use REST again.