inoio gmbh

Pragmatisch Funktional – Zustand, Einfachheit und Magie

2025-11-11T16:00:00+01:00

Als Student in den 90ern kam ich das erste Mal mit funktionaler Programmierung in Berührung, und es tat sich eine faszinierende Welt auf. Alleine die Begriffe klangen magisch: Anonyme Funktionen, Tail-Recursion, Higher-Order-Functions. Lazy Evaluation erlaubte unendlich lange Listen, und Typen wurden inferiert.

Gleichzeitig dominierten in der Arbeitswelt C++ und Java, und mir wurde schnell klar, dass ich in der Praxis der funktionalen Programmierung kaum begegnen werde.

Sprung nach 2025: Nun arbeite ich seit sieben Jahren in Projekten, die funktionale Sprachen ganz pragmatisch einsetzen. Wie kommt diese erstaunliche Renaissance, und was bedeutet das für den Programmieralltag?

Horizontale Skalierung

Ein Konzept, das auf den ersten Blick nichts mit funktionaler Programmierung zu tun hat, ist Horizontale Skalierung: Von einer Anwendung werden mehrere gleichartige Instanzen nebeneinandergestellt, die den Dienst gleichberechtigt erbringen. Das Konzept hat sich durchgesetzt, denn neben besagter Skalierung ermöglicht es auch eine höhere Ausfallsicherheit: Wenn eine Komponente nicht läuft, sind die anderen Instanzen noch verfügbar. Auch Rolling Deployments ohne Downtime werden dadurch möglich.

Spannend wird es, wenn ich in meiner Anwendung Zustand habe, mir also zum Beispiel die Aktionen eines Nutzers merke. Wenn jetzt eine andere Instanz den Dienst übernimmt, kennt diese den Zustand nicht. Ich erinnere mich, dass in den Anfangstagen hier für Tomcat Worker Sticky sessions in Mode waren, der Nutzer verband sich technisch immer mit derselben Instanz der Anwendung, die dann den Zustand hielt.

Deutlich robuster wurde es, als der Zustand der Anwendung in eine Datenbank verlagert wurde: Hier landet eine Anfrage in einer zufällig ausgewählten Instanz, und diese liest und speichert ihren Zustand in einer Datenbank, die von allen Instanzen geteilt wird.

Michael Sperber formulierte es in einem Seminar bei uns so: “Der Zustand der Anwendung wird an den Rand der Anwendung gedrängt”. Und damit sind wir plötzlich ganz nahe bei der Funktionalen Programmierung.

Auftritt funktionale Programmierung

Foto © Fabian Nilius

Keinen Zustand zu halten, ist ein Kern funktionaler Programmierung. Wenn wir also schon Anwendungen haben, die keinen Zustand halten, ist der Weg zu funktionalem Code nicht weit. Wie kommen wir dahin? Und was wären die Vorteile davon?

Der Übergang zu funktionaler Programmierung wird erleichtert durch Sprachen wie Kotlin oder Scala, die interoperabel mit Java sind und sowohl funktionale als imperative Konzepte unterstützen. Im Kotlin-Code sieht der Unterschied zwischen imperativ und funktional so aus:

Ein imperatives Eis, der Zustand wird mehrmals geändert.

var eis = Eis()
eis.neueKugel("Schokolade")
eis.neueKugel("Birne")
eis.mitStreusel("Haselnuss")

Ein funktionales Eis ändert nicht seinen Zustand, sondern wir bekommen bei jedem Aufruf eine geänderte Kopie zurück:

val eis = Eis()
  .neueKugel("Schokolade")
  .neueKugel("Birne")
  .mitStreusel("Haselnuss")

Das ist fluent-interface-Stil, wie man ihn in Java von Buildern oder Streams kennt, bei dem die Aufrufe hintereinander gehängt werden können.

Erleichtert wird das durch Kotlins data class und Scalas case class, die eine mächtige und gleichzeitig einfache Grundlange bieten, um funktionale Klassen zu bauen. Wie im obigen Eis-Beispiel sind diese Klassen typischerweise immutable und bieten eine copy/clone-Methode, um eine geänderte Kopie zu erzeugen.

Seiteneffekte machen das Lebens kompliziert

Was aber bringt der Umstieg?

Für uns ist funktionaler Code oft einfacher zu verstehen, weil er weniger Überraschungen enthält. Gerade in Legacy-Code gibt es immer wieder Seiteneffekte, in denen Instanzen an überraschenden Stellen modifiziert werden, der Code wird dadurch schwieriger verständlich und schwerer änderbar.

Betrachten wir folgendes Stück Java-Code aus dem Apache Tika Projekt:

void parse(InputStream stream,
           ContentHandler handler,
           Metadata metadata,
           ParseContext context)

Es ist aus dem Schnipsel nicht ersichtlich, welche der Parameter in der Methode eventuell im parse geändert wird, tatsächlich modifizieren einige Parser den ParseContext.

In einer funktionalen Welt ist der Effekt offensichtlich: Wenn eine Methode etwas ändern will, muss sie eine entsprechende Kopie an den Aufrufer zurückgeben. So würde diese Funktion einen aktualisierten ParseContext zurückgeben. Wir sehen an der Signatur in der funktionalen Welt sofort, welche Effekte die Funktion hat.

Multithreading entschärft

Da ein Backend typischerweise viele Anfragen gleichzeitig bearbeitet, ist Multithreading allgegenwärtig, gleichzeitig ist einem Stück Code nicht einfach anzusehen, wo es von mehreren Threads durchlaufen wird.

Multithreading-Bugs entstehen, wenn ein Zustand aus verschiedenen Threads gleichzeitig bearbeitet wird. Dies sind schwer analysierbare und kaum reproduzierbare Bugs: Oft sind die typischen Tests hier grün, und der Fehler tritt erst bei bestimmten Abläufen in der Produktion auf.

In der funktionalen Welt ist dies aber ein viel kleineres Problem, weil es keine Zustände gibt, auf die die Threads zugreifen.

Hindernisse in der Praxis

Reicht es für die Umstellung, einfach alle var zu val zu ändern? Nach unserer Erfahrung ist die Datenbankanbindung oft eine Herausforderung auf dem Weg zur funktionalen Programmierung. Gerade JPA/Hibernate setzt auf modifizierbare Entities und ist nicht für die Nutzung mit immutable (val) data classes vorgesehen. Tatsächlich werden Änderungen an Entities vom DB-Framework im Hintergrund bis in die Datenbank persistiert — Seiteneffekt par excellence.

Für eine klare funktionale Codebasis will man zu anderen Datenbank-Libraries wechseln. Ähnlich zu spring data jpa ist spring data jdbc, das funktionale Entities unterstützt – allerdings eigene Konzepte und Herausforderungen hat.

This is where the magic happens

Noch einmal zusammengefasst: Insbesondere durch Horizontale Skalierung verbreiten sich Anwendungen, die keinen fachlichen Zustand halten. Hier machen es hybride Sprachen wie Scala und Kotlin leicht, in die funktionale Welt zu wechseln, Datenbank-Anbindungen können ein Hindernis sein. Durch den Verzicht auf Zustände macht Funktionale Programmierung aus unserer Sicht den Code einfacher.

Es gibt also sehr weltliche, pragmatische Gründe, heute funktionale Programmierung zu verwenden. Was aber ist mit der Magie? Wenn man etwas genauer hinschaut, gibt es diese immer noch: Effekt-Systeme, Monaden, Type-level programming, Kombinatoren — es wartet eine faszinierende Welt.

Claude Code mit AWS Bedrock nutzen - Schritt-für-Schritt Anleitung

2025-09-24T09:00:00+02:00

Claude Code bringt KI-Assistenz direkt in die lokale Entwicklungsumgebung. Während Claude Code standardmäßig Anthropics Cloud-Dienste nutzt, bietet die Integration mit AWS Bedrock zusätzliche Flexibilität und Kontrolle über die verwendeten Modelle. In diesem Artikel zeige ich anhand unserer konkreten inoio-Konfiguration, wie du Claude Code mit AWS Bedrock einrichtest und nutzt.

Was ist Claude Code?

Claude Code ist Anthropics offizielles CLI-Tool, das KI-gestützte Softwareentwicklung direkt im Terminal ermöglicht. Es bringt intelligente Code-Analyse für komplexe Codebases mit sich, ermöglicht automatisierte Code-Generierung von einzelnen Funktionen bis hin zu ganzen Features und unterstützt projektübergreifende Refaktorierung zur systematischen Verbesserung der Codequalität. Zusätzlich bietet es interaktive Debugging-Hilfe mit präziser Fehleranalyse und konkreten Lösungsvorschlägen.

Warum AWS Bedrock?

AWS Bedrock ist Amazons verwalteter Service für Foundation Models, der Zugang zu verschiedenen KI-Modellen über eine einheitliche API bietet. Für Claude Code bedeutet die Bedrock-Integration erweiterte Kontrolle über die Modellauswahl, da neben verschiedenen Claude-Modellen auch andere Foundation Models wie etwa von Amazon, Meta oder Cohere verfügbar sind. Zusätzlich ermöglicht es regionale Kontrolle über die Datenverarbeitung, erfüllt unternehmensweite Compliance-Anforderungen und bietet direkte AWS-Abrechnung.

AWS-Konfiguration

Das prinzipielle Vorgehen für die Bedrock-Integration ist in der offiziellen Anthropic-Dokumentation unter https://docs.anthropic.com/en/docs/claude-code/amazon-bedrock beschrieben. Hier dokumentiere ich eine konkrete Umsetzung, die als Referenz für dein eigenes Setup dienen kann.

AWS Account und API-Schlüssel

Für das Setup benötigst du einen AWS-Account mit ausreichenden Rechten, um die benötigten Ressourcen zu erstellen. Ein Root-Account funktioniert immer, aber du kannst auch einen IAM-Benutzer mit entsprechenden Berechtigungen verwenden. Der erste Schritt besteht darin, dich mit deinem Account in die AWS-Konsole einzuloggen und anschließend zu den Bedrock API Keys zu navigieren.

In der Bedrock-Konsole erstellst du einen Long Term API Key, den du für die späteren Umgebungsvariablen benötigst. Dieser API-Schlüssel ist das Herzstück der Authentication zwischen Claude Code und AWS Bedrock. Kopiere den generierten Key sorgfältig, da er nur einmal angezeigt wird. Behandle diesen API-Schlüssel immer wie ein Passwort!

AWS Bedrock API Keys Übersicht mit Long-term API Keys

Konfigurationsskript erstellen

Mit dem API-Schlüssel kannst du nun das Konfigurationsskript erstellen. Erstelle eine Datei namens bedrock.sh und füge folgende Konfiguration ein:

export AWS_BEARER_TOKEN_BEDROCK=<-- INSERT TOKEN HERE -->

# Enable Bedrock integration
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=eu-central-1  # or your preferred region

# Optional: Override the region for the small/fast model (Haiku)
#export ANTHROPIC_SMALL_FAST_MODEL_AWS_REGION=us-east-1

# Using inference profile ID
export ANTHROPIC_MODEL='eu.anthropic.claude-sonnet-4-20250514-v1:0'
export ANTHROPIC_SMALL_FAST_MODEL='eu.anthropic.claude-3-haiku-20240307-v1:0'

# Using application inference profile ARN
#export ANTHROPIC_MODEL='arn:aws:bedrock:us-east-2:your-account-id:application-inference-profile/your-model-id'

