Does it make sense to use GraphQL for microservices intercommunication?

Question

I've read a lot on using GraphQL as API gateway for the front-end in front of the micro-services. But I wonder if all the GraphQL advantages over Rest aren't relevant to communication between the micro-services as well. Any inputs, pros/cons and successful usage examples will be appreciated.

Answer 1

Key notes to consider:

• GraphQL isn't a magic bullet, nor is it "better" than REST. It is just different.
• You can definitely use both at the same time, so it is not either/or.
• Per specific use, GraphQL (or REST) can be anywhere on the scale of great to horrible.
• GraphQL and REST aren't exact substitutes:
  • GraphQL is a query language, specification, and collection of tools, designed to operate over a single endpoint via HTTP, optimizing for performance and flexibility.
  • REST is an Architectural Style / approach for general communication utilizing the uniform interface of the protocols it exists in.

Some reasons for avoiding a common use of GraphQL between microservices:

• GraphQL is mainly useful when the client need a flexible response it can control without making changes to the server's code.

  • When you grant the client service control over the data that comes in, it can lead to exposing too much data, hence compromising Encapsulation on the serving service. This is a long-term risk on System maintainability and ability to change.

• Between microservices, latency is far less an issue than between client-server, so goes for the aggregation capabilities.

• Uniform interface is really useful when you have many services - but graphQL may be counter-productive for that cause.

• The flexible queries defined by QueryQL can be more challenging in terms of performance optimizing it.

• Updating an hierarchy of object at once (graphQL natural structure) may add complexities in atomicity, idempotency, error reporting, etc.

To recap:

• GraphQL can be really great for server to server communication, but most likely it would be a good fit in a small percentage of the use-cases.
• Do you have a use-case for an API Gateway between services? Maybe this is the question you should ask yourself. GraphQL is just a (popular) tool.
• Like always, it is best to match a problem to a tool.

Answer 2

I don't have experience with using GraphQL in a microservices environment but I'm inclined to think that its not the greatest for microservices.

To add a little more color to @Lior Bar-On's answer, GraphQL is more of a query language and is more dynamic in nature. It is often used to aggregate data sets as a result of a single request which in turn will potentially require many requests being made to many services in a microservice environment. At the same time, it also adds complexity to have to translate the gathering of information from respective sources of the information (other microservices). Of course, how complex would depend on how micro your services are and what queries you may look to support.

On the other hand, I think a monolith that uses an MVC architecture may actually have an upper hand because it owns a larger body of a data that it can query.