GraphQL and Microservices

Viewed 3485

At my company we've decided on a microservice architecture for a new project. We've taken a look at GraphQL and realised its potential and advantages for using as our single API endpoint.

What we disagree on is how the communication should be done between GraphQL and each micro service. Some argue for REST, others say we should also have a graphQL endpoint for each service.

I was wondering what are some of the pros and cons of each. For example, having everything in graphQL seems a bit redundant, as we'd be replicating parts of the schema in each service. On the other hand, we're using GraphQL to avoid some REST pitfalls. We're afraid having REST endpoints will nullify the advantages gained from gQL.

Has anyone come across a similar dilemma? None of us are experienced with GraphQL, so is there some obvious pro and con here that we might be missing?

Thanks in advance!

3 Answers

My company has been using GraphQL in production for about a year. Maintaining the schemas in our "Platform API" and also in our microservices became arduous. Developers kept asking us why they needed to do double work and what the benefit was. Especially since we required in-depth code reviews to change/update the production GraphQL schema

Apollo GraphQL released schema stitching which has solved most of the problems we were having. Essentially individual microservices each maintain their own GraphQL endpoint, then our Node.js Platform API stitches them all together. The resulting API is a client developer's dream, and the backend developers get the level of autonomy about their code they're used to. I highly recommend trying schema stitching. We've been adopting it incrementally for a few months and it's been wonderful.

As an added benefit, while defining our sub-schemas we started decoupling certain microservices, instead relying on the stitched data extensions to fill in holes in objects. Feels like the missing piece in DDD

You are asking about how to use GraphQL in a microservice architecture. One approach you are considering is that all microservices are GraphQL. The other approach is using GraphQL as the API gateway and REST for the backend data APIs.

In a recent evaluation which includes load tests of Node based data API microservices, I concluded that Express (REST) was more efficient than Apollo (GraphQL). It turns out that the general purpose parsing and executing of GraphQL queries can be relatively expensive when compared to JSON parsing with specific, hand coded API handlers. In light of that discovery, I would suggest keeping the data APIs RESTful.

Related