Online Plattform entwickeln?

Du hast eine vielversprechende Idee für ein Online-Business und möchtest schnell heraus finden, ob sie auch in der Praxis etwas taugt? Ich kann dir dabei helfen.

Ich bin Michael, 37. Seit ich 15 bin entwickle ich Webseiten. Genauer gesagt komplette Online-Plattformen mit Datenbank und allem was sonst noch dazugehört. Viele meiner früheren Projekte waren erfolgreich. Darunter eine Online Musik Community, ein B2B Shopsystem für einen großen Druckerhersteller und ein Content Management System für Obamacare (healthcare.org).

Mein letztes großes Herzensprojekt “Substance” hat mir aber vor allem eines gezeigt: Was bei der Entwicklung einer Web-Plattform alles schief gehen kann, technisch sowie zwischenmenschlich.

Mit Ken (der Plattform, auf der du gerade diese Zeilen liest) habe ich es schlussendlich geschafft, meine Idee einer Online Schreibplattform umzusetzen und ich möchte dir zeigen, wie ich das gemacht habe. Du bekommst von mir jene Komplettlösung, die für mich und mein Projekt funktioniert hat und höchstwahrscheinlich auch für dich passt, speziell wenn du ganz am Anfang stehst.

Dieser Text ist richtet sich sowohl an Unternehmer als auch an Entwickler. Wenn du technisches Verständnis mitbringst, super. Wenn nicht, wirst du nach dem Lesen die richtigen Fragen an deinen potentiellen IT-Dienstleister stellen können und heraus finden ob es ein Match ist.

Aber fangen wir mit dem unangenehmen Teil an…

So klappt es sehr wahrscheinlich nicht

Wir wollten die Wissenschaft revolutionieren. Zumindest den Austausch von Wissen. Dafür haben ich, mein Partner und ein Mitarbeiter fast 10 Jahre investiert, und uns zunächst mit wissenschaftlichen Verlagen zusammen getan. Es ging uns zu langsam und schließlich haben wir auf unsere bisherige Arbeit aufbauend begonnen “Substance” als eigenes Produkt zu entwickeln. Aber auch hier lief vieles nicht nach Plan. Hier einige meiner Learnings aus dieser Zeit, und der Zeit davor.

Weg 1: Standard-Software

Oft scheint es sehr naheliegend eine fertige Lösung (z.B. ein Shopsystem) zu verwenden und an deine Bedürfnisse anzupassen. Das Verlockende daran ist, dass du anfangs rasend schnell vorankommst und dabei ganz offensichtlich, wie vom Anbieter versprochen, extrem viel Zeit sparst.

Dieses Gefühl hält solange, bis du mit deinem Projekt an den Punkt gekommen bist, wo du etwas Neues, innovatives hinzufügen möchtest. Dann wirst du mit an Sicherheit grenzender Wahrscheinlichkeit fluchen. Zumindest mir ging es immer so, wenn ich versucht habe, Standard-Software anzupassen.

Selbst wenn die Standardlösung erweiterbar oder gar Open Source ist (Wordpress, du bist gemeint!) und du Änderungen vornehmen kannst, musst du oder dein Programmierteam erst einmal verstehen, wie alles im Detail funktioniert. Und bis dann dieses eine extra Popup so sitzt wie du es wolltest, haben deine Programmierer bereits mehrere Tage Zeit investiert.

Versteh mich nicht falsch. Es gibt gute Standardsoftware. Allerdings nur für Endbenutzer (Twitter, Airbnb, Google Docs, Ken 😉). Ich habe jedoch noch keine gefunden, die dir wirklich hilft, wenn du etwas Neues erschaffen willst, für eine Zielgruppe, die aus “normalen Menschen”, also nicht aus Technikern, besteht.

Weg 2: Standard-Software (die sich als Custom-Software tarnt)

Wenn dir jemand ein Software-System anbietet, und Teile des User-Interfaces erinnern dich stark an Excel-Tabellen, dann ist das ein schlechtes Zeichen. Wenn dann angemerkt wird “das sehen ja eh nur die Admins…” ist es höchste Zeit dich aus dem Staub zu machen. Du hast es wahrscheinlich mit einer dieser “flexiblen” Lösungen zu tun, die “alle Stückerl spielen”, aber “keines gscheit”. Du musst verstehen: Wenn dir Firmen Softwarelösungen anbieten, haben sie ein wichtiges Ziel: Mit möglichst wenig Mehraufwand möglichst viele Kunden (=Use Cases) zu bedienen. Eine Art das zu schaffen, ist ganz viele Konfigurationsparameter ins System einzubauen. An denen schraubt man dann rum, bis es für den neuen Kunden (z.B. für dich) passt. Nicht selten zahlst du dafür dann einen großen Batzen Geld, obwohl eigentlich nur ein Standard-Produkt für dich konfiguriert, dabei aber nichts für dich entwickelt oder gestaltet wird.

Nehmen wir an, du äußerst einen Anpassungswunsch: “Ich hätte hier daneben gern Information X angezeigt.” Und du hörst: “Uuhh, das geht nicht so ohne weiteres. Aber hier auf der Detail-Seite könnten wir es einblenden.” Gratulation, du bist gerade dabei, deine Online-Plattform um die Bedürfnisse deiner Software-Bude herum zu bauen. Deine User werden jauchzen vor Freude!

Ich muss gerade in zwei Unternehmen miterleben, welche schmerzliche Erfahrung dieser Weg bedeuten kann. In einem Startup mit einer genialen Idee haben die Gründer einen 6-stelligen Betrag für eine Erstentwicklung verbrannt und müssen nun de facto von vorne starten. Im zweiten Fall zwingt ein Konzern seinen Mitarbeitern in Europa ein neues Standard ERP-System auf, das nach 8 Jahren voller Pannen in der Entwicklung endlich ausgerollt wird. Das wirklich tragische daran ist, dass die Mitarbeiter bereits ein über 15 Jahre speziell für sie entwickeltes und ständig verbessertes System verwenden. Sie können es nicht fassen, ihre seit Jahren geschätzte Arbeitsumgebung jetzt gegen ein seelenloses Monstrum von Standardsoftware tauschen zu müssen.

Weg 3: Alles selber machen

Okay, also am Besten alles selber machen. Richtig?

Falsch.

Vor allem erfahrene Programmierer bevorzugen oft diese Variante, da man die volle Kontrolle über die Programmabläufe behält und immer und überall eingreifen kann. Das ist grundsätzlich super, aber was dabei oft übersehen wird ist, dass man definitiv mit einer viel längeren Entwicklungszeit rechnen muss. Und es viel schwieriger für neue Entwickler wird sich zurecht zu finden.

Bei unserem Projekt Substance haben mein Partner und ich so gut wie alles selbst gemacht. Nachdem sich unsere Wege schließlich trennten, wurde mir bewusst, dass jede Zeile selbst produzierter Code eine enorme Verantwortung bedeutet. Nicht weil unser Code schlecht war, sondern weil die Belastung für mich zu groß gewesen wäre diese Menge an Code weiter zu warten, habe ich mich von den Ergebnissen von 7-Jahren leidenschaftlicher Arbeit verabschiedet. Das war echt bitter und es hat gedauert bis ich das verdaut habe. Ich habe dann auf einige wenige Frameworks und Libraries gesetzt, selbst wenn diese Einschränkungen mit sich brachten. Aber ich war entlastet und konnte mich den Kernproblemen widmen.

Weg 4: Alle coolen Frameworks und Libraries verwenden

Frameworks und Libraries sind also die Lösung? Leider wieder falsch.