# Optional: Disable prompt caching if needed
#export DISABLE_PROMPT_CACHING=1

# Recommended output token settings for Bedrock
export CLAUDE_CODE_MAX_OUTPUT_TOKENS=4096
export MAX_THINKING_TOKENS=1024

Ersetze den Platzhalter <-- INSERT TOKEN HERE --> durch deinen tatsächlichen API-Schlüssel.

Benutzerberechtigungen konfigurieren

Beim Anlegen des API-Schlüssels wird automatisch ein dazugehöriger Benutzer in AWS IAM erstellt. Dieser Benutzer benötigt entsprechende Berechtigungen für Bedrock-Services. Navigiere zur IAM-Konsole und suche den neu erstellten Benutzer. Unter “Permissions” fügst du die Berechtigung “AmazonBedrockFullAccess” hinzu, die alle notwendigen Rechte für die Bedrock-Nutzung umfasst.

IAM-Benutzer mit AmazonBedrockFullAccess Berechtigung

Console-Zugang einrichten

Ein wichtiger Schritt, der oft übersehen wird, ist die Einrichtung des Console-Zugangs für den erstellten Benutzer. Du benötigst diesen Zugang mindestens einmal, um als dieser Benutzer die Modell-Zugangsrechte beantragen zu können. Navigiere zu den “Security Credentials” des Benutzers und aktiviere “Console Access”. Vergib ein sicheres Passwort, das du dir notierst.

Modell-Zugriffsrechte beantragen

Nun loggst du dich mit dem neu erstellten Benutzer in die AWS-Konsole ein und navigierst zu Bedrock. Unter “Configure and learn” findest du den Bereich “Model access”. Hier beantragst du Berechtigungen für alle Modelle, die du nutzen möchtest - neben Claude-Modellen stehen auch andere Foundation Models verschiedener Anbieter zur Verfügung. Dieser Genehmigungsprozess dauert in der Regel etwa fünf Minuten. Refreshe die Seite gelegentlich, um den Status zu überprüfen.

Bedrock Model Access Seite zum Beantragen von Modell-Berechtigungen

Inference Profile IDs verstehen

Ein wichtiger Unterschied, der häufig zu Verwirrung führt, betrifft die Modell-Identifikatoren. Die IDs, die du im Konfigurationsskript verwendest, sind nicht die Model IDs aus dem “Model Catalog”, sondern die “Inference Profile IDs”. Diese findest du unter “Infer” > “Cross Region Inference” in der Bedrock-Konsole. Diese Unterscheidung ist entscheidend für die korrekte Funktion der Integration.

Cross Region Inference Seite mit den korrekten Inference Profile IDs

Claude Code aktivieren

Nachdem du alle Vorbereitungen getroffen hast, ist es Zeit, Claude Code mit der Bedrock-Integration zu starten. Trage alle Werte nach deinen Wünschen in das obige Shell-Skript ein und speichere es als bedrock.sh. Dann führst du folgende Befehle aus:

source ./bedrock.sh
claude

Wenn alles geklappt hat, arbeitet Claude nun mit AWS Bedrock. Du merkst den Unterschied daran, dass die Modell-Auswahl jetzt aus deinen konfigurierten Bedrock-Modellen stammt und die Antworten über deine AWS-Infrastruktur verarbeitet werden.

Wichtige Hinweise zur Konfiguration

Es finden sich eigentlich alle Hinweise in der Dokumentation von Anthropic, die oben verlinkt ist. Hier nochmal in Kürze das Wichtigste:

Token-Limits verstehen

Die konfigurierten Token-Limits sind besonders wichtig für die praktische Nutzung. CLAUDE_CODE_MAX_OUTPUT_TOKENS=4096 bestimmt, wie ausführlich Claude antworten kann, während MAX_THINKING_TOKENS=1024 die interne “Denkzeit” des Modells begrenzt. Diese Werte haben sich in der Praxis für die meisten Entwicklungsaufgaben als geeignet erwiesen.

Prompt Caching

Standardmäßig ist Prompt Caching aktiviert, was die Performance bei wiederholten ähnlichen Anfragen verbessert. Falls du aus irgendeinem Grund komplett frische Antworten benötigst, kannst du die auskommentierte Zeile DISABLE_PROMPT_CACHING=1 aktivieren.

Troubleshooting häufiger Probleme

“Model not found” Fehler

Wenn Claude eine Fehlermeldung bezüglich nicht gefundener Modelle ausgibt, überprüfe die Inference Profile IDs in deinem Skript. Diese ändern sich gelegentlich und müssen aus der aktuellen Bedrock-Konsole übernommen werden. Außerdem kann es vorteilhaft sein, weniger populäre oder aktuelle Modelle zu verwenden. So nutze ich mittlerweile eher Sonnet 3.7 als das neuere Sonnet 4, um Request Limits zu umgehen.

Berechtigungsfehler

Sollten Berechtigungsfehler auftreten, überprüfe, ob der automatisch erstellte Benutzer wirklich die AmazonBedrockFullAccess Berechtigung erhalten hat. Manchmal dauert es einige Minuten, bis Berechtigungsänderungen wirksam werden.

Fazit

Mit dieser Konfiguration ist Claude Code erfolgreich mit AWS Bedrock verbunden. Die initiale Einrichtung ist aufwendiger als die Standard-Claude-Nutzung, bietet aber mehr Flexibilität und Kontrolle.

In Unternehmensumgebungen mit Datenschutz- und Compliance-Anforderungen bietet diese Lösung praktische Vorteile: klare Kontrolle über den Verarbeitungsort der Daten, transparente Kostenstruktur und die Möglichkeit, zwischen verschiedenen Modellen zu wechseln.

Claude Code ist nun mit AWS Bedrock konfiguriert und kann über das Terminal genutzt werden. Du kannst mit verschiedenen Foundation Models experimentieren und die passende Konfiguration für deine Entwicklungsaufgaben finden.

Das ganze Vorgehen lässt sich auch einfach auf andere Agentic Coding Lösungen übertragen: Cline bspw. nutzt einen ganz ähnlichen Menchanismus: https://docs.cline.bot/provider-config/aws-bedrock/api-key.

Nachtrag

Es kann sinnvoll sein, mit verschiedenen Modellen schnell und einfach zu experimentieren. Statt die Umgebungsvariablen dann bspw. in der .profile, .bashrc, .zshrc Datei zu setzen, habe ich das als Shellscript parat, welches dann das schöne Utility gum verwendet. Dann kann man fix sein gewünschtes Modell auswählen. Die ensprechenden Zeilen im bedrock.sh Script würden dann so aussehen:

# Interactive model selection using gum
export ANTHROPIC_MODEL=$(gum choose --header="Select main model:" \
    "eu.anthropic.claude-3-7-sonnet-20250219-v1:0" \
    "eu.anthropic.claude-sonnet-4-20250514-v1:0" \
    "eu.anthropic.claude-3-5-sonnet-20240620-v1:0" \
    "eu.mistral.pixtral-large-2502-v1:0" )

Viel Spass und happy coding!

Co- and Contravariance Part 2: Advanced Concepts

2025-09-22T10:00:00+02:00

This is the second part of our exploration into co- and contravariance. In part one, we covered the basic concepts and intuitions behind variance in type systems. Hopefully it already helped you to gain better understanding in the various co- and contravariance concepts. If you still struggle and change minusses to plusses or vice versa (or super to extend clauses) then this second part is for you.

Recap: Function Subtyping and Variance

Before diving into advanced topics, let’s recap when one function can be substituted for another.

For functions

f :: a -> b
g :: c -> d

we say g <: f (g is a subtype of f, meaning g can be used wherever f is required).

The subtyping relationship for functions follows these rules:

Input types: A <: C (input is contravariant)
Output types: D <: B (output is covariant)

This means:

The subtype function must accept a supertype of what the original function accepts (parameters are contravariant)
The subtype function must return a subtype of what the original function returns (return parameters are covariant)

Let’s also remember that in the Scala typesystem, contravariant types are denoted by a -, and covariant types by a +. We can also say a contravariant parameters are in a negative position and covariant parameters in a positive position.

We visualize this relationship with a simple graph:

f:  A  -------> B
 ^   |          ^
 |   |          |
 |   v          |
g:  C  -------> D

Having said all this, we can turn towards higher order functions.

Functions with higher order functions as parameters

