Search code examples
javaspringmicroservices

In the microservices architecture, why they say is bad to share REST Client libraries?


We have 15 services build with Java Spring, they talk each other using REST .

Each time we add a new service to the pool we create from scratch all the code, including rest client code that will talk to other Services and the POJO classes used to map the resource(s) being requested.

We end up copy and pasting from the source code of other services into the new service.

I think it would be better to put all these POJO's and rest client code into a library for all the services to consume it, it would save us a lot of work coding, but "they" say we should not do that with microservices.

So, why is that? We end up copy and pasting the exactly same code over and over again, I don't see the difference.


Solution

  • The main issue is coupling. Sam Newman, author of Building Microservices puts it well:

    In general, I dislike code reuse across services, as it can easily become a source of coupling. Having a shared library for serialisation and de-serialisation of domain objects is a classic example of where the driver to code reuse can be a problem. What happens when you add a field to a domain entity? Do you have to ask all your clients to upgrade the version of the shared library they have? If you do, you loose independent deployability, the most important principle of microservices (IMHO).

    Code duplication does have some obvious downsides. But I think those downsides are better than the downsides of using shared code that ends up coupling services. If using shared libraries, be careful to monitor their use, and if you are unsure on whether or not they are a good idea, I'd strongly suggest you lean towards code duplication between services instead.

    https://samnewman.io/blog/2015/06/22/answering-questions-from-devoxx-on-microservices/