Vor allem weniger erfahrene Entwickler stürzen sich oft von einem coolen Tool ins nächste (been there, done that). Zugegeben, es ist auch wirklich schwer den Überblick zu behalten und eine gute nachhaltige Technologiewahl zu treffen. Wenn du schon mal zu Web-Frameworks recherchiert hast, weißt du es gibt viele Optionen, und jede einzelne wird sowohl religiös verehrt als auch von anderer Seite süffisant belächelt.

Zur Erklärung: Ein Web-Framework gibt Entwicklern ein Grundgerüst vor - man spart sich viel Zeit und kann gleich mit der Produktentwicklung loslegen. Libraries sind Software Komponenten, die eine bestimmte Aufgabe lösen und die man zu einem Gesamtsystem zusammensetzen kann. Viele Internet Startups sind überhaupt erst möglich geworden, weil sie auf Frameworks und Libraries zurückgreifen konnten. Als Beispiel fällt mir hier Github ein, welche als Framework Ruby on Rails verwendet haben, um das Versionierungssystem Git über eine grafische Weboberfläche zugänglich zu machen.

Die Nachteile von Frameworks und Libraries zeigen sich oft erst später. Frameworks geben manchmal zu viel vor (Entwickler sagen dann “opinionated”) und machen es den Entwicklern schwer in bestimmte Programmabläufe einzugreifen. Man hört dann: “Das Framework ist wieder im Weg.” Sowohl bei Frameworks als bei Libraries kann es vorkommen, dass Fehler enthalten sind, die man nicht gleich bemerkt. Dann ist man oft auf die Hilfe der Autoren angewiesen.

Zusammengefasst: Frameworks und Libraries, ja. Ich plädiere aber dafür, sie sparsam und geschickt auszuwählen. Sie müssen gut zusammen passen. Und sobald du dich entschieden hast, lass dich nicht beirren und halte deinen Kurs!

Weg 5: Zu viel Technologie

Technologie hat in den letzten Jahren einen unglaublichen Hype erlebt. Ich glaube, das hat dazu geführt, dass wir versuchen so ziemlich jedes Problem mit Technologie zu erschlagen. Wahrscheinlich braucht dein Projekt keine Blockchain, und über Machine Learning kannst du dir ernsthaft Gedanken machen, sobald du hunderttausende Datensätze gesammelt hast.

Bei unserem Projekt Substance haben wir versucht unser Problem “wissenschaftliches Publizieren vereinfachen” mit Technologie zu lösen. Wir haben unsere ganz eigene Editor-Lösung von der Pike auf entwickelt, damit wir so etwas wie Google Docs für wissenschaftliche Publikationen bauen können.

Rückblickend bin ich überzeugt, es wäre besser gewesen einige technische Anforderungen vorübergehend zurückzustellen (Echtzeit-Editieren, Versionsmanagement, etc.) um ein Basisprodukt schneller in die Hände der User zu kriegen.

Weg 6: Software-Entwicklung nach Lehrbuch

Aus eigener Erfahrung traue ich mich behaupten, dass es einen falschen Platz für Software-Entwicklung nach Lehrbuch gibt. Und zwar in Startups.

Wenn du frisch von der Uni oder der FH kommst, bist du darauf vorbereitet in einem großen IT-Unternehmen an großen Projekten mitzuarbeiten. Requirements-Engineering, Test-getriebene Entwicklung und Scrum sind deine Toolsets um die Komplexität zu meistern. Nichts davon ist schlecht, aber in einem IT-Startup, in dem noch nicht klar ist wohin die Reise eigentlich geht, ist diese Herangehensweise vor allem eines - ein großer Bremsklotz.

Als Startup musst du dich an eine Lösung herantasten, und du musst einer Testgruppe von Benutzern so schnell wie möglich ein funktionales System bieten können. Sobald sich eine Lösung herauskristallisiert hat, ist es an der Zeit strikter auf Lehrbuch-Techniken zurückzugreifen.

Wie immer im Leben braucht es einen gesunden Mittelweg. Wenn du ein kleines Programmierteam hast, rate ich dir zunächst auf automatisierte Tests zu verzichten. Generell ist ein defensiver Programmierstil in dieser frühen Phase oft hinderlich. Um einen neuen Workflow an Usern zu testen, musst du nicht jeden möglichen Fehlerfall prüfen. Das kostet Zeit und ist zu einem späteren Zeitpunkt wichtig, aber erstmal geht es um eine Sache: Sichtbare Ergebnisse für den Benutzer und ausloten einer selbsterklärenden Benutzeroberfläche.

Auch mit Optimierungen solltest du unbedingt warten. Was bringt es dir, wenn du eine schnellere Ladezeit bei einem Prototypen heraus holst, das Konzept aber danach weg wirfst, weil ein anderes bei den Benutzern besser angekommen ist?

Weg 7: Keiner, der die Entscheidungen trifft

Hierzu eine kleine Geschichte. Gemeinsam mit einer handvoll namhafter Open-Access Verlage haben wir das Substance Consortium gegründet. Unser Ziel war es, gemeinsam eine Open-Source Lösung “Texture” zu entwickeln, um den gesamten Publishing Prozess zu vereinfachen und zu beschleunigen. Wir, Substance, kümmerten uns um die technische Umsetzung, die Verlage um die Anforderungen. Ich war extrem stolz, so etwas mit auf die Beine gestellt zu haben. Wir würden demokratisch entscheiden, welche Dinge Sinn machen und in das Projekt aufgenommen werden und welche nicht. Einige Jahre lang lief es super. Mit wenig Budget haben wir eine tolle Lösung entwickelt. Ich würde sagen, wir waren zu 87,3% fertig.

Und dann wurde es kompliziert. Die Verlage hatten im Detail unterschiedliche Anforderungen (verschiedene Inhaltstypen und Darstellungsformen) und erst auf den letzten Metern des Projekts wurde uns bewusst, dass wir den Spagat, alle unter einer Technologie zu vereinen nicht mehr schaffen würden.

Wenn ich nochmal in derselben Situation wäre, wie zum Start des Projekts, würde ich von Anfang an mehr Verantwortung übernehmen. Es muss eine Person geben, die in letzter Konsequenz die Entscheidungen trifft, auch wenn diese mal für eine Partei unangenehm ist. Selbst wenn es dann gar nicht zum Start des Projekts gekommen wäre, wäre das immer noch besser als jahrelange intensive Arbeit ohne essbare Früchte.

Es ist ewig schade für alle Beteiligten, dass dieses vielversprechende Projekt auf den letzten Metern abgebrochen werden musste.

Weg 8: Deine Programmierer verstehen dich nicht (und umgekehrt)

Es gibt eher kreative, intuitive Menschen und eher analytische, rationale Menschen. Erstere Gruppe findet man meiner Erfahrung nach oft bei Unternehmern. Letztere öfter als nicht bei Ingenieuren und Technikern. In diesem Umstand lauert eine Gefahr, die meiner Schätzung nach 7 von 10 IT-Projekten das Leben kostet.

“Hört er oder sie mir überhaupt zu?” ist ein Gedanke, der bei einem Gespräch zwischen Unternehmern und Programmierern oft präsent ist. Und zwar bei beiden. Das Einzige was dann programmiert ist, sind eine Menge Missverständnisse und Frustration. Und nach einigen Monaten harter Arbeit, ein gescheitertes Projekt.

Eigentlich könnten diese beiden Typen sich perfekt ergänzen. Würde ein Unternehmer sein Projekt für einen Tag lang aus der Sicht seines Programmierers betrachten, würde er den Kunden erklären können, warum gewisse Wünsche und Anforderungen keine gute Idee sind. Und könnte der Programmierer für einen Tag in die Sicht des Unternehmers schlüpfen, würde er vielleicht beim nächsten Problem eine kluge Abkürzung wählen, anstatt blind eine technisch perfekte Lösung zu erarbeiten, die eigentlich gar nicht notwendig wäre.

