When we first started developing software commercially, we were often unsure what technology stack to pick when starting a new project.

But now, a few years richer in experience, we found a solid stack to work with that we usually pick as a base for new projects.

The Architecture

Almost all of the software we build is web based and consists of a backend service (mostly a REST-like service) and a fronted (usually a SPA). Authentication is usually handled by a token that is passed in the as an http header (cookies set by the server have given us quite a few headaches in the past especially in the safari browser, so we try to avoid them).

The Backend

The backend is JVM based and mostly written in Java or Scala. There are numerous advantages in choosing a JVM language for our company and while most are not unique to the JVM in combination they provide a pretty compelling argument.

• The sheer size of the ecosystem including tooling and libraries
• The JVM as a runtime environment with its state of the art garbage collector
• The size of the hiring pool is massive (this applies only to java of course). Practically every university teaches at least some Java today
• Java received quite a few new language features in recent years making it not nearly as boilerplate heavy as it used to be (lambdas, streams, local type inference, records)

In some projects we chose scala to utilize its powerful type system. With the release of dotty we hope for an even better scala experience especially in the tooling area.

Automatic creation of typescript definitions

To prevent boilerplate and tedious work we are using tooling to make the exchange of typed objects between the backend and frontend via JSON easier. These tools generate typescript definition files for us based on the backend classes (either POJOs in Java or case classes in scala). For Java, we can really recommend the excellent typescript-generator maven plugin. For scala, we have built an in-house solution (just send us a comment if you are interested in the implementation).

Javalin

We are really big fans of the javalin framework which is a no thrills easy to use web/http library with a focus on being simple (yeah we know that is quite a loaded word). To quote from the website:

You never extend classes and you rarely implement interfaces.

A really refreshing approach. No inheritance, no annotations, no magic. But still very concise. The great list of tutorials (e.g. creating a native image using graalvm) completes it.

Postgres

Another staple for us is the postgres database. It is rock solid and provides many important features like enums (to prevent magic strings/constants) and json columns if you need a more dynamic approach to data storage (without pulling in a document store like couch or mongo as a dependency).

Docker-(Compose)

For deployment we often rely on docker (though we had some problems deploying docker on desktop computers, but we will leave that to another blog post) and docker-compose. We are especially fond of docker-compose, since the container + network + volume definitions have solved a lot of configuration and deployment headaches for us.

The Frontend

The frontend is written in typescript with react for view binding which is almost the de facto standard nowadays. We have had mixed experiences with using angular 2 in the past (especially the change detection mechanism has caused quite a bit of trouble). I think react will be a reliable part of our frontends for quite some time to come.

While we have tried technologies like scala.js and similar approaches in the past, either the generated output size or the Javascript interoperability always left something to be desired. Furthermore the growing capabilities of the typescript type system (it really is quite impressive by now) have made it difficult for competitors to enter the field. But maybe this will change with the advent of webassembly.

What stack are you using? What experiences have you had on your journey?