Large graphQL servers are the new monlith. As we linked more and more services to our data graphql, over 40 services, the codebase becomes large and hard to manage. Also the blast impact of this system can be massive, with poor isolation between systems.

Data pockets

We have lots of micro services managed by different teams. Calling all this services directly from frontend applications creates complexity and lots of data service contracts to manage. GraphQL helped to ease these issues but created new problems.

A new bottleneck on communication and change management. Federated GQL can be a solution. This allows the schemas to be defined and owned by the micro-services. They can also extend other parts of the schema allowing the clients to join and use services as if it was a single data graph.

The single schema is accessed from a gateway. The gateway uses schemas and services defined in a registry. The gateway parses the query and calls the correct services, then joins the responses to send to the client.

Schema management

As services define parts of the schema, they interact with the registry to validate the schema changes. These can be versioned and tested in different environments before moving to production. It is important to monitor field usage from clients to ensure schema changes can be validated to reduce the risk of breaking changes.

Conclusions

As with a single graphQL service, being able to access data from seperate services without over-fetching data is very powerful. It has enabled teams to move quickly. It can be easy to see which clients use which fields in the schema.

The code base is now distributed across many services and a workflow is important to ensure the schema is valid and clients don’t fail as fields are added and removed.

Follow me on twitter @andyianriley
or see andyianriley @ linkedin.