What we use

Let us show you roughly what are main tech stack is. We will not explain why we have chosen those on this page. This is subject to our Arc42 based Architecture Documentation.

In this section, we describe the basic rules we try to follow when making technology decisions.

Key drivers for technical decisions

  1. Any decision should be as little opinionated as possible
    We should never choose a technology just because we consider it eg. cool or only because we have experienced it as a good fit for another use case. Decisions should be made depending on the use case.

  2. Keep it simple stupid (KISS)
    Based on our interpretation of Agile Development we think that we should choose the simplest approach to tackle a task. Particularly, we always try to avoid optimizing things before it turns out that optimization is needed (see Donald Knuth). This applies, in the same way, to small things eg.

    • optimizing algorithms like SQL-queries

    • choosing frameworks for persistence, offering rest endpoints, frontend frameworks

    • infrastructural topics like VCS build system

      As well as it applies to "bigger" things eg.

    • Deciding architectural things like using CQRS

    • Using microservices vs. putting things into a monolith

  3. Choosing standard
    Try to use standard options. Eg. when there are several similar web frameworks, go for the more prominent one. Because for the more prominent one we will

    • get more support from other developers if we run into problems

    • expect more support from the project itself, and also the project itself will exist longer

    • have better tooling support (if applicable)

    • have it easier to find more developers

  4. Match techniques with skills of core team members
    The chosen technique should be either already known by the team (or part of the team) or the team must be willing to learn it.

It is obvious that some criteria could be in conflict with others. Then we use just common sense.

Read more about concrete decisions that have been taken

General

Python as general purpose scripting language

Writing all scripts that helps the developer. Eg, database importer/exporter, tools for building, deploying.

Backend

Language

Java 12

Java is well known, not only considering the current core team. It has certainly one of best tooling support. We assume it to be the most popular language for programming modern backend systems.
We decided to wanted to have Jigsaw in place, to start with a pretty modular system even, when staring with monolith. As we want to use the most recent version of Java, that has mature tooling support and works with other libraries/frameworks we want to use, we decided to use version 12 of Java.

Frameworks

Basic

Spring Boot

Decided for it’s popularity and it’s fast pathed way of setting up typical backend systems. It relies on the strong foundation of Spring for Dependency Injection and AOP, making it easy to implement enterprise grade systems.

Spring Security

To secure all endpoints

Spring Data Rest

To make the creation of HAL compliant REST endpoints a breeze.

Persistence

JPA

To map database entities into Java classes. The defacto standard in the Java world.

PostgreSQL

We assume this is the most advanced relational database, that also supports things like Json datatypes and has proven for years, it’s matureness.

Frontend

Language

JavaScript/HTML/CSS as the main language for the frontend.

We are not sure if we should use Typscript. But HTLM/CSS is out of question.

Frameworks

Spring WebMVC

Use for the server side rendering of page with the help of:

Thymeleaf

As the templating engine

React

Used to deal with user interaction rich parts of the site. For the current MVP, this will be the part were the user enters his profile.

How we to manage Source Code

We are using Github for:

  • all code repositories

  • tickets/issues

  • code reviews

  • building our components

(got to organization)

Working in a project like this together, with multiple developers contributing, requires that each developer can work on different branches until he finishes his task. Than he merges his changes into to main branch (the master) to make them available to others.

CCVS (centralized version control systems) support this process just not as good as DVCS. Whoever worked with multiple branches in eg. SVN knows how complicated it is there to merge branches.

The drawback of DCVS, that they are admittedly harder to understand, does not count too much for us, as the whole core team already knows GIT. We also consider DCVS/GIT as the defacto standard in Software Development. So this should not stop others from contributing.

We have chosen GIT as the concrete representative of a DCVS, as we consider it as the most used system with the best tooling support.

GitHub, is just the most used public available service that offer Git. It is free for usage in open source projects like this one. It offers additional issues/tickets, some ci/cd functionality via actions and is due to it’s popularity well known among developers.

Package

We are using Apache Maven to build our Software and wrap it into Docker Container. While Maven is kind of standard, it could be that we switch to Gradle when we need this flexibility.

In the world of Containers, Docker is for sure the standard with nothing currently really competing as of know. We the recent changes in Management in the Company behind Docker, this could change in future, but as of now, we are safe.

Build/Deploy

The build will be triggered in GitHub via GitHub-Actions. Once the project has been build as a Docker Image, it will be uploaded to GitHub Packages.

Then the following will be triggered

  1. Fetch the docker image from GitHub-Packages

  2. Create new Server-Instance in Hetzner-Cloud via CLI-Tool or Cloud API

  3. Bootstrap the Server-instance by installing docker in it

  4. Load and start the docker image in the instance

  5. Retarget the load balancer (NGINX?) to the new instance if applicable.

  6. Destroy the old instance if everything works