Search code examples
javajmsmicroservices

JMS/REST clients as a centralized library vs one per microservice?


Why does the microservices architecture mindset see benefit in duplicating all REST/JMS clients so each service has its independent code?

Does the trade-off really work out - given the comfortability and maintainability of a single library/adapter towards a server-spec so everybody uses it as an abstraction?

What are the the benefits in practice?


Solution

  • As this is on the brisk of asking for opinion, let's answer about the facts at hand.

    The core thing to understand: any concept should never be seen as unalterable law. You don't follow rules because they are rules, but because they provide helpful guidance regarding your design decisions.

    In that sense this is about balancing. When you can really abstract common infrastructure elements, then it is good practice to avoid code duplication where possible.

    So instead of creating more and more copies of the same class, you rather turn that into an "internal library" and have your service instances use that. The downside here is of course that all services using this library now have a dependency on it.

    Coming from there, you would strive to really provide a framework. Meaning: base, common parts are implemented only once - but in a fashion that allows the different services to configure/extend/enhance the framework where necessary.