Using GraphQL in a microservice oriented architecture
This is the fourth blog post in the series of GraphQL in which we discuss some of the design patterns of GraphQL, and how do we leverage the concept of GraphQL with respect to a microservice oriented architecture.
In the last blog post we covered how GraphQL schemas are designed and implemented and how the data hierarchy can be optimized to minimize the number of API calls.
So when we speak of GraphQL, one of its benefits has been to fetch data from multiple data sources , combining what would be multiple API calls into one , and then presenting the data to the client, now when we speak of a microservice oriented architecture we are talking about separation of concern and logic in a modular approach, these being to opposite idea in need of merging.
Enter GraphQL Stitching
In a micro services architecture, each micro services has a unique endpoint and routing rules. This approach requires the front end development team to define multiple Apollo clients to consume the different endpoints or configure complex routing rules. By enabling schema stitching,one can merge the schemas from the various micro services that represent the composite view of all of the backing GraphQL APIs and thus simplifying our client programming model. The result being a single GraphQL endpoint to program against. In addition, this allows our client side program model to really embrace GraphQL and batch queries that spanned multiple services which in the previous architecture was not possible.
Now lets explore some of the design patterns that can be used around GraphQL in backend.
- Composite Pattern : Use when you want to aggregate data from multiple places into one convenient API.
- Proxy Pattern : Use when you want to add functionality to an old api. Example Use Case: Say you have an old public API, you want to add authentication to it. Firewall off the old one, whitelist your GraphQL server, add authentication to the GraphQL server.
- Facade pattern: Use when you want to simplify a complex api. The difference between a proxy and a facade is simple. Proxies — represents the original, perhaps add some functionality like authentication. Facade — simplifies the original.
Moving onto the some of the best practices around GraphQL ,
- Lean Data Models For Simple Queries And Mutations
- Nested Objects To Reduce Network Calls
- Enabling Proper Error Handling
Conclusion
So in this blog we discussed on some of the key challenges and approach on using GraphQL in a microservice oriented environment, this was a brief overview on some of the design patterns and solutions around using Micro-services with GraphQL , we will be building a GraphQL implementation of the same.
