Hey @joeblew99. Do you mean other microservices communicating with watermill-based applications? If so, it shouldn't be an issue, as the messages are not any special when consumed/produced by watermill (except metadata). You can use any other library to produce messages that will be consumed by watermill and the other way around.

Can you think of some example of this?

I hope that examples should be much better now. If something is not clear, please ask :)

https://github.com/ThreeDotsLabs/watermill/tree/master/_examples

@m110

Hey @joeblew99. Do you mean other microservices communicating with watermill-based applications? If so, it shouldn't be an issue, as the messages are not any special when consumed/produced by watermill (except metadata). You can use any other library to produce messages that will be consumed by watermill and the other way around.

Yes, for example if you code in python or whatever. I was thinking about the idea of using protobufs for all API aspects. Then the transport is independent and so can be used in various ways by developers using different languages.
Of course you could just use grpc gateway and default to a Rest like approach but it can to limiting.

Can you think of some example of this?

Example.
A team and they are building a large system that is composed of many microservices.
The Ml team want to use python.
The CRM team want to use Nodejs.
But as an architect you want a unified SQL and Messaging system that they all use.
And you want those 2 points to do metrics, tracing, etc, so that you have a centralised system for that.

@joeblew99 is the title better now?

@roblaszczak yes thanks :)