Frei3.de – Wie schwer ist es, eine Plattform zu entwickeln? Fallstudie

Aus AutarkWiki
Zur Navigation springen Zur Suche springen
HagenGrell-Person-frei3-001.jpg

Wie schwer ist es, eine Plattform zu entwickeln?

Die Online-Plattform Twitter wird von vielen Nutzern als sehr leicht zu bedienen empfunden, daher müsste es doch auch leicht sein, Twitter zu programmieren, richtig? YouTube, Facebook und TikTok machen uns scheinbar spielend interessante Vorschläge, das müssten andere Plattformen doch auch können, oder? Als Nutzer der populäre Silicon-Valley- und mittlerweile auch China-Tech-Plattformen (TikTok, DLive, Trovo etc) sind wir häufig sehr verwöhnt, was die schiere Nutzerfreundlichkeit von modernen Online-Plattformen angeht. Doch was leicht aussieht, ist nicht leicht gemacht, meist im Gegenteil: Je intuitiver, bequemer und einfacher eine Plattform zu bedienen ist, desto mehr Gehirnschmalz und Arbeitsleistung steckte in ihrer Entwicklung. Eine Fallstudio zur Plattform
https://www.frei3.de.

Siehe: Hagen Grell

Mein Name ist Hagen Grell

und als Gründer, Projektleiter und Co-Entwickler eines Technologie-Startup-Unternehmens habe ich eine besondere Perspektive, was Schein und Sein moderner Internet-Plattformen betrifft. Als ich 2018 gemeinsam mit einem Backend-Entwickler begann, die Plattform frei3.de zu entwickeln (damals noch „FreiHoch3“ genannt), waren wir überschwänglich von jugendlicher Arroganz und Selbstüberschätzung. Die meisten Programmierer, die etwas auf sich halten, werden folgenden Sturm-und-Drang-Gedanken kennen: „Ok, das ist eine tolle Herausforderung, dieses Programm kann ich in einem Monat fertig schreiben, kein Problem für mich und meine Spitzenfähigkeiten“. Und ja, gelegentlich haben wir Glück und es handelt sich um ein schwieriges, aber beherrschbares, abgegrenztes Problem, welches innerhalb einer gewissen Zeit tatsächlich erledigt ist, obgleich aus einem Monat dann gern drei werden können .

Doch was passiert, wenn eine Aufgabe so groß ist und gleichzeitig so klein scheint, wie ein Eisberg, dessen 5% Spitze aus dem Wasser ragt und dessen 95% Masse sich bedrohlich unter der Oberfläche versteckt? Was passiert, wenn man obendrein ein Versprechen gegeben hat und diese Versprechen dazu öffentlich verkündete? Und was wenn man als Kirsche auf der Torte 68.000 Euro als Startfinanzierung sammelte und daher nicht mehr „aus der Nummer“ herauskommt? – Über die Höhen und Tiefen dieser Achterbahnfahrt, über Schweiß, Tränen und Glücksgefühle und über den goldenen Wert von Durchhaltevermögen möchte ich Ihnen heute berichten.

Fertig-Lösungen, Forking, Neuentwicklung

Als wir mit den Arbeiten an frei3 starteten, war uns klar, dass wir mit einer Neuentwicklung begannen. Fertig-Lösungen wie BuddyPress, BuddyBoss, Huthub oder PeerTube (letztere für Videoanwendungen) wären zwar eine Möglichkeit für die Anfangszeit gewesen, um binnen kurzer Zeit etwas vorlegen zu können (vergleichbar damit, eine fertige App einfach auf dem Smartphone zu installieren). Aber dies hätte uns später in massive oder sogar unlösbare Schwierigkeiten gebracht, wenn wir von zehntausende auf hunderttausende auf Millionen Nutzer würden „hochsklarieren“ müssen. Hochskalieren bedeutet, eine Anwendung mit all ihren komplizierten, ineinander verwobenen Funktionalitäten für eine plötzlich exponentiell höhere Nutzerzahl (zB in kurzer Zeit verzehnfacht) bereitstellen zu müssen. Das ist alles andere als trivial und hätte uns bei einer Fertig-Lösung das Genick brechen können.