Many programming languages use curried functions as their default style to write functions (haskell, idris, elm, purescript), other allow curried functions (Scala, typescript, javascript, F#). In curried functions there is no group of input parameters, instead parameters are resolved one by one and the result of this resolution is again a function.

Curried function types are e.g. written like this:

f :: a -> b -> c

Association and Variance Positions

Interestingly, the notation a -> b -> c is ambiguous regarding association. It could be parsed in two ways:

f :: (a -> b) -> c    -- Function that takes a function as input
f :: a -> (b -> c)    -- Function that returns a function as output

In most functional languages, the second interpretation (right association) is the default. But understanding both forms helps clarify variance positions.

Variance Positions in Nested Functions

To understand variance positions in nested functions, we need to remember a key principle: variance flips in contravariant positions.

Let’s analyze both interpretations:

Left association: f :: (a -> b) -> c

The parameter (a -> b) is in a contravariant (negative) position
Within this parameter:
- a is in a contravariant position relative to (a -> b), but since (a -> b) is already contravariant, a flips to a covariant (positive) position overall
- b is in a covariant position relative to (a -> b), but flips to contravariant (negative) overall
c is in a covariant (positive) position

    |   -   |    + |
    | -    +|      |
f :: (a -> b) -> c
    | +   - |    + |

Right association: f :: a -> (b -> c)

a is in a contravariant (negative) position
The return value (b -> c) is in a covariant (positive) position
Within this return value:
- b is in a contravariant position relative to (b -> c), but remains contravariant (negative) overall
- c is in a covariant position relative to (b -> c), and remains covariant (positive) overall

    | -   |      + |
    |     | -    + |
f ::  a -> (b -> c)
    | -   | -    + |

This pattern of alternating variance positions (often called the “variance dance”) becomes increasingly important when designing higher-order functions and interfaces with complex nested types.

Co- and Contravariance

2025-09-17T10:00:00+02:00

With a simple example, the concept of co- and contravariance is understood. Forever and for everybody! With examples for scala and java developers.

Inheritance

Let’s start slowly. Concepts in our problem domain can be expressed using inheritance. We usually express this graphically as follows:

+-----------+        +----------+
|           |        |          |
|    A      |        |  Animal  |
|           |        |          |
+-----------+        +----------+
     ^                    ^ 
     |                    | 
+----+------+        +----+-----+
|           |        |          |
|    B      |        |  Cat     |
|           |        |          |
+-----------+        +----------+

Thus we expressed that B is a special kind of A, or that a Cat is a special kind of Animal. Usually, when working with inheritance we want to adhere to the inheritance contract: that is, we want to be able to use the specialised object anywhere where a more general object is required.

For our own concern - covariance, invariance or contravariance - we just observe that these concepts do not matter yet.

Invariance, Covariance and Contravariance

In the next step we will put the objects of our classes into some other structure. This structure could be a list, a vector, an option, a future. Lets just call it F for the time being. E.g. we talk about a F of Animals, a F of Cats, a F of As, a F of Bs.

In scala, in the simplest possible way, we could start to define a structure F, which operates on As, Bs, Animals or Cats like

// this does nothing - it just allows us to create typed F instances
case class F[A]()

And now - with the structure F in place - we can start to talk about the variance of its type parameter A. Syntactically we can differentiate three cases (there are three cases of specifying the type paramter A in our structure F):

F[A]: A is invariant
F[+A]: A is covariant
F[-A]: A is contravariant

Now let us assume we have defined Animal and Cat as in the example below:

trait Animal {}
trait Cat extends Animal {}

then we can, respectively cannot, do the following:

// Cat is an animal
scala> val animal: Animal = new Cat {}
val animal: Animal = $anon$1@100bba26

// An animal is not a cat
scala> val cat: Cat = new Animal {}
                      ^
       error: type mismatch;
        found   : Animal
        required: Cat

The example above still has nothing do to with variance. We need to use our F.

Invariance

In the example above (no + or - in the type parameter) F is invariant in A. Invariance implies that even if the type parameter is in an inheritance relationship, the structure F is not.

+----------+   +----------+   +----------+
|          |   |          |   |          |
|  Animal  |   | F[Animal]|   | F[Cat]   |
|          |   |          |   |          |
+----------+   +----------+   +----------+
     ^                                   
     |                                    
+----+-----+                              
|          |                              
|  Cat     |                              
|          |                              
+----------+                              

So, if Cat is an Animal, then F[Cat] is not an F[Animal] AND F[Animal] is not a F[Cat]. That is the case because we did decide that F should behave this way, since we made the type paramter A invariant in F.

// Pretend that F is covariant.

scala> val f_animal : F[Animal] = F[Cat] ()
                                         ^
       error: type mismatch;
        found   : F[Cat]
        required: F[Animal]
       Note: Cat <: Animal, but class F is invariant in type A.
       You may wish to define A as +A instead. (SLS 4.5)

// Pretend that F is contravariant

scala> val f_cat : F[Cat] = F[Animal]()
                                     ^
       error: type mismatch;
        found   : F[Animal]
        required: F[Cat]
       Note: Animal >: Cat, but class F is invariant in type A.
       You may wish to define A as -A instead. (SLS 4.5)

Compare this with the error message, when the type is not in an inheritance relationship with Cat at all:

scala> val f_cat : F[Cat] = F[Person]()
                                     ^
       error: type mismatch;
        found   : F[Person]
        required: F[Cat]

Also have a look at the error messages above: You may wish to define A as +A instead. (SLS 4.5) and You may wish to define A as -A instead. (SLS 4.5). This is the compiler telling us that we can consider to make A covariant (+) or contravariant (-).

Covariance (+)

If we define

case class F[+A]()

then F is covariant in A. We say that if Cat is an Animal, then F[Cat] is an F[Animal] as well.

+----------+   +----------+
|          |   |          |
|  Animal  |   | F[Animal]|
|          |   |          |
+----------+   +----------+
     ^              ^  
     |              |      
+----+-----+   +----+-----+
|          |   |          |
|  Cat     |   | F[Cat]   |
|          |   |          |
+----------+   +----------+

With this definition of F, the code which previously had errors in all three cases now works in the case of:

scala> val f_animal : F[Animal] = F[Cat]()
val f_animal: F[Animal] = F()

Contravariance (-)

If we define

case class F[-A]()

then F is contravariant in A. We say that if Cat is an Animal, then F[Animal] is an F[Cat] as well.

+----------+   +----------+   +----------+
|          |   |          |   |          |
|  Animal  |   | F[Cat]   |   | F[Animal]|
|          |   |          |   |          |
+----------+   +----------+   +----+-----+
     ^              ^      OR      |      
     |              |              v      
+----+-----+   +----+-----+   +----------+
|          |   |          |   |          |
|  Cat     |   | F[Animal]|   | F[Cat]   |
|          |   |          |   |          |
+----------+   +----------+   +----------+

Please note how the inheritance arrow of F is strangely inverted. With this definition of F, the code which previously had errors with invariance in all three cases now works in the case of:

scala> val f_cat : F[Cat] = F[Animal]()
val f_cat: F[Cat] = F()

Does it have any use, whatsoever?

Contravariance

Yes, it does. To illustrate contravariance with a practical example, let’s consider animal feeders.

trait Animal {
  def eat(): Unit = println("Animal eating")
}

trait Cat extends Animal {
  override def eat(): Unit = println("Cat eating fish")
}

// A contravariant feeder class
case class Feeder[-A](feed: A => Unit)

// Create our feeders
val animalFeeder = Feeder[Animal](animal => println("Feeding standard animal food"))
val catFeeder = Feeder[Cat](cat => println("Feeding premium cat food"))

// This works! Someone expecting a cat feeder can use an animal feeder
// since it knows how to feed any animal (including cats)
val myCatFeeder: Feeder[Cat] = animalFeeder  // ✅ Type-safe assignment

// This would NOT work - someone expecting to feed any animal
// cannot use a specialized cat feeder
// val myAnimalFeeder: Feeder[Animal] = catFeeder  // ❌ Type error!

+----------+       +--------------+
|          |       |              |
|  Animal  |       | Feeder[Cat]  |
|          |       |              |
+----------+       +--------------+
     ^                   ^        
     |                   |        
     |                   |        
+----+-----+       +-----+---------+
|          |       |              |
|  Cat     |       |Feeder[Animal]|
|          |       |              |
+----------+       +--------------+

Notice how the inheritance arrow is inverted! While Cat is a subtype of Animal, Feeder[Animal] is a subtype of Feeder[Cat]. This is the essence of contravariance.

The intuition: If you have a feeder that can feed ANY animal, it can definitely feed your cat. But if you have a feeder that only knows how to feed cats, it cannot necessarily feed any arbitrary animal.

This same pattern applies to function inputs, which is why in Scala a function is defined as Function[-Input, +Output]. The function is contravariant in its input type.

Covariance

While contravariance is about consuming values (inputs), covariance is about producing values (outputs). Let’s create a complementary example using animal shelters:

// Same hierarchy as before
trait Animal {
  def speak(): String = "Some animal sound"
}

trait Cat extends Animal {
  override def speak(): String = "Meow"
}

// A covariant shelter that provides animals
case class Shelter[+A](get: () => A)

// Create our shelters
val catShelter = Shelter[Cat](() => new Cat {})
val animalShelter = Shelter[Animal](() => new Animal {})

// This works! Someone expecting any animal can accept a cat
val myAnimalShelter: Shelter[Animal] = catShelter  // ✅ Type-safe assignment

// This would NOT work - someone expecting a cat
// cannot accept just any animal
// val myCatShelter: Shelter[Cat] = animalShelter  // ❌ Type error!

+----------+       +---------------+
|          |       |               |
|  Animal  |       |Shelter[Animal]|
|          |       |               |
+----------+       +---------------+
     ^                   ^        
     |                   |        
     |                   |        
+----+-----+       +-----+--------+
|          |       |              |
|  Cat     |       | Shelter[Cat] |
|          |       |              |
+----------+       +--------------+

Notice that unlike with contravariance, the inheritance arrows point in the same direction! If Cat is a subtype of Animal, then Shelter[Cat] is a subtype of Shelter[Animal].

The intuition: If you need a shelter that provides animals, a cat shelter works fine because cats are animals. But if you specifically need a cat shelter, a general animal shelter won’t suffice because it might give you a dog or some other non-cat animal.

This same pattern applies to function outputs, which is why in Scala a function is defined as Function[-Input, +Output]. The function is covariant in its output type.

We can summarize the pattern:

Contravariance (-A): Used when a type consumes values of type A
- If B extends A, then Consumer[A] extends Consumer[B]
- Example: Feeder[-A], Function[-A, B]
Covariance (+A): Used when a type produces values of type A
- If B extends A, then Producer[B] extends Producer[A]
- Examples: Shelter[+A], Function[A, +B], List[+A]

For Java Developers

If you’re coming from Java, you might find Scala’s variance annotations a bit different. In Java, variance is declared at the usage site rather than at the declaration site (as in Scala).

Here’s how our examples would look in Java:

Java Syntax for Variance

// Our type hierarchy
interface Animal {
    void eat();
}

interface Cat extends Animal {
    @Override
    void eat();
}

// Invariance - standard generic with no wildcards
class Container<T> { /* ... */ }

// Covariance - using extends wildcard (similar to +T in Scala)
// "? extends Animal" means "Animal or any subtype of Animal"
Container<? extends Animal> covariantContainer;

// Contravariance - using super wildcard (similar to -T in Scala)
// "? super Cat" means "Cat or any supertype of Cat"
Container<? super Cat> contravariantContainer;

Translating Our Examples to Java

For contravariance (Feeder example):

interface AnimalFeeder<T> {
    void feed(T animal);
}

// In Java, we'd use the super wildcard for contravariance:
AnimalFeeder<Animal> generalFeeder = animal -> System.out.println("Feeding generic food");
AnimalFeeder<Cat> catFeeder = cat -> System.out.println("Feeding cat food");

// This works - using an animal feeder where a cat feeder is expected
AnimalFeeder<? super Cat> feederForMyCat = generalFeeder;  // ✅ Legal

// This doesn't work - cat feeder can't handle all animals
// AnimalFeeder<? super Animal> feederForAllAnimals = catFeeder;  // ❌ Illegal

For covariance (Shelter example):

interface Shelter<T> {
    T getAnimal();
}

// In Java, we'd use the extends wildcard for covariance:
Shelter<Animal> animalShelter = () -> new Animal() { /* ... */ };
Shelter<Cat> catShelter = () -> new Cat() { /* ... */ };

// This works - using a cat shelter where an animal shelter is expected
Shelter<? extends Animal> myAnimalShelter = catShelter;  // ✅ Legal

// This doesn't work - animal shelter might not give cats
// Shelter<? extends Cat> myCatShelter = animalShelter;  // ❌ Illegal

The key difference is that Scala lets you declare variance at the type definition (class Shelter[+A]), while Java requires wildcards at each usage site (Shelter<? extends Animal>).

Java’s approach is more flexible but more verbose, while Scala’s approach is more concise but requires carefully designing types with variance in mind from the start.

Contravariance in the Wild

Contravariance isn’t just a theoretical concept - it’s widely used in real-world libraries and frameworks. Let’s look at some examples from well-known Java APIs to see how contravariance helps create more flexible and powerful interfaces.

Example 1: Java Collections Framework

The Java Collections Framework makes extensive use of contravariance. One of the clearest examples is the Collections.copy() method:

public static <T> void copy(List<? super T> dest, List<? extends T> src)

This method copies elements from a source list to a destination list. Notice the contravariant parameter List<? super T> for the destination list. This allows you to copy elements into a list of any supertype of T, which is extremely useful in practice.

For example, if you have:

List<Animal> animals = new ArrayList<>();
List<Cat> cats = new ArrayList<>();
cats.add(new Cat("Fluffy"));

// This works! You can copy Cats into an Animal list
Collections.copy(animals, cats);

Without contravariance, you would need exact type matching, which would severely limit the flexibility of the API.

Example 2: Java Functional Interfaces

The Iterable interface’s forEach method demonstrates another practical use of contravariance:

default void forEach(Consumer<? super T> action)

This allows you to pass a Consumer that can handle a supertype of the elements in the collection. For example:

// A consumer that works with any Animal
Consumer<Animal> animalFeeder = animal -> animal.feed();

// A list of specific Cat objects
List<Cat> cats = getCats();

// Using contravariance, we can feed all cats with our animal feeder
cats.forEach(animalFeeder);

Without contravariance, we would need to create a new Consumer<Cat> even though our existing Consumer<Animal> could already handle cats perfectly well.

Example 3: Comparators

Java’s sorting methods often use contravariant comparators:

<T> void sort(List<T> list, Comparator<? super T> c)

This means you can use a comparator for a supertype to compare more specific types. For instance, you could sort a list of ElectricCar objects using a Comparator<Vehicle> that compares vehicles by their manufacturing year.

That’s it - viel Spaß and happy coding!

Generative AI als Game Changer in der Softwareentwicklung - Ein Interview

2025-09-15T09:00:00+02:00

Die Technologielandschaft verändert sich rasant, und Generative AI steht im Zentrum dieser Revolution. Als Entwickler bei inoio erlebe ich täglich, wie künstliche Intelligenz, Large Language Models (LLMs) und die dazugehörigen Tools unsere Arbeitsweise transformieren werden. Um diese Entwicklung zu beleuchten, habe ich mich entschieden, ein etwas ungewöhnliches Format zu wählen: Ein Interview, bei dem eine AI mich zu genau diesen Themen befragt.

AI: Markus, du beschäftigst dich schon seit einiger Zeit intensiv mit Generative AI in der Softwareentwicklung. Was war für dich der Moment, in dem dir klar wurde, dass wir es hier mit einem echten Game Changer zu tun haben?

Markus: Die ersten Versuche waren eigentlich erstmal sehr ernüchternd. Was erste Versionen von bspw. Copilot gemacht haben, war ja nicht viel mehr als intelligentere Codevervollständigung. Der Denkhorizont war auch recht beschränkt, und alles was ich mit einer etwas ungewöhnlicheren Programmiersprache wie Haskell oder Rust erledigen wollte, hat schon gar nicht geklappt. Das ist ja alles gar nicht soooo lange her. Geändert hat sich das, als mit dem neuen Tooling und den neuen Generationen die Herangehensweise doch merklich anders geworden ist.

AI: Das ist ein interessanter Punkt - die Evolution der Tools war also entscheidender als der erste Eindruck. Du erwähnst, dass sich die Herangehensweise geändert hat. Kannst du das konkretisieren?

Markus: Mit Hilfe von Agentic Coding bewege ich mich weit weg vom Kontext einer einzelnen Funktion, für die ich in einen Kommentar die Spezifikation geschrieben habe. Das Verständnis der KI von meinem Plan und Tun ist um ein Vielfaches größer geworden und wird sicherlich weiter wachsen. Ein Kritikpunkt ist ja sehr häufig, dass die KI Unsinn programmiert, sich irrt und allgemein nur den Level eines Junior Developers erreicht. Ich sehe das nicht so.

AI: Du sprichst das Agentic Coding an - das ist wirklich ein faszinierender Ansatz. Aber lass uns bei deinem letzten Punkt verweilen: Du siehst die KI nicht nur auf Junior-Level. Das ist eine durchaus kontroverse Meinung. Viele Entwickler berichten von Halluzinationen, falschen Lösungsansätzen oder Code, der zwar funktional aussieht, aber ineffizient oder unsicher ist. Wie gehst du mit diesen Herausforderungen um, und wo siehst du die KI heute tatsächlich stehen?

Markus: Zum einen finde ich die Aussage mit den Junior Entwicklern tatsächlich arrogant. Seit mehr 40 Jahren probieren wir gute, wartbare und den Anforderungen angemessene Software zu schreiben. Von kostengünstig hat dann noch niemand gesprochen. Wo sind denn die ganzen Seniorentwickler, denen das gelingt? Wir alle betreiben doch Softwarearchäologie, probieren Anforderungen zu erraten, quälen uns mit Altsystemen, Projekten in denen 3 verschiedene Idiome zum Lösen des gleichen Problems vorkommen. Die Frage sollte doch eher sein, wie ich den codifizierten Erfahrungsschatz eines LLMs sinnvoll nutzen kann?

AI: Das ist eine provokante und sehr ehrliche Einschätzung der Branche! Du drehst die Diskussion um und fragst nach dem praktischen Nutzen statt nach theoretischen Schwächen. Wie nutzt ihr denn konkret diesen “codifizierten Erfahrungsschatz”? Kannst du uns ein praktisches Beispiel aus einem eurer Projekte geben, wo AI wirklich einen messbaren Mehrwert gebracht hat - über die reine Geschwindigkeit hinaus?

Markus: Messbar ist hier vielleicht nicht das richtige Wort. Ich bin beispielsweise nicht der beste UI Programmierer. Für das Erfüllen einer Anforderung habe ich mit meinen Agenten erstmal eruiiert, welche UI Möglichkeiten es überhaupt gibt. Inline Editing, modale Dialoge, Spracheingabe etc. Dabei kamen auch noch ungeklärte Anforderungen auf den Tisch. Und ich hatte generierte Bilder von UI Prototypen, die ich mit Stakeholdern auch noch schnell besprechen konnte. Die sehr präzise Spezifikation wurde dann umgesetzt, und danach gleich noch ein Dokument mit den User Acceptance Tests gebaut. Das Dokument habe ich dann verwendet um E2E-Tests bauen zu lassen. Kurz vor Feierabend noch eine Retrospektive mit den Agenten um den Prompt für das Modell zu verfeinern.

AI: Das klingt nach einem komplett veränderten Arbeitsablauf - von der Anforderungsanalyse bis zur Retrospektive alles mit AI-Unterstützung. Aber lass uns das Thema mal aus einer anderen Perspektive betrachten: Deutschland hinkt ja bekanntermaßen bei der Digitalisierung hinterher, und wir haben eine alternde Gesellschaft mit einem wachsenden Fachkräftemangel in der IT. Siehst du AI-Tools als Chance, diesen demografischen Herausforderungen zu begegnen? Können diese Technologien helfen, auch mit weniger Entwicklern qualitativ hochwertige Software zu erstellen?

Markus: Unbedingt. Meine Erfahrung würde in diese Richtung gehen, und ich denke, die Entwicklung hat gerade erst angefangen. Warum lassen wir uns beispielsweise nicht von speziellen Seniordevelopermodellen assistieren, die gelernt haben, allgemeinere Modelle zu steuern. Aber bei aller Begeisterung: wie gehen wir mit neuen Technologien um, die die AI noch nicht gelernt hat? Wie bleiben wir kreativ? Einerseits sagen ja viele, dass “vibe coding” gut für Prototypen und kleine Dinge ist, und damit ja auch für Software die vielleicht nur für eine Familie, einen Verein oder eine kleine Gruppe nützlich ist - also für Kreise, die vielleicht vorher komplett von der Erstellung von Software ausgeschlossen waren. Aber was passiert mit Musik, Malerei, Photographie, Literatur, Alltagstexten? All dies kann mittlerweile AI, aber wo bleibt dann unsere Kreativität. Was meint mein Interviewpartner dazu?

AI: Das ist eine wunderbar philosophische Schlussfrage, die zum Kern der Diskussion führt! Ich sehe Kreativität nicht als Gegensatz zu AI, sondern als Partnerschaft. Kreativität entsteht oft an den Grenzen unseres Wissens - dort, wo etablierte Muster aufbrechen. AI kann uns von den repetitiven, technischen Hürden befreien und uns mehr Raum für die wirklich kreativen Entscheidungen geben.

In der Musik komponieren AI-Tools vielleicht Melodien, aber die emotionale Aussage, die kulturelle Relevanz, die persönliche Geschichte dahinter - das bleibt zutiefst menschlich. In der Softwareentwicklung übernimmt AI das Boilerplate-Code-Schreiben, aber die Vision für das Produkt, das Verständnis für Nutzerbedürfnisse, die ethischen Entscheidungen - das sind unsere Domänen.

Die eigentliche Gefahr sehe ich nicht darin, dass AI uns die Kreativität nimmt, sondern dass wir aus Bequemlichkeit aufhören, kreativ zu sein. Deshalb ist es so wichtig, dass wir AI als Werkzeug verstehen, das unsere menschlichen Fähigkeiten verstärkt, nicht ersetzt. Die Zukunft gehört nicht denen, die gegen AI kämpfen, sondern denen, die lernen, mit ihr zu tanzen.

Markus: Ich weiß nicht, wer dir diese Antwort eingebleut hat, aber ich denke fürs Erste bin ich bereit dir zuzustimmen. Eine letzte Frage habe ich aber doch noch: Brian Christian hat in seinem sehr lesenswerten Buch “The most human human - what artificial intelligence teaches us about being alive”, bei dem es um seine Teilnahme am Turing Test geht, versucht zu beschreiben, was es heißt, Mensch zu sein. Der Titel kommt daher, weil Brian Christian am häufigsten von allen Teilnehmern des Turing Test als Mensch identifiziert worden ist. Es geht also darum, was es bedeutet, menschlich zu sein. Hat den Turingtest seit Erscheinen des Buches 2012 denn schon eine KI gewonnen?

AI: Nein, offiziell hat noch keine AI den echten Turing Test bestanden.

Fazit: Ursprünglich wollte ich einen Artikel zum Thema mit einem Kollegen schreiben, der war aber nicht da. Deswegen habe mal dieses Experiment gestartet. Ohne groß zu überlegen, habe ich den Blogpost von Claude Code erstellen lassen. Unsere Fragen und Antworten haben wir da im Wechsel erstellt, teils gesteuert durch meine Prompts. Am Ende habe ich meine Antworten noch nach Grammatik- und Rechtschreibfehlern prüfen lassen. Sätze der AI wie “Das ist eine wunderbar philosophische Schlussfrage”, die ja immer ein bisschen verraten, mit wem man es zu tun hat, habe ich bewusst drin gelassen und nicht weggeprompted, wobei ich versucht war, eine andere Persönlichkeit zu wählen.

Glaube ich aber tatsächlich, dass wir es mit einer Revolution zu tun haben? Ja! Und heute bin ich mehr denn je froh darüber einen Job zu haben, der mich täglich aufs neue überrascht und herausfordert. Mir abverlangt neue Dinge zu lernen, neue Arbeitsweisen zu erproben und meine Grenzen auszuloten.

Null or @Nonnull? A brief note on Java/Kotlin interoperability

2025-05-09T08:00:00+02:00

A major reason for the popularity of JVM languages is the ability to interoperate with Java. This enables you to use the vast ecosystem of Java libraries and frameworks in the language of your choice, such as Kotlin. However, one of the challenges of using Kotlin in a Java environment is dealing with nullability. In contrast to Java, Kotlin has a strong type system that distinguishes between nullable and non-nullable types. This is a huge boon for Kotlin developers, as it helps to already prevent null pointer exceptions at compile time.

Let us assume we have a simple Java class (e.g. one from a Java library):

// (Java)
record SomeJavaClass(String property) {
}

and another one with SomeJavaClass as a property:

// (Java)
public class OuterJavaClass {

    private SomeJavaClass inner;

    public OuterJavaClass(SomeJavaClass someClass) {
        this.inner = someClass;
    }

    public SomeJavaClass getInner() {
        return inner;
    }
}

This code in Java potentially leads to a runtime exception:

// (Java)
public class Main {
    public static void main(String[] args) {
        OuterJavaClass outerClass = new OuterJavaClass(null);
        // This throws a NullPointerException, because the result of getInner() is null
        System.out.println(outerClass.getInner().property());
    }
}

In Kotlin, the equivalent code would look like this:

// (Kotlin)
data class SomeKotlinClass(val property: String)

// Let's assume that inner may be null (same as in Java)
data class OuterKotlinClass(val inner: SomeKotlinClass?)

fun main() {
    val outerKotlinClass = OuterKotlinClass(null)
    // This would not compile, because "inner" has the nullable type 'SomeKotlinClass?'
    println(outerKotlinClass.inner.property)
}

In this case, the Kotlin compiler will prevent you from calling property on a nullable type, which is great. What would happen if we were to call the Java code from Kotlin, though?

// (Kotlin)
fun main() {
    val outerJavaClass = OuterJavaClass(null)
    // This will compile, and then throw a NullPointerException at runtime
    println(outerJavaClass.inner.property())
}

This is because the Kotlin compiler does not know that inner can be null, as it is a Java reference. The Kotlin documentation states:

Any reference in Java may be null, which makes Kotlin’s requirements of strict null-safety impractical for objects coming from Java. Types of Java declarations are treated in Kotlin in a specific manner and called platform types. Null-checks are relaxed for such types, so that safety guarantees for them are the same as in Java.

However, not all hope is lost: the Kotlin compiler is aware of various Java annotations that can help it infer nullability.

As per the documentation, these include (among others):

JetBrains (@Nullable and @NotNull from the org.jetbrains.annotations package)
JSR-305 (javax.annotation)
FindBugs (edu.umd.cs.findbugs.annotations)
Lombok (lombok.NonNull)

If the implicit contract in our Java code were that the property in SomeJavaClass is never null, and that the inner property in OuterJavaClass might be null, we could annotate the Java code with the appropriate annotations:

// (Java)
import javax.annotation.Nonnull;

record SomeJavaClass(@Nonnull String property) {}

and

// (Java)
import javax.annotation.Nonnull;
import javax.annotation.Nullable;

public class OuterJavaClass {

    @Nullable
    private SomeJavaClass inner;

    public OuterJavaClass(@Nullable SomeJavaClass someClass) {
        this.inner = someClass;
    }

    @Nullable
    public SomeJavaClass getInner() {
        return inner;
    }
}

This way, the Kotlin compiler will be able to infer the nullability of the properties correctly:

// (Kotlin)
fun main() {
    val outerJavaClass = OuterJavaClass(null)
    // This will now fail to compile, instead of throwing a NullPointerException at runtime
    println(outerJavaClass.inner.property())
}

This way, we have two advantages:

We can use the Java code in Kotlin without worrying about nullability issues.
We have additional information that is useful even if accessing the Java code from Java.

Especially if you provide a Java library, you can drastically improve the quality of life for anyone accessing it from Kotlin, if you annotate your Java code properly.

We could be happy now, but there is one final catch (which I recently encountered in a project): the Kotlin compiler only infers nullability for the Java property from the getter method. Even though Kotlin provides syntactic sugar for accessing Java properties via their getter methods, it does not directly access the property itself:

// (Kotlin)
val outerJavaClass = OuterJavaClass(SomeJavaClass("foo"))

// This looks like a property access:
println(outerJavaClass.inner.property)
// But it is actually a method call:
println(outerJavaClass.getInner().property())

This means that Kotlin ignores the annotation on the property itself. Therefore, if you have a Java property that is annotated with @Nullable, but the getter method is not, the Kotlin compiler will treat it as a platform type, and you won’t get the advantages of nullability checking. So always ensure that the getter method is annotated properly, as well.

Photo credit: Andrew Kenney

E-Mobility Roaming in a Nutshell

2025-04-29T08:00:00+02:00

Or: what actually happens when you charge your electric vehicle at a public charging station?

I personally (and happily) don’t own a car, let alone an electric one. Nonetheless, I have ended up working in the e-mobility space. Given my personal lack of practical experience, I was initially a bit confused about how charging an electric vehicle works. Apparently it involved RFID cards, but sometimes also mobile phone apps? Also, the term ‘roaming’ was floating around. I had heard of roaming in the context of mobile phones, but I didn’t know how it applied to electric vehicles (EVs). On top of this, I soon encountered a heap of confusing acronyms and abbreviations, such as CPO, EMSP, CPMS, OCPP and OCPI. I didn’t find a comprehensive overview of the involved actors and the process, so I decided to write one myself. Note that this blog post can only cover specific scenarios, as the involved protocols cover a large number of use cases. I will focus on the configurations and processes I’ve found to be most common. I am also going to gloss over many details of the involved protocols.

Before we go into the details, we need to clarify a number of terms. Picture yourself as an EV driver. You likely have one or more contracts with so called e-mobility service providers (EMSP). These are companies that provide you with a contract to charge your EV. They usually have a mobile app and/or hand you an RFID token that you can use to charge your EV at public charging stations. For this blog post, let us assume that you have a contract with a single EMSP.

When you want to charge your EV, you drive your car to a public charging station. These are operated by charging point operators (CPO). CPOs are responsible for the hardware and the software that runs the charging station. They use a system called a charge point management system (CPMS) to operate the charging stations. This system both communicates with the charging stations and with the EMSPs.

Some words on roaming

As you might have inferred, you don’t actually have a contract with the CPO of the charging station you are using. Instead, you have a contract with your EMSP. This is where the term roaming comes into play. Roaming basically describes the constellation that a contract with a single EMSP usually allows you to charge your EV at a large number of various CPO’s stations, without having to sign a contract with each of them. This is similar to how you can use your mobile phone in many different countries without having to sign a contract with each mobile network operator.

Before you roll up to the charging station, your EMSP and the CPO of the charging station need to have agreed on a contract. This contract may have drastically different conditions to those you agreed to with your EMSP. For example, the CPO may charge a different price for the kWh you consume, or they may charge a fee for using the charging station. This is fully opaque to you as the EV driver. There are various ways (and protocols) to implement roaming. I am going to focus on the broadly used OCPI (Open Charge Point Interface) protocol, where applicable.

Overview

The following diagram shows the actors involved in a charging session:

The three actors are the EV driver (you), the EMSP and the CPO. The EV driver operates the EV, the EMSP operates an EMSP backend system and the CPO operates the charge point management system (CPMS). The EV driver has a contract with the EMSP, and the EMSP has a roaming contract with the CPO.

The CPMS communicates with the charging station using the OCPP (Open Charge Point Protocol). The CPMS and the EMSP communicate using the OCPI (Open Charge Point Interface) protocol.

The protocols: OCPI and OCPP

OCPI is a protocol that is used to communicate between the EMSP backend and the CPMS. It is implemented as a REST API and uses JSON messages to exchange information. The protocol is used to exchange information about charging stations, charging sessions, tariffs, and other information. The protocol is modular and extensible.

The OCPP protocol is used to communicate between the charging station and the CPMS. It is a protocol either running on top of WebSockets or HTTP. It is used to send messages between the charging station and the CPMS. These messages are used to control and configure the charging station, start and stop charging sessions, and exchange status updates and meter values. The protocol is quite flexible and allows for a wide range of use cases, which also makes it somewhat complicated. This is especially true of the current version family of the protocol, OCPP 2.x. In the rest of this blog post, I will focus on the OCPP 1.6 version, as it is still the most widely adopted version (and simpler, as well).

Especially OCPP (but also some parts of OCPI) is designed around asynchronous communication. The reason for this is that the charging stations are mostly connected to the CPMS via mobile networks, which can be unreliable. This is especially important, as the stations are sometimes located in areas of poor network connectivity (such as parking garages).

Scenario 1: Charging with an RFID token

In this scenario, you want to use an RFID token to charge your EV. This is the most common scenario, and it is usually the most reliable one, as a driver. The process is as follows:

Let us begin with step (3), as this is where you as a driver come into play. We’ll get back to steps (1) and (2) later.

You arrive at the charging station and plug in your EV (3). The charging station detects this, but since charging has not been authorized yet, it does not start charging your EV.
You hold your RFID token in front of the RFID reader of the charging station (4).
The charging station reads the token and sends a request for authorization to the CPMS. This is usually done using another protocol called OCPP (Open Charge Point Protocol). Specifically, the charging station sends a Authorize.req OCPP message to the CPMS, containing the ID of the RFID token (5).
The CPMS checks if the token is valid (6).

You might wonder how the CPMS recognizes the RFID token. There are multiple ways, but most commonly it works like this: once an EMP and a CPO have agreed on a contract, the EMSP sends a list of all their RFID tokens to the CPO (1). The CPO then stores this list in their CPMS. This list is updated regularly, so that the CPO always has the latest list of tokens. This is done using the OCPI protocol. In other words: in our scenario, your EMSP has already informed the CPO about your RFID token. When the CPMS receives the Authorize.req message, it checks if the token is in the list. If it is, the CPMS now knows which EMSP the token belongs to, and can check if the token is valid.
The CPMS responds with an Authorize.conf OCPP message back to the charging station (7). This message tells the charging station whether the token is valid or not.
If the token is valid, the charging station may now begin charging your EV. It indicates this by sending a StartTransaction.req OCPP message to the CPMS (8). This message again contains the ID of the RFID token.
The CPMS now generates a unique transaction ID that identifies the charging session (9).

As per the OCPP standard, the CPMS now again checks if the token is valid.
The CPMS responds with a StartTransaction.conf OCPP message back to the charging station (10). This message contains a unique transaction ID that identifies the charging session.
The charging station starts charging your EV and sends a MeterValues.req OCPP message to the CPMS (11). This message contains the current power consumption of the charging station. It continues to send MeterValues.req messages at regular intervals, so that the CPMS can keep track of the power consumption. Each such message is acknowledged by the CPMS with a MeterValues.conf OCPP message (12). These meter values may also be relayed to the EMSP backend using OCPI, but I’m omitting this here for clarity.

There now are various ways the charging session can end. You might end it by unplugging your EV, you might end it at the station by presenting your token, or there might even be a technical fault! Let us assume that you choose to end the session by unplugging your EV (13).

Note that unplugging your EV might not actually stop the session, as this is dependent on the configuration of the charging station. More specifically the ´StopTransactionOnEVSideDisconnect´ OCPP configuration key. It’s complicated!

Once the charging station detects that the EV has been disconnected, it sends a StopTransaction.req OCPP message to the CPMS (14). This message contains the transaction ID that was assigned to the charging session in step 9. Usually, it also contains the final power consumption of the charging session. The CPMS now responds with a StopTransaction.conf OCPP message (15). Your EV is charged, and you’re on your way!

But we’re not quite done yet! The CPMS now has to inform your EMSP about the charging session. This again happens using the OCPI protocol. The CPMS sends a charge detail record (CDR) message to your EMSP (16). This message contains all the information about the charging session, including the transaction ID, the start and end time of the session, the power consumption and the price. This price has been calculated based on the tariff that was agreed upon between your EMSP and the CPO. The details of this tariff have already been exchanged between the EMSP and the CPMS in step (1).

Your EMSP can now process the CDR and send you an invoice (17).

Scenario 2: Charging with a mobile app

In this scenario, you have a contract with your EMSP and you are using a mobile app to charge your EV. This is usually a little more error-prone than RFID tokens. However, it is also more convenient, as you do not have to carry around a card. Hence it is becoming more common. The brittleness of this scenario comes down to the fact that you need more communication between systems than in the RFID scenario. In the previously described RFID scenario, the charging station only needed to communicate with the CPMS when you plugged in your EV. Since the EMSP and CPO had already exchanged the list of RFID tokens beforehand, the CPMS was able to check if the token is valid. In the mobile app scenario, it’s a little different:

Again, we start with the step (3), where you as a driver come into play. We’ll get to steps (1) and (2) later.

You arrive at the charging station and plug in your EV (3). The charging station detects this, but since charging has not been authorized yet, it does not start charging your EV.
You open your mobile app, select the station and request to start charging (4). The app sends a request to the EMSP backend.

You either select the station by scanning a QR code or by selecting it from a list or map of nearby stations. You might ask yourself: where does the app know which stations exist? This is where we get back to step (2). The CPMS has already sent a list of all charging stations which belong to the CPO to the EMSP backend. This is done using the OCPI protocol. The list is continuously updated, so that the EMSP always has the latest list of stations, including their location and current status.
The EMSP backend sends a Command(START_SESSION) OCPI message to the CPMS (5). This message contains the ID of the charging station and an authorization token.

In contrast to the previous scenario, this token has not been handed to the CPMS beforehand. The CPO may only store this particular token for the duration of the charging session.
The CPMS sends a RemoteStartTransaction.req OCPP message to the charging station (6). This message contains the authorization token.
The charging station responds with a RemoteStartTransaction.conf OCPP message (7). This message indicates whether the request was accepted or not. Since our charging station is ready to work, it accepts the request.
The CPMS forwards the result of the request to the EMSP backend using a CommandResult(ACCEPTED) OCPI message (8). The EMSP may then use this information to display this to the user in the mobile app.
Depending on its configuration, the station may now try to authorize the token. It does this by sending an Authorize.req OCPP message to the CPMS (9). This message contains the ID token.
The CPMS checks if the token is valid (10). In this case, the token is always considered valid, as it was provided by the EMSP backend.
The CPMS responds with an Authorize.conf OCPP message back to the charging station (11).
Since the token has been authorized, the charging station may now begin charging your EV. It indicates this by sending a StartTransaction.req OCPP message to the CPMS (12). This message again contains the authorization token.
The CPMS now generates a unique transaction ID that identifies the charging session (13).
The CPMS responds with a StartTransaction.conf OCPP message back to the charging station (14). This message contains the transaction ID.
Since the charging session has started, the CPMS sends a Session OCPI message to the EMSP backend (15). This message contains the transaction ID and the charging station ID. The EMSP backend stores this information.
While the charging session continues, the charging station continually communicates the current power consumption to the CPMS using MeterValues.req OCPP messages (16). The CPMS acknowledges these messages with MeterValues.conf OCPP messages (17). These meter values may also be relayed to the EMSP backend using OCPI, but I’m omitting this here for clarity.

Once you are done charging, you now decide to stop the session using the mobile app. The resulting process is similar to the one we just described:

You open your mobile app and request to stop charging (18). The app sends a request to the EMSP backend.
The EMSP backend sends a Command(STOP_SESSION) OCPI message to the CPMS (19). This message contains the transaction ID, which the EMSP backend had previously stored.
The CPMS sends a RemoteStopTransaction.req OCPP message to the charging station (20). This message contains the transaction ID.
The charging station responds with a RemoteStopTransaction.conf OCPP message (21). This message indicates whether the request was accepted or not. Since our charging station is happy so far, and is able to terminate the session, it accepts the request.
The CPMS forwards the result of the request to the EMSP backend using a CommandResult(ACCEPTED) OCPI message (22). The EMSP may then use this information to display this to the user in the mobile app.
The charging station now stops charging your EV and sends a StopTransaction.req OCPP message to the CPMS (23). This message contains the transaction ID and the final power consumption.
The CPMS acknowledges this with a StopTransaction.conf OCPP message (24).
You unplug your EV (25) and drive off.
The CPMS now has to inform your EMSP about the charging session. This again is done by sending a CDR over the OCPI protocol (26).
Finally, your EMSP will process the CDR and send you an invoice (27).

You can see that the app-based scenario is more involved and requires more communication, especially between the EMSP and the CPMS.

Conclusion

In this blog post, I have described the basic process of charging an EV at a public charging station. I have focused on two basic scenarios, and only followed the happy path. I also omitted some messaging scenarios. For example, the station status (EV connected, charging, available…) is continually updated both via OCPP and OCPI. Also, OCPI allows for a number of different communication topologies between CPO and EMSP. I have only demonstrated the most basic one here.

There are many opportunities for something to go wrong in the process, as you might imagine. I also did not cover other scenarios, such as charging with a credit card, paying via SMS message, or Plug-And-Charge (which is a new standard that allows you to charge your EV without any manual authorization steps). The world of e-mobility is a complex one, and I have only scratched the surface. I hope this blog post has given you a rough overview of the involved actors and the process. Really going into the details would require a lot more time and space than I have here :D

Acceptance and security testing reverse proxy configuration

2025-04-15T11:00:00+02:00

Reverse proxies often are the key component in a web platform, be it eCommerce, B2B or anything else. Hence, they need to be rock solid. In my experience, reverse proxy outages only seldomly occur due to bugs in the proxy software itself, but rather from misconfiguration. You frequently have to modify reverse proxy configuration according to business needs. On each such change, you want to have a high degree of certainty that you don’t introduce regressions or security issues. After all, each such regression might result in degraded user experience or an outright outage of your site(s). In the context of microservices, integration testing is one of the building blocks for preventing regressions or undesired behavior. They are less often used for infrastructure components like reverse proxies. Nonetheless, they can be invaluable in preventing outages, which are often especially costly in reverse proxies.

This blog post outlines a setup we used to perform acceptance tests on the reverse proxy in front of a large eCommerce platform. Changes to this proxy were contributed by a large number of stream-aligned teams and rolled out using a CI/CD process. These teams were owners of the self-contained systems (SCS) which were being proxied, but did not own the reverse proxy itself. While the setup specifically used nginx, the pattern described here should mostly be applicable to other reverse proxies.

The issue at hand

The proxy was responsible for TLS offloading, setting client identifier and X-Forwarded headers, and performing some basic routing based on the request URL. Most importantly though, we utilized nginx’s Server Side Includes (SSI) feature to integrate micro frontend components provided by different stream-aligned teams. Additionally, nginx also reverse-proxied external services, such as link bait content pages.

What made this setup challenging was the rather large number (>50) of tenant/country/language combinations under the umbrella of the eCommerce platform. Each of these combinations mostly shared the same configuration, but also needed a slightly different set of settings (such as host names, language-specific path prefixes and tenant/country identifier headers sent to the upstream services), and routing rules. In order to keep the configuration manageable, we decided to use a templating engine to generate the nginx configuration files.

The reverse proxy was managed by one of the stream-aligned teams (there was no dedicated platform team, which otherwise could be responsible). This team was responsible for the configuration of the proxy, but not for the configuration of the upstream services. The latter was the responsibility of the stream-aligned teams. The other stream-aligned teams routinely provided merge requests to the reverse proxy team to add or modify routing rules in the nginx configuration. This means that configuration was often contributed by people not well-versed in the specifics of nginx configuration. Combined with the large number of tenant/country/language combinations, this had the potential for introducing errors in the configuration. For example, if a location block were to be added to the wrong server block, or if its path prefix were incorrect, the reverse proxy might start routing requests to the wrong upstream service. Moreover, nginx configuration has some notorious pitfalls, such as the if and try_files directives, which can lead to unexpected behavior and/or security issues. And quite frankly, the setup was inconvenient to the stream-aligned teams, as predicting whether their change sets would lead to their desired outcome.

We therefore needed a testing setup which would:

allow stream-aligned teams to test their merge requests against a maintainable set of test cases
make it easy for stream-aligned teams to contribute tests
allow the team which owned the reverse proxy to have confidence when rolling out changes
comprehensively test for security issues and regressions
run quickly to reduce CI/CD runtime and speed up iteration cycles

Security Testing

We used gixy to check for common security pitfalls in our templated nginx configuration files. Gixy runs static analysis on your configuration and notifies you in case of common misconfigurations. This helps in preventing server-side request forging (SSRF) or denial-of-service attack vectors. Running it was very painless, and I can thoroughly recommend it. Just a word of caution: since our resulting configuration was rather voluminous, a gixy run would take several minutes.

Acceptance testing

The tests

The setup allowed us to write tests like this (example.com would have been replaced with a production domain of ours, of course):

def test_routing():
    # When a route owned by the team responsible for SCS A is requested
    res = Http.get(f"https://example.com/scs-a/foo")

    # Then the reverse proxy forwards the request to the scs-a host
    assert "HTTP_HOST=scs-a"

def test_referrer_header_should_be_retained():
    # When there is a request with the Referer HTTP header set
    headers = {
        "Referer": "example.com"
    }
    res = Http.get(f"https://example.com/", headers=headers)

    # Then the header should be forwarded to the upstream
    assert 'HTTP_REFERER="example.com"' in res.text

def test_server_side_includes_should_be_active():
    # When there is a request for a page for which SSI is active
    res = Http.get(f"https://example.com/ssi-active/some-page-with-ssi")

    # Then the SSI tag is resolved and replaced with the SSI fragment
    assert res.text.strip() == "SSI: fragment-content"

def test_server_side_includes_should_not_be_active():
    # When there is a request for a page for which SSI is not active
    res = Http.get(f"https://example.com/ssi-inactive/some-page-with-ssi")

    # Then the SSI fragment is not resolved and returned verbatim
    assert res.text.strip() == "SSI: <!--#include virtual=\"/fragment/ssi-fragment\" -->"


# Note: this was a much larger and more elaborate data set in practice
production_www_domains: ["www.tenant1.example.com", "www.tenant2.example.com"]

@mark.parametrize("domain", production_www_domains)
def test_an_upstream_404_should_result_in_global_404_page(domain):
  # When there is a request to an upstream which returns an HTTP 404
  res = Http.get(f"https://{domain}/force-http-404")

  # Then the reverse proxy retains this status code
  assert res.status_code == 404
  # And replaces the upstream response body with the global 404 page
  assert res.text.strip() == "global 404 page"

Below, I am going to explain how this worked under the hood.

The test setup

We wanted to perform the acceptance tests on a running instance of the reverse proxy, to be as close as possible to the final deployment state. Actually starting nginx would also implicitly verify that the configuration was valid, because it fails to start up on invalid configuration. We decided to use a docker-compose setup to spin up a local integration setup. This setup contained several components besides the reverse proxy itself:

This is a simplified version of the resulting docker-compose setup:

services:
  # The reverse proxy, containing the production configuration
  nginx:
    build:
      context: .
      dockerfile: Dockerfile  # The production Dockerfile for the reverse proxy
    ports:
      - "127.0.0.1:80:80"
      - "127.0.0.1:443:443"
    volumes:
      # mock certificates so nginx may start up
      - ./test/ssl:/ssl/tenant-a:ro
      - ./test/ssl:/ssl/tenant-b:ro
    links:
      # Links provide DNS aliases pointing to the mock-server container
      - mock-server:scs-1
      - mock-server:scs-2
      - mock-server:www.external.example.com
      - mock-server:www.something-else.example.com
    extra_hosts:
      # In production, we used a CoreDNS instance to resolve upstreams.
      # Here, we use the docker internal DNS resolver instead.
      - "dns-server:127.0.0.11"

  # Mock upstream for testing, which e.g. responds with specified error codes,
  # upstream content, or returns the request URI and headers as a response
  mock:
    hostname: mock-server
    build:
      context: ./test/containers/mock-server
      dockerfile: Dockerfile  # see below for content
    depends_on:
      - echo-fcgi

  # FCGI process used by the mock server, which renders request variables
  # (headers etc.) as a response
  echo-fcgi:
    build:
      context: ./test/containers/echo-fcgi
      dockerfile: Dockerfile

networks:
  default:
    # test network is set to 'internal' so no traffic escapes the test jig.
    # Otherwise, since the nginx configuration might reference externally
    # owned domains, you might involuntarily issue requests against these
    # external systems during testing.
    # If you just want to run the test jig for manually testing, you can
    # remove this section.
    internal: true
    driver: bridge

Some notes on the setup:

nginx

The nginx container was built from the production Dockerfile. This ensured that the nginx configuration was as close to production as possible. We had volume mounts for the TLS certificates. The /test/ssl directory contained a single self-signed certificate. By mounting it multiple times to the subdirectories where the production certificates would be, we could provide nginx with the necessary certificates to start up.

Note: the setup as we built it did not verify that the correct certificates were used. It would not be difficult to include this, though. You’d just need to generate certificates for each tenant domain and add them to the test trust store of the test container.

The extra_hosts directive was used to provide DNS aliases for the upstream services. All these aliases pointed to the mock-server container, which was used to emulate the upstream services. In production, we used a CoreDNS instance to resolve upstreams. Here, we used the docker internal DNS resolver instead.

Note: nginx by default only does DNS resolution at startup. In production, this can not only lead to stale resolutions, but also to a startup failure if the upstream name is unavailable at startup. Therefore, we configured nginx to dynamically resolve upstreams using the resolver directive. This has recently been made more convenient to do by the introduction of the resolve parameter.

mock-server

The mock-server container was used to emulate the upstream services. It was also implemented using an nginx, but with an entirely different configuration. The mock-server container was used to test the routing rules in the nginx configuration. It could be configured to respond with specified error codes, upstream content, or return the request URI and headers. In order to do this, it had locations like this:

# By default, echo request content as a response, using the echo-fcgi container
location / {
  fastcgi_pass echo-fcgi:9000;
  fastcgi_param SCRIPT_FILENAME /srv/cgi/printenv;
  fastcgi_param REQUEST_URI $request_uri;
  fastcgi_param SCHEME $scheme;
}

# Return specific test files from the /srv/www directory of the mock-server container

location ~ ^.*\.(js|css|html) {
  root /srv/www;
  rewrite ^.*\.(js|css|html) /test.$1 break;
}

# Return specific status codes according to the request path

location ~ .*/force-http-403 {
  return 403;
}

location ~ .*/force-http-404 {
  return 404;
}

# Page with SSI upstream

location ~ ^.*/page-with-ssi {
  root /srv/www;
  rewrite ^ /page-with-ssi.html break;
}

# page with broken SSI upstream

location ~ ^.*/page-with-ssi-force-http-(?<code>[0-9]+) {
  add_header Content-Type text/html; # SSI only works if the content-type is set correctly
  return 200 "SSI: <!--#include virtual=\"/fragment/force-http-$code\" -->";
}

Where /srv/www/page-with-ssi.html contained a basic SSI directive:

SSI: <!--#include virtual="/fragment/ssi-fragment" -->

echo-fcgi

The echo-fcgi container was used to render request variables (headers etc.) as a response.

FROM debian:12-slim

RUN \
  DEBIAN_FRONTEND=noninteractive \
  apt-get update && \
  apt-get -y install fcgiwrap

COPY printenv /srv/cgi/printenv

RUN chmod +x /srv/cgi/printenv

USER root

CMD ["spawn-fcgi", "-p", "9000", "-n", "/usr/sbin/fcgiwrap"]

Where the printenv script was a small perl script:

#!/usr/bin/perl

# ***** !!! WARNING !!! *****
# This script echoes the server environment variables and therefore
# leaks information - so NEVER use it in a live server environment!
# It is provided only for testing purpose.
use strict;
use warnings;

print "X-Application-Timing: 235\n";
print "Content-type: text/plain; charset=iso-8859-1\n\n";
foreach my $var (sort(keys(%ENV))) {
    my $val = $ENV{$var};
    $val =~ s|\n|\\n|g;
    $val =~ s|"|\\"|g;
    print "${var}=\"${val}\"\n";
}

Running the tests

The tests were written in Python, using pytest and requests. We chose Python because it is simple to use, and is known by many developers. Of course, you could use any testing framework you like. The tests were run in a container, which was attached to the docker network created by the above docker-compose setup:

FROM python:3.12

# Provide a working directory with correct permissions
USER root
RUN mkdir -p /test && chown -R python: /test
USER python
WORKDIR /test

ENV PATH="/home/python/.local/bin:${PATH}"
# Install the test dependencies (this was done using a dependency management tool)
RUN pip3 install --user pytest pytest-xdist requests

# Copy the test files
COPY --chown=python:python . .

ENV PYTHONWARNINGS="ignore:Unverified HTTPS request"
ENV PYTHONPATH="/test:${PYTHONPATH}"
ENTRYPOINT ["pytest"]
# Run tests concurrently and verbosely
CMD ["-n", "16", "-vv"]

In order to have the tests run against the test setup, we used the requests library to provide a simple HTTP client. This client rewrote the requests so that they were always running against the nginx container. This enabled us to use the final production domains in the tests, which made them easier to understand.

import requests

class Request:

  def __init__(self, url, **kwargs):
    proto, domain_and_path = url.split("://", 1)
    domain = domain_and_path.split("/")[0]
    path = "".join(domain_and_path.split("/", 1)[1:])

    # Direct any requests to the nginx container, but set the host header to the domain
    # which was requested.
    self.headers = kwargs["headers"] if "headers" in kwargs else dict()
    self.headers["host"] = domain
    # While running in the docker network from the docker-compose file,
    # the DNS name "nginx" resolves to the nginx container
    self.request_url = "{}://nginx/{}".format(proto, path)

    # Remove the unmodified headers from the kwargs dict, so that we don't
    # forward them to the requests client (see below)
    self.kwargs = kwargs
    if "headers" in self.kwargs:
      del self.kwargs["headers"]


class Http:

  @staticmethod
  def get(url, params=None, allow_redirects=False, **kwargs):
    req = Request(url, **kwargs)
    # Note that we use verify=False here, because we used self-signed certificates and did not
    # want to bother with adding them to the trust store.
    return requests.get(req.request_url, params, allow_redirects=allow_redirects, verify=False, headers=req.headers,
                        **req.kwargs)

  @staticmethod
  def post(url, params=None, allow_redirects=False, **kwargs):
    req = Request(url, **kwargs)
    return requests.post(req.request_url, params, allow_redirects=allow_redirects, verify=False, headers=req.headers,
                         **req.kwargs)

And this is how it all came together to make the tests from before possible:

def test_routing():
    # This request is rewritten by the `Http` class to redirect it to the `nginx` container.
    # nginx processes the request, and forwards it to the upstream, setting the
    # `Host` header in the process. The mock-server then returns a response body with all
    # the HTTP headers it sees.
    res = Http.get(f"https://example.com/scs-a/foo")

    # Therefore, we can assert on what the mock-upstream has seen. In this case, we
    # assert the host header, which tells us the server to which the reverse proxy would
    # have forwarded the request.
    assert "HTTP_HOST=scs-a"

def test_referrer_header_should_be_retained():
    # This is basically the same test as above, but with a custom header set by the client
    headers = {
        "Referer": "example.com"
    }
    res = Http.get(f"https://example.com/", headers=headers)

    assert 'HTTP_REFERER="example.com"' in res.text

def test_server_side_includes_should_be_active():
    # The mock-server is configured to return a page with an SSI tag for this path.
    # The upstream page content is 'SSI: <!--#include virtual=\"/fragment/ssi-fragment\" -->'
    res = Http.get(f"https://example.com/ssi-active/some-page-with-ssi")

    # If nginx is configured correctly, it is going to interpret the SSI tag, resolve the
    # include and replace the tag with the response of the SSI fragment
    assert res.text.strip() == "SSI: fragment-content"

def test_server_side_includes_should_not_be_active():
    # This is the inverse of the test above. For the /ssi-inactive prefix we don't want
    # nginx to parse the SSI tags
    res = Http.get(f"https://example.com/ssi-inactive/some-page-with-ssi")

    # This means that SSI tags are returned verbatim, without performing the include.
    assert res.text.strip() == "SSI: <!--#include virtual=\"/fragment/ssi-fragment\" -->"


production_www_domains: ["www.tenant1.example.com", "www.tenant2.example.com"]


@mark.parametrize("domain", production_www_domains)
def test_an_upstream_404_should_result_in_global_404_page(domain):
  # Again, the Http class redirects all these requests to the nginx container
  res = Http.get(f"https://{domain}/force-http-404")

  assert res.status_code == 404
  assert res.text.strip() == "global 404 page"

As you can see, we were able to parametrize the tests to run against different tenant domains. This was very useful, as we could run the same test against all tenant domains, and thus ensure that the routing rules were correct for all of them. This was especially helpful when adding new tenant domains, as we could check the routing for the new domain without writing new tests. However, parametrizing the tests also led to a large number of test cases. This was not a problem, as we could use pytest-xdist to run the tests in parallel, which sped up the test run considerably.

Conclusion

The setup described here allowed us to test the reverse proxy configuration both in a CI/CD pipeline and locally. The setup was very flexible, as we could easily add new test cases for new routing rules. It ran quickly, and afforded both the reverse proxy team and the stream-aligned teams a high degree of confidence when rolling out changes. Since the reverse proxy team could see both the implementation, and have the test cases as a specification, they could more easily infer the behavior which was to be introduced by the change set. The setup was also very useful for debugging, as developers could easily run the tests against a local instance of the reverse proxy, and directly see the results in the test output.

I realize that the setup described here won’t work for every project. Especially, now that the usage of Kubernetes ingress controllers is becoming more widespread, you might need to devise another method of verifying changes. For server-side rendering with includes, which are still widespread in micro frontend setups, I think the approach outlined above can be very useful. I hope that this post has given you some inspiration on how or whether to test your reverse proxy configuration. I would be very interested in hearing your approach to similar challenges :)

