Boehrsi.de - Blog

Über die Git Struktur meiner Dienste schrieb ich bereits, heute geht es etwas tiefer in die technischen Interna und die Ideen dahinter. Wie erwähnt nutze ich einen Core und selbiger erhält eine beliebige Anzahl an Implementierungen. Dies kombiniert ergibt dann einen Service. Doch wie habe ich dies umgesetzt, wie erfolgt im Code die eigentliche Verbindung zwischen Core und Implementierungen und wie arbeitet man wirklich mit diesem simplen Modularisierungskonzept?
Wie bereits mehrfach erwähnt nutze ich den folgenden Ansatz für kleinere Projekte, an welchen ich meist alleine arbeite. Für mittlere Projekte, mit mehreren Entwicklern, könnte man den Ansatz mit simplem Scripting auch nutzbar machen, für größere Teams würde ich selbigen aber nicht empfehlen. Doch nun zum technischen.

Ich arbeite gerne mit Flutter, migrierte meine internen Java & Android Projekte und schreibe quasi täglich die eine oder andere Zeile Code. Doch ist Flutter auch was für den echten produktiven Einsatz? Diese Frage kann ich seit kurzem nun auch offiziell mit einem klar ja beantworten. Grund dafür ist meine erste Flutter App im Google Play Store (Tessa - Reit-Assistent open_in_new), welche durchaus umfangreich geworden ist und mit Dart und Flutter als Basis sehr gut funktioniert.
Der Kontext ist mit einer Companion App für Pferdebesitzer eher außerhalb meiner Kernkompetenzen, aber genau dies zeigt mir noch mehr das man mit Flutter Apps entwickeln kann, die den eigenen Wünschen oder den Wünschen eines Auftraggebers entsprechen. Grund für das Thema der App ist meine Frau, welche mit dem Reiten ein Hobby gefunden hat, welches durchaus komplex sein kann.

• Tessa - Reit-Assistent bei Google Play open_in_new
• Tessa - Reit-Assistent im Projektebereich open_in_new

Um sowohl ein hohes Maß an Wiederverwendbarkeit, wie auch ein niedriges Level an Komplexität zu erreichen, habe ich mir für meine Boehrsi.de Services eine Kleinigkeit überlegt. Meinen Ansatz zur flexiblen Entwicklung ohne unnötigen Overhead möchte ich im Folgenden mit euch teilen. Dabei geht es um die Datei- und Git-Struktur, denn auf den Code Aufbau werde ich in einem gesonderten Beitrag eingehen.
Wie bereits erwähnt gibt es viele Wege und das Spektrum ist sehr breit, wenn es darum geht ein Setup für Projekte mit mehreren Modulen, bzw. einem gewissen Level an Flexibilität zu erreichen. Um einordnen zu können wo mein Konzept hilfreich sein könnte und wo es an seine Grenzen stößt, gibt es im folgenden meine Anforderungen und die Beschreibung meines eigentlichen Ziels.

Nachdem ich bereits ein paar Worte darüber verloren habe, warum ich meine Services selbstgeschrieben habe, geht es heute mit den Anforderungen und der generellen Architektur weiter. Als ich vor zwei Jahren meine Java Services schrieb, war das Thema Microservices natürlich auch in meinem Kopf sehr aktiv. Das Resultat damals waren zwei komplett unabhängige Services, für die Suche und die Kommentare. Alles unabhängig, was natürlich seine Vorteile hat, aber eben auch Nachteile.
Die Nachteile wollte ich mit meinen neuen Diensten eliminieren, denn wenn man schon erneut auf der grünen Wiese startet, soll das Ganze natürlich auch ordentliche Verbesserungen bringen. Insgesamt überlegte ich mir die folgenden Anforderungen, welche auf meinen Erfahrungen mit meinen bis dato aktiven Services beruhen.

Ich habe schon oft über die Services, welche die Such- und Kommentarfunktion hier im Blog zur Verfügung stellen, gesprochen. Das ich selbige selbst entwickelt habe wurde auch schon oft breitgetreten, aber auf die Interna bin ich bis dato noch nicht eingegangen.
Dieser Beitrag macht nun den Anfang und ist der Start für eine neue News-Sammlung. Heutiges Thema soll die Frage sein, warum ich die genannten Services selber entwickelt habe und nicht einfach vorhandene Lösungen genutzt habe. Im allgemeinen lässt sich die Frage recht einfach beantworten, denn ich bin ein Softwareentwickler. Entsprechend baue ich meine Software falls selbiges sinnvoll ist, gerne selbst. Doch warum hatte ich in diesem Fall das Gefühl es wäre sinnvoll?

