[ekropotin]

I’ve Been stuck with Spring for many years too and I think it’s just awful choice for micro services that need to scale, simply due to startup time.

Not to defend Nodejs ecosystem - your points are 100% valid.

With that in mind, I think Go is much better option.

[ivan_gammel]

Spring may be a bad choice for microservices (context required, because it is not true in general), but it is strange to compare it (DI framework/mvc/orm abstraction etc) with Go (programming language). Java exists in many flavors, you do not have to use Spring to build a performant microservice.

[ekropotin]

Fair enough! Indeed, there are ways to build performant microservices on Java, e.g. Qwarkus + GraalVM, but I've never seen anyone in enterprise world is doing it - 99% of services are still being build on Spring Boot, so in my mind Java in SB are inseparable.

[tracker1]

That's kind of where I stand on this too... though I'm more fond of a lot of C# than Java, I find that it's the developer ecosystem and work environments themselves that exist on so many piles of abstractions and patterns that it's often hard to even grasp the meat of what's being done over the abstractions themselves.

I've trended towards feature oriented hierarchies over type of thing hierarchies as I find they tend to be simpler, easier to replace over time and often much easier to maintain than separating DAL/BLL/SVC/VM/M/V layers etc. I really don't mind if my endpoint file sits next to my database access file, next to my validation file along with the test files for all of them in a single directory for a given feature. The feature is the concern, not the fact that you have a web endpoint, or need to talk to a database.

They're also easier to manage in a monolith and break apart as needed without having to replicate the jungle for want of a banana.

[ivan_gammel]

I bet this is happening because in many enterprise applications you do not need high performance. Requirements to a service doing 1000 transactions a day are very different from requirements to a service doing HFT. Service per bounded context may be reasonable choice and Spring Boot/Spring Cloud may be adequate solution for it.

[tracker1]

I think this is probably a large part of it... I remember working on an app a few years ago, where it was explicit that it likely wouldn't see more than 15-20 active users at any given deployment... and with the level of normalization at the database layer, and literally 95% of the logic INSIDE the database (sprocs), it was just about falling over on a modest server trying to handle a dozen users.

Worse still, is the variance and onboarding for each customer was taking roughly twice as long as the previous one... I left during the dev cycle to bring in the 4th client. These were state/county agencies, each with slightly differing requirements. I was in charge of the UI and the API for the UI... putting all the logic inside the DB itself was emphatically NOT my decision.

[re-thc]

> because in many enterprise applications you do not need high performance

Looking at and having looked at some of their cloud spend etc, nah.

To be more specific there's a lot of fat. Whether that's HFT style high performance is a different story.

[ivan_gammel]

You can drop cloud spending by 10x factor and still use Spring Boot comfortably. In startup world exist infra costs benchmarks and they are very generous. That fat does not come from frameworks, it comes from not spending an extra hour on solution design.

[amarant]

Minecraft builds their servers using Micronaut! It's such a breath of fresh air compared to spring.

I've only ever had to debug spring DI once, I'll admit it usually works. But when it doesn't..... All those proxy objects will drive you nuts!

It's a very clever solution really.. And that's the problem! You don't want to build your servers on a clever foundation, you want a simple one!