Why GraphQL for Microservices?

In 2022, many companies have adopted microservices into their software architecture. By splitting up their services into smaller parts, these companies benefit from modularity, scalability and distributed development. But how these microservices communicate with each other or the outside world is often a point of discussion and a challenge.

Popular patterns include API gateways or a data mesh to combine microservices. And GraphQL can play a vital role in the communication layer between microservices.

Why GraphQL for Microservices?

Microservices usually cover specific parts of your organization or so-called domains. Imagine a team of developers working on authentication; this team will also work on the authentication microservice.

Different teams work on other domains, for example, payments or inventory. These microservices are independent of each other but still need to communicate. Most microservice architectures require multiple requests to different internal microservices to serve a single client request.

Today, many companies use REST for both internal and external communication of their microservices. REST is a good approach for APIs that want their response to be static with limited customization possibilities. But when you want the data to be dynamic, REST has its constraints. REST APIs are often seen as a contract, meaning that the data always comes in the same form and shape.

On the other end, you have GraphQL, which is highly customizable and lets the consumer take control of the returned data. GraphQL APIs revolve around graphs, giving consumers the option to mix and match data from different graphs in one request.

GraphQL has been increasing in popularity, and companies like Facebook, GitHub, Shopify and Netflix have adopted GraphQL since its introduction in 2015.

Organizing Services around Graphs

When using GraphQL as the communication layer for your microservices, the domain of a team turns into a graph. This graph contains all the possible data the microservice can expose for a domain.

In GraphQL, this graph is represented by a GraphQL schema, which describes via a set of types and operations what data is available and in which form. The team responsible for a domain, let’s say the payments team, is responsible for keeping this schema up to date.

When your microservice exposes a GraphQL schema, you can combine this schema with the schemas from the other microservices with GraphQL. Combining the schemas can be done in an API gateway or data mesh. By combining these microservices in a separate service, you:

Conceal your microservices architecture from the consumer.
Reduce the number of client requests to individual microservices.
Simplify consumption of your microservices architecture.

But building a GraphQL service for every microservice can be very time-consuming, as patterns for caching and authentication are different in GraphQL and REST services. Also, you need to build an additional GraphQL service that combines all the schemas from the services of your other teams, including figuring out who’s responsible for maintaining that service. What if there is a way to leverage your REST investments while also benefiting from GraphQL?

Adopting GraphQL

GraphQL services aren’t tied to a specific programming language, as it relies on GraphQL Schema Definition Language (SDL). Therefore, microservices that want to support GraphQL can be built in any framework or library as long as they expose a GraphQL schema based on GraphQL SDL.

When your microservices are already exposing REST API endpoints, there’s a way to connect them through GraphQL SDL.

For example, with StepZen you can create GraphQL APIs with GraphQL SDL and deploy them directly in the cloud. Instead of building a GraphQL server into every microservice to expose a GraphQL schema, you can create these schemas directly in StepZen.

StepZen can connect every microservice exposing a REST or GraphQL API endpoint using pure GraphQL SDL. This service you create with StepZen becomes the service that combines all the schemas of your microservices architecture and becomes the entry point for all client requests.

Developer and Operational Productivity Gains

GraphQL in your microservices architecture serves multiple purposes. You save your organization time adopting GraphQL for every microservice. You also get a data layer (or API gateway) service that routes internal requests to all your microservices in a performant way.

See the article by my colleagues Dan and Anant - GraphQL Is Built for Federation, But Don’t Do It Wrong - for a great discussion about building a federated graph with GraphQL.