fix(docker): implement multi-stage build

[credmp]

Docker supports the concept of multi-stage builds. First you create layers that contain all the development tools and build tools that are required, then it takes the smallest possible image that can run the application. That smallest possible image is what is pushed to the registry.

Using this technique the image size becomes manageable, my results so far:

• 1.2GB original biff Dockerfile
• 832MB removing the default-jre
• 600MB moving to Alpine as a base image
• 452MB using multi-stage buildes

Additional size reduction is possible through graalvm's native-image, however I have not been able to build the biff starter with it.

[credmp]

Hi Jacob!

I use docker in my "easy" setup extensively, thus for me image size is somewhat important. It is now down to 450MB from 1.2GB, so that is a nice step.

I am greatly enjoying the project structure that you created, it is very easy to get started on a project. I just finished one for my internal organization (which uses docker). I will continue development with it. Let me know if you want to add some features (perhaps a more modular approach to the datastore?) to biff, I will gladly donate some of my time to you.

Cheers,

Arjen

[jacobobryant]

Looks great! Would there be any issues if we change the base images to use Java 21 since that's the LTS release?

Also glad to hear you've been enjoying Biff! What data store are you using at work--Postgres/RDBMS? I'm definitely interested in improving the experience for people who need to swap out the default components, though I am wary of introducing too much modularity/indirection at the expense of those who stick with the defaults. e.g. I probably wouldn't want to introduce some data store protocol that all transactions + queries go through, but I'd be interested in things that reduce the effort it takes to swap the database out manually. In the Postgres howto, some of the code (mainly steps 2 and 5, and also the use-postgres component from step 3) could be pulled out into a separate library. I didn't do that because I didn't want to take on the additional maintenance burden, but it'd be a good opportunity for contributors.

My point above notwithstanding, I am actually in the middle of experimenting with Pathom, which more-or-less has you use EQL as an abstraction over the database's query language. So that could be another avenue for making it easier to swap the database out. Though I don't know if I'll ever have the starter app use Pathom by default or if I'll just write a howto guide for those who want to add it.

Other than that, I just added some issues tagged as Roadmap. They're all pretty exploratory; if any of them look interesting I'd be happy to chat more. Blog posts (e.g. experience reports, howtos) are always super helpful too.

[credmp]

No, no reason not to use 21 indeed. It already worked on 11 and 17, so it should be all good to do so.