Wenn du nicht das Gefühl hast dein Programmierer versteht dich, fangt gar nicht erst an zu arbeiten. Dasselbe gilt in umgekehrter Richtung. Vertrauen, Wertschätzung und die Fähigkeit zu verstehen wie der oder die andere ungefähr tickt sind essentiell für das Gelingen eines Software-Vorhabens.

Kommunikation ist bei solchen Projekten so wichtig, denn weder Produktdesign, noch Software-Architektur sind “harte Wissenschaften” in denen man auf irgendwelche Gesetzmäßigkeiten zurückgreifen kann. Du bewegst dich in einem Raum, in dem es nicht die eine richtige Lösung gibt. Vielmehr gibt es dort 10.000 Lösungen die funktionieren, und 9.000.000.000 Nicht-Lösungen die du erkennen musst, um sie frühzeitig in die Tonne zu treten und mit geschärftem Blick weiterzusuchen.

Weg 9: Du betreibst deine eigene Server-Infrastruktur

Es gibt keine Infrastruktur, die du selbst betreibst, die dir nicht auf den Kopf fallen könnte. Gerade in der Anfangsphase eines Projekts, kann dir das zum Verhängnis werden. Außer du kannst dir gleich ein zehn Personen starkes DevOps Team leisten.

Ab in die Cloud also mit deiner App. Aber das ist auch so leicht dahingesagt. Es gibt ja eine Unzahl an Technologien und Anbietern. Die Chance, dass du dich hier verrennst, ist in etwa gleich groß wie die, dass dir deine selbst betreuten Server um die Ohren fliegen. Im Kapitel Cloud-Hosting erfährst du wie ich mich bei Ken aus dieser Misere manövriert habe.

Weg 10: Du leistest dir keinen UI-Designer

Sogar wenn du selbst Designer bist, tu’s nicht! Du hast einen Tunnelblick auf dein Projekt. Und du wirst Sachen machen, die kein Mensch außer dir versteht. Garantiert. Ein ausgezeichneter Designer mit neutralem Blick ist eine der besten Investitionen, die du machen kannst. Der Zeitaufwand ist verglichen mit den Programmierkosten gering, der Mehrwert für deine Benutzer unbezahlbar.

Jetzt kennst du 10 Wege/Extreme, die für mich nicht zum Erfolg geführt haben. Aber wie sollst du es denn sonst angehen? Ich erzähle dir, wie ich es mit meiner Plattform Ken gemacht habe.

Ken - Diesmal hat es funktioniert

Mein langjähriges Projekt “Substance” war für mich zu Ende. Was jetzt? Und wie gehe ich es diesmal anders, besser an?

Nach wie vor fühlte ich mich dem Thema Wissensaustausch sehr verbunden. Ich wollte schon immer, dass es unkompliziert ist, sich leicht anfühlt und Spass macht. Das war beim komplexen wissenschaftlichen Diskurs nicht immer gegeben.

Irgendwann kam sie, die Idee: Was, wenn man Wissen in Form von persönlichen Erfahrungen weitergeben könnte, von Mensch zu Mensch?

Produktentwicklung

Okay, die Idee hat mir schon ziemlich gut gefallen, aber sie ist nichts wert, wenn ich sie nicht auch umsetzen und testen kann. Der letzten Idee (eigentlich waren es viele) bin ich fast 10 Jahre nachgegangen, und wenn daraus auch viele tolle Teillösungen hervorgegangen sind, sie wurde (zumindest bis heute) nicht real. 10 Jahre darf es diesmal nicht dauern, nein ich hatte nur ca. 1 Jahr Zeit. Und ich brauchte ein geeignetes Business-Modell.

Das Business Modell

Ich bin dieser Frage diesmal nicht wissenschaftlich nachgegangen. Es war mehr so ein Durchspielen von Szenarien, und viel mit anderen darüber diskutieren. Eine Sache war schnell klar, ein Marktplatz sollte es werden. Autoren schreiben ihre Erfahrungen auf und legen dafür einen Preis fest. Bei jedem Verkauf geht der Großteil des Umsatzes an den Autor, ein Teil davon als Plattform-Beitrag an Ken. Ein bisschen wie Airbnb, nur werden Erfahrungen statt Unterkünften gehandelt. Als nächstes brauchte ich einen Brand…

Brand

Ich habe zwar ein gewisses Gespür für Design und mich in der Vergangenheit selbst um das Branding meiner Projekte gekümmert. Bei Ken habe ich das erste Mal von Anfang an, eng mit einem Designer zusammengearbeitet und eines ist jetzt klar: Nie wieder ohne! Danke Stefan! 🙂 Es ist wie eine DNA, die sich überall wieder findet. Und es ist schon ein geiles Gefühl, wenn Leute berichten, die Plattform habe eine Art Persönlichkeit und man fühlt sich wohl wenn man damit arbeitet.

Mockups und Screendesigns

Mockups und später Screendesigns waren das primäre Kommunikationswerkzeug für uns während der gesamten Entwicklung. Ich habe die Mockups erstellt, und damit meine Ideen für das Produkt formuliert. Manchmal hat Stefan sie verstanden, manchmal nicht. 😉

Dann war es Zeit darüber zu diskutieren und ein paar Tage später bin ich dann mit neuen, besseren Ideen und Mockups wieder da gestanden. Für die Teile des Systems, die schon schlüssig waren, hat Stefan fertige Screendesigns erstellt.

Technische Umsetzung

Das haben wir auch einige Wochen so weiter gemacht. Aber parallel dazu ging es für mich schon an die Umsetzung. Meinen ersten Prototypen hatte ich in Windeseile fertig, da ich auf bestehendem Programmcode aufbauen konnte. An einem bestimmten Punkt wurde es allerdings eng, und ich musste mir eingestehen, dass ich mit der aktuellen technologischen Basis nicht weitermachen kann. Das war extrem schwierig für mich, da ich ca. 10 Jahre lang gemeinsam mit meinem früheren Partner eine eigene Technologie für Textbearbeitung entwickelt habe. Diese war auch sehr erfolgreich und hat uns und unseren Kunden gute Dienste erwiesen. Aber für mein neues Projekt passte es nicht mehr. Ich hatte geringere Anforderungen und musste Komplexität loswerden. Deswegen habe ich mich im Januar 2021 auf die Suche nach den besten und effektivsten Technologien gemacht, und mein Projekt auf komplett neue Beine gestellt. Das hat mich sicher 3 Monate extra Zeit gekostet, aber es hat sich zu 100% gelohnt.

