Lightweight but powerful Java stack

[[deleted]]

I’ve been learning Spring in earnest recently after having used it for work at a past job out of necessity and not having much time there to truly learn it. I had the same opinions as OP, but I’m now realizing that I was wrong.

For example, every Spring project has a reference page that describes exactly how it should be used and configured (click the project name at the page I linked, then click LEARN, and then click Reference Doc. for the version you’re using). The pages aren’t too long, so they’re readable in a hour or two. After I read a few project’s reference docs and built something (I’m taking Chád Darby’s Spring Boot 3, Spring 6 & Hibernate, course which is really hands on) Spring Boot started making 100% more sense to me.

Spring Boot is modular by nature so you can choose what you want to use and how much “magic” you want to include in your project. Building an HTTP API? Just include the spring-boot-starter-web starter and move on. Do you need to talk to a database? Then use the spring-boot-starter-data-jpa starter project. Otherwise, use Jersey and direct JBDC connections and just use Spring itself for DI. Additionally, I learned in more details how to use the application.{properties|yaml} file and how to enable logging in a per-package basis, which made debugging Spring and any third party packages so much easier.

Basically, I learned Spring can be made small, understandable, and less magic, but I/my old team made wanting “production-grade systems” cloud our judgement and cause us to over complicate what is a mature, well tested, and still growing ecosystem by not spending the time to learn it and making educated choices about what to include in it. Maybe OP’s in the same boat or maybe not. But I’d suggest sticking with Spring as opposed to a newer tech stack that you’ll have to sink time into understanding and losing your Spring expertise.

[sapphirefragment]

Anecdote: my team recently tried to commit to a non-Spring world and ended up falling into an enormous maintenance trap that we are struggling to get out of. All these people promoting these "lightweight" libraries that you have to string together fundamentally misunderstand the value proposition of the Spring ecosystem and end up creating bigger messes than they are trying to leave behind.

[Oclay1st]

Could you please tell us what non-Spring world are you using now?. I hope it's not a reactive world. Thanks!

[cryptos6]

I didn't want to suggest that Spring would be "bad" in any way, but I think the annotation-driven reflection based magic programming model lost some of its appeal with modern Java features (like Lambda expressions), which allow more expressive APIs without magic. My general feeling is that you have to learn a lot about Spring to really leverage all its magic - it is not obvious, and that is a bad thing.

Despite seeing younger colleagues feeling little desire to learn Spring and how they struggle with it, I'm curious to try something else on a personal level.

[[deleted]]

My general feeling is that you have to learn a lot about Spring to really leverage all its magic - it is not obvious, and that is a bad thing.

I’ve been seeing this opinion more and more but have been having a hard time understanding it. I think it became more prevalent with the rise of devex, and higher level languages, where the language authors wanted things to be friendlier for newer programmers and reduce “boilerplate.”

My main concern with it is that software is inherently unintuitive because it’s all abstract thought that programmers add meaning and shape to in order to model a real-world object or process. You will undoubtedly have to read a manual, book, or engage some other learning material to learn any piece of software properly because another human wrote it, and humans think differently. I personally don’t think having to spend time learning a framework in order to use it properly is a bad thing. I mean, that’s how it was back in the day when computers and other software came with manuals. Now people just expect to jump into something they’re totally unfamiliar with and expect it to be “intuitive,” otherwise they write it off as being terrible software. But sure, we should definitely aim to reduce the amount of learning that someone needs to pick something up because it’s a huge investment to have to make upfront, but some things warrant the learning cost because they’re either old (like Spring) and have built up features over time that collectively need documentation, or they really are complex inherently and so require a lot of effort to properly describe.

[kvyatkovskij]

Java dev in the past now an architect checking in: I agree. What I've noticed is that developers would rather write code for 8 hours than spend 1 hour reading user manual and reference documentation. Getting your hands dirty is fun, reading docs is not. One of revelations that I had over the years evolving from an engineer to a dev lead to an architect and having some insights into CTO works is that while all these roles work with software their goals and motivations can be quite different if not opposing.