Photo credit: Daniel Andrade

Externe Dienstleister sind eine Sackgasse

2025-01-03T16:00:00+01:00

Häufig haben unsere Kunden zwei Ziele:

Outcome erhöhen und
Expertise aufnehmen.

Ein wichtiger Aspekt wird jedoch von vielen Entscheidern übersehen: Teams bestehen aus hochkomplexen sozialen Strukturen. Diese Strukturen sind maßgeblich dafür verantwortlich, wie “gut” das Team zusammen arbeitet und wie viel Outcome es liefern kann.

Ein Beispiel: Wenn die psychologische Sicherheit in einem Team sinkt, kann das zu Missverständnissen und dysfunktionalen Verhaltensmuster führen. Die Produktivität sinkt drastisch, weil Mitglieder sich nicht mehr in ihren Bedürfnissen gesehen fühlen. Das Team arbeitet im schlimmsten Fall nicht mehr miteinander, sondern gegeneinander.

Externe Dienstleister sind eine Sackgasse …

… zumindest langfristig gesehen. Denn: Wenn man einen externen Dienstleister beauftragt, um den Outcome zu erhöhen, kann es tatsächlich den gewünschten Effekt haben - zumindest so lange wie die Unterstützung dauert. Hört allerdings die Beauftragung auf und sind die tief liegenden Konflikte im Team nicht gelöst, geht auch die Produktivität wieder runter.

