I wonder how many of these rules can be enforced with static analysis and ArchUnit.
Spring Boot Done Right: Lessons from a 400-Module Codebase
61–70 of 100 posts
Re: Spring Boot Done Right: Lessons from a 400-Module Codebase
#62Earlier 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.
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.
Re: Spring Boot Done Right: Lessons from a 400-Module Codebase
#63Earlier 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.
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.
Re: Spring Boot Done Right: Lessons from a 400-Module Codebase
#64Earlier quoted context omitted.
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.
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.
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: Spring Boot Done Right: Lessons from a 400-Module Codebase
#65Ops 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.
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.
Re: Spring Boot Done Right: Lessons from a 400-Module Codebase
#66Earlier 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 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 compare…
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?... 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.
Re: Spring Boot Done Right: Lessons from a 400-Module Codebase
#67I 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…
> I also prefer using various SaaS solutions to handle authentication and user registration rather than rebuilding it all myself with Spring Boot Security.
I'm confused. Spring Security does provide you ways to create your own auth layer. However, you can use your existing identity provider or any external provider (there are starters for many providers).
Re: Spring Boot Done Right: Lessons from a 400-Module Codebase
#68I 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…
I like Java fine. I would probably prefer Ruby, Rust or LISP given the chance. But I can't disagree with anything you say. So many Java enterprise shops have absurd inheritance and "design pattern" abuse that makes it harder to actually work with the code, and slows things down.
Similar for C# in practice... I actually really like a lot of modern C#, though I use FastEndpoints as an (imo) upgrade to minimal API surface, generally with Dapper and as few layers as possible in a feature oriented structure (single project as long as possible). I had to split off some logic into a separate shared library and worker service app from the api app on the server. Client is a React SPA.
Re: Spring Boot Done Right: Lessons from a 400-Module Codebase
#69Earlier 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.
I think that's generally true of most knowledge domains for anything resembling complex work. Govt, banking, pharma, medical, SaaS all will have a lot of specific requirements that come from deep historical, regulatory or business needs.
I would suggest that the rise of Python is very similar, as it's common in education circles. It's not even that Java as a language is particularly bad, it's how it is used in practice. Though I really do favor C# over Java, there's a similar stigma that comes from the community itself, not the language or it's baseline abilities. And this is a valid criticism.
Re: Spring Boot Done Right: Lessons from a 400-Module Codebase
#70I 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…
Java is fine, but spring boot is an abomination. Give micronaut a go and see for yourself!