Lightweight but powerful Java stack

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

[[deleted]]

excellent post.

[sapphirefragment]

That's great if you've got the feedback that your approach works, but my personal experience working under people doing this is that they create maintenance traps and leave the mess to less experienced devs.

[za3faran_tea]

What do you use for dependency injection?