Technik

So ist Plantini gebaut

Plantini ist noch nicht veröffentlicht; die Seite und die Testversion sind ein unvollständiger Teaser (siehe Hinweis zum Stand des Projekts unten). Plantini soll für Schulen und für alle Neugierigen zuverlässig laufen, Kinderdaten schützen und mit der Community wachsen können. Diese Seite erklärt, wie die Plattform aufgebaut ist, warum wir uns für diese Bausteine entschieden haben und wohin sie sich entwickeln kann.

Das Gesamtbild

Plantini besteht aus drei Teilen: der App, dem Server und dem Anmeldedienst. Der Server vereint die Fach-API und das Redaktionssystem für Inhalte (beides auf Basis von Strapi). Die App spricht ausschließlich mit der Fach-API und dem Anmeldedienst. Die Verwaltungsoberfläche des Redaktionssystems, die Datenbank und der Bestimmungsdienst sind von außen nicht erreichbar.

Architektur von Plantini Die App spricht über Caddy mit der Fach-API und dem Anmeldedienst. Die Fach-API nutzt Redaktionssystem, PostgreSQL, Redis und den externen Bestimmungsdienst Pl@ntNet. AppFlutter · Web, Android, iOS CaddyHTTPS · Eingang Fach-APIStrapi · Node.js KeycloakAnmeldung · OpenID Connect PostgreSQLDaten RedisWarteschlange Pl@ntNetBestimmung (extern) Wikipedia · OSMTexte, Fotos, Karten

Durchgezogen: eigene Dienste auf unserem Server. Gestrichelt: externe Quellen. Die Fach-API ruft sie selbst ab; die App spricht nie direkt mit ihnen.

Vom Foto zur Bestimmung

  1. Die App reduziert das Foto auf das Nötige (ohne Metadaten) und lädt es privat auf den Server.
  2. Die Fach-API legt einen Auftrag in die Warteschlange (Redis). Ein Worker fragt Pl@ntNet ab – mit dem Schlüssel, den die App nie sieht.
  3. Die App zeigt Vorschläge mit Ähnlichkeit. Erst wenn die Person einen Vorschlag bestätigt, entsteht der Fund im privaten Herbarium.
  4. Ohne Netz wird der Fund lokal gespeichert und später mit stabilen IDs übertragen. Doppeltes Senden erzeugt keine doppelten Funde.

Warum diese Architektur gut ist

Ein Vertrag für alles

Die Schnittstelle ist in einer OpenAPI-Datei beschrieben. Daraus entsteht der Client der App automatisch. Server und App können nicht unbemerkt auseinanderlaufen, und Änderungen fallen schon beim Bauen auf.

Der Server entscheidet

Levelabschluss, Bestimmung und Berechtigungen prüft der Server, nicht die App. So lassen sich Ergebnisse nicht am Handy fälschen, und Geheimnisse wie der Pl@ntNet-Schlüssel bleiben auf dem Server.

Offline zuerst

Lernen und Herbarium funktionieren draußen ohne Empfang. Schreibvorgänge tragen eindeutige IDs und sind wiederholbar; ein abgebrochener Upload richtet nichts an.

Datenschutz im Entwurf

Fotos und genaue Fundorte gehören den Lernenden und sind nur für sie sichtbar. Statistiken (zum Beispiel „wie viele haben diese Art gesammelt“) erscheinen erst ab einer Mindestzahl von Konten, damit niemand erkennbar wird. Kartenkacheln laufen über unseren Server, damit der Kartenanbieter weder IP-Adresse noch angesehene Orte erfährt. Diese Website lädt keine Schriften oder Skripte von Dritten.

Geprüfte Inhalte, nachvollziehbar veröffentlicht

Pflanzen, Ökosysteme und Quizfragen werden redaktionell gepflegt und als unveränderliche Veröffentlichung (Release) ausgeliefert. Fehlerhafte Inhalte lassen sich zurückrollen, die App lädt nur vollständige, geprüfte Stände.

Eine Codebasis, viele Geräte

Dieselbe App läuft im Browser, auf Android, iOS und Linux. Wir pflegen eine Oberfläche statt vier und liefern Fehlerkorrekturen überall gleichzeitig aus.

Schlank und austauschbar

