I was wondering something about messaging in micro...

# random

[Albert]

I was wondering something about messaging in microservices. What I see a lot on the internet when setting up microservices that use messaging through a message broker you will find a lot of articles/talks about using a solution like Kafka or RabbitMQ. In these articles if you have tens or hundreds of microservices they all need to implement a driver to communicate with that message broker.
So the idea that I am playing with is to create a messaging service which internally could use something like Kafka or RabbitMQ. Also good to mention that the application I am working with doesn't require 100k+ message second. Creating a messaging service I see at least the following benefits:
- Could create formats/flows which is more feasible for teams
- Could create a protocol based on websocket which makes it easier to implement for services
- Easier to switch to a different message broker
- Could implement utilities, which could help teams
I have only seen a couple of articles which describes this kind of approach. So my question is, why are most examples of services directly talking to the message broker? In those examples it would probably be a nightmare to switch to a different broker.

[aarjav]

In my projects, the underlying message broker or even db is usually abstracted away from the application logic. So it would really be the dependency that I replace (for the most part). But if you're fine with something more invasive then you may want to look at https://vertx.io/ as well. It's not like creating your own message broker but it can make use of Kafka or rabbitmq

[Albert]

Thanks @aarjav. We also abstracting database and brokers in the application. vert.x would be a great option to build this in. Also we try not to replace the brokers themselves, but utilize them better for the needs of other developers. Because I am not reading a lot of those kind approach I wondered if this is a wrong approach (altough I think it is safe to test, because of the abstraction in the applications itself).

[Gerard Klijs]

Switching from message broker while already in production will be PITA anyway. But for a client we build a kind of wrapper around the java client, which theoretically could be used also with something else then Kafka. Also as a pet project I made a GraphQL endpoint based on Kafka in/output, witch used other micro-services to handle the messages.