Mit diesen Fragen habe ich mich intensiv auseinandergesetzt. Und ich widme jeder dieser Fragen ein ausführliches Kapitel.

  • Kerntechnologie: Es gibt eine Reihe von sogenannten “Technologiestacks”. Alle haben ihre Vor- und Nachteile. Ich will einerseits ganz schnell und Produkt-orientiert entwickeln können, andererseits brauche ich ein stabiles System, das mir nicht gleich nach dem Launch um die Ohren fliegt.

  • Datenbank: Wie speichere ich meine Daten zuverlässig? Ich will keinen Datenverlust, und ich will, dass die Datenbank auch bei vielen Anfragen nicht in die Knie geht.

  • Textverarbeitung: Das Schreiben eines Artikels soll sich ganz natürlich anfühlen. Leider ist das im Web bis auf wenige Ausnahmen nicht gegeben. Jeder der mal Inhalte fürs Web erstellt hat, weiß wie viele Nerven man hier oft liegen lässt.

  • Zahlungsabwicklung: Ken funktioniert wie gesagt wie ein Marktplatz. Es gibt Anbieter (Autoren) Und Käufer (Leser). Ich brauche also eine Lösung, in der ich sowohl Zahlungen von Lesern entgegennehmen, als auch Geld an Autoren auszahlen kann. Das Ganze soll vollautomatisiert ablaufen, denn ich will nicht manuell tausende Rechnungen schreiben und Überweisungen machen.

  • E-Mails: Ich brauche einen zuverlässigen Service um E-Mails über die Plattform zu versenden.

  • Bilder: Das Thema Bilder ist bei genauerer Betrachtung weniger trivial als man annehmen möchte. Meine User sollen ohne viel zu überlegen ein Bild hochladen können. Bei Profil-und Coverbildern soll, wenn notwendig, automatisch ein passender Bildausschnitt gewählt werden. Bei der Anzeige der Bilder sollen unterschiedlich große Versionen der Bilder angezeigt werden, je nachdem ob man gerade mit einem Smartphone oder einem Desktop Computer unterwegs ist. Beim Laden eines Artikels müssen Platzhalter für die Bilder dargestellt werden, damit die Seite beim Laden nicht rumspringt. Denn Google bewertet solche Eigenschaften und reiht Webseiten nach ihrer Usability-Performance. Die Darstellung von Bildern spielt hier eine sehr wichtige Rolle!

  • Videos: Ken User sollen ganz unkompliziert Videos hochladen können, egal in welchem Format. Die Videos sollen dann automatisch fürs Web aufbereitet werden. Ähnlich wie bei Bildern spielt hier die Performance eine große Rolle. Deswegen suche ich nach einer Lösung die Streaming erlaubt. Ich möchte mich bewusst nicht von Plattformen wie Youtube oder Vimeo abhängig machen.

  • Security: Das war ein schwieriger Balanceakt für mich. Denn ich wusste, wenn ich an alles denken will was potentiell schiefgehen kann, dann würde ich wohl noch 3 Jahre mit der Entwicklung brauchen. Gleichzeitig wollte ich ruhig schlafen können, sobald die Plattform online ist.

  • Cloud-Operation: Ich habe bei früheren Projekten meine eigenen Server betreut. Das hatte den Vorteil, dass ich viel Performance für wenig Geld bekommen habe. Und den Nachteil, dass ich oft sehr schlecht geschlafen habe. Ich will nie wieder für das Einspielen von Sicherheitsupdates verantwortlich sein und um 3:00 morgens einen Server neustarten, der aus welchen Gründen auch immer Schluckauf bekommen hat. Diesmal kommt alles in die Cloud, nach den modernsten Standards.

Kerntechnologie

Die Wahl der Kerntechnologie war wahrscheinlich die heikelste Entscheidung, die ich zu treffen hatte, denn sie wirkt sich auf alle anderen Bereiche aus. Hier durfte ich mir also keinen groben Schnitzer erlauben. Worauf ich mich bereits sehr früh festlegen konnte ist, dass die Programmiersprache Javascript nicht nur im Frontend sondern auch im Backend zum Einsatz kommen soll. Das hat zum Einen persönliche Gründe - ich habe viele Jahre lang ausschließlich mit Javascript programmiert - zum Anderen pragmatische - Code wiederverwendbar machen und Komplexität reduzieren. Mittels Node.js wird Javascript auch auf dem Server verwendbar.

Bevor ich ein Framework oder eine Library ins Projekt einbinde, muss ich mich kritisch und ausgiebig damit auseinandergesetzt haben. Schließlich geht man ja hier längerfristig eine enge Beziehung ein. Und damit meine ich gar nicht unbedingt nur technisch. Für mich ist es ganz wichtig zu verstehen, wie die Leute ticken, die hinter dem Projekt stehen. Aus Erfahrung weiß ich, dass viele Open-Source Projekte den genialen Köpfen von Einzelpersonen entstammen. Oft werden sie langfristig nur von einer Person betreut. Mir ist es wichtig, dass das Projekt auch außerhalb des Code’s lebendig ist. Gibt es eine aktive Community? Werden regelmäßig Fragen gestellt und beantwortet? Wie ist die Stimmung im Projekt? Manchmal finde ich auf Youtube Präsentationen von den Erfindern der Software-Tools, das ist auch super hilfreich. Man entwickelt dann schon ein Gespür, wo das Projekt gerade steht und ob es in einem Jahr noch existieren wird.

Ich selbst hatte diesmal eine tolle Entscheidungshilfe. Und zwar bin ich im Jahr 2012 mal mit einem Herrn Guillermo Rauch beim Frühstück in San Francisco zusammengesessen. Der war wie ich schon vor über 10 Jahren sehr aktiv in der Web Open Source Szene und hatte ambitionierte Projekte am Start. Und wie ich nun herausfand, ist er auch der Mann, der hinter dem Framework Next.js steht, auf welches meine Wahl schlussendlich fiel.

Next.js richtet sich speziell an Front-End Entwickler, mit dem Ziel möglichst viele technischen Hürden aus dem Weg zu räumen, damit sich Teams vollständig auf die Entwicklung neuer Produkte konzentrieren können. Die gesteigerte Entwicklungsgeschwindigkeit mit Hilfe von Next.js hat sich inzwischen herumgesprochen und so setzen Teams von Airbnb, Apple oder Tiktok bereits darauf. Next.js ist im Wesentlichen eine Erweiterung zu React, ein Front-End Framework, das von Facebook als Open Source Library entwickelt wird, und sich im Laufe der letzten Jahre zu einem De-Facto-Standard entwickelt hat.

Was mich an Next.js besonders angesprochen hat ist, dass es zwar eine fixe Code-Struktur vorgibt, gleichzeitig aber wirklich mit so ziemlich allen relevanten Javascript Libraries perfekt zusammen spielt. Es gibt eine große Beispielsammlung mit konkreten Integrationen wie Zahlungsabwicklung, Einbindung von Video Services, Shop-Systemen etc. Man kann sich diesen Beispielen bedienen, hat aber nach wie vor die Freiheit jede Zeile Code an die eigenen Bedürfnisse anzupassen. In dieser Form habe ich das noch nie gesehen, und mir gefällt, dass Next.js für Programmier-Anfänger gut verständlich ist, während es Profis nicht in die Quere kommt.

Next.js fordert es zwar nicht strikt ein, legt allerdings eine moderne “Serverless” Architektur nahe. Die genaue Definition lässt sich im Web nachlesen, aber im Wesentlichen bedeutet es, dass man den “Server” so “klein und dumm” wie möglich hält. Und ja, die Bezeichnung “Serverless” hat mich auch zunächst verwirrt, denn einen Server gibt es nach wie vor. Treffender wäre “Less server”, also möglichst wenig Server.

