[antonymoose]

Funny how that works - I started with Spring both before and after Boot as well as some Scala.

I wouldn’t trade Java / Spring for the world. It forces a coherence, perhaps not perfectly, but it provides guidelines to follow.

I’ve been stuck in Node / TypeScript / Microservice hell for most of the last 15 years and I couldn’t hate it more. The open-source ecosystem is extremely lacking, even now, on something like a good XML library. I think we’ve got four different ones installed in our core platform each handling different needs (traversal, generation, manipulation, validation).

On top of it all, since there isn’t “one way” we’ve got several dozen micro services. There isn’t a single bit of consistency other than “Express.” Logging, authentication, routing, validation - it’s all completely up in the air. It robs us all of efficiency from the lack of common language and pattern. We spend more time refreshing ourselves on any given project than doing feature work or bug fixes.

Madness!

[e7h4nz]

Removed microservices and RPC, keep all TypeScript codes in a single monorepo. Avoiding `any` and using ts-rest automatically keep types synchronized between the web and frontend applications.

This has made my life much easier.

[BariumBlue]

I hear this a lot from a lot of my coworkers who like Java Spring - they trust Spring to do things right, more than themselves.

On the other hand, I hate Java Spring because I feel like I don't trust it - it doesn't let me look into and understand the internals easily, making me feel like I'm afloat on a pile of abstracts I'm not allowed to look down into.

Looking at some other projects enterprise js/ts codebases though, I see a lot of "I don't understand how this works so I'll try random things until it works". In that kind of environment, I can understand the attraction of Spring - it's not great, but it also won't be a flaming pile of unbaked abstractions.

[ivan_gammel]

Spring framework may look complicated only at start, until you get it, but then it becomes quite easy to reason about.

OTOH, Spring Boot is a huge pile of various loosely coupled framework connectors, web, queues, security, databases etc. Some of them are of good quality, some are not so good. It is that uneven mix giving the perception that Spring is a mess.

[functional_dev]

Agreed, Spring Framework is quite simple... just look here - https://vectree.io/c/spring-framework

[nh23423fefe]

> it doesn't let me look into and understand the internals easily

what does this mean? you can single step into framework code

[antonymoose]

Mostly just boils down to a Chain-of-Responsibility pattern which is incredibly easy to reason about. Just a way to compose functions.

As far as digging into internal, how often do you look into Express or Rails internals or any other? For me it’s a rare day to need to do so.

Only time I recall having to read Spring source code was when I used their Social Media Auth library sometime in the early 2010s when it was quite a primitive experience.

[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!

[reeredfdfdf]

I agree. Whenever I've tried jumping into NodeJS world, I quickly get overwhelmed by the lack of obvious "right" solutions to common problems. There's no way to know which of the dozens of ORM's, auth libraries or whatever will be still around 10 years from now. With Java & Spring the choice is always obvious.

Of course there are "batteries included" frameworks for NodeJS too, but they all seem to be unstable compared to Spring Boot.

[tracker1]

I tend to defer auth to JWT token usage... you have a properly RSA signed token against a valid public key, you're in.

In terms of ORMs, I actually avoid them... I like data adapters that make writing general SQL queries easier... for C# I tend to use Dapper... for JS/TS, I'll use a template string interpreter shim over the database adapter that returns Enumerable<T>?... very similar to my usage of Dapper.

Just about the simplest things that I can do to get things going, and generally in the simplest path forward. Today, generally speaking, hono, zod, openapi with a bit of hand-wiring as described above. At least for the backend, services, etc. With open-api configured, I can generate client adapters and relatively easily integrate with an OAuth provider of my choice (often AD/Entra in practice).

I will also usually create a self-signing JWT auth for dev/testing to make it easier to be "anyone" in any role for testing... where the release application is more restricted.