Federated GraphQL & Apollo Federation with microservices

The first principle of GraphQL Principles Is “One Graph” – the rule that encourages the implementation of a single graph to maximize the value of GraphQL. This is immediately accompanied by a “federation implementation”.

“Although there is only one graph, the application of this graph needs to be consolidated across multiple teams.”

Using Apollo Federation, we are able to create a graphical platform-powered architecture. This is a single supergraph consisting of a collection of sub-graphs made using some GraphQL guidelines and some interesting libraries. It looks very promising. But first … let’s take a step back and go back to those days when all the components of the supergraph were part of one massive entity.

The monolith

do not get me wrong. I’m not going to declare that the monolithic approach is the source of all evil in the world. I do not believe that every monolith application is built without a well thought out approach and that micro services are a silver bullet for any problem you encounter.

If we can not build a clean code base with monolithic applications, micro services will certainly not solve our problems. Besides, introducing micro services to this type of application will only lead to more chaos and despair.

The rule of a single data graph is quite easy to implement in a monolithic approach. The most important function of a rear key is to please the front end key. And what can make them happier than access to everything they need, and exactly what they need with the help of one query?

Monolith has its place in nature. However, it comes with some limitations. With the growth of the app, this approach just isn’t good enough, and most of all (crucial), it’s not something the cool kid wants to hear about. This brings us to the world of micro-services. Modularity is the key.

Micro services

Each micro-service is a well-designed machine that reveals a set of special endpoints. One way to deal with them would be direct communication between a customer and a micro-service. The customer app will talk to endpoints exposed to the public by micro services. Again, similar to monolithic architecture, this may be fine for some small applications. However, when we grow up, it is not good enough. This brings us to the Gateway API pattern.

The Gateway API

In this approach, micro services are not directly exposed to the customer application. An additional level of indirect swimming is displayed between the client and the API.

With the use of API Gateway printing, we can simplify the client. Now the place responsible for calling a number of services will move from customer to gate. It will also reduce the number of customers back and forth. This is also where you might view user authentication. With this knowledge, we will be able to move smoothly to the Apollo Federation.

Supergraph and sub-graphs

The Apollo Federation has adopted the Gateway API pattern. One graph, a supergraph, consists of sub-graphs. Each service is responsible for creating a sub-graph and the integrated supergraph is exposed by the API Gateway. The Gateway API serves as a single entry point for client applications.

Let’s take a closer look at what a sample application might look like. This would be a fairly simple example with three services, and only a few lines of code in pure JavaScript (in a node environment, of course).

Post service:

Comments service

… and last but not least: API Gateway.

Apollo provides us with some useful libraries. @ apollo / federation Allows us to create unified graphs and sub-graphs that allow us to construct a sub-graph scheme as shown in the example in the code. @ apollo / gateway Is the package Which brings ApolloGateway to the place. Finally, the Apollo also provides a useful CLI tool, migratory, Which is useful for managing graphs.

Core concepts

It all revolves around three main concepts:

• Entities,
• Expanding entities,
• Reference solutions.

What is an entity one may ask? Here is a simple example:

The only difference with standard GraphQL is @key teaching. With this, we can uniquely identify our being. The owner of this entity is a Post service. It would not have been particularly interesting if it was the only thing we could do with the entity. It can be expanded by other services. In our case, Comments service Expands the Post entity by adding the keyword extend And marking an external field with the @external teaching.

The last part of the puzzle are Reference solutions, That every entity needs. It will help us … resolve the entity.

The Gateway API

Two services alone are useless to us. As mentioned earlier, we are not allowed to communicate with them directly. We need an API gateway. The sample code is short and clear. The only part that needs to be explained is List service array. In our scenario, we define a list of services by name, followed by the URL where they are available. Under the hood, the Apollo Gate will produce a super-graph based on sub-graphs extracted from toilets.

What does everything look like from the customer’s point of view? We perform two queries using Apollo Playground and bring up the list of all posts.

The first query only includes the posts service:

The response contains only data from this service:

We can see that the data was indeed only brought from the posts service:

We are now adding a note section to our query:

Comment sections are only available with a comment service. However, from the customer’s point of view, it is completely irrelevant. The query is simple and all the requested data is there.

When we look closely, we can see that there were two requests that the Apollo Gate be sung. One for the posts service and another for the comments service.

God List service Very useful for local development or prototype creation. However, it may not be suitable for production (and may be removed in future releases). We need a central listing that allows us to track our consent. One solution might be use ApolloStudio.

If we look at the code, it looks like the services are running on:

Post Service – http: // localhost: 5001.

Comments service – http: // localhost: 5002.

To simplify things, we will look at supraps with the use of rover cli and publish it in Apollo Studio.

where Need to replace your graph ID and By your API developer from Apollo Studio.

If we want to use graphs from the listing instead of providing a serviceList Array, the ApolloGateway class must be run without any arguments. Furthermore, two environmental variables must be provided.

Apollo Federation – Summary

The Apollo Federation allows us to build distributed systems in a clean and declarative approach using GraphQL. This is a nice piece of technology worth trying. Through Apollo, we get a lot of interesting tools that are fun to work with. The Rover CLI can be combined with CI / CD and we can provide our own central registration solution. Indeed, Apollo gives us a Full specifications.

With that, you have a lot of reasons to try it and everything you need to make an informed choice about it!