Einfach neue Server dazu stellen und die Anwendung darauf installieren, ist technisch unmöglich, denn folgende Fragen müssen umfassend gelöst werden: (1) Wie kommunizieren die Server miteinander und „sprechen sich ab“, wie wird die Last verteilt? (2) Wie kommunizieren die Server abhörsicher unter höchstem Sicherheitsstandard? (3) Wie und wann werden die Datenbanken miteinander abgeglichen? (4) Wie werden die Daten auf den verschiedenen Servern redundant gespeichert, um Datenverlust zu vermeiden, wenn zB eine Festplatte ausfällt? (5) Wie wird Datenkonsistenz gesichert, wenn zB ein Serverzentrum in einem Teil der Welt ausfällt, aber die anderen Server noch erreichbar sind? (6) Wie geht man mit nötigen Wartungsarbeiten um und synchronisiert Updates auf allen Servern? (7) Wie versteckt und schützt man die tatsächlichen IPs der Server, um gegen Hacker-Angriffe gerüstet zu sein, insbesondere bei vielen Servern? (8) Wie garantiert man einen reibungslosen Traffic-Fluss für den Proxy, wenn die meisten Anbieter ab einem bestimmten verbrauchten Traffic-Volumen drosseln? – Und viele viele Fragen mehr.

HagenGrell-Person-frei3-012.jpg

Philosophie der frei3-Entwicklung

Eine eigene Anwendung hat auch den unschlagbaren Vorteil, komplett unter eigener Kontrolle zu liegen, sodass das Team frei und kreativ entwickeln kann und nur die eigene Fantasie und die Fantasie (und Wünsche) der Kunden die Obergrenze darstellen. Die Weiterentwicklung einer fremden App dagegen stößt nicht nur an mögliche Lizenzprobleme, sondern auch an „Legacy“-Probleme. Das heißt, sobald zB PeerTube einen Fork bekommt (Abtrennung von der Hauptentwicklungslinie für eigene Anpassungen) – nennen wir diesen Fork zum Beispiel „MeinPeerTube“ – wird es schwieriger oder mit der Zeit sogar unmöglich, Verbesserungen von PeerTube in MeinPeerTube zu übernehmen. Zudem müssen die MeinPeerTube-Entwickler sich so tief in die PeerTube-Software einlesen und werden so viel Code selbst schreiben, dass mit der Zeit (2-3 Jahre später) MeinPeerTube zu einer de facto kompletten Eigenentwicklung wird, die mit PeerTube nur noch wenig gemeinsam hat. Und die MeinPeerTube-Entwickler laufen sogar Gefahr, die grundsätzliche Kern-Software von PeerTube umschreiben zu müssen, wenn PeerTube software-architektonisch ein anderes Ziel hatte als die Entwickler von MeinPeerTube nun verfolgen.

Bei frei3 sind wir daher einen anderen Weg gegangen und haben von Anfang an auf eine Neuentwicklung gesetzt. Im Vergleich mit dem Forking-Ansatz ist dies analog zu einem Wettrennen zwischen einem Fahrrad (Forking) und einem LKW (Neuentwicklung). Das Fahrrad wird in der Anfangszeit viel schneller vom Fleck kommen und den LKW zunächst gnadenlos abhängen. Doch sobald der massige LKW Fahrt aufgenommen hat, wird er das Fahrrad letzlich überholen und (ver)trägt auch viel mehr Masse in seinem Innern (Nutzer, Funktionalität, Traffic etc), was für eine Online-Plattform entscheidend ist.

Natürlich setzen wir dennoch auf moderne Web-Technologien, die hier gar nicht alle aufgelistet werden können, ohne in Technik-Jargon zu verfallen. Das heißt, wir verfolgen einerseits modular eine PIE-Philosophie „Proudly invented elsewhere“ – stolze Nutzung fremder Software – allerdings nur für nicht-kritische Software-Bereiche.

Kritische, meist sicherheitsrelevante Bereiche auf frei3 entwickeln wir selbst. Dies geht soweit, dass wir die Zusammenarbeit mit Anbietern wie AWS oder Cloudflare vermeiden, um nicht auf deren guten Willen angewiesen zu sein, sondern notfalls unsere Software von einem zum nächsten Server-Anbieter oder in eigene Mini-Rechenzentren auslagern zu können. Wir verfolgen damit die NIH-Philosophie „Not invented here“ – dies ist die Vermeidung fremder und möglicherweise korrumpierbarer Software in kritischen Bereichen.