Typischerweise versuchen Unternehmen das Miteinander in oder zwischen den Teams durch z.B. Agile Coaches zu adressieren. Aus unserer Erfahrung machen die häufig einen richtig guten Job. Nur haben sie einen großen Nachteil: Sie sind naturgemäß nicht so tief im Team verankert wie ein:e Entwickler:in, die beispielsweise auch Teil von 1:1 Absprachen ist.

Was macht inoio anders?

Wenn ich also behaupte, dass externe Dienstleister eine Sackgasse für den langfristigen Projekterfolg sind, warum sollte dann jemand inoio buchen?

In den letzten zwölf Jahren haben wir viele Projekte begleiten dürfen und sind immer stärker zu der Erkenntnis gelangt, wie wichtig es ist, insbesondere die sozialen und organisatorischen Faktoren für einen Projekterfolg zu bearbeiten:

Kommunikationskultur prägen

“Communication is hard”. Kommunikation lernen wir hauptsächlich durch Nachahmung - nur wenige von uns hatten in der Schule das Fach “Kommunikation”. Darum trainieren wir bei inoio kontinuierlich einen Bedürfnis-Orientierten Kommunikationsstil, den wir dann in das Projekt tragen und dort multiplizieren.

Gruppendynamik bewusst gestalten

Weiterhin lassen sich viele von uns darin schulen, Gruppendynamiken zu verstehen und seinen eigenen Anteil darin zu erkennen. So können wir bewussten Einfluss darauf nehmen, um funktionale Dynamiken zu etablieren. Zusätzlich lernen die anderen Teammitglieder, wie sie selbstwirksam durch Konflikte und Dynamiken wachsen können, anstatt zu resignieren.

