English | EN 
As I sat down to write about GraphQL and microservices, my mind raced with the possibilities.
Though I have heard of GraphQL for some time now, I have only recently begun to really explore it.
Note: Facebook (now Meta) started GraphQL development in 2012 and released it in 2015. GraphQL was moved on 7 November 2018 to the newly established GraphQL Foundation, hosted by the non-profit Linux Foundation. On 9 February 2018, the GraphQL Schema Definition Language (SDL) became part of the specification
GraphQL. (2023, April 16). In Wikipedia. Retrieved April 22, 2023, from https://en.wikipedia.org/wiki/GraphQL
Up until this point, most of my experience had been with RESTful services (i.e., Representational State Transfer Services). REST-based services have been around for a long time and are arguably the most common way of communicating between microservices. With a REST-based approach, each microservice has its own API endpoint, and requests and responses are sent over HTTP. This approach has several advantages, including simplicity, scalability, ease of extensibility and the ability to cache responses. However, it can also result in a lot of chatty communication and redundant data being transmitted, which can sometimes slow down an application.
Recently I have had the opportunity to implement and test GraphQL solutions for a client, to address several business use cases that involved the retrieval of data to help drive business decisions. In the past, I may have built a microservices solution or series of REST-based services to serve up this business data to a report or consuming application. The consuming application may have called several services or implemented a workflow, to derive the desired output. However, in this case, the requirement was to explore the benefit of GraphQL based APIs.
In my journey to explore the benefit of GraphQL, I had the opportunity to implement solutions in both AWS AppSync and Apollo GraphQL Server (Lambda).
During the journey, I was able to consult with a few experts that have implemented one or more of these solutions for various clients. Learning from each of these experts and through my own exploration, sparked my curiosity of how GraphQL might play a significant role in a solution based on a microservices architecture.
In a microservices architecture, services are designed to be small, independent, and focused on a specific task or business capability.
GraphQL, on the other hand, provides a single API endpoint that can be used to query and mutate data across multiple microservices. This approach allows the client to specify exactly what data it needs, reducing the amount of redundant data being transmitted and improving the efficiency of an application or solution.
GraphQL and REST are two different approaches to building services and APIs, and each has its own strengths and weaknesses. Here are some common reasons why GraphQL may be considered better than REST-based services in certain situations:
- GraphQL exposes several services via a single endpoint
- GraphQL is a query language and runtime for APIs
- GraphQL provides a flexible and efficient way to query data from multiple services, reducing the amount of workflow required between services
- GraphQL clients can specify exactly what data they need, reducing the amount of unnecessary data returned in a response and thus improve performance.
- GraphQL can be more efficient data retrieval
- GraphQL uses a strongly typed schema to define the API
- GraphQL provides more flexibility and control to clients, while reducing the complexity and overhead of consumption
- GraphQL by nature can be less chatty then REST based services, which can result in over-fetching of data
- GraphQL offers flexible options for versioning services
- Pipeline Resolvers (i.e., Composable Functions) is a great feature for when on service output is required as input into another service. With GraphQL it can easily be part of the same request.
So, which approach is better for a microservices architecture? The truth is that it depends on the specific needs of the solution. REST-based services are well-established and have proven to be effective for many different applications. However, if the solution requires a more efficient and flexible way of communicating between microservices, then GraphQL may be the better fit.
Overall, GraphQL may not be the best approach in all cases. However, it can certainly be a valuable tool for implementing a solution based on a microservices architecture, by providing a flexible and efficient way to query and manipulate data from multiple services.