Hier beantwortet sich auch die Frage „Warum das Rad neu erfinden?“, denn diese muss richtiger heißen: „WANN das Rad neu erfinden?“ – Immer dann, wenn die bisherigen Räder nicht dem Anwendungsfall genügen! – Kann ich mit einem Autorad (mit Felge und Reifen) auch bequem das Auto lenken? – Nein, daher erfinde ich das Lenkrad. Kann ich mit dem Autorad oder Lenkrad in einem Getriebe Kräfte übertragen und transformieren? – Nein, daher erfinde ich das Zahnrad. Kann ich mit einem Autorad, Lenkrad oder Zahnrad ein leichtgewichtiges, von einer Person bewegbares Fahrrad bauen? – Nein, daher erfinde ich das Fahrrad-Rad mit Speichen. Die Liste ist lang. Ja, es lohnt sich, das Rad immer wieder neu zu erfinden, wenn es für einen neuen Anwendungsfall notwendig ist.

Der Entwicklungs-Eisberg Online-Plattform

Kommen wir zu den Tiefen der Entwicklung einer Online-Plattform.

Was ist alles nötig für eine neue Plattform wie frei3.de, um den immensen Technologie-Vorsprung aufzuholen, den „Big Tech“ Silicon-Valley-Riesen mit 2- bis 3-stelligen Millionensummen durch Investoren aufbauen konnten?

Zunächst einmal das Design:
Dieses entsteht nicht von heute auf morgen, sondern ist ein stetiger Prozess der Weiterentwicklung. Dies ist auch an den turnusmäßigen Schönheitsoperationen zu erkennen, die Facebook und YouTube sich selbst verschreiben. Ziel ist es, die Plattform soweit in den Hintergrund zu rücken, dass die Inhalte maximal „strahlen“ können. Dies kann in Extremfällen soweit gehen, dass die Plattformen sich so dermaßen „häuten“, dass sie nahezu ihr eigenes „Branding“ verlieren. Solch eine Plattform in ihren schlichten Grautönen und minimalen Strukturelementen kann oft kaum noch von den anderen unterschieden werden.

Dennoch steckt grundsätzlich eine hohe Kunst hinter dem Interface-Design:
Der Nutzer muss (1) möglichst leicht durch technisch hochkomplizierte Vorgänge geführt werden, sodass er (2) geradezu spielerisch hochkomplexe Funktionen versteht und anwenden kann, (3) ohne ein Handbuch zu lesen. Optimalerweise sollte er dabei (4) möglichst wenige Klicks benötigen, (5) kaum Ladezeiten „erleiden“ müssen und (6) sich selbst in neuen Menüs sofort und ohne Frust zurecht finden.

Und dies ist auch ein perfektes Beispiel für die Eisberg-Analogie. Über der Oberfläche sind die Menüs leicht, einfach und intuitiv. Unter der Oberfläche dauert es meist zig bis hunderte kleiner und großer Iterationen, um ein anfangs grobes, unpraktisches, hässliches Menü zu einem schlanken, wohlgeordneten, verständlichen Menü umzubauen.

Nicht zu vergessen, (7) die optisch befriedigende Ästhetik, sodass Ränder miteinander abschließen oder so wirken (denn manchmal müssen absichtlich einen Pixel „ungerade“, um gerade zu wirken), Farben miteinander harmonieren und Animationen flüssig sind und angenehme Emotionen hervorrufen. Und nicht zu vergessen: All diese Anforderungen müssen natürlich (8) responsive sein, das heißt auf Geräten und Bildschirmen beliebiger Größen von 400 Pixel bis 4000 Pixel schön aussehen, gut lesbar und angenehm benutzbar sein.

Sicherheit:
ist ein weiterer extrem wichtiger Faktor, insbesondere für neue Plattformen wie frei3.de:
Der Nutzer darf nur angemeldet gewissen Funktionen sehen und nutzen. Hacker dürfen keinen Zugriff auf sensible Daten bekommen. Nutzer dürfen nur verifiziert auf verschiedene Services und Daten Zugriff bekommen. Dabei kommen Datenbanksysteme ins Spiel (wir nutzen 4 verschiedene Datenbanksysteme um ihre Vorteile miteinander zu vereinen), Web-Server-Software, Proxy-Server-Software, Frameworks (wir nutzen Java und verschiedene Java-Frameworks), Tunneling-Softare, Javascript- und Javascript-Frameworks und die verschiedenen Provider-Schnittstellen. Natürlich muss die Kommunikation verschlüsselt sein und auch die Nutzung von Cookies und LocalStorage im Browser sollte ein gewisses Maß an Sicherheit bieten.