Ich versuch “Serverless” mal mit einem Beispiel zu veranschaulichen. Stell dir vor, du möchtest einen Bildupload realisieren. Dann wäre der klassische Weg, das Bild auf deinen Server hochzuladen, dort zu verarbeiten und zu speichern. Nehmen wir an, dass jetzt tausende Menschen das gleichzeitig machen, dann würde es dich vermutlich nicht überraschen, wenn dein Server bald unter der schweren Last zu keuchen beginnt. Einen interessanten Ausweg bietet hier Serverless. Wenn du auf Ken ein Bild hochlädst, dann wird zuerst eine geheime Upload Adresse (URL) beim Server angefragt. An diese Adresse wird dann das Bild geschickt. Das besondere dabei: Der Ken Server selbst hat nicht länger mit Bildern zu tun, stattdessen verwende ich ein Cloud Storage Service (DigitalOcean Spaces bzw. Amazon S3) für diese Aufgabe. Dadurch benötigt Ken wesentlich weniger Speicher, und eine Fehlerquelle ist auch ausgeschaltet. Zusätzlich können diese “Serverless Functions”, die den Server ausmachen, auf verteilter Infrastruktur “deployed” werden. Wir werden in den späteren Kapiteln noch öfter auf Serverless Bezug nehmen. Für Ken ist “Serverless” die Versicherung bei Bedarf hochskalieren zu können, also eine hohe Anzahl an Anfragen verarbeiten zu können. Vercel, die Firma die hinter Next.js bietet hierfür eine einfach zu verwendende Hosting Lösung, die Serverless Functions einschließt.

Next.js ist jedenfalls insgesamt ein tolles Projekt, mit einem super Team dahinter. Und viele Zeichen deuten darauf hin, dass dessen Dominanz in den nächsten Jahren noch weiter zunehmen wird. Deswegen habe ich ruhigen Gewissens auf dieses Pferd gesetzt.

Datenbank

Okay, hier könnte man weit ausholen. Denn Datenbank Lösungen und Pro-Contra Listen zu ihren Vor- und Nachteilen gibt es viele. Ich halte mich aber zurück, denn man kann sich hier umfassend im Internet informieren. Was Datenbanken angeht habe ich mich bei Ken für den konservativen/klassischen Weg entschieden. Meiner Erfahrung nach sind SQL Datenbanken absolut zuverlässig, und ausreichend um die meisten Anwendungsfälle abzudecken. Auf Ken werden Artikel gekauft, deswegen sollte rechnen zu den Stärken meiner Datenbank zählen. Und das kann SQL richtig gut.

Konkret fiel meine Wahl auf PostgreSQL, ein modernes Open Source Datenbank System, das kaum Wünsche offen lässt. Ohne allzu sehr in die Tiefe zu gehen, möchte ich kurz teilen, wie ich das Datenbank-Design bei Ken angegangen bin.

Zunächst bin ich der festen Überzeugung, dass ein Datenbankmodell die Konsequenz der User Experience sein soll (siehe Mockups und Screendesigns) und niemals umgekehrt. Anders gesagt, alles was am Bildschirm des Users auftauchen soll, muss irgendwo sicher gespeichert werden, und leicht abrufbar sein. Aufgabe der Datenbankmodellierung ist es ein möglichst genaues Bild der Wirklichkeit abzubilden. Dazu werden Tabellen angelegt (z.B. users, articles, article_covers) und miteinander in Beziehung gebracht.

Dabei sollte man das Speichern und Abfragen von Daten möglichst getrennt betrachten. Ich speichere die Rohdaten in vielen kleinen Tabellen und bringe sie mit Fremdschlüsseln (Foreign Keys) miteinander in Verbindung. Wichtig ist, dass hier Datenintegritäts-Regeln eingehalten werden. Ein Artikel darf nicht ohne einen Benutzer, der ihn erstellt hat existieren. Ein Coverbild ist optional, und wird deswegen getrennt vom Artikel gespeichert. Die Rohdaten sind zwar somit safe, aber doch ziemlich unpraktisch abzufragen. Deswegen gibt es sogenannte SQL Views, also eine spezielle und optimierte Sicht auf die Daten. Bei Ken gibt es für jede Seite eine solche View, die sich genau jene Daten herauspickt, die angezeigt werden sollen. Die Artikelseite z.B. umfasst Daten aus den Tabellen users, articles, article_covers. Diese Vorgehensweise hat sich für mich sehr bewährt, da ich nicht in Versuchung komme, die Daten “optimiert” zu speichern um direkter auf sie zugreifen zu können. Man hätte das Coverbild auch gleich direkt in der Artikeltabelle speichern können, dort gehört es allerdings bei genauerer Betrachtung nicht hin.

Textverarbeitung

Die Textverarbeitung ist ein zentraler Bestandteil meiner Plattform Ken. Vielleicht kommt dein Projekt ja auch ohne aus, aber sobald du Bereiche hast, wo Benutzer Texte eingeben und formatieren können sollen, solltest du dir dieses Kapitel unbedingt reinziehen. :)

Wie eingangs schon erwähnt, habe ich fast 10 Jahre damit zugebracht den perfekten web-basierten Texteditor für wissenschaftliche Dokumente mitzuentwickeln. Und er sollte so ziemlich alles können: Text, Überschriften, Formatierungen, komplexe Tabellen, Bilder, Referenzen mit automatischer Nummerierung und vieles mehr. Wir sind verdammt weit gekommen, aber für mein Projekt Ken waren einige Punkte nach wie vor nicht ausreichend unterstützt. Zum Beispiel editieren auf Mobilgeräten. Und so habe ich mich erneut auf die Suche gemacht, nach der besten Lösung für dieses Problem im Jahr 2021.

Da ich diesen Bereich von sogenannten “Rich Text Editors” wirklich ausgezeichnet kenne, und weiß worauf es ankommt, kann ich mit 99,9% iger Wahrscheinlichkeit sagen, dass es derzeit wahrscheinlich keine flexiblere Lösung als ProseMirror gibt. Du und deine Entwickler können sich also ca. 1000 Stunden Research sparen. 😉

Auch den Entwickler hinter dem Projekt Marijn Haverbeke kenne ich persönlich, und wir haben uns ein paar mal fachlich ausgetauscht. Bei ihm mach ich eine Ausnahme meiner Regel, keine Projekte zu integrieren hinter denen nur eine einzelne Person steht. Da die Disziplin der Rich-Text-Editor-Entwicklung einer Raketenwissenschaft gleichkommt, vertraue ich auf Marijn, dem Einstein seines Fachs.

Die Besonderheit von ProseMirror ist, dass man genau festlegen kann wie ein Dokument aufgebaut sein soll. In meinem Fall gibt es die Block-Typen: Paragraph, Überschrift 1, 2 und 3, Zitat, Bild, Video, Ken-Linie, Stichpunktliste, Aufzählung. Zusätzlich zu den Block-Typen gibt es sogenannte Marks, also Annotationen von Text. Das sind bei Ken: Fett, Kursiv, Link. Das coole ist, dass du das genau so einrichten kannst wie du es für deine Anwendung brauchst. Der einfachste Anwendungsfall ist, dass du eine hässliche Textarea gegen eine ProseMirror Instanz tauscht, bei der z.B. nur Fett, Kursiv erlaubt ist. Du könntest aber auch ein “Rich”-Formular machen, das sich anfühlt wie Microsoft Word, aber eine Struktur vorgibt. Das wäre z.B. die perfekte technische Basis für Förderanträge. *g* Die meisten Entwickler wissen nicht, dass man das machen kann, bzw. nicht wie man es macht. Und so ist das Netz voll von öden Formularen.

Zahlungsabwicklung

Ich habe mir einige größere Payment Provider im Detail angeschaut. Darunter Mollie, Braintree (= Paypal) und Stripe. Recht schnell war klar, dass ich mich für Stripe entscheiden werde. Denn es hat mit Abstand das intuitivste User-Interface beim Bezahlvorgang. Ich hasse es, wenn ich beim Bezahlvorgang über zig Seiten gelotst werde, nur um zu erfahren, dass meine gewählte Zahlungsmethode dann doch nicht funktioniert hat. Und dann wieder alles von vorne. Grrrr. Aber nicht bei Stripe! Das ist wirklich sauber gemacht, sieh selbst!

