Adam Grudziński

Algebra i Spółka ·

Algebra neu gebaut: von Flask-Templates zu React und TypeScript

Der Kalender funktionierte, doch Unterrichtsraum, Aufgaben und Schülerbereich ließen sich im alten Aufbau immer schwerer erweitern. Zuerst bildete ich die vorhandenen Funktionen in React und TypeScript nach; erst danach begann ich, sie zu verbessern.

Zum Beitragstext

In den ersten Monaten funktionierte Algebra so wie die meisten einfachen Websites. Der Browser fragte beim Server eine Seite an, und der Server, geschrieben in Flask (einem verbreiteten Werkzeug zum Bau von Websites), nahm ein fertiges Seitengerüst, ein sogenanntes Template, setzte Daten aus der Datenbank ein und schickte das Ganze zurück. Für Seiten, die sich nicht ändern, und für das Buchungsformular reichte das völlig.

Im Winter war Algebra aber keine Website mit Kalender mehr. Dazu kamen ein Schülerbereich mit Aufgaben, in denen Formeln wie im Schulbuch aussehen müssen, eine Formelsammlung, die Einstufung des Niveaus, die ersten Spiele und ein Unterrichtsraum mit Video und Tafel. All das passiert auf dem Bildschirm des Schülers: Es reagiert auf Klicks, rechnet neu und verändert sich, ohne dass die Seite neu geladen wird. Auf die alte Art hieß das immer mehr einzelne Codestücke, die an die Seiten angeklebt wurden und immer weniger voneinander wussten.

Warum neu bauen

Im Januar versuchte ich noch, den alten Aufbau zu retten. Aus den größten Seiten, dem Aufgabenbereich und der Formelsammlung, zog ich Aussehen und Verhalten in eigene Dateien, damit man sie überhaupt lesen konnte. Das half eine Weile, aber mit jeder neuen Funktion kam dasselbe Problem zurück: Wie eine einzelne Seite funktionierte, war über mehrere Dateien an verschiedenen Stellen verstreut, und eine Korrektur an einer Stelle machte etwas an einer anderen kaputt.

React, ein Werkzeug für Websites, die sich wie Apps verhalten, löst genau dieses Problem. Es teilt den Bildschirm in Bausteine auf, und jeder davon, etwa das Fenster mit einer Aufgabe, hat sein Aussehen und sein Verhalten an einem Ort. TypeScript ergänzt das um eine genaue Beschreibung der Daten, die zwischen den Teilen der Anwendung hin- und hergehen. Das klingt nach Formalität, bedeutet in der Praxis aber, dass der Computer einen guten Teil der Fehler findet, bevor eine neue Version auf die Website kommt, und nicht erst beim Schüler, der gerade eine Stunde buchen will.

Erst eine treue Kopie, dann Änderungen

Wer etwas neu baut, das funktioniert, ist versucht, bei der Gelegenheit alles auf einmal zu verbessern. Ich hielt das für den direkten Weg in eine Lage, in der nichts funktioniert und niemand weiß, warum. Deshalb habe ich Ende Februar eine Seite nach der anderen übertragen, jede so, dass sie genauso aussah und funktionierte wie bisher. Zuerst kamen die, ohne die es die Plattform nicht gibt: Aufgaben, Anmeldung über Google, Buchungen und Nachrichten. Danach Kalender, Profil, Einstufung, Zahlungen und der Unterrichtsraum, und zum Schluss zehn kleinere Seiten, die es bis dahin nur dem Namen nach gab.

Erst als die neue Version alles konnte, was die alte konnte, habe ich mich an Änderungen gemacht. Anfang März hörte der Server auf, Seiten zusammenzubauen. Seitdem speichert er nur noch Daten und beantwortet die Fragen, die ihm die Website stellt, während das, was der Nutzer sieht, erst in dessen Browser entsteht. Die alten Templates habe ich aus dem Projekt entfernt, und beide Teile führten fortan ein völlig eigenes Leben.

Website und Daten an zwei Orten

Durch die Trennung änderte sich auch, was wo läuft. Der Teil, den der Nutzer sieht, besteht jetzt aus fertigen Dateien, die Cloudflare ausliefert, eine Firma, die Kopien von Websites nah bei den Besuchern bereithält, sodass ich mich hier um keinen Server kümmern muss. Der Datenteil blieb bei Render, einer Firma, die Anwendungen auf ihren eigenen Servern laufen lässt, und im April habe ich ihn zu einem ähnlichen Dienst umgezogen, Koyeb. Die Datenbank selbst wanderte im März von Neon zu Supabase, wo sie bis heute läuft.

Mit dieser Aufteilung kamen Probleme, von denen ich vorher keine Ahnung hatte. Der Browser achtet auf Sicherheit und lässt eine Seite unter einer Adresse nicht einfach so mit einem Server unter einer anderen sprechen, also musste der Datenserver eine Liste der Adressen bekommen, von denen aus man ihn fragen darf. Am tückischsten war eine Kleinigkeit: Der Server leitete Fragen an eine Adresse ohne Schrägstrich am Ende auf dieselbe Adresse mit Schrägstrich um, und bei so einer Weiterleitung verwarf der Browser die Frage, bevor sie überhaupt ankam.

Ein Unterrichtsraum, der sich alle paar Tage änderte

Parallel zum Umbau suchte ich nach einem Weg, online zu unterrichten, ohne zwischen Anwendungen hin- und herzuspringen. Ende Januar setzte ich eine Tafel von Miro auf die Seite. Anfang Februar ersetzte ich sie durch die Tafel tldraw mit Videogesprächen über Jitsi und einen Tag später durch die Tafel WBO, weil tldraw die Räume abgeschaltet hatte, die ich nutzte. Zwei Tage darauf stellte sich heraus, dass der öffentliche Jitsi-Server Gespräche, die auf einer fremden Seite eingebaut sind, nach fünf Minuten abbricht. Also probierte ich noch am selben Tag JaaS aus, Jitsi als fertigen Dienst, und stieg am Abend auf eine eigene Videoverbindung um, gebaut mit PeerJS, einem Werkzeug, das Browser direkt miteinander verbindet.

Jede dieser Änderungen reparierte etwas und nahm etwas anderes weg. Aus diesen Wochen habe ich eines mitgenommen: Ein fremder Dienst auf der eigenen Seite spielt immer nach fremden Regeln, und die können sich von einem Tag auf den anderen ändern.

Nach dem Umstieg

Heute ist alles, was der Schüler sieht, mit React und TypeScript gebaut, und der Flask-Server kümmert sich nur noch um die Daten. Eine neue Funktion bedeutet meistens einen neuen Baustein auf dem Bildschirm und eine neue Frage, die der Server beantworten kann, und nicht ein weiteres Codestück, das an eine alte Seite geklebt wird. Die wichtigste Lehre aus diesem Umstieg hat aber nichts mit React zu tun: Wenn man etwas neu baut, das funktioniert, sollte man es zuerst eins zu eins nachbauen und erst danach verbessern.

Die ganze Serie

Das ist der dritte Teil einer Serie darüber, wie Algebra i Spółka entstanden ist:

  1. Die erste Algebra: Flask, Templates und PHP, das ich schnell aufgab
  2. Buchungen, die bei jedem Deployment verschwanden
  3. Algebra neu gebaut: von Flask-Templates zu React und TypeScript
  4. Eine Preisliste in einer Datei, Premium und mein erstes Zahlungsgateway
  5. Aufgaben, eine Formelsammlung und Zeichnungen, die nicht stimmen wollten

Wie das Ganze heute aussieht, beschreibe ich im Beitrag Algebra i Spółka von innen.