
Ask HN: Is GraphQL suitable for communication between microservices? - F21Global
I am looking to implement an app following the principles of domain driven design using microservices. In this situation, I plan to have each bounded context in my domain to be a microservice. I think this is a good size for each microservice for now and leaves the option to break them down into smaller services if needed in the future.<p>In terms of talking to the client(s), I plan to have a GraphQL API gateway sitting in front of these microservices.<p>I am also planning to have synchronous communication between the microservices as they are easier to reason about and test and if needed, some of them could be turned into async endpoints in the future.<p>Regarding communication between microservices, there are currently a few different flavors, for example:
- REST
- GRPC
- Thrift<p>I&#x27;ve experience with GRPC and REST and personally prefer GRPC. Using protobufs in GRPC makes renaming fields and adding new fields much more easier and reduces the risk of breaking clients.<p>After looking into GraphQL, I wonder if GraphQL might be useful for implementing communication between microservices. For example, it is also possible to use GraphQL over GRPC by using a JSON codec and having the GRPC be equivalent to the &#x2F;graphql endpoint. In this case, you&#x27;d get the benefits of grpc middlewares, tracing, retrys and backoffs.<p>If using GraphQL on GRPC, I think the only benefit of GraphQL over protobuf GRPC is the ability to select only the fields we need and select nested&#x2F;graph data when reading from a microservice.<p>Have any of you considered or implemented using GraphQL for communication between microservices? How did it go? Would you recommend it?
======
djsumdog
I don't have experience with GraphQL or other graphing APIs but I do have
experience with micro services written in Scala using a RabbitMQ backend and
running in Docker containers on DC/OS (mesos).

We were experimenting with some other tools back on that projects and were
looking at migration paths. If you're starting from zero, I'd recommend
looking at Kafka. It's a true pub/sub model and you can use it easily to
communicate with various services.

RabbitMQ is good for things that are unreliable and you don't care about data
loss. We did care a lot about data loss and had to deal witreliable transfers
(like SMS/text messages) there are better solutions like ZeroMQ. Avoid RMQ if
you can is what I'm saying.

I'd personally recommend a backend like Kafka and writing your services in a
language you like and are comfortable with. Write strong, solid test cases.
With good unit tests and integration tests, language choices become less of an
issue.

Also take a look at event-source for persistence. You can use regular old
relational databases if you have an event sourcing micro service you rely on
to persist information.