Ich habe mich entschieden, lediglich Kartenzahlung und Apple Pay zu erlauben. Klarna/Sofort wird zwar ebenfalls von Stripe unterstützt, hat allerdings den Nachteil, dass Zahlungen erst nach mehreren Stunden bestätigt werden. Das Handhaben von “Pending Payments” ist technisch aufwendiger, und man muss auf fehlgeschlagene Zahlungen reagieren können. Aktuell keine Option für mich, denn meine User sollen den Text sofort nach dem Bezahlen zu sehen bekommen.

Stripe hat außerdem eine Art Marktplatz Funktion (Stripe Connect), mit der ich User auf meiner Plattform auch via Stripe auszahlen kann. Muss ich aber erst integrieren. Bis dahin geh ich halt mit einem Stapel Zahlscheine zur Bank um meine Autoren auszuzahlen! ;)

Neee, im Ernst, unser Banken-Finanztransaktionsystem ist hoffnungslos veraltet. Selbst wenn so ein tolles System wie Stripe zwischengeschalten ist, dauert es Tage, bis Geld erfolgreich den Besitzer gewechselt hat. Ich habe deshalb ein wachsames Auge auf diese kontrovers diskutierten neuen Krypto-Technologien. Ripple und Bitpay sind z.B. Projekte, die für Ken bald interessant werden könnten. Dann könnte ich nämlich Zahlungen empfangen und senden, ohne dass eine Bank dabei involviert ist. Was natürlich auch die Kosten extrem senken würde. Bei Stripe wird aktuell für jede Transaktion 0,25 € und bis zu 2,9% des Betrags berechnet. Mit Bitpay wären es 1%, unabhängig vom Betrag. Und unabhängig davon in welchem Land der Empfänger gerade sitzt.

Heute (13. Oktober 2021) habe ich erfahren, dass Stripe ein Krypto-Team aufbaut, also in absehbarer Zeit auch Krypto-Transaktionen unterstützen wird. Vielversprechend!

E-Mails

Um E-Mails zu versenden verwende ich die Plattform Mailjet.com. Ich hatte bislang noch keine Probleme, und noch habe ich keine Kosten, da ich mich noch unterhalb der Grenze von 6.000 Emails bewege.

Bilder

Im Kapitel “Kerntechnologie” habe ich bereits beschrieben, dass der Bildupload “Serverless” funktioniert. Das heißt der Ken-Server kann sich entspannen, und Bilder werden direkt vom Browser des Users auf ein Cloud Storage Service übertragen. In meinem Fall DigitalOcean Spaces. Aber das ist nur ein Aspekt der Lösung. Spielen wir das Ganze mal an einem Beispiel von vorne bis hinten durch. Nehmen wir an, du bist auf Ken eingeloggt, schreibst eine Erfahrung auf und fügst jetzt ein Bild hinzu.

Zunächst wandert das 5 MB große Original wie beschrieben unverändert in den Cloud Storage. Aber so kann man das Bild natürlich nicht im Web anzeigen. Stell dir vor du bist gerade mit deinem Smartphone in einer dünn besiedelten Gegend unterwegs. Wir brauchen für jede Bildschirmgröße und Internetverbindung eine passende Bildversion. Und jetzt kommt ein weiterer genialer Service ins Spiel, der mir enorm viel Zeit und Programmierarbeit erspart hat: ImgIX (imgix.com) liefert Bilder in passenden Größen automatisch aus. Next.js hat dazu ein eigenes Image-Feature, das perfekt mit ImgIX zusammenarbeitet.

Aber ImgIX kann noch mehr. Ich verwende es z.B. nach dem Hochladen eines Profilbilds, um einen passenden quadratischen Bildausschnitt mit dem Gesicht darin auszuwählen. Das hat mir viel Zeit gespart, denn einen Bildcropper zu integrieren ist wesentlich zeitaufwendiger und teurer.

ImgIX sorgt dafür, dass die Bilder überall auf der Welt auf verschiedenen Servern gespeichert sind. Damit man immer superschnellen Zugriff hat. Mit diesem Setup erreicht man einen unglaublich schnellen Seitenaufbau, der die User freut (auch wenn sie sich nicht dessen bewusst sind). Aber noch viel wichtiger, Google bevorzugt Seiten mit einem zackigen Bildaufbau.

Auch noch super wichtig: Vergiss nicht darauf die Bildgröße (Breite mal Höhe in Pixel) in deiner Datenbank zu speichern. Du musst die exakte Bildgröße beim Anzeigen der Bilder angeben, damit die Bilder beim Laden der Seite nicht rumspringen. In der neuesten Version von Next.js gibt es sogar ein Preload Feature, dabei werden niedrigauflösende verschwommene Vorschaubilder generiert, die angezeigt werden bis die vollauflösende Version fertig geladen ist. Das macht auch nochmal einen Riesenunterschied in der subjektiven Wahrnehmung. Ich werde diese Vorschaubilder möglichst bald auf Ken integrieren, und dann diesen Text hier entsprechend aktualisieren.

Videos

Ich wollte um jeden Preis das Einbinden von Youtube Videos vermeiden. Erstens weil Ken dadurch abhängig von Youtube wird. Wer weiß was denen einfällt? *g* Zweitens ist die User-Experience alles andere als ideal. Benutzer müssten erst einen Youtube Account anlegen, das Video dort hochladen und dann auf Ken einbinden.

Auf Youtube zu verzichten ist allerdings gar nicht so leicht. Denn Menschen sind es gewohnt schnelle Video Streams zu haben. In unterschiedlichen Auflösungen, je nach Gerät und aktueller Internet-Geschwindigkeit. Zum Glück hat jemand dieses Problem erkannt und einen Service gestartet.

Mit Hilfe von Mux können meine Benutzer Videos direkt über die Plattform hochladen, und Mux kümmert sich um das Hosting und Streaming. Bin sehr zufrieden.

Security

“1 Million Benutzer-Datensätze von Online-Plattform Ken entwendet.” Diese oder eine ähnliche Schlagzeile würde ich gerne nie lesen. Was also tun?

100%ige Sicherheit gibt es nicht, deswegen lautet ein Grundsatz von mir:

Daten, die du nicht sammelst, können sie dir nicht stehlen.

Ich speichere also Daten nur, wenn es wirklich nicht anders geht. Ursprünglich wollte ich einen Messenger integrieren, damit Leser und Autoren direkt über die Plattform kommunizieren können. Ich habe mich dagegen entschieden, denn für persönliche Nachrichten möchte ich nicht verantwortlich sein. Stattdessen bringe ich Leser und Autoren nach einem “Handshake” über E-Mail in direkten Kontakt. Ken kann niemals mitlesen.

Eine weitere typische Schwachstelle sind Passwörter. Besonders Admin-Accounts mit schwachen Passwörtern sind ein beliebtes Einfallstor. Deswegen gibt es bei Ken keine Passwörter. Bei jeder Anmeldung wird ein einmaliger Code erzeugt und an die E-Mail-Adresse gesandt.

Das ist meiner Meinung nach ausreichend. 2-Faktor Authentifizierung ist nervig für die Benutzer und in vielen Fällen wirkungslos. Warum? Weil man Accounts in der Regel zurücksetzen kann, und zwar über die mit dem Account verbundene E-Mail Adresse. Das E-Mail-Postfach ist also die größte Schwachstelle. Also ändere bei der Gelegenheit gleich dein Gmail-Passwort! 😉

Mit der hier beschriebenen Cloud-Lösung musst du dich auch nicht um Security Patches deines Servers kümmern. Vorausgesetzt du hast einen gewissenhaften Hosting-Anbieter.

