Hacker News Reader

Comment by mightyham | Hacker News Reader

Springboot's dependency injection, auto configuration and yaml configuration system is a value proposition that I find hard to beat. I find it's fairly effortless to build almost any kind of backend software, and if I want something "lightweight" I probably wouldn't use java in the first place.

While that's my pragmatic view, to be less critical, I am glad to see a project that provides a robust and elegant API for building rest services in Java.

View on HN

The aforementioned are huge detractors for me to be honest. I find a no-magic, code-only solution like Javalin (and Express etc) far more intuitive.

To be fair Spring Boot can be (and almost exclusively is) code-only nowadays. None of that XML stuff you found in the early days.

I actually preferred the XML config, and I hate XML. Why? It was all in one spot, not spread out among the source files. It could be "deployed" alongside the code and not have to recompile/build. This was a bigger deal back then when "config" was often outside the official "installation" procedures that required 5 layers of OK's to put a new "compiled version" of an application in a production system. Not saying that was the right way to do it, but it existed.

It's actually not that hard to beat. Quarkus proved that it's way better than Spring Boot in a lot of aspects based on open standards and battle tested frameworks like Vertx. Also on Quarkus you can use in parallel blocking and non-blocking IO and also high level declarative routes with annotations to lower lever vertx routes and handlers.

You don’t even need a framework to beat it.

Pick a DI library: Guice, Avaje Inject, Weld, countless others

Pick a configuration library: Avaje Config, Typesafe Config, Microprofile Config, countless others.

There’s a lot more to Spring Boot than DI and configuration.

Of course. But OP specifically pointed out configuration and DI as hard to beat.

The rubegoldbergery around DI is amazing. You don't really need a DI library in many cases. A single Java SPI supplying access to all interface dependencies works extremely well. You provide a default implementation consumers can override using basic SPI mechanics. Done.

> I am glad to see a project that provides a robust and elegant API for building rest services in Java.

Alternatives for _consuming_ REST services is perhaps an equally interesting proposition, particularly since there are potentially many consumers per service e.g., the manifold JSON project[1].

Other areas where Springboot feels overbearing include JPA/ORM support. In my view this is its greatest weakness, but like the "no one ever got fired for buying IBM" cliche, the same can be said today about Springboot.

1. https://github.com/manifold-systems/manifold/blob/master/man...

I find it interesting to see how would something like Javalin work if coupled with Spring DI. Throw the Spring web stuff out and use Javalin instead. Spring web always felt archaic to configure when you want to go beyond simple CRUD operations like implementing sophisticated RBAC.

Reply on news.ycombinator.com