Während es für fast alles ein Plugin / Package gibt im Dart / Flutter Kontext, existieren natürlich trotzdem die kleinen Ausnahmen die einem fehlen. Für diese Dinge schreibt man dann selber Code, verwendet ihn in der nächsten App wieder und entscheidet sich dann vielleicht eine Library daraus zu machen.
Selbiges tat ich vor kurzem und in diesem Zuge habe ich mein erstes Dart / Flutter Package veröffentlicht. OnUpgrade open_in_new soll dem Entwickler helfen eventuell nötige Migrationen bei App-Upgrades durchzuführen oder den Nutzer über neue Funktionen zu informieren. Das Package stellt dabei die Logik zum Speichern, Vergleichen und Auswerten der zuletzt installierten und aktuell genutzten App-Version zur Verfügung. Was im Falle eines Updates ausgeführt wird, wie ein eventueller Dialog aussieht oder wie der generelle weitere Ablauf ist, entscheidet der Entwickler.

• OnUpgrade auf pub.dev open_in_new
• OnUpgrade auf GitHub open_in_new
• OnUpgrade im Projektebereich open_in_new

Eigentlich möchte man defensiv programmieren und entsprechend dem Nutzer möglichst viele Fehler vom Leib halten, das macht auch Sinn. Doch Workarounds und Fallbacks über und über einzusetzen, sodass man irgendwann eher Probleme einbaut als sie zu verhindern, ist meiner Meinung nach schlimmer als ein ordentlich kommunizierter Fehler. Als Beispiel würde ich hier ein Auto nehmen. Es hat Benzin im Tank und falls selbiger bald leer ist fährt man zur Tankstelle. Sollte diese geschlossen sein, macht es Sinn zur Sicherheit einen Kanister mit Benzin auf Reserve zu haben. Was aber eher wenig Sinn macht, ist alle zufällig herumstehenden Kanister des Nachbarn in den Tank zu schütten und zu hoffen es war Benzin dabei. Mit diesem Vorgehen hat man vielleicht in wenigen Fällen Glück, meist ist es aber eher eine wenig zielführende Idee.

Sowohl GitHub Actions, wie auch Flutter waren bereits häufiger Thema hier im Blog und heute geht es um die Kombination aus beiden. Bei einem Großteil meiner GitHub Projekte nutze ich mittlerweile GitHub Actions für diverse Aufgaben und bei meinen Flutter Projekten sieht dies nicht anders aus.
Aktuell nutze ich Flutter Action open_in_new für die eigentlichen Flutter Befehle, Codecov open_in_new für das automatische Hochladen der Tests und abschließend Dart/Flutter Package Analyzer open_in_new, um das Formatting und meinen Pub.dev Score zu überprüfen. Diese Kombination erlaubt es mir mit nur einem Push einen Build zu analysieren, die Tests auszuführen und direkt bei Codecov zu hinterlegen.

• GitHub Actions open_in_new
• Codecov Website open_in_new

Auf eine übersichtliche und schön Art informieren wie der Projektstatus ist, wo man die Downloads findet und welche Lizenz genutzt wird? All das geht und zwar in Form kleiner hübscher Badges. Diese Information ist nicht neu, aber ich habe im Rahmen von einem meiner Projekte nun das erste Mal aktiv mit selbigen gearbeitet.
Für eine kleines Dart / Flutter Package, über welches ich in den kommenden Tagen berichten werde, wollte ich gerne den Status diverser Eigenschaften anzeigen und schaute mich nach verfügbaren Lösungen um.
Badges sind kleine automatisch generierte Bilder, die meist aus einem Label und der dazugehörigen Information bestehen. Normalerweise müsst ihr nur euren Projektnamen, eine öffentliche Id oder eine andere Referenz eintragen und schon geht es los.

• Badges.bar open_in_new
• Shields.io open_in_new

Das Kommentar-Service Update ist abgeschossen und im Rahmen des Updates habe ich direkt noch ein paar weitere Dinge erledigt. Das Hauptfeature ist allerdings die neue Kommentare-Abonnieren Funktion. Dies könnt ihr einfach pro News machen. Sobald dann ein neuer Kommentar in der jeweiligen News erstellt wird, erhaltet ihr eine E-Mail. Solltet ihr kein Interesse mehr an einer News haben, enthält jede der E-Mails einen One-Click Link und schon gibt es keine Nachrichten mehr.
Das Update wurde heute gegen 13 Uhr gestartet und die eigentlichen Ausfallzeiten des Kommentar- bzw. Such-Services lagen bei 5 – 10 Minuten. Nach Abschluss der eigentlichen Aktualisierung erfolgten ein paar letzte Tests auf dem Live-System und dann die Anpassung der UI. Alle Komponenten waren gegen 16 Uhr aktualisiert und liefen wieder, die gesamten Release Notes gibt es im unteren Teil der News.