6

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.

Stephen Kennedy
  • 20,585
  • 22
  • 95
  • 108
hmojica
  • 603
  • 8
  • 11
  • 1
    Because conceptually, each of the micro services represents a domain, and sharing types between domains is generally not good design. What if in one domain the type changes? That's not supposed to influence the others. – daniu May 17 '18 at 21:04
  • it's called service versioning. on one side someone may ask `what if in one domain the type changes` but the services need to talk each other or with the client. so imho it's ok to have a common domain client/library, but keep in mind its version and interoperability – gusto2 May 17 '18 at 21:12
  • 1
    You should not be copying code. – Derrops May 17 '18 at 23:53
  • The question is not opinion-based, but is a possible duplicate of https://stackoverflow.com/questions/48961000/why-shared-libraries-between-microservices-are-bad – Michael Freidgeim May 14 '20 at 03:45

3 Answers3

13

I would say "they" are wrong and you are right. There are several issues with copy and pasting client code:

  • If there is a bug in your client code, you will have to fix the bug in 15 places instead of just 1.
  • It slows things down. You now have to test and maintain multiple copies of the same code.
  • It is common practice to create client libraries and distribute them via a standard dependency manager like maven. Amazon does this https://github.com/aws/aws-sdk-java along with virtually everyone else.

In summary, you are right and Amazon is the strongest example supporting your opinion. They do exactly what you are suggesting for their web services, and they are arguably the largest most powerful player in the microservices space.

Also to address the concern of tight coupling in the other answer. Good apis are backward compatible, so a change to the api would not require upgrading all the clients even if they use the same client library.

ilooner
  • 2,480
  • 15
  • 32
  • 2
    I totally agree with your comment. I also create client many library to share between microservices in my project. The most important is the Backward compatible, when u upgrade new version it only affects to some services not all, others will call old api. – Barcelona May 10 '19 at 03:11
  • We have some convention in creating lib to share between services. For example: no database entities, no repositories...Use abstraction classes and let the services implement it in their way. – Barcelona May 10 '19 at 03:14
  • I agree with you as well. The coupling will exist, whether it's explicit or not. If you introduce a non-backward compatible change to your API, it's gonna break its clients anyway. But I believe that the client library should be just a convenience, and not the only way to consume the API. – Jefferson Lima Mar 10 '21 at 18:02
  • 2
    You are both ignoring the tolerant reader principle. Using REST over RPC gives us the potential advantage of less coupling. We can ignore fields we do not need in the client, we can talk over JSON in order to be language-agnostic, we can even avoid URL coupling with hypermedia. What you assume is that any REST API is supposed to be consumed as if it were pure RPC, with binary coupling of method signatures. You basically undo the benefits of REST. The whole point of microservices is lower coupling, so Sam Newman is right. You should avoid coupling, and especially the binary kind. – Andreas Evers Jul 26 '21 at 08:43
8

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/

Always Learning
  • 2,623
  • 3
  • 20
  • 39
  • The key point is “ downsides of using shared code that ends up **coupling services**”. If your shared code doesn’t **couple** services, it seems ok to keep it in shared library. – Michael Freidgeim May 13 '20 at 13:51
2

I agree with the statements about coupling. I'm forced to use a specific set of Maven dependencies in a reuse scenario, and no one is allowed to update them. The result is that creating new services gets harder because the frameworks are out of date, and so is the documentation.

On the other hand, code reuse can save a lot of time and money, especially boilerplate code used in services, if it is well constructed and has proper tests.

I think there is a middle ground here that involves versioning and a certain amount of routine maintenance.

Steve11235
  • 2,849
  • 1
  • 17
  • 18