Der ganze Betrieb läuft in Containern auf einem einzigen Server und lässt sich auf einem anderen Server in kurzer Zeit neu aufsetzen. Jeder Baustein ist Open Source und durch eine Alternative ersetzbar, ohne dass wir von einem Anbieter abhängen.

3D ohne Spezialtechnik

Die 3D-Ökosysteme und Charaktere entstehen in Blender und werden als schlanke Geometrie ausgeliefert. Die App zeichnet sie selbst, ohne Spiele-Engine und ohne Zusatzmodule, und läuft daher auch auf einfachen Geräten.

Warum wir diese Anbieter gewählt haben

Unsere Auswahlkriterien waren immer dieselben: offene Lizenz, selbst betreibbar, reif und weit verbreitet (damit es Dokumentation, Updates und Fachleute gibt) und sparsam mit Daten. Nur wo es keine freie Alternative gibt, nutzen wir externe Dienste, und dann nur serverseitig.

BausteinWarum
FlutterEine App für Web, Android, iOS und Desktop; eigene Zeichenschicht für unsere 3D-Ansichten; gute Offline-Werkzeuge; große Community.
StrapiQuelloffenes Redaktionssystem mit Rollen und Entwurf/Veröffentlichung. Redakteur*innen pflegen Inhalte ohne Programmierung, wir erweitern es mit eigener Fach-API.
KeycloakBewährter, quelloffener Anmeldedienst mit OpenID Connect. Wir müssen keine Passwörter selbst speichern, bekommen E-Mail-Bestätigung, Rollen (auch für Lehrkräfte) und sichere Anmeldeverfahren (PKCE) fertig.
PostgreSQLZuverlässige, freie Datenbank mit starken Garantien für Konsistenz; seit Jahrzehnten erprobt.
RedisSchnelle Warteschlange: Bestimmungen laufen im Hintergrund, begrenzen Anfragen an Pl@ntNet und überstehen Ausfälle durch Wiederholung.
CaddyWebserver, der HTTPS-Zertifikate automatisch beschafft und erneuert. Wenig Konfiguration heißt weniger Fehlerquellen.
DockerGleiche Umgebung auf Entwicklungsrechner und Server; Updates sind ein Austausch von Images und lassen sich zurücknehmen.
Pl@ntNetWissenschaftlich getragene Pflanzenbestimmung. Wir nutzen sie nur serverseitig; Bestimmungen sind Vorschläge, keine Garantie.
Wikipedia, Wikimedia, iNaturalistFreie Texte und Fotos mit klarer Lizenz. Wir zeigen immer Urheber*in und Lizenz, prüfen Zuordnungen und speichern Kopien auf unserem Server, statt die Quellen bei jedem Aufruf zu belasten.
OpenStreetMapFreie Karte für das Herbarium; wir laden Kacheln einmal und liefern sie aus unserem Zwischenspeicher aus.
Blender, three.js, ViteFreie Werkzeuge für Modelle, 3D auf der Website und den Bau der Seite; alle ohne Lizenzkosten und mit Dateiformaten, die wir behalten.
netcupDeutscher Hosting-Anbieter für den Server. Der Betrieb liegt in unserer Hand und ließe sich jederzeit zu einem anderen Anbieter oder in eine öffentliche Infrastruktur umziehen.

Wie sich Plantini künftig erweitern lässt

Ehrlich gesagt: der aktuelle Stand

Plantini ist ein früher, aktiv entwickelter Stand. Ein Server trägt derzeit alles, eine nächtliche Sicherung läuft auf demselben Server (ohne externe Kopie), eine Überwachung mit Alarmierung fehlt noch, und die Inhalte werden schrittweise fachlich geprüft. Die Architektur ist so gewählt, dass diese Lücken geschlossen werden können, ohne von vorn zu beginnen. Fragen oder Ideen? Schreib mir. Eine Liste der verwendeten Software mit Links findest du auf der Startseite. Was sich wann geändert hat, steht im Änderungsprotokoll. Für alle, die mitarbeiten möchten, gibt es ein ausführliches Entwicklerhandbuch mit Architektur, Code, Betrieb und Anleitung zur Redaktion. Es ist passwortgeschützt; den Zugang gibt es auf Anfrage.

Hinweis zum Stand des Projekts