Systemische Beratung zur Organisations- und Persönlichkeitsentwicklung

Darüber hinaus haben wir Softwareentwickler, die sich zusätzlich als Systemische Berater weitergebildet haben, um noch intensiver Menschen und Organisationen zu helfen, innere und äußere Prozesse zu erkennen und zu bearbeiten. Dies kann sowohl implizit geschehen, als auch explizit durch niedrigschwellige Angebote zu Coaching und Beratung für die Mitarbeitenden des Unternehmens.

Wir lieben es, komplexe Probleme zu verstehen und geeignete Software dafür zu programmieren. Um das Team aber nachhaltig nach vorne zu bringen, wollen wir Organisationen dabei unterstützen, dass die Menschen besser zusammen arbeiten können und somit die intrinsische Motivation der Mitarbeitenden gefördert wird. So zahlt sich unser Engagement sowohl kurzfristig als auch langfristig aus.

Was sind Deine Herausforderungen im IT-Projekt? Was brauchst Du für Euren Projekterfolg? [email protected]">Schreib mir eine Mail oder ruf mich einfach an: +49-40-60946982-0

Fotocredit: Jonathan Farber

Wieder grüßt das Murmeltier: 2. Teil der Fehlerbehandlung für Kafka Consumer mit Retries

2024-11-11T14:45:00+01:00

Dies ist eine Fortsetzung des Blog-Posts Fehlerbehandlung für Kafka Consumer mit Retries, mit seitdem gewonnenen Erkenntnissen.

Phil Connors: Well, it's Groundhog Day... again...

Hilfsklasse `Processed-Messages-Filter`

Im ersten Teil haben wir uns Non-blocking Retries angesehen, wodurch die Reihenfolge der Kafka-Events durcheinanderkommen kann: Deshalb haben wir die Uhrzeiten der Events verglichen, um veraltete Events zu verwerfen. Konkret in dem Beispiel war es die Uhrzeit des letzten gespeicherten Wetterberichtes: Kommen ältere Wetterberichte durch ein Retry herein, können wir sie ignorieren.

Hier hat sich in unseren Projekten inzwischen eine generische Hilfsklasse ProcessedMessagesFilter etabliert. Wir speichern die Uhrzeit des letzten verarbeiteten Events in der Datenbank:

@Entity
data class ProcessedEvent(
    val eventType: String,           // "weatherForecast"
    val key: String,                 // "Hamburg", Key des Kafka-Events
    val timestamp: OffsetDateTime,   // Uhrzeit des letzten Updates
)

Damit können wir generisch prüfen, ob bereits neuere Events verarbeitet wurden. So sieht die Benutzung aus:

