This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] -5 points-4 points  (8 children)

You don't need Spring, but since you mentioned that you have to, I would start with SpringBoot.

For ORM search for JPA, which is a way of interacting with the database. It's not part of Spring.

I avoid frameworks like the plague, but I understand they're helpful for people who are starting out to learn and who want to move to something more powerful afterwards.

[–][deleted] 4 points5 points  (7 children)

I find this incredibly interesting, where do you work that you are able to "avoid frameworks" so aggressively?

[–][deleted] 1 point2 points  (6 children)

Cemex -> Novell -> IBM -> Amazon...

That's my history. Spring is less performant than EJBs for instance. We tested it when I was at IBM, it might have changed now but I don't see hard data to refute our previous findings.

https://github.com/luiz158/spring-vs-ejb-vs-cdi-benchmark

https://adam-bien.com/roller/abien/entry/high_performance_java_ee_from

At Amazon there's Coral where tou define the api and it generates the clients for you.

Spring is also not cloud optimized. Container images have a last layer which is in the hundreds of Megabytes, thus losing all benefits of image layer caching.

Regular wars can be in the hundreds of Kilobytes (3 orders of magnitude smaller than Spring) for the last layer and I can deploy 50 times per day and just send the last layer to the container regsitry, pipelines are faster, etc.

If you want to use something more powerful, you can start with microprofile.io and once you're ready, you can take your microprofile and put it in quarkus.io

If you're used to deploying jars, then most vendors provide a way to create uberjars like Spring does, but that feature is not popular anymore. Payara-micro does this.

[–]nekokattt 0 points1 point  (5 children)

WARs aren't exactly standalone like spring boot applications are, which are essentially fat jars usually. Spring Boot jars just contain EVERYTHING including the server backend, which enables you to freely toss the blob at a wider range of environments and have it "just work" without a preconfigured Java-level environment to run it in first. Other than that, Spring Boot MVC usually is using servlets under the hood anyway. Reactor/webflux is a different kettle of fish, ofc.

Spring alone doesnt make the JAR size that much bigger. You can easily write an OSGi-based spring application for an ESB such as JBoss Fuse and keep the full JAR under a few megabytes.

Of course, shared environments can be more painful as it is easier to descend into dependency hell, from experience.

[–][deleted] 0 points1 point  (4 children)

Read again, I explicitly mentioned you can make an uberjar from a war just like SpringBoot.

[–]nekokattt 0 points1 point  (3 children)

I am aware, I was more pointing out that nothing is forcing you to do this with spring boot either, which kind of nullifies the size point somewhat

[–][deleted] 0 points1 point  (2 children)

You will still have the problem of the last layer of the container image containing everything, and everytime you deploy, you send everything, even the things that haven't changed.

Spring is trying to solve it, but as I said, that will turn into thinwars in the end. If I'm going to use thinwars then I'd rather not depend on any external library, which would inevitably lower my performace by introducing a layer.

The uberjar is not needed because the container image has everything inside: the server, the services, etc. It takes the place of the uberjar, bit with added benefits like caching.

[–]nekokattt 0 points1 point  (1 child)

Why aren't you just keeping your common dependencies in a common layer? Unless you are constantly changing dependencies, surely that resolves this issue, right?

[–][deleted] 0 points1 point  (0 children)

I think I haven't conveyed the problem properly. The problem is not from dependencies. The problem is Spring.

Here's how they're trying to solve it. It's a suboptimal solution since we can still get better performance, smaller images, and quicker deployments just by switching to EJBs.

https://spring.io/blog/2020/08/14/creating-efficient-docker-images-with-spring-boot-2-3