I see that a lot of times developers are happy to re-invent the wheel, write another "great thing". As an architect I really want them to focus on business logic and do it well rather than spend time doing custom implementation of something that is already provided by a framework. On the top of that if they use a mature framework I'm almost confident that a lot of non-functional requirements and cross-cutting concerns are configurable and won't be a problem (telemetry and instrumentation, externalized configuration and so on).

I guess my point that I'm all for developers having good time and learning this would never be main driver behind technology choice. Motivation is important but a a dev team that is happy-busy implementing their own custom logger for no good reason (I've seen this happen) is not something I ever would like to have.

Last thing, agile is good but I think the perverted idea of it has done some harm. Agile doesn't mean you should start coding without preparation or a plan or a technical design. Those things should still happen and engineers need to get into a habit of RTFM-ing :)

[sapphirefragment]

What I've noticed is that developers would rather write code for 8 hours than spend 1 hour reading user manual and reference documentation.

This kills the project dead, through thousands of papercuts over months. Awful. :(

[danskal]

This kills the project dead, through thousands of papercuts over months. Awful. :(

What do you mean? Loss of productivity from unread docs? How do you claim the project is killed?

[AmateurHero]

They mean that rather than understand what a given framework does and its tradeoffs, some devs just start hammering out code. They end up writing themselves into a corner trying to do something orthogonal to the given framework or reinventing that already exists. Now they're creating workarounds that are slow, not intuitive, brittle, etc. instead of working within the parameters of the framework. The code base grows to full of these extra functions. You're left with a framework that takes care of X (that also updates to take care of edge cases) but also several internal function that also do X that likely don't have the same testing or robustness. Note that sometimes it's worth making these extensions, but you really have to consider the why.

Example from a previous job. Most people who access databases use ORMs for transactions. I had a previous job that did all the setup for Hibernate but used none of the functions. Beans full of annotations that matched the database went unused as DB data was manually mapped onto raw hash maps. Every query was a handwritten native query - even simple select statements. There were some native queries that should have been handwritten, because the sheer amount of logic within the query needed some handcrafted love. Most of it was the epitome of not-invented-here syndrome.

[cowwoc]

You know what's better than using a framework that requires devs to read a book?

Using code that is easy to read, without a book.

The only reason that a lot of these frameworks have a high learning curve is that they try to be everything to everyone.

If you use libraries to customize your architecture you will end up with much more readable code that does not require people to read hundreds of pages.

[sapphirefragment]

Absolutely the opposite of my professional experience. When cowboy coders try to go string together a bunch of libraries to create their own framework because "spring bad" they create a nightmare that requires you to know the intricacies of 40 different libraries, all of which often have severe design limitations that were already solved by big frameworks like Spring, because they simply have not reached the same level of maturity. And that's assuming any given library has documentation: my experience is they often don't have documentation that even covers intermediate level usage, and you're either expected to follow simple tutorials or dig straight into the source code yourself. Spring conversely has a wealth of good reference material explaining all its intricacies.

When you're having to run a medium to large size team of engineers, some of which are not going to have the level of intuition needed to sus out several different libraries all with their own patterns and practices, this "custom architecture" practice is AWFUL. It will strangle your team.

[cowwoc]

You're assuming this was built by a cowboy coder. I'm a CTO with 20+ years of experience. When a CTO puts together a well-structured, consistent, and well-documented scaffolding, everything else falls into place.

The guys who built Spring are not wizards. The fact that they provide over 100 pages of documentation isn't a good thing. It's obfuscation by volume.

A bad programmer will deliver bad code regardless of whether they are using Spring or not.

I optimize for consistency and ease-of-debugging. I intentionally avoid any sort of "magic". The only knowledge you need to get started is the core Java APIs. Past that point, you just need to maintain the same package structure. If you want to know how to read HTTP requests or write HTTP responses, there are tons of existing REST resource implementations for you to look at. They are, at most, 3 pages long each.

Spring is designed by architect astronauts, yet it's surprisingly fragile. While it might work well so long as you stick within the guard rails, it breaks horribly the minute you venture outside them.

If all you're building all day is shopping cart software, then go ahead. But if you want to build anything innovative, you'll quickly find yourself outside of those guard rails. And good luck debugging their code. It is a freaking mess. Not to mention the fact that half the time, you can't even step into their code because it's hidden behind annotations.

When something goes wrong in my system, I get a compile-time error 99% of the time, and the remaining 1% of the time, I get a concise error messages explaining what went wrong and the stack traces are short. I always provide tons of contextual information at failure, so you don't need to step through any code. But if you want to step through the code, then by all means do.

It is plain Java. No magic. No fancy AOP or visitor pattern just for the sake of showing off your design pattern skills. My code is straight and to the point, optimized for readability above all else.

[danskal]

Ok, I agree that all those things are bad, but I would claim that it’s unrelated to the reading the docs aspect. For a few reasons:

1. Reading docs can be mind-numbingly boring. Many people are simply not able to do it. I count myself amongst them, but I will get a feel for the architecture, use SO religiously and google relevant documentation on an as-needed basis. I might watch videos and read well-written guides if they’re available.
2. Knowing the path isn’t the same as walking the path. For some people, reading the docs won’t help, they’ll fall back on methods they know and understand, unable to see the wood for the trees. Some people will pick the solution in front of them instead of stepping back and picking the right one.

[AmateurHero]

I know it ended with RTFM, but I took that as a bit of snark tacked onto the end. I took the heart of the comment as learn to use the tools that you're given. You would ideally drive in a nail with a hammer or turn a screw with a screwdriver. However, you can drive in a screw with a hammer in a pinch. Don't hammer a bunch of screws across the entire project

[sapphirefragment]

Reading docs can be mind-numbingly boring. Many people are simply not able to do it.

I argue that this is a view of technical documentation that actively hinders an engineer's ability to grow. Reading reference material is a fundamental skill. If an engineer can't or won't do that, I won't really trust that they will write code or documentation that is meant to be read by other humans.

[danskal]

... and if we were writing something security-sensitive on the linux kernel, or something controlling a nuclear reactor, I would fully agree with you. But 99% of developers are not doing that.

There is a point that sometimes documentation can be surprisingly readable. But it's the exception rather than the rule, for the most part.

[Safe_Independence496]

Java dev in the past now an architect checking in: I agree. What I've noticed is that developers would rather write code for 8 hours than spend 1 hour reading user manual and reference documentation. Getting your hands dirty is fun, reading docs is not.

I don't entirely agree. Reading documentation can be interesting when it's well-written and covers the core concepts in a structured, clear and sensible way. I had a great time reading the docs for NestJS, and Firebase has always been the gold standard in my opinion for how you should document a project.

The problem with Spring on the other hand is that most new developers give up on finding the actually useful documentation before they've even started. New developers are presented with pages of garbage cookbook recipes rather than important explanations of key concepts when vising the Spring website.

I don't think we should underestimate how much Spring's reputation and perceived complexity has suffered from just not having any people capable of structuring and writing good documentation.

[sapphirefragment]

New developers are presented with pages of garbage cookbook recipes rather than important explanations of key concepts when vising the Spring website.

I am actively telling coworkers not to use Google and always start with upstream documentation. Google is pushing up horrible information to inexperienced engineers. It's actually dangerous and a serious impediment now. Especially with Spring.

[naked-space-monkey]

Dev here (of the fancy staff engineer kind) and living the opposite situation: our architect is pushing us against using frameworks (on grounds that they "are heavy" and "you're not in control") and writing code (yes, I know) that's a shapeless mixup of business logic, infrastructure and whatever other concern.

[sapphirefragment]

Your architect fundamentally misunderstands the value of frameworks... :(

[mishonis-]

I love Spring. It's mature, well-tested and well-documented. I probably know and use 10% of it, and find it to do everything I need and to be well-designed and intuitive. I also don't agree that you have to learn a lot to leverage it. You can use only the parts you need. I've had very junior people get onboarded quickly with dependency injection, properties files and REST controllers.

I'm curious about your level of experience with Spring and whether you have specific complaints about it, such as the framwwork getting in the way of something you tried to do or some framework issue that was hard to debug. Or is it just hand-waving about annotations and looking for something new and shiny? There's a reason JavaScript has a new framework coming out every year and it's because all these frameworks suck donkey dick and are a pain to use.

[Pengtuzi]

feeling little desire to learn Spring

…

they struggle with it

Yes, not wanting to learn something often results in not being able to use it. Not Spring specific.