A Simple Quarkus+Kotlin Starter WebApp
Newton’s First Law states that an object prefers to stay static if it’s already in a stopped state and once moving, it would prefer to stay moving. It’s called Law of Inertia although Newton applied it to inorganic objects, no one can argue that it’s remarkably true of us humans as well. Often times, starting a Project is the hardest part — no matter how easy it seems at the outset. Once started, it’s relatively easier to keep going. We might make mistakes and correct course but once the project has gained some momentum, it keeps moving without a lot of push.
The same applies to Software Developers.
When tasked with starting a new Product/Project/Programming Task, I have found myself visiting multiple google sites to get a simple web application up and running — even using popular frameworks. While every framework has a Getting Started Guide, getting a few of these working together is often not as straightforward and requires quite a few visits to the University of Google (and ChatGPT?)
And if you stray away from popular path and perhaps use a library which is not mainstream among your peers, you’ll very quickly run against Dead ends and fall repeatedly into stackoverflow valleys. What was supposed to be simple starter project becomes multi day affair of trials and errors which almost work but not quite.
I faced a similar fate while trying to bootstrap a web application for a Client. Without going into the why we selected a particular library, here is our Tech Stack:
- Java 17
- Kotlin instead of Java
- Quarkus instead of SpringBoot
- Postgres
- Jooq instead of Hibernate/JPA
- TestContainers instead of H2
- Freemarker instead of React
The Getting Started Guides at Quarkus are quite helpful. However, as you can imagine, these do not cover this exact stack.
While there are obvious explanations for most of the components, I think, (8) would be quite controversial. It’s not as blasphemous as it sounds to ditch React in favor of a simpler UI library. For one thing, React has a non-trivial learning curve. We did not have access to a React Developer right away and our UI is not expected to have complexity needing a dedicated UI Framework. Besides, HTML Page based workflows are simpler to understand and reason about than SPAs. If this version of the Product gets sufficient traction, we can look into onboarding a React Developer.
Also keeping UI simpler for the starting phase means we can actually go faster with Client Feedback since we don’t have to worry about complex UI bugs. A page based display also lets you introduce React/Angular gradually on a Page by Page basis. Please see comments in README to see how code is structured to make this a reality.
Jooq vs Hibernate might also generate some debate. Quite frankly, I detest the dynamic code generation of SpringBoot/Hibernate. All of us have come across functions like findUserByEmailAndStatusAndAgeAndHeightAndGender in SpringBoot applications! Too much abstraction leads to developer throwing code at the problem without clear understanding of the underlying SQL that is being generated. Most often, the SQL generated is sub optimal and since it works under low volume, it gets deployed to Production and fails to handle slightest increase in volume. While auto generated functions seem deceptively inviting, any decent application would require you to write custom SQL and it’s no fun trying to map JQL to actual SQL. Besides, neither JQL nor Native SQL provide any compile time error checking. We found it was worthwhile to pay the price of going slightly lower in the SQL stack with JOOQ — compile time checks, no magical SQL generated at run time, you get what you write and it’s still database agnostic (if this a goal worth pursuing but that’s another topic!).
The Entire project is hosted here. You can download and run it by following simple instructions in the README.