Our technology stack

Let us show you briefly what technologies we use. We will not explain why we have chosen those here. This is subject to our Arc42 based Architecture Documentation.

Backend/Data Science

Java
for general programming

Python
for data-related tasks and scripting

Spring Boot
for Java microservices

Flask
for Python microservices

Frontend

Javascript

Typescript

Angular
For our Single Page Application

Infrastructure

PostgreSQL
as our default database

Docker
for containerization

Cloud Init
for bootstrapping cloud instances

Docker-Compose
for development and deployment

S3 - Minio
our S3 Bucket Implementation

Keycloak
our Iam System

Nginx
for delivering our Angular App

Hetzner Cloud
Our cloud provider

Elastic Stack
for monitoring and logging

Traefik
Traffic routing and SSL-Handling

GitHub
Version control/Tickets

GitHub Actions
CI/CD

Apache Kafka
for messaging

Organisational

Nextcloud
Project coordination

Collabora Office
Project coordination

Figma
Prototyping UIs

Asciidoctor
This kind of documentation

Key drivers for technical decisions

Any decision should be as little opinionated as possible
We should never choose a technology just because we consider it as cool or because we have had good experience with it in another use case. Decisions should be made depending on the use case.
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
Best of breed
Default for standard options. Eg. when there are several similar web frameworks, go for the more prominent one. Because we expect that:
- we are getting more support from other developers if we run into problems
- expect more support from the upstream project itself, and also the project itself will exist for a longer time
- have better tooling support (if applicable)
- have it easier to find more developers
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.

Some criteria could conflict with others. Life is not always easy.