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

See the article here, which says how and why approach #1 works better. Also look at the below image taken from the article I mentioned:

One of the main benefits of having everything behind a single endpoint is that data can be routed more effectively than if each request had its own service. While this is the often touted value of GraphQL, a reduction in complexity and service creep, the resultant data structure also allows data ownership to be extremely well defined, and clearly delineated.

Another benefit of adopting GraphQL is the fact that you can fundamentally assert greater control over the data loading process. Because the process for data loaders goes into its own endpoint, you can either honor the request partially, fully, or with caveats, and thereby control in an extremely granular way how data is transferred.

The following article explains these two benefits along with others very well: https://nordicapis.com/7-unique-benefits-of-using-graphql-in-microservices/

Answer 2

As of 2019 the best way is to write microservises that implements apollo gateway specification and then glue together these services using a gateway following approach #1. The fastest way to build the gateway is a docker image like this one Then use docker-compose to start all the services concurrently:

version: '3'

services:
    service1:
        build: service1
    service2:
        build: service2
    gateway:
        ports:
            - 80:80
        image: xmorse/apollo-federation-gateway
        environment: 
            - CACHE_MAX_AGE=5
            - "FORWARD_HEADERS=Authorization, X-Custom-Header" # default is Authorization, pass '' to reset
            - URL_0=http://service1
            - URL_1=http://service2

Answer 3

I have been working with GraphQL and microservices

Based on my experience what works for me is a combination of both approaches depending on the functionality/usage, I will never have a single gateway as in approach 1... but nether a graphql for each microservice as approach 2.

For example based on the image of the answer from Enayat, what I would do in this case is to have 3 graph gateways (Not 5 as in the image)

• App (Product, Basket, Shipping, Inventory, needed/linked to other services)

• Payment

• User

This way you need to put extra attention to the design of the needed/linked minimal data exposed from the depending services, like an auth token, userid, paymentid, payment status

In my experience for example, I have the "User" gateway, in that GraphQL I have the user queries/mutations, login, sign in, sign out, change password, recover email, confirm email, delete account, edit profile, upload picture, etc... this graph on it own is quite large!, it is separated because at the end the other services/gateways only cares about the resulting info like userid, name or token.

This way is easier to...

• Scale/shutdown the different gateways nodes depending on they usage. (for example people might not always be editing their profile or paying... but searching products might be used more frequently).

• Once a gateways matures, grows, usage is known or you have more expertise on the domain you can identify which are the part of the schema that could have they own gateway (... happened to me with a huge schema that interacts with git repositories, I separated the gateway that interact with a repository and I saw that the only input needed/linked info was... the folder path and expected branch)

• The history of you repositories is more clear and you can have a repository/developer/team dedicated to a gateway and its involved microservices.

UPDATE:

I have a kubernetes cluster online that is using the same approach that I describe here with all the backends using GraphQL, all opensource, here is the main repository: https://github.com/vicjicaman/microservice-realm

This is an update to my answer because I think that it is better if the answer/approach is backed up code that is running and can be consulted/reviewed, I hope that this helps.