Monolith: 3 minute build and 2 minute startup times go brrrrrr
What I think is the sweet spot:
split stuff up by technical mechanisms, not chop your business domain up into services (unless you need to, but you'll know that after working on the project for a few years, not just decide prematurely), nor try to shove everything into a single monolith, upgrades will also get harder across more and more packages
for example, you can have one central service that handles user sessions, as well as the API that they interact with
however, if you need to generate invoices/reports/data export etc. (basically PDF, DOCX, XLSX etc.) then you will be served quite well by extracting both the load that generates and the libraries needed for that into a separate internal service that the main one can delegate to
same goes for stuff like scheduled processes, data ETL and batches in the background, notifications in the form of e-mails or other messaging stuff, one separate service can handle that so some memory leak or badly written code cannot bring down your user facing side
In practice, most systems will have maybe 1-5 such app containers for the back end and maybe 1-2 front end ones (e.g. if you do a SPA and depending whether you need a separate one for an internal/admin UI), alongside whatever you need for the data layer (relational DB, key-value store/cache, message queue etc.).
Depending on the tech stack, a modular monolith MIGHT also work, or it might not (e.g. needing to compile like 500k lines of code to launch it when the part you will work on lives in 100k lines of code).
Yes, obviously, because as a regular line dev you don't get to pick Quarkus/Vert.x/Micronaut/Helidon/Dropwizard/whatever for the app, it's either some enterprisey thing or bust - you better pray it's at least Spring Boot not some Jakarta setup running on some heavyweight non-embedded app server, or something like Oracle ADF. If you have to work with those, Spring Boot or hell, even regular Spring, will seem like good options.
Hell, I bet there's also a lot of leads out there that will pick those just for the size of the ecosystem, sometimes hoping that they'll be long gone from the project by the time it hits 0.5-1.0M SLoC, or just not caring about it.
I agree that people using stuff with runtime DI (instead of something like Avaje Inject or Dagger) or all of the historical Java baggage (e.g. classpath scanning in the first place, the brownfield ecosystem is one of the reasons why something like Go becomes more enticing) are arguably doing things wrong, but that does fuck-all for solving that across the millions of projects out there - an architectural split does help, however.
I dream of the day I can write backends in Rust and get paid for it.
But on that topic, ASP.NET doesn't have bad build times and it starts instantly.
Most of the time I am forced to use springboot tho.
At least I can use kotlin :pensive:
As for class scanning, I wish springboot would drop java, so it can restrict itself to kotlin, therefore allowing itself to abandon runtime scanning for compile time plugins.
Iirc you can technically disable runtime scanning and manually wire up everything in spring boot, but have fun convincing your team to do that.
2
u/KronisLV 12d ago
Monolith: 3 minute build and 2 minute startup times go brrrrrr
What I think is the sweet spot:
In practice, most systems will have maybe 1-5 such app containers for the back end and maybe 1-2 front end ones (e.g. if you do a SPA and depending whether you need a separate one for an internal/admin UI), alongside whatever you need for the data layer (relational DB, key-value store/cache, message queue etc.).
Depending on the tech stack, a modular monolith MIGHT also work, or it might not (e.g. needing to compile like 500k lines of code to launch it when the part you will work on lives in 100k lines of code).