| Again, "10s of thousands" of lines of code is nothing. It's a few months work. 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. |
Thanks for telling me what I want :-) I also worked on statically typed monoliths (.Net)! I also worked on micro service systems (>70 services, 2 years of work) written in NodeJs.
It all has its pros and cons.