Cloud-Hosting

Hui, das war ein wilder Ritt. Ich habe mir viele Systeme angesehen, und es kam mir alles wie ein verdammt kompliziertes Puzzle vor. Ich kombinierte verschiedene Teilsysteme, und ich konnte das Gesamtbild schon erkennen. Dennoch zwickte es immer irgendwo. Die “Puzzleteile” schauen alle irgendwie gleich aus, und es blieb mir nichts anderes übrig als alle erdenklichen Kombinationen durchzuprobieren.

Amazon Web Services

Angfangen habe ich mit Amazon AWS. Dort gibt es alles was das Cloud-Computing-Herz begehrt. Die Amazon Elastic Compute Cloud (EC2), Serverless Computing (AWS Lambda), S3 für das Speichern von Files und gleich mehrere Optionen für meine SQL Datenbank. Ich fand das Produkt AWS Aurora Serverless super spannend. Es verspricht mir eine PostgresQL-kompatible Datenbank, die wesentlich flotter ist und vor allem für Serverless-Architekturen ausgelegt wurde. Bei Serverless hast du ja statt einem fixen Server ganz viele “Mini-Server” die kommen und gehen, je nachdem wie viel Rechenpower gerade gebraucht wird. Das Problem ist, dass Datenbanken nur eine limitierte Anzahl von gleichzeitigen Verbindungen zulassen, und das läuft dann bei Serverless ganz schnell aus dem Ruder.

Mit AWS Aurora Serverless sind Datenbank-Zugriffe über eine HTTP API möglich. Es gibt also keine persistenten Verbindungen mehr. Voller Vorfreude habe ich mich bei AWS angemeldet, habe die notwendigen Produkte bestellt und wollte loslegen. Und gleich das erste Dilemma: Man kann sich gar nicht mehr klassisch mit der Datenbank verbinden. Mein praktisches grafisches Datenbank-Management-Tool konnte ich also vergessen, und das war keine Option. Nach vielen Stunden Recherche war klar, das Einzige was ich machen kann ist einen eigenen Proxy-Server einzurichten, der diese Verbindungen dann zulässt. Viel zu kompliziert. Und überhaupt wurde mir klar wie saumäßig teuer die Amazon Services sind (da fängt man bei 100€ pro Monat gerade erst an). Und das User Interface, die AWS Management Console, hat mich stark an Excel-Tabellen erinnert. 😱”Aber ist ja nur für die Admins…”, würde man mir dann sagen. Als wären Admins keine Menschen, die eine übersichtliche Benutzerschnittstelle verdient hätten.

Also goodbye Amazon erstmal. Und hello DigitalOcean.

DigitalOcean

DigitalOcean wurde in den letzten Jahren eine Art Herausforderer für das übermächtige Amazon AWS. Die Benutzerschnittstelle ist zwar auch nicht perfekt, aber viel viel besser und übersichtlicher. Ich konnte alles in einem Tag durchdringen, während ich bei Amazon gefühlt wohl erst ein Studium gebraucht hätte, um alles im Griff zu haben. Außerdem ist DigitalOcean wesentlich günstiger. Gerade erst wurde ein neuer Service gelauncht “DigitalOcean Apps”. Genau wonach ich gesucht habe! Damit kann ich meinen Code einfach deployen, ohne selbst einen Server einrichten zu müssen. Zwar ist das Ganze jetzt nicht “Serverless” und unendlich skalierbar, aber ich dachte mir, egal ich muss ja mal irgendwo starten. Und wenn Ken dann Millionen Zugriffe am Tag hat, dann überleg ich mir was. ;-)

Meine App war super schnell unter beta.letsken.com gelauncht. Neben Apps, verwendete ich noch weitere Produkte von DigitalOcean. Spaces funktioniert genau gleich wie Amazon S3 und kostet weniger. Einen Postgres Datenbank-Cluster konnte ich auch ohne Probleme einrichten.

Ich war ziemlich zufrieden und nachdem die Beta-Version einige Monate lief (dort haben die ersten Autoren bereits ihre Inhalte erstellt) war es Zeit Ken inoffiziell zu launchen. Am 5.8.2021 war es so weit. Ken geht unter letsken.com online, und meine Freundin Sonja hält die Ken Rechnung Nr. 1 in der Hand.

Alles funktioniert! 🍾

Im Livebetrieb der ersten Wochen offenbarten sich dann aber doch ein paar Probleme. Ich wollte, dass die Seite über die Rootdomain letsken.com erreichbar ist, und das www.letsken.com und beta.letsken.com auf diese weiterleiten. Geht leider nicht mit DigitalOcean. Hört sich jetzt sich wie eine Kleinigkeit an, aber für Google ist das zum Beispiel doof. Weil man jede Seite dann 3x im Netz findet. Unter jeder Domain einmal. Außerdem gab es hin und wieder Aussetzer von DigitalOcean Apps und das Veröffentlichen von Änderungen an der Plattform dauerte schon mal 5-10 Minuten. Was soll ich machen?

Vercel

Vercel ist die Firma, die hinter Next.js steht, und sie bieten eben auch einen Hosting-Service dafür an. Vercel ist die mit Abstand am intuitivsten zu bedienende Lösung da draußen, das trau ich mich ohne weiteres zu behaupten. Denn diese Jungs und Mädels sind Front-End-Experten und haben es sich zum Ziel gesetzt, Webapp Entwicklung zugänglicher zu machen. So dass du sich auf das Kreieren von Anwendungen konzentrieren kannst, und dich nicht 90% der Zeit mit technischen Details aufhalten musst. Ich fühlte mich von dieser Mission extrem angesprochen.

Es hat mich dann auch nicht überrascht, dass Vercel Domain-Weiterleitungen wie ich sie brauche unterstützt. Natürlich wäre Vercel meine erste Wahl, nicht zuletzt weil das System Serverless ist und unendlich skalieren kann.

Wäre da nur nicht das Problem mit den limitierten Datenbankverbindungen. Connection-Pooling war die Lösung für dieses Problem. Dabei erfolgen Datenbankzugriffe nicht direkt sondern über einen Proxy. Dieser hält intern nur eine kleine Zahl an Verbindungen offen, nach außen kann er aber beliebig viele Verbindungen bedienen.

Am 25.8.2021 habe ich mein System von DigitalOcean Apps auf Vercel umgestellt. Und es fühlt sich richtig gut an. Jetzt können wirklich ganz viele Anfragen auf Ken einprasseln und das System wird stabil bleiben.

Einziges Problem: Ken ist jetzt viel langsamer. Allerdings nur bei den dynamischen Seiten (Server Side Rendering) wo direkt auf die Datenbank zugegriffen werden muss. Die Serverless Functions und die Datenbank sind zwar am selben Ort (London), jedoch in unterschiedlichen Datenzentren. Mit meiner ursprünglichen DigitalOcean-Lösung war beides im selben Datenzentrum (Frankfurt) darum waren die Seitenzugriffe unglaublich schnell.

Render.com

Es ließ mir keine Ruhe, der Aufbau der Seite war mir zu langsam. Ich machte mich auf die Suche nach Alternativen, und wurde fündig. Render.com wurde gegründet, weil die Anbieter nicht mit DigitalOcean Apps zufrieden waren (wie ich). Kein Serverless, aber ein super einfaches Setup für Apps und Datenbank. Das Projekt ist noch recht jung und es stehen erst zwei Datenzentren zur Auswahl. Oregon, USA und Frankfurt, Deutschland. Puh, Glück gehabt! :)

Jetzt wäre ein guter Zeitpunkt, die Seite neu laden, um dich zu überzeugen wie schnell sie lädt, Render.com sei Dank!

