
Ask HN: Downside of exporting SDK per microservice and best practices - federicoponzi
Every microservice, exposes APIs. I&#x27;ve read somewhere that, it&#x27;s a bad practice to export an SDK to other microservices because it limits the independent deployability. But is it true? What are other downsides of this approach?
The problem is that, without the SDK, every microservice will need to request the same data, and validate it in some way - which is some boilerplate code which in general one would like to have automatically filled.
======
davismwfl
You don't share code between the services, services call each other. This mean
you will have some code that is duplicated between services, that's normal.

One microservice should never directly modify data another microservice
manges, each service should manage and maintain its own data source to keep
the responsibilities clear.

There are some other methods for certain common functionality, like using
sidecars etc. There are pros and cons of it all, just depends on the situation
and beliefs of the architect.

IME, most companies aren't ready for, nor do they need, a true full scale
microservices architecture. Instead a hybrid approach is more likely to be
successful, where certain key services are isolated but the rest of the app
can still be more of a monolith. The trick is identifying those key services
and separating them out. One I almost always separate as a start is
authentication/authorization, done properly it will keep that code very
focused, clean and more secure. Other likely candidates are any service that
might ingest large amounts of data but is focused, this will let you scale it
independently to support load and growth but not force you into a complete
microservices environment which can be daunting to manage at first.

