|
|
|
|
|
|
by mpfundstein
3025 days ago
|
|
|
To quote myself regarding micro-services: "I REALLY REALLY REALLY like that micro-services make your boundaries explicit and enforce you to write contractual APIs aka Interfaces. Much more than all the promises of scalability etc." With huge applications, I mean 10s of thousands of lines of code with features added on a daily basis by multiple developers. What both have in common is that they started us as seemingly small 'throwaway tools' but grew into business scale applications that serve now a core purpose. Btw, who said I didn't use MySQL and PHP ? :D |
|
|
Introducing microservices into a small code base feels like it would be counter-productive. It adds a ton of unnecessary complexity to a tiny code base.
You don't want contractual APIs for code like that, as it grows the contracts are going to be constantly breaking as new features are added and the only people who care are the other, internal, developers.
If you used a statically typed language, in a monolith it would tell you immediately that it had happened as soon as you did your sync (which should be happening multiple times a day for everyone). Better still, the other developer would have had to deal with it, the only code you'd need to worry about is the new code you added, and again, your check in would break the build.
Code how you want, but my mind boggles at people doing microservices for tiny code bases. Much better to have a monolith until you get into the million of lines.
I am just thankful I work on statically typed monoliths where my tools just deal with it and I don't have to spend time setting up and debugging microservices instead of doing actual work.