Um Ihnen nun die schiere Masse an Standard-Funktionalität einmal vor Augen zu führen, die der Nutzer von einer Online-Medien-Plattform unbewusst erwartet, hier eine kurze Aufführung derselben.

  • Suche: Der Nutzer möchte schnell, bequem, optisch ansprechend und übersichtlich aufbereitet in allen nutzergenierten Daten suchen, automatische Suchvorschläge bekommen, dabei leicht den Überblick behalten und zusätzlich nach verschiedenen Kriterien filtern. Dafür werden Vorschaukarten benötigt, die optimalerweise Sonderfunktionalität wie Datum-als-Phrase (zB „vor 3 Tagen“) oder einen integrierten Abo-Knopf haben.
  • Der Nutzer erwartet weiterhin Standard-Elemente wie Modal-Fenster (oder In-Window-Popups, Lightboxes, es gibt viele Synonyme), Dropdown-Menüs, die Möglichkeit per Drag&Drop zu sortieren, bequeme Datumswähler, Mehr/ Weniger-Anzeigen Bereiche, auch Pager und verschiedene Fortschrittsanzeigen oder dass statt eines Scrollbalkens die Textbox mitwächst, wenn man den Text eingibt
  • Die Navigation darf natürlich auch nicht vernachlässigt werden. Der Nutzer erwartet ein schickes Menü, was immer und überall verfügbar ist und übersichtlich die schiere Komplexität der Seite in logischen Kategorien darstellt. Auch eine Unternavigation darf nicht fehlen, um Unterbereiche übersichtlicher zu machen.
  • Natürlich sind auch Javascript-Services unerlässlich, die der Nutzer allerdings gar nicht sieht. So brauchen die meisten Online-Plattformen wie wir eine Bibliothek zur Positionierung von Elementen, eine Emoji-Bibliothek, eine Bibliothek, um URLs zu erkennen und durch Links zu ersetzen, eine Bibliothek für hauseigene Ajax-Calls, eine Bibliothek für Daten-Management auf Browser-Seite (zB erkennen wir, ob Ihr Formular-Text von Ihnen verändert wurde oder wieder in den Ursprungszustand zurückgekehrt ist). Von etlichen Datums-, Zahlen- und logischen Funktionen ganz zu schweigen.
  • Auch die Datenkonvertierung muss gesondert behandelt werden. Dazu gehört ein API-Format, Konvertierung zwischen Datenbank-Ausgaben, Objekten, JSON und anderen Datenformaten und -prinzipien.
  • Der Nutzer muss über Neuerungen informiert werden, daher braucht eine Plattform ein Nutzer-Info-System. Am besten eines, was neben dem Notifications-System existiert, denn Notifications sind zwischen den Nutzern untereinander und gehen leichter unter. Sie brauchen außerdem ein Alerts-System, das sind direkte Rückmeldungen, die er Nutzer bekommt wie „Seite gespeichert“. Und zuletzt brauchen Plattformen ein hauseigenes CMS, um den eigenen Content auf den eigenen Seiten zu verwalten.
  • Auch erwartet der Nutzer für jede relevante Seite auf anderen Plattformen eine Link-Vorschau, die Open-Graph und Twitters Pendant unterstützt – Überschrift, Titelbild, Textvorschau etc. Optimalerweise sollte die ganze Plattform auch suchmaschinenoptimiert sein (SEO).
  • Natürlich reicht es nicht, das alles nur in einer Sprache zur Verfügung zu stellen. Eine Plattform, die schon nur in Europa wirkt, geschweige denn international, braucht Internationalisierung, eine Möglichkeit, um alle Schaltflächen und Texte der Plattform in jeder beliebigen Sprache darzustellen, inklusive völlig verdrehten Formulierungen und dem Einfügen und Zahlen und Daten. Und natürlich muss dann auch jemand all diese Texte übersetzen und regelmäßig pflegen.
  • Selbstverständlich braucht die Plattform auch ihr eigenes Admin-Backend. Programmierer und Mitarbeiter müssen die Server überwachen, Kundenanfragen beantworten, Daten anlegen und verändern, Statistiken überwachen und bei Fehlern reagieren, Cronjobs verwalten und Botzugriff limitieren. Auch die Rechteverwaltung zählt in diesen Bereich.

Quellen / Weblinks

[1] Eigenaussage von Hagen Grell im Gespräch mit der Redaktion