When and How to use GraphQL with Microservice Architecture

Question

I\'m trying to understand where GraphQL is most suitable to use within a Microservice architecture.

There is some debate about having only 1 GraphQL schema that works as

Answer 1

As of mid 2019 the solution for the 1st Approach has now the name "Schema Federation" coined by the Apollo people (Previously this was often referred to as GraphQL stitching). They also propose the modules @apollo/federation and @apollo/gateway for this.

ADD: Please note that with Schema Federation you can't modify the schema at the gateway level. So for every bit you need in your schema, you need to have a separate service.

Answer 2

Definitely approach #1.

Having your clients talk to multiple GraphQL services (as in approach #2) entirely defeats the purpose of using GraphQL in the first place, which is to provide a schema over your entire application data to allow fetching it in a single roundtrip.

Having a shared nothing architecture might seem reasonable from the microservices perspective, but for your client-side code it is an absolute nightmare, because every time you change one of your microservices, you have to update all of your clients. You will definitely regret that.

GraphQL and microservices are a perfect fit, because GraphQL hides the fact that you have a microservice architecture from the clients. From a backend perspective, you want to split everything into microservices, but from a frontend perspective, you would like all your data to come from a single API. Using GraphQL is the best way I know of that lets you do both. It lets you split up your backend into microservices, while still providing a single API to all your application, and allowing joins across data from different services.

If you don't want to use REST for your microservices, you can of course have each of them have its own GraphQL API, but you should still have an API gateway. The reason people use API gateways is to make it more manageable to call microservices from client applications, not because it fits well into the microservices pattern.

Answer 3

We also had similar concerns on the bootstraping a Microservices ecosystem with graphql. And we are able to solve it with Apollo GraphQL.

We built these solutions from scratch for our One Platform. Folders ending with service are microservices others are SPAs aka (Single Page Applications)

This consists of various microservices and spas with an API Gateway which is the primary interface for multiple microservices.

Along with this you can find a OP CLI generator which can help to bootstrap a microservice from scratch.

Project - https://github.com/1-Platform/one-platform

I request to please have a look on this project and feel free to adopt if this looks good to you.

Regards

Rigin Oommen

Answer 4

The way it is being described in this question, I believe that using a custom API gateway as an orchestration service can make a lot of sense for complex enterprise focused applications. GraphQL can be a good technology choice for that orchestration service, at least as far as querying goes. The advantage to your first approach (one schema for all microservices) is the ability to stitch together the data from multiple microservices in a single request. That may, or may not, be very important depending on your situation. If the GUI calls for rendering data from multiple microservices all at once, then this approach can simplify the client code such that a single call can return data that is suitable for data binding with the GUI elements of such frameworks as Angular or React. This advantage doesn't apply for mutations.

The disadvantage is tight coupling between the data APIs and the orchestration service. Releases can no longer be atomic. If you refrain from introducing backwards breaking changes in your data APIs, then this can introduce complexity only when rolling back a release. For example, if you are about to release new versions of two data APIs with the corresponding changes in the orchestration service and you need to roll one of those releases back but not the other, then you will be forced to roll back all three anyway.

In this comparison of GraphQL vs REST you will find that GraphQL is not quite as efficient as RESTful APIs so I would not recommend replacing REST with GraphQL for the data APIs.

Answer 5

For approach #2, in fact that's the way I choose, because it's much easier than maintaining the annoying API gateway manually. With this way you can develop your services independently. Make life much easier :P

There are some great tools to combine schemas into one, e.g. graphql-weaver and apollo's graphql-tools, I'm using graphql-weaver, it's easy to use and works great.

Answer 6

To question 1, Intuit acknowledged the power of GraphQL few years back when it announced moving to One Intuit API ecosystem (https://www.slideshare.net/IntuitDeveloper/building-the-next-generation-of-quickbooks-app-integrations-quickbooks-connect-2017). Intuit chose to go with approach 1. The drawback that you mention actually prevents developers from introducing breaking schema changes that could potentially disrupt client applications.

GraphQL has helped improve productivity of developers in a number of ways.

1. When designing a new microservice for a domain, engineers (backend/ frontend/ stakeholders) agree on a schema for the domain entities. Once the schema is approved, it is merged with the master domain schema (universal) and deployed on the Gateway.Front end engineers can start coding client applications with this schema while backend engineers implement the functionality. Having one universal schema means that there are no two microservices with redundant functionality.

2. GraphQL has helped client applications become simpler and faster. Want to retrieve data from /update data to multiple microservices? All client applications have to do is fire ONE GraphQL request and the API Gateway abstraction layer will take care to fetch and collate data from multiple sources (microservices). Open source frameworks like Apollo (https://www.apollographql.com/) have accelerated the pace of GraphQL adoption.

3. With mobile being the first choice for modern applications, it is important to design for lower data bandwidth requirements from ground zero. GraphQL helps by allowing client apps to request for specific fields only.

To question 2: We built a custom abstraction layer at the API Gateway that knows which part of the schema is owned by which service (provider). When a query request arrives, the abstraction layer forwards the request to the appropriate service(s). Once the underlying service returns the response, the abstraction layer is responsible to return the requested fields.

However, today there are several platforms out there (Apollo server, graphql-yoga, etc.) that allow one to build a GraphQL abstraction layer in no time.