While microservices are a useful construct, architecture patterns follow Conway's Law. Microservices pattern is no different. My sense is that, in your case, if you are the only full-time dev and are working with other folks (remotely, part-time, or on contract basis), microservices work better for you because of Conway's Law :D
It's useful to break down any application into smaller services that communicate with each other. But the management & communication overhead of each microservice starts to take over at an exponential rate. That's why, personally, I've always felt that monoliths with a good structuring of packages, libraries etc work better. Then, I'm only working on a single code-base which is easier to run & test locally without other dependencies involved.
Re-usable components for multiple clients could be published as libraries/npm packages. That way, you don't have to run it as a separate service communicating over TCP.
Agree on the fact that the management & communication overhead. There is a lot more to think about in terms of interactions between things, but I find it makes you much more conscious of the changes that are made to any service.
I also find it forces me into being more TDD. If I know a data model in API A is relied on by a Worker B then I'll write a test to ensure the correct properties are always returned.
Interesting point on the monolith with good package structuring though. Never really thought about that. It's almost strongly typed 'microservices' all running in the same executable.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks James! Glad you enjoy the articles.
While microservices are a useful construct, architecture patterns follow Conway's Law. Microservices pattern is no different. My sense is that, in your case, if you are the only full-time dev and are working with other folks (remotely, part-time, or on contract basis), microservices work better for you because of Conway's Law :D
It's useful to break down any application into smaller services that communicate with each other. But the management & communication overhead of each microservice starts to take over at an exponential rate. That's why, personally, I've always felt that monoliths with a good structuring of packages, libraries etc work better. Then, I'm only working on a single code-base which is easier to run & test locally without other dependencies involved.
Re-usable components for multiple clients could be published as libraries/npm packages. That way, you don't have to run it as a separate service communicating over TCP.
Agree on the fact that the management & communication overhead. There is a lot more to think about in terms of interactions between things, but I find it makes you much more conscious of the changes that are made to any service.
I also find it forces me into being more TDD. If I know a data model in API A is relied on by a Worker B then I'll write a test to ensure the correct properties are always returned.
Interesting point on the monolith with good package structuring though. Never really thought about that. It's almost strongly typed 'microservices' all running in the same executable.