Live data from Hacker News

Spring Boot Done Right: Lessons from a 400-Module Codebase

medium.com

41–50 of 100 posts

Re: Spring Boot Done Right: Lessons from a 400-Module Codebase

#41
post #14

I worked on a core Spring Boot project for five or six years at a very large enterprise. In my opinion, the most dangerous thing about this framework is that it makes its core users feel far too self-assured. When looking at problems, your mind becomes consumed with how to force everything into design patterns—like architectural separation, DI, or interface / implementation split. This causes developers to lose sight…

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 g…

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.

Re: Spring Boot Done Right: Lessons from a 400-Module Codebase

#42
- Swap out Java for Kotlin. The Spring guys won't officially drop support for Java; but a lot of their recent releases are becoming very Kotlin centered. Seriously, it's much nicer to use from Kotlin. I've done both.

- Go for declarative Kotlin DSLs over annotation magic for most things. Much easier to debug. It's just function calls. And DSLs are nice in IDEs with autocomplete.

- Keep it simple. It's a huge framework. But you probably don't need most of it.

- Don't go Spring everything, a lot of stuff in Spring is a bit experimental (Spring AI/MCP stuff) or a bit bare bones (Spring Data, it's a limited and extra level of indirection you mostly shouldn't need) or flat out misguided/over-engineered (Spring Batch, good alternatives are available for that).

- Decide on synchronous or asynchronous IO. The former is a lot more scalable now that Java has green threads. The latter is relatively painless from Kotlin but an absolute PITA from Java. They are very different internally and both have their pros/cons. If you need async, Kotlin co-routines is the easier path to do that. Either way, it's one of the bigger decisions to take.

- Don't copy their way of deeply nested inheritance hierarchies. Very much in fashion 20 years ago; a bit of an anti pattern now. Internal code complexity is the part I like least about Spring. And it has some really byzantine stuff in there with 5-6 levels of inheritance or worse.

Re: Spring Boot Done Right: Lessons from a 400-Module Codebase

#45
post #14

I worked on a core Spring Boot project for five or six years at a very large enterprise. In my opinion, the most dangerous thing about this framework is that it makes its core users feel far too self-assured. When looking at problems, your mind becomes consumed with how to force everything into design patterns—like architectural separation, DI, or interface / implementation split. This causes developers to lose sight…

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 g…

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.

Re: Spring Boot Done Right: Lessons from a 400-Module Codebase

#46

Ops person here who has supported Java/SpringBoot applications. I think most of dislike of Java apps comes not from language or framework BUT from fact that most Java using workspaces are filled with mediocracy. They tend to be businesses with products that have extreme moats and thus quality of software barely matters. I imagine most people who would even read this medium article are dreaming of better than that.

There are certain non-software industries that seem to have strong hiring preferences for workers who started in the industry over computer science chops, and a lot of those tend to use Java. For example, biotechs.

Re: Spring Boot Done Right: Lessons from a 400-Module Codebase

#47

Does this app take 5 minutes to start? That's so much dynamic Spring magic. Also, how do you keep track of control flow when anything at anytime could have been overridden by something else? It seems like tracing and debugging this thing would be like exploring someone else's codebase every time.

Who cares about startup times if apps is started only when new version is deployed?

And 5 minutes is a bit long, maybe someone is doing some database operations during start?

Re: Spring Boot Done Right: Lessons from a 400-Module Codebase

#48
post #26
post #2

Hacker news likes to dunk on Spring Boot, but its usage in enterprises is very very high.

it doesn't mean that usage of something being very high is a clever idea. lots of people take meth - so are you gonna take meth too. ```@EnableConfigurationProperties(CasConfigurationProperties.class) @EnableScheduling @ConditionalOnFeatureEnabled(feature = CasFeatureModule.FeatureCatalog.SimpleMFA) @AutoConfiguration @Import({ CasSimpleMultifactorAuthenticationComponentSerializationConfiguration.class, CasSimpleMult…

dude, that is a configuration.

it is completely declarative and lives in the best place, near your code, not on some other inaccessible repository.

what have you preferred? a json file? a yaml one?

I had them, and I find the annotations are more readable than other solutions.

Re: Spring Boot Done Right: Lessons from a 400-Module Codebase

#49

Ops person here who has supported Java/SpringBoot applications. I think most of dislike of Java apps comes not from language or framework BUT from fact that most Java using workspaces are filled with mediocracy. They tend to be businesses with products that have extreme moats and thus quality of software barely matters. I imagine most people who would even read this medium article are dreaming of better than that.

There are certain non-software industries that seem to have strong hiring preferences for workers who started in the industry over computer science chops, and a lot of those tend to use Java. For example, biotechs.

Because most of time, understanding the business logic is harder than writing to the code in these industries.

Java is default since it's what taught to many college graduates with added bonus that's taught to most college grads in Indian subcontinent so outsourcing is much easier.

Re: Spring Boot Done Right: Lessons from a 400-Module Codebase

#50

Earlier quoted context omitted.

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 g…

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 tho…

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.

Post reply on HN