…oder doch? Der letzte Blogeintrag ist schon ein paar (> 365) Tage her. Da könnte der Eindruck entstehen, dass sich im letzten Jahr in Sachen IT nicht viel getan hat.
Das Gegenteil
ist der Fall. Ich glaube, dass es nicht ganz einfach wird, alles, was im letzten Jahr passiert ist, zusammenzufassen, aber ich starte einfach mal.
Plan B
Seit dem letzten Schuljahr 2021/2022 ist unsere neue Vertretungsplan-App im täglichen Einsatz.
Seit den ersten Tests zum Ende des (vor)letzten Schuljahrs startete die App dann für das Kollegium und die Schülerschaft. Da wir die App per LDAP an unser Benutzerverzeichnis binden können waren sehr schnell alle Benutzer dabei und nutzten bald die App regelmäßig.
Zu diesem Zeitpunkt war die App noch so konzipiert, dass eine permanente Internetverbindung nötig war. Zudem war das Zusammenspiel von Front- und Backend nicht optimiert. Was die technischen Details angeht hier der Versuch einer groben Zusammenfassung von meinem einjährigen Trial- and Error-Marathon.
Die Frameworks
Plan B basiert (zur Zeit 😉 ) im Wesentlichen auf dem Meteor JS Framework. Dies ist ein Fullstack Javascript Framework, das für Entwickler eine Art „all-in-one“ Lösung für MongoDB+NodeJS Backend und (in unserem Fall) ReactJS Frontend bietet. Daten aus der NoSQL Datenbank MongoDB werden dabei per DDP Protokoll direkt an den Client gepusht. Das heißt, es sind keine gesonderten API Requests nötig, um eine Sicht auf den aktuellen Datenbestand zu haben. Änderungen in der Datenbank werden per Observer direkt an den Client weitergegeben. Diese Kanäle lassen sich per Pub/Sub Verfahren öffnen (und schließen). Änderungen an der Datenbank werden in der Regel über Methoden und oder Client Aktionen auf den Mongo Collections realisiert. Meteor nutzt hierfür die clientseitig MiniMongo Bibliothek.
Meilensteine
Auf dem Weg zur aktuellen Programmversion haben sich einige sehr entscheidende Dinge, meist im Hintergrund der App, geändert. Alle Änderungen brachten neue Funktionen, Optimierungen (Server, Client, Datenverbrauch) und natürlich neue Bugs mit sich 😉
Minimierung von Subscriptions
Observer sind teuer. Sie kosten CPU Zeit auf dem Server. Je mehr Subscriptions und Observer offen sind, desto höher die Speicher und CPU Auslastung. Zu Beginn hatte ich schnell festgestellt, dass wenn z.B. der Zugriff einer gesamten Klasse (im Anfangsunterricht in Informatik der Klasse 5 z.B.) stattfand, die Reaktionszeit der App gegen unendlich strebte.
Durch das einfache Reduzieren der Menge von Subscriptions pro Client konnte die CPU Auslastung erheblich gesenkt werden. Von unschätzbarem Wert dabei ist das Meteor DevTool. Hier bekommt man eine schöne Übersicht über alle aktiven Subscriptions, den aktuellen Stand der MiniMongoDB und mittlerweile auch Performance Infos.
Datenbank-Schema
Zu Beginn war Plan B als reines Anzeige-Werkzeug für MacStupas5 XML Daten gedacht. Die exportierten XML Daten wurden daher einfach per XML Parser in JSON Objekte verwandelt und dann in der App angezeigt. Das klappte zunächst mal sehr schnell, brachte aber potenzielle Probleme und Grenzen mit sich.
Zum Einen waren die Views im Frontend natürlich auf die JSON Struktur der Objekte angewiesen. Änderungen hier hätten unmittelbar massive Änderungen an den jeweiligen React Komponenten bedingt. Zum Anderen waren durch diesen im Grunde nicht vorhandene Datenmodell keine CRUD Operationen auf den Entitäten möglich, da es de facto keine Entitäten (Klassen, Lehrer, Räume, …) gab.
In den Herbstferien 2021 kam dann das Konzept auf, alle Stundeneinträge, Vertretungen und weitere beteiligte Objekte zu klassifizieren und in Form von geeigneten Datenbankschemata zu modellieren. Das erforderte einen massiven Umbau des Backends, brachte zwangsläufig komplexere Import-Methoden für Stunden- und Vertretungsinfos mit sich und bei der Gelegenheit wurde das gesamte Backend in JSDoc dokumentiert.
Durch den Umbau wurde Plan B erstmal zu einem potenziell eigenständigen Vertretungsplanprogramm, da durch geeignete CRUD Operationen nun das Erstellen von Plänen direkt in der App möglich wurde.
Erst durch die Remodellierung der Datenbankstruktur wurde es möglich, Features wie Raum-Reservierungen oder Raum-Änderungen einzubauen.
Ready for Dorfleben: Offline First
Der nächste große Umbau der App fand dann in den Weihnachtsferien statt. Zunächst wurde der „offline first“-Ansatz implementiert. Das heißt, die häufig verwendeten Daten, die per Subscription (oder nicht-reaktiv per Methode) auf dem Client landen, werden auf einer lokalen Datenbank im Client gespeichert. So können auch bei fehlender / langsamer Internetverbindung Infos jederzeit eingesehen werden. Ist die Verbindung wieder da, werden die Daten automatisch rehydriert.
Untis
Um auch potenziell für andere Planprogramme offen zu sein wurde ein Untis Import implementiert. Dabei wurde auch das Absenz-Schema überarbeitet.
Monitoring
Auch im Bereich Monitoring wurde die App wesentlich verbessert. Detaillierte Angaben zu Servermetriken, CPU und RAM Auslastung, Observer, Oplog Infos, Node Infos, Methoden und Pub/Sub Response Zeiten etc. können nur für die gezielte Optimierung des Backends genutzt werden.
Multi Tenancy
In den Sommerferien war es dann soweit: Die „SGS VPlan“ App hat ein neues Label bekommen und heißt nun „Plan B“.
Neben der Umbenennung kam noch der Support für „Multi Tenancy“, also die Unterteilung der App in verschiedene, voneinander getrennte Einheiten, hinzu. Konkret heißt das: Auch andere Schulen konnten prinzipiell bei Plan B mitmachen. Auslöser hierfür war eine Anfrage unserer Nachbarschule (https://www.hauptschule-sundern.de). Diese nutzt Untis, und einige Tests zeigten, dass auch hier Plan B sinnvoll genutzt werden kann.
Mittlerweile wird Plan B an der Hauptschule Sundern und auch am St. Anna Gymnasium Wuppertal mit Untis und MacStupas5 getestet. Durch die aktive Nutzung und die vielen hilfreichen Rückmeldungen von vielen der mittlerweile mehr als 1300 Benutzern wird die App immer weiter „feingeschliffen“, Bugs ausgemerzt und die Zuverlässigkeit weiter gesteigert.
Skalierbarkeit
Mehr Benutzer heißt potenziell mehr Serverlast, heißt möglicherweise mehr Probleme bei der Auslastung.
Zu Beginn des neuen Schuljahres wird die App bei scalingo.com gehostet. Hier ist die DSGVO-konforme Auftragsdatenverarbeitung sichergestellt. Außerdem bietet Scalingo einen sehr komfortablen Workflow für das Deployment und den Build Prozess. Zudem sind dort Meteor Anwendungen per Loadbalancer inkl. sticky Session Support samt MongoDB Replica Set gut und ohne downtime skalierbar.
Pläne?
Auch wenn die Ideen für Features nicht enden wollen, werde ich mich in den nächsten Wochen auf die Zuverlässigkeit der Codebasis, vor allem für das Backend, konzentrieren. Hier können und müssen noch jede Menge Unit- und Integration-Tests geschrieben werden.
Weiterhin wird in Absprache mit der Hauptschule Sundern der Untis Import weiter verbessert und in der Praxis erprobt.