dredger-todos-async

dredger-todos dient zum Demonstrieren und Testen von dredger. dredger generiert aus OpenAPI- und AsyncAPI-Spezifikationen Go-Code, der ein Gerüst für einen Micro-Service darstellt. Entsprechend den Spezifikationen werden die definierten REST-Endpoints und publish-/subscriber-Funktionen für asynchrone Kommunikation automatisch generiert. Darüber hinaus werden auch auch Funktionalitäten generiert, die ein typischer Microservice benötigt:

• Konfiguration
• Commandline
• Sicherheitsfunktionen, wie ein Policy-Enforment-Point
• Logging
• Monitoring
• Tracing
• Nutzung von templ für HTML-Seiten und deren Lokalisierung
• Support für HTMX, SSE

Die Basis-Funktionalität ist es neue Aufgaben Hinzufügen zu können, diese als erledigt (√) oder nicht erledigt ([]) zu markieren, sowie einzelne Aufgaben zu löschen (🗑️).

Man kann aber Aufgabenliste auch gemeinsam editieren, d.h. mit mehreren Instanzen des Micro-Services, bspw. auf verschiedenen HTTP-Ports, bedient auf zwei oder mehr Webbrowser(-Seiten). Dazu muss man für alle Instanzen das gleiche Label Setzen.

Installation

Zuerst sollte man dredgerTodos vom Quellcode installieren, wobei eine funktionierende Go-Umgebung und das Werkzeug just vorausgesetzt werden:

just required
just install

Außerdem muss lokal ein Nats Server laufen.

Nun kann man mehrere Instanzen in mehreren Shells (Terminals) starten:

dredgerTodos -p 9990
dredgerTodos -p 9991
dredgerTodos -p 9992

In 3 verschiedenen Browser-Fenstern kann man sich die Aufgabenlisten anschauen:

http://localhost:9990
http://localhost:9991
http://localhost:9992

Als erstes setzt man in allen Fenstern das gleiche Label. Danach kann man in einem beliebigen Fenster die gemeinsame Aufgabenliste pflegen.

Umsetzung

Initial wurden die OpenAPI- und die AsyncAPI-Spezifikationen erstellt und mit dredger generate OpenAPI.yaml AsyncAPI.yaml -o . -f -n dredger-todos der initiale Code generiert. Schrittweise wurden REST-Handler, Async-Publisher, Async-Subscriber und weitere Anpassungen vorgenommen. Ein besonderer Fokus bilden die usecases, die die Business-Logik im Kern abbilden. Der Quellcode orientiert sich generell an der Clean Architecture von Uncle Bob.

Bei den usecases wird ersichtlich, dass dredgerTodos eigentlich 2 Micro-Services in einem sind. Mit den REST-Services wird vor allem die Web-Oberfläche mittels HTMX realisiert. Mit SSE kann diese auch asynchron aktualisiert werden. Aktionen auf der Web-Oberfläche ändern den internen Zustand der Aufgabenliste NICHT. Stattdessen werden asynchron Messages an den Message Broker (NATS) published. Der andere Teil des Micro-Services hat die Messages subscribed und erst beim Empfang einer Message wird der lokale Zustand der Aufgabenliste aktualisiert und ein refresh der Aufgabenliste auf der Web-Seite mittels SSE signalisiert. Mittels des Session-Management können auch mehrere Nutzende (Nutzung verschiedener Browser) gleichzeitig dredgerTodos nutzen.