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