re: How to Breakthrough the Old Monolith Using the Strangler Pattern VIEW POST


I don't have much experience using microservices per se, but a more general software engineering background, so here's my two cents (also I prefer the term "facade" instead of "bouncer"):

  1. The job of the facade is to present a single interface to the outside world (in this case for compatibility), regardless of the inner workings. If you were to remove the facade and instead use your server config to glue everything together, wouldn't your server config become the facade? Now the question is: how would you like to manage your facade or interface? In the server config, or in the code next to (but largely independent from) the code of the other components? I'd say the latter.
  2. I'm not familiar enough with Kafka or RabbitMQ and what they do, but I can say this: if you're using it as a way to communicate between the facade and the individual components, then go ahead. If you want the individual components to communicate with each other as well, then beware of coupling. You might end up with individual components which communicate so much with each other over the bus, instead of through the facade, that they become/remain tightly coupled, and it's still hard to change one component. Remember: the aim of refactoring is that each component has a single responsibility with a single interface (although that might not be feasible within the constraints that you have)

I think this is roughly what Kyle also replied, but written a bit more verbose. I hope this helps :)


How would we send messages to other Micro services through the facade? I realise this isn't an implementation blog post but It's not really mentioned.

code of conduct - report abuse