Topical

Motivation

Beim Einsatz von Messaging (MQTT) ist es oft hilfreich die Liste vergangener Nachrichten einsehbar zu haben.

Hintergrund

Mir wurde MQTT immer wieder wärmstens empfohlen, niederschwellig, Hacker-freundlich und auch sonst so.

Im lokalen Hackerspace™ vor Ort wird bisschen mit IOT rumgespielt, also hab ich mal einen Broker auf den Server vor Ort geworfen.

Mein Erfahrungs-Horizont von Messaging ist sehr begrenzt (nicht vorhanden).

Also rein in die Materie und sich die Finger schmutzig machen. Die meisten Dinge lernt man wenn man direkt mit Problemen konfrontiert wird.

Projekt

Ein MQTT Client, der auf verschiedenen Topics lauscht, die Daten irgendwie abspeichert, und dann als Webseite wieder ausgibt.

Vorgänger

Zunächst hatte ich versucht das Problem mit Python zu lösen.

Besagter MQTT Client ist dauerhaft am lauschen, und wirft die Daten in eine SQLite Datenbank.

Die Webseite jedoch wurde bei jeder Änderung statisch gerendert. Mag funktionieren, jedoch bei vielen Nachrichten auf vielen Topics wird es hakelig.

Also wird dies als Machbarkeits-Studie verbucht, und dann einmal ordentlich neu umgesetzt.

Werkzeuge

Spring-Boot auf Java 17 (damals; inzwischen 21). Eclipse Paho für den MQTT Client.

Dazu eine ordentliche MySQL Datenbank.

Das Frontent komplett in Thymeleaf, dazu Bulma fürs CSS.

Implementierung

Kaum wechselt man auf eine solide Technologie fängt alles an Spaß zu machen.

Jede Message landet innerhalb von einem eigenen Thread in der Datenbank. Somit sind tausende parallel ankommende Messages kein Problem mehr.

Ich bin bisschen verwundert: Die Spezifikation von MQTT Sagt absolut nichts über den Inhalt der Messages aus.

Das einzige was drin steht: Es sind bytes. Schönen Dank! Little Endian oder Big Endian?!

Natürlich hab ich mich letztendlich für Big Endian entschieden. Kein Frage!

Eine Design Entscheidung war auch die Filter der Topics auf denen gelauscht wird in die Datenbank zu legen.

Mag bisschen verwunderlich sein, wenn man die Anwendung das erste mal startet. Es passiert nichts, da noch keine Filter da sind.

Auf der anderen Seite erlaubt es die Anpassung der Filter zur Laufzeit. Neu laden zur Laufzeit inklusive.

Als Bonus gibt es noch eine Callback-API.

Eine Message die durch einen bestimmten Filter auf ein Topic reinkommt lässt sich auf einen HTTP Endpunkt weiterleiten.

Genauso auch umgekehrt: Man kann die API nutzen um Messages auf diversen Topics zu veröffentlichen.

Impressionen

Die Homepage. Oben eine Übersicht wie viele Messages insgesamt auf wie vielen Topics jemals eingesammelt wurden.

Unten folgen dann die Details zu den einzelnen Messages.

Topical selbst schickt Nachrichten über eigene Statistiken zur Laufzeit.

In MQTT sind die Datentypen nicht definiert. Deshalb werden verschiedene Varianten der Interpretation ausgegeben.

Hier kam eine ganz normale Ganzzahl in Form von rohen bytes daher.

Fazit

Auf dem Weg zur endgültigen Anwendung war es eine längere Durststrecke. Zeitweise bisschen nervig.

Ab dem Punkt als das Projekt sichtbar Gestalt annahm machte es eine menge Spaß.

Habe natürlich eine Menge über Messaging im Allgemeinen und Speziellen über MQTT gelernt.

Es ist herrlich einfach sich Schleifen im Message-Bus zu bauen.

Erst recht bei Verwendung einer HTTP Bridge. So eine wie ich in Topical eingebaut habe.

Umso nerviger ist es die Schleifen aufzulösen.

Aber halb so wild. Mit Topical hat man ein mächtiges Debugging Tool zur Hand.

Ausblick

Das Projekt wirkt zeitweise ein bisschen wie eingeschlafen.

Das liegt aber nicht daran dass ich das Interesse verloren habe. Im Gegenteil, es wird rege genutzt.

Es hat einen Punkt erreicht wo es nichts mehr zum hinzufügen oder wegnehmen gibt.

Alles was bleibt ist von Zeit zu Zeit die Abhängigkeiten auf Stand zu bringen. Perfekter Zustand - gerne mehr davon!