Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

medium.com

Post reply on HN
Print view View original

71–80 of 100 posts

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

#71

Post by tracker1 »

throwawey1234 wrote: post #65
ecshafer wrote: post #16

Earlier quoted context omitted.

I 100% agree. I have seen enterprise spring applications that throw away all of the speed through huge amounts of hot path object creation, nested loops, absurd amounts of factories, etc. After going through enough AbstractFactoryFactory calls to make object in an n^3 loop, the framework doesn't matter.

In my experience, the same enterprise developers will write complex abstractions in any language. If you have a million coders, 500k will by definition write below average code. And if some of them are elevated to tech leads in enterprise companies, they will spread their "style" to others.

This is definitely true... as a mod/admin on EchoJS, can't tell you the number of times I've seen unnecessary IoC/DI libraries created in JS/TS to match the style of Java or C#.

The reality is that as a scripted environment, there are provisions to override dependencies for testability.... so unless you literally need multiple implementations of a given adapter, you don't need a DI/IoC framework and adding one only detracts from your overall solution. I'm a strong believer in that abstractions should mostly serve to hide relative complexity to make the rest of the application easier to reason with.

I'm also a big fan of the first version of anything being done in a scripted language with an emphasis on correct behavior. JS/TS and Python are more adaptable earlier on without committing to Java/C# or even Rust or Go. I understand a desire for homogeny, but that often can hold you back from creating something functional and easy to replace first.

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

#72

Post by tracker1 »

the_arun wrote: post #21
switchbak wrote: post #19

Earlier quoted context omitted.

There really is an unlimited potential for crappy code in the enterprise. I imagine the volume will increase drastically in the age of AI.

Usually languages are not the issue. It is the code that we write. As long as languages help us to find/debug a problem caused by crappy code - we should be good. Coding is kinda creative work. There is no standard to measure creativity or pitfalls of using wrong patterns. The incidents & RCAs usually find these. But most of the times it is already too late to fix core problem.

Not sure that I agree... I think some of the worst AI code I've had to deal with and the most problematic are when dealing with Java or C#... I've found TS/JS relatively nice and Rust in particular has been very nice in terms of getting output that "works" as long as function/testing is well defined in advance.

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

#73

Post by swisniewski »

There is no right way to do Spring Boot.The entire idea is broken.

Dependency injection is good. It makes it possible to test stuff.

Automagic wiring of dependencies based on annotations is bad and horrible.

If you want to do dependency injection, you should do it the way Go programs do it. Create the types you need in your main method and pass them into the constructors that need them.

When you write tests and you want to inject something else, then create something else and pass that in.

But the idea that you create magic containers and then decorate packages or classes or methods or fields somewhere and then stuff suddenly gets wired into something else via reflection magic is a maintenance nightmare. This is particularly true when some bean is missing, and the one guy who knows which random package out of hundreds has that bean in it is on vacation and the poor schmucks on his team have no clue why their stuff doesn't work.

"I added Spring Boot to our messy Java project."

"Now you have 3 problems."

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

#74

Post by amarant »

ekropotin wrote: post #60
ivan_gammel wrote: post #51

Earlier quoted context omitted.

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.

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.

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!

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

#75

Post by tracker1 »

robmccoll wrote: post #58
krzyk wrote: post #47

Earlier quoted context omitted.

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?

I care because every second of that startup time is lost productivity and focus. For me and any developer on my team. Hot reload only works if no class or method has changed so that's not a solution. I've worked on codebases of similar size and complexity in many languages, and the developer experience of a compile and restart that takes less than five seconds is game changing.

I can imagine a full build of the project(s) in TFA are on the order of several minutes to build/run the first, and maybe every time. I remember working on projects before SSDs were common that would take on the order of a half hour or more... the layers of abstraction were so that you literally had to thread through 15+ projects in two different solutions in order to add a single parameter for a query and it would take a couple weeks to develop and test.

That said, I did catch up on my RSS feeds during that job.

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

#76

Post by tracker1 »

theflyinghorse wrote: post #55
dzonga wrote: post #26

Earlier quoted context omitted.

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…

This is still relatively tame! I've seen stuff where there are layers of annotations some of which will spawn docker containers effectively bringing docker compose into java application as part of the set up. Some containers would need to come up, do a quick file change, then die and the the rest of configuration proceeded (this was for an automated test tool). Entirely stupid, could have been written with just coupl…

FWIW, I think .Net Aspire is pretty interesting along a similar vein. I mostly just rely on shell scripts and docker-compose configuration(s) for dev though.

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

#77

Post by tracker1 »

fiftyacorn wrote: post #11
rockyj wrote: post #6

Earlier quoted context omitted.

And at the same time, gives you a dozen of footguns. This is just a list for the gotchas in the "@Transactional" annotation - https://dev.to/closeup1202/8-spring-transactional-pitfalls-t... Now read up on all the dozen of annotations. But yeah, we did not want to "re-invent the wheel".

Im comparing against node equivalent ORMs and find spring consistently better. Yeah ive got to read up on annotations - but when it comes to transactions its always worth revisiting them to check for changes

Meh...

    await using cn = await pool.connect();
    const records = await cn.query`
      SELECT ...
      FROM ...
      WHERE ...
    `;
    for await (const record of records) {
      ...
    }
Oh, spring is so much better...

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

#78

Post by allador »

Keep in mind that a big part of the configuration complexity of CAS is because of how it's used and customized in the real world.

These kinds of infrastructure systems its very common to replace a bunch of the built in functionality with your own classes, and so there's alot of effort put into supporting that use case.

I helped build a large open source enterprise financial systems, and most of the deploying orgs used CAS for authN. Both CAS and the financial system was built with similar approach to extensibility.

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

#79

Post by evantbyrne »

stackskipton wrote: post #49
evantbyrne wrote: post #46

Earlier quoted context omitted.

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.

Getting up to speed on the business logic was arguably the easiest part of my last job where the product was a liquid biopsy. Regardless of industry, you have to learn how to communicate with stakeholders and collect requirements. The existing software being a mess was a much more significant challenge. They also had similar issues on the data science side, where I would argue they did not lean into modern ML nearly enough and instead opted to do the familiar thing.

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

#80

Post by dlandis »

There's a lot of good ideas in Spring and there have been some outstanding engineers working on that framework over the past ~25 years. But it has accumulated so much baggage and relies on and perpetuates so many patterns that simply don't make sense anymore... I would love to see what the team would do with a fresh start. I wonder if they have or are considering doing a complete rewrite or starting something totally new for the next generation that will take us through the next 25 years of Java.
Post reply on HN