Meine Hosting-Kosten

Meine monatlichen Hosting-Kosten belaufen sich derzeit auf weniger als 50$, und setzen sich so zusammen:

  • Render.com Web Service: 7 $

  • Postgres Datenbank Render.com: 20 $

  • DigitalOcean Spaces: 5 $

  • ImgIX: 10 $

  • Mux.com Videos: Variabel

Skalierung

Was passiert eigentlich, wenn eine Story auf Ken durch die Decke geht? Und auf einmal tausende Menschen auf einmal auf die Seite zugreifen? Dazu habe ich mir etwas überlegt. Next.js unterstützt zwei Möglichkeiten Webseiten zu generieren:

  • Bei Server Side Rendering (SSR) wird bei jedem Zugriff eine Anfrage an die Datenbank gemacht und diese Daten dann in ein Seitenlayout eingefügt und angezeigt. Der Vorteil dieser Herangehensweise ist, dass man als User alle Informationen immer topaktuell sieht. Der Nachteil: Bei jedem Zugriff auf die Story muss eine Verbindung zur Datenbank aufgebaut werden. Bei 1.000 gleichzeitigen Zugriffen pro Sekunde entstehen 1.000 Datenbankanfragen. Das geht natürlich nicht lange gut, und dann wird die Seite extrem langsam oder verabschiedet sich komplett. Doof, was kann man da tun?

  • Static Site Generation (SSG) hilft hier. Jetzt wird die Seite nicht mehr bei jeder Anfrage neu berechnet, sondern einmal eine aktuelle Version berechnet, die dann immer wiederverwendet also “gecached” wird.

Da sich auf Ken die Inhalte ständig ändern können, kann ich die Seiten nicht einmalig und für immer vorrendern. Deswegen habe ich es jetzt so gelöst, das bei jeder Anfrage die Seite sofort aus dem Cache geholt und blitzschnell angezeigt wird. Im Hintergrund wird jedoch eine Neuberechnung angestoßen, allerdings maximal alle 20 Sekunden.

Lassen wir jetzt nochmal 1.000 gleichzeitige Anfragen innerhalb einer Sekunde auf Ken einprasseln. Nun wird die Seite 1.000 mal sofort angezeigt. Im Hintergrund wird die Seite währenddessen neu berechnet, jedoch nur ein mal (also eine Datenbankanfrage).

Einziger Nachteil dieser Methode: Wenn der Artikel veröffentlicht wird, kann es bis zu 20 Sekunden dauern, bis du die neueste Version auch siehst. Denke aber das ist verschmerzbar. 😉

Natürlich gibt es noch ca. eine Million weitere Tricks wie man die Seitengeschwindigkeit optimieren kann, aber ich bin davon überzeugt, dass diese Taktik für Ken erstmal lange ausreichen wird.

Achtung, ich verwende Static Site Generation sparsam, und nur bei öffentlichen Teilen der Ken Website. Wenn du dich einloggst, und deinen Entwurf auf Ken bearbeitest, siehst du natürlich immer die topaktuelle Version. Nachdem ich ausschließen kann, dass alle Autoren gleichzeitig an ihren Texten schreiben, werden sich auch die Datenbankanfragen in einem sehr überschaubaren Rahmen bewegen.

Buchhaltung

Ich hasse es repetitive Aufgaben zu machen. Speziell dann, wenn einem dabei leicht Fehler passieren können. Meine Buchhaltung war bis vor kurzem (wie vermutlich bei den meisten Unternehmen) noch ziemlich in der Steinzeit. Eingangsrechnungen einsortieren, Ausgangsrechnungen schreiben und Rechnungsnummer manuell hochzählen. Am Ende des Monats ab mit dem Stapel Papier zum Steuerberater.

Ich möchte meine Plattform auch dazu nutzen Bürokratie loszuwerden und alles was irgendwie geht zu automatisieren. Der Schritt mit den Ausgangsrechnungen ist schon mal getan. Bei jedem Kauf auf Ken wird automatisch eine Rechnung mit fortlaufender Rechnungsnummer generiert, die der Käufer abrufen kann. Am Ende des Monats exportiere ich eine CSV-Datei die alle Rechnungen der Plattform enthält und schick sie dem Steuerberater. Ich kann auf Ken aber auch interne Rechnungen ausstellen. Z.b. wenn ich ein Consulting Honorar an eine Firma verrechne. Das hat jetzt mit Ken als Plattform nichts zu tun, aber es macht mir das Leben leichter, wenn ich alles an einer Stelle habe. Auszahlungen an Autoren sind ebenfalls Rechnungen im System, und überall verwende ich dieselbe Rechnungsnummer Sequenz. Ziemlich cool! Und technisch war das gar nicht so aufwendig, habe ich festgestellt. Nachdem die Plattform erst mal am Laufen war, ist es einfach Sachen dazu zu bauen, die ganz genau auf mich zurechtgeschnitten sind. Ich fühl mich da jetzt ziemlich unabhängig. Mein Ziel: Eine Firma - ein einziges EDV System.

Nun habe ich auch alle Eingangsrechnungen direkt auf der Plattform erfasst. So habe ich immer einen super Überblick über meine Projektausgaben, bzw. auch Ausgaben, die ich nicht dem Projekt zurechne. Dazu logge ich mich auf Ken ein, habe einen Admin-Bereich wo ich die eingescannten Rechnungen hochladen kann. Jetzt kann ich dem Steuerberater auch wieder ein CSV + die zugehörigen Rechnungen als digitales Archiv schicken.

Aber das Ganze hat noch einen anderen, viel wichtigeren Grund. Ich tracke alle Ausgaben des Ken Projekts von Beginn an. Ich kann also sagen, Stand heute hat Ken so und so viel an Investitionen verursacht, und so und so viel Umsatz im Gegenzug generiert.

Einige meiner engen Partner, die selbst ihre eigenen Unternehmen führen, investieren in Ken ihre Zeit und bekommen im Gegenzug Umsatzbeteiligung. Damit ich nicht in Excel Tabellen herum rechnen muss, habe ich auch diese Berechnungen im Hauptsystem integriert. Als Partner siehst du dann: Ich habe so und so viele EUR in Arbeitszeit investiert und aktuell so und so viele Prozente Umsatzanteil.

Schlusswort

Ich bin stolz nach mehreren erfolglosen Anläufen nun eine Schreib-Plattform in nur wenigen Monaten entwickelt zu haben. Und weil es für mich so schwierig war die richtige Balance bei der technischen Umsetzung zu finden, hoffe ich dass dieser Text vielen mutigen Unternehmern hilft ihr eigenes Projekt erfolgreich zu launchen.

Ab wann Ken auch in finanzieller Hinsicht ein Erfolg ist, wird sich in den nächsten Monaten und Jahren zeigen. Ich werde weiter berichten, was mir auf dem Weg so passiert. Ihr könnt auch also schon mal auf Erfahrungsberichte zu Marketing oder Suchmaschinenoptimierung freuen. :)

Wenn du noch irgendwelche Fragen hast, klicke bitte auf den “Nachricht senden” Button weiter unten. Ich bekomme dann eine E-Mail und werde dir so schnell wie möglich antworten. Und wenn du gerade keine Frage hast, freu ich mich über ein kurzes Feedback, was du aus diesem Text mitnehmen konntest. Danke und bis gleich! :)

Published by Michael Aufreiter on Nov 5, 2021
Revised on Sep 10, 2022
Respond to the author

On Ken, we're trying to figure out how the world works — through written conversations with depth and substance.

Your response will be public, and the author will be notified.