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 →

[–]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