I’ve been coding for many, many years. I started when I was 13, and that is decades ago. Software development was different back then; programs ran on a single PC, claiming it completely, with text based interfaces (windows were drawn with characters), and maybe, just maybe, there was a shared storage, because some PC had it’s drive shared.

It was also the time when there were not many existing software systems. You had WordPerfect (no WYSIWYG), I remember some kind of simple spreadsheet, and basic bookkeeping software. But that was about it. The world, and all the potential software had, was wide open.

So in the years that followed I wrote many systems. Small ones, to solve small but real problems; an address register for myself, a CRM tool for the local gym, a similar one for the dance school. What a time! It was not much work, especially after MSAcesss was introduced, you got a lot of functionality for the amount of effort you had put in.

I still do need to have a talk to the people who created the default green color scheme, very curious who thought that was a good idea. Oh, and there was clippy of course 😄.

But then things slowly started to change, and writing software became ever more complex. Not only did people started to expect more, but also software itself became more complex to make. Nowadays things need to run on a cloud platform, scale dynamically, have fail over, etc. All for good reasons, but this makes getting started, or finishing up, a lot more work. Nothing like the MSAccess experience of creating a new application, and just get going with solving the problem.

So for my recent private and hobby projects, a webapp to allow a healthcare team to make their own roster, something that scrapes websites of dance schools and collects where the next dance events are, I chose a different approach and created a software stack that was aimed at simplicity of coding:

• SpringBoot as a basis
• Vaadin for the web UI
• HSQLDB as the database.
• EBean for persistency

And all this is distributed in a single bootable jar. No Docker, no Kubernettes, no cloud, just java -jar in some Linux home directory. Oh yes, and a systemd service to auto-start it.

So why this stack? Well…

Vaadin is very well suited for coding administrative UIs, and the developer totally need not involving himself with HTML. Just create textfields, buttons, dialogs, and handle them, like you are working on a desktop application. Does that scale big? Not really. Is it simple? Yes. Does it look good? Yeah. And you always have the option to include Thymeleaf (my favorite HTML template engine), HTMX, or go browser side with Angular, and unleash your HTML and CSS skills. (Which I did for certain aspects of the self rostering, because of performance).

HSQLDB can run in multiple modes; embedded in memory, embedded with the data stored on disk, or as a standalone server with data stored on disk. Or, if you code it right, embedded as a standalone server: the bootable jar starts an HSQLDB server which is only reachable on a port on localhost. This means you can still connect to it with a SQL tool, and inspect / modify / backup the data, but no need to install a DB server like Postgresql. Let alone Docker compose or K8s things. Of course Liquibase (or similar) is used to make changes to the schema. And backups/restores are easy: you only need to copy some files around. Does it scale well? Nah. Is it simple? Yes. Do you have all the important features of a SQL database? Yes.

The ‘not scaling well’ is debatable, because one only needs to change the spring boot configuration to connect to a database elsewhere. But that is a different stack then.

Anyone who has ever worked with JPA knows that it can be a bitch. The clones in pre or post events can be confusing, and when something is managed by the EntityManager, or not. EBean keeps things simple; it uses the JPA annotations to enhance the entities, but if you call “save” then the entity just gets saved. No managing, no clones, save is just save, delete is just delete. Is it mainstream? No. Is it simple? Yes. Do you have all you expect from an ORM? Yes, and more. It supports optimistic locking, query bean generation, partial fetches, and a many things people probably not use.

Not all solutions need complex infrastructure, not all transport needs a V10 supercar. But the end users are just as pleased.