Übersicht

Ich arbeite sowohl an Backend als auch Frontend. Bei der Erstellung einer Funktion musste ich Endpunkte und Request/Response DTOs in Java WebFlux schreiben und dann im Frontend dieselbe URL und TypeScript-Typen erstellen. Um die Swagger-Dokumentation abzugleichen, musste ich bereits vorhandene Informationen im Backend in ein anderes Format übertragen.

Der größte Engpass war der Prozess, bei dem die vom Backend erstellten API-Verträge in eine Form umgeschrieben wurden, die das Frontend verwenden kann. Wenn sich auch nur eines der URL-, HTTP-Methoden-, Pfad-/Abfrageparameter- oder Request/Response-Strukturen auf beiden Seiten unterschiedlich änderte, wurde das Problem erst nach der Kompilierung entdeckt. Es war nicht nur eine lästige Aufgabe, sondern die Inkonsistenzen, die durch die doppelte Verwaltung derselben Informationen durch Menschen entstanden, waren ein größeres Problem.

Ich wollte auch die Wiederholung beim Erstellen von RouterFunction und Handler reduzieren. Wenn ich einen Verweis wie ApiAccountHandler::search zum Router hinzugefügt habe, dachte ich, dass das Skelett einer nicht existierenden Handler-Klasse und -Methode automatisch erstellt werden könnte. Das wiederholte Schreiben von Entity-Feldnamen wie "username" als Strings beim Erstellen von MongoDB-Abfragen war ebenfalls mühsam und fehleranfällig, weshalb ich die Funktion, die die Entity-Quellen liest und in Java-Enums umwandelt, ebenfalls in dasselbe Tool integriert habe.

So wurden zuerst Swagger/OpenAPI-Generierung, Handler-Skelett-Generierung und Mongo-Entity-Feld-Enum-Generierung erstellt, und später wurde die AsyncAPI-Generierung hinzugefügt, während RSocket verwendet wurde. Obwohl sie wie separate Ideen erscheinen, ist der Ausgangspunkt derselbe. Es geht darum, dass Menschen nicht erneut Fakten, die bereits im Backend-Quellcode festgehalten sind, umschreiben und dass Entwicklungswerkzeuge die maschinenlesbaren Teile stattdessen erstellen.