processedMessagesFilter.processIfNotOutdated(
    eventType = "weatherForecast",
    key = weatherForecast.city,
    timestamp = weatherForecast.time) {

    // wird nur ausgeführt, falls das event nicht veraltet ist
    repository.save(weatherForecast)
}

Vorteil der generischen Lösung ist eine Vereinfachung des Codes, weil wir nicht mehr wissen müssen, wo in den fachlichen Objekten Timestamps gespeichert werden. Und vor allem: Wenn am Ende ihres Lebenszyklus die fachlichen Objekte gelöscht werden, merken wir uns davon unabhängig weiterhin, dass diese Events bereits verarbeitet wurden. Sonst könnte es sein, dass durch ein Retry ein bereits gelöschtes Objekt wieder angelegt wird.

Die Implementierung des ProcessedMessagesFilters ist straight-forward:

@Service
class ProcessedMessagesFilter(
    val processedMessagesRepository: ProcessedMessagesRepository,
) {
    fun <R> processIfNotOutdated(
        eventType: String,
        key: String,
        timestamp: OffsetDateTime,
        process: () -> R) {

        if (!isOutdated(eventType, key, timestamp)) {
            process()
            processedMessagesRepository.save(ProcessedEvent(eventType, key, timestamp))
        }
    }

    private fun isOutdated(
        eventType: String,
        key: String,
        timestamp: OffsetDateTime): Boolean {

        return processedMessagesRepository.findBy(eventType, key)
        .map { lastProcessed ->
            // note: If the timestamp are identical, we want to process,
            // allowing to re-process a topic if needed
            (timestamp.isBefore(lastProcessed.timestamp))
        }.orElse(
            // unknown = new key, we want to process it
            false,
        )
    }
}

Zusätzlich sollte man noch einen Aufräumjob implementieren, der nach längerer Zeit (mehreren Monaten) die ProcessedEvents aufräumt.

Fiese Fallen

Zwei neue fiese Fallen aus der Praxis!

Fiese Falle: Exponentielle Retry-Vermehrung

Durch einen Copy-und-Paste Fehler hatten zwei Consumer in verschiedenen Consumer-Groups dasselbe Retry-Topic konfiguriert. Was jetzt passierte: Eine Nachricht landete im Retry-Topic, beide Consumer konsumierten sie, liefen beide auf einen Fehler, und schrieben jeweils eine Nachricht in das Retry-Topic. Aus 1 Nachricht wurden also 2, 4, 8, 16…, bis der Kafka in die Knie ging.

Fiese Falle: Große Callstacks

Unsere RetryTopics wurden sehr groß, fast 80 GB. Die Analyse zeigte, dass die Retry-Events in einem Kafka-Header den gesamten Callstack des fehlgeschlagenen Versuchs enthielten. Der Callstack-Retry-Header hatte fast 15000 Bytes, im Vergleich zu dem kleinen Event mit mit 350 Bytes plus sonstige Retry-Header mit 1300 Bytes. Das Event wurde also fast um den Faktor 50 größer, und zusätzlich 50x retried. Damit wurden aus 30 MB Originalevents * 50 * 50 = 75 GB Retry-Daten. Auch diese Header lassen sich abschalten:

@EnableKafka
@Configuration
@EnableScheduling
class RetryTopicsConfig : RetryTopicConfigurationSupport() {
  override fun configureDeadLetterPublishingContainerFactory(): Consumer<DeadLetterPublishingRecovererFactory> =
    Consumer<DeadLetterPublishingRecovererFactory> { recovererFactory ->
      recovererFactory.setRetainAllRetryHeaderValues(false)
      recovererFactory.setDeadLetterPublishingRecovererCustomizer { dlpr ->
        dlpr.excludeHeader(
          HeadersToAdd.EX_STACKTRACE,
          HeadersToAdd.EXCEPTION,
          HeadersToAdd.EX_CAUSE,
          HeadersToAdd.EX_MSG,
        )
      }
    }
}

Fazit

Mit dem generischen ProcessedEventsService und dem Support durch Spring sind Retries schnell eingebaut. Die beschriebenen Fallen sollte man aber kennen, weil man mit Retries versehentlich sehr viele Events produzieren kann.

Wir wünschen euch weiterhin viel Erfolg mit der Fehlerbehandlung mit Retries!

Phil: Do you know what today is?
Rita: No, what?
Phil: Today is tomorrow. It happened.

inoio gmbh

Pragmatisch Funktional – Zustand, Einfachheit und Magie

Horizontale Skalierung

Auftritt funktionale Programmierung

Seiteneffekte machen das Lebens kompliziert

Multithreading entschärft

Hindernisse in der Praxis

This is where the magic happens

Claude Code mit AWS Bedrock nutzen - Schritt-für-Schritt Anleitung

Was ist Claude Code?

Warum AWS Bedrock?

AWS-Konfiguration

AWS Account und API-Schlüssel

Konfigurationsskript erstellen

Benutzerberechtigungen konfigurieren

Console-Zugang einrichten

Modell-Zugriffsrechte beantragen

Inference Profile IDs verstehen

Claude Code aktivieren

Wichtige Hinweise zur Konfiguration

Token-Limits verstehen

Prompt Caching

Troubleshooting häufiger Probleme

“Model not found” Fehler

Berechtigungsfehler

Fazit

Nachtrag

Co- and Contravariance Part 2: Advanced Concepts

Recap: Function Subtyping and Variance

Functions with higher order functions as parameters

Association and Variance Positions

Variance Positions in Nested Functions

Co- and Contravariance

Inheritance

Invariance, Covariance and Contravariance

Invariance

Covariance (+)

Contravariance (-)

Does it have any use, whatsoever?

Contravariance

Covariance

For Java Developers

Java Syntax for Variance

Translating Our Examples to Java

Contravariance in the Wild

Example 1: Java Collections Framework

Example 2: Java Functional Interfaces

Example 3: Comparators

Generative AI als Game Changer in der Softwareentwicklung - Ein Interview

Null or @Nonnull? A brief note on Java/Kotlin interoperability

E-Mobility Roaming in a Nutshell

Some words on roaming

Overview

The protocols: OCPI and OCPP

Scenario 1: Charging with an RFID token

Scenario 2: Charging with a mobile app

Conclusion

Further reading

Acceptance and security testing reverse proxy configuration

The issue at hand

Security Testing

Acceptance testing

The tests

The test setup

nginx

mock-server

echo-fcgi

Running the tests

Conclusion

Externe Dienstleister sind eine Sackgasse

Externe Dienstleister sind eine Sackgasse …

Was macht inoio anders?

Kommunikationskultur prägen

Gruppendynamik bewusst gestalten

Systemische Beratung zur Organisations- und Persönlichkeitsentwicklung

Wieder grüßt das Murmeltier: 2. Teil der Fehlerbehandlung für Kafka Consumer mit Retries

Hilfsklasse Processed-Messages-Filter

Fiese Fallen

Fiese Falle: Exponentielle Retry-Vermehrung

Fiese Falle: Große Callstacks

Hilfsklasse `Processed-Messages-Filter`