How has GraphQL helped us move from a monolithic app to microservices?
--
Microservice-based architecture is very popular among software companies around the globe, as it is more scalable and reliable than the monolithic approach. It is also easier to maintain. For these reasons, we decided to move from the monolithic app to microservices, relying on GraphQL, which went open-source in 2015. GraphGL enabled us to solve several issues, like serving the whole API from a single endpoint, rather than dozens of endpoints and made the process much more efficient.
In this post, you will find out how GraphQL can help you make the transition from the monolithic approach to microservices. Let’s dive in.
What is GraphQL?
To start with, GraphQL is an open-source data query language and a server-side runtime for Application Programming Interfaces (APIs). It has been built to make APIs fast and flexible for developers, allowing them to create requests that pull data from multiple sources in a single API call.
Why use GraphQL?
GraphQL is a great choice as:
- It facilitates rapid application prototyping
- It enables you to fetch data from different sources with just a single API call
- It eliminates over and under-fetching issues
How does GraphQL help you make the transition from a monolithic app to microservices?
Let’s consider a hypothetical scenario where we had to work on a social media application and it had a RESTful API with a /users/<id> endpoint. By consuming it, we could get back a user object. From there, we could also get the name and the ID of the user’s best friend. Now, if we wanted to show the user with his best friend’s name in the user interface, we could consider different options.
One option would be to make two requests to /users/<id>. The first request would be with the user’s ID. The second one would be with his best friend’s ID. However, this process is not efficient — we would prefer to fetch this information using a single request.
The other option that we could consider is defining our API endpoints based on the UI interface. However, there would be an issue. Our ability to change the UI would be linked directly to our ability to change the API and it would result in several problems. For example, if we needed to show the profile picture of the user’s best friend to this view, we would be required to update our API to return it from the relevant endpoint. As a result, our team would have to put up extra time to implement the functionality and thus potentially slow down the application development process.
And this is exactly where GraphQL would come to play. GraphQL would enable the API to know how to retrieve a user for a given ID. It would also help the API to understand that the users could have specific names and best friends. Besides, the best friends would be in fact… users, so, it could retrieve a name for the best friend of a specific user and there wouldn’t be any problems with the UI. When the interface would change, the query would be updated to request the relevant data. However, in this case, it wouldn’t cause any change to the API.
While the approach sounds really good, there’s a conflict with the fundamental concept of microservices. Also, this way we would decouple the information that is shown in the user interface from the information that is exposed from the backend API. However, if all of them had defined their own APIs, it would not be possible for us to get all the data from a single endpoint.
Nevertheless, it is always crucial to make our microservices self-contained. Checking the name of a user’s best friend would be one of the key features of our application. In this case, our user’s service, which would contain all the code to retrieve the best friend’s name, would be used more than our email service. The email service would send notification to the users to inform them about the birthdays of their best friends and we would need more instances of our users’ service running than of our email service to ensure that no user got any dropped requests for the best friends’ name. It would seem quite impossible to achieve this if the two services are part of the same monolithic application, as we would not be able to access both of them with a single API.
GraphQL would enable us to make the transition by helping us to combine multiple schemas into one. We would manage to solve the issue with GraphQL’s remote schema stitching technology, which combines two separate schemas into one. The technology allows you to have two different services define their APIs in their respective directories and then combine and expose them together as a single API. In other words, the technology effectively enables developers to stitch data from multiple microservices.
The Implementation Process
The implementation process requires using two different Apollo npm packages. They are known as graphql-tools and apollo-link-http. You would also utilize node-fetch for communicating between servers.
There are 4 simple steps to follow:
1. First, import all required tools and libraries from graphql-tools:
2. Next, we introspect the remote schema. Use HttpLink to describe where to find a schema.
3. Then transform information about a remote schema into a schema. The graphql-server helps to expose it to the client application.
4. remoteSchema is transformed into a fully-fledged GraphQL schema. It is ready to receive requests. For each of the remote schemas or microservices, you have to repeat the second and third steps. Then you merge them into a single schema, called mergedSchema.
That’s how we’d combine multiple schemas into one and make the transition from the monolithic approach to microservices.
Wrapping Up
GraphQL enables us to serve the whole API from a single endpoint, rather than dozens of endpoints that were defined by a unique path. As a result, we have several advantages. We no longer have to worry about different team members using different naming conventions for different paths. Also, we don’t have to worry about making multiple requests just to get a single data set. Furthermore, it simplifies API management significantly.
That’s how our team worked on a similar project, combining multiple schemas into one and making the transition from the monolithic approach to microservices.
