Als Proton 2014 startete, war unser einziger Dienst Proton Mail. 2017 kam Proton VPN(neues Fenster) dazu, und kürzlich haben wir Proton Calendar und Proton Drive(neues Fenster) veröffentlicht.
Als wir wuchsen und neue Dienste herausbrachten, wurde uns klar, dass wir die Proton-Marke und unsere öffentlichen Websites vereinheitlichen mussten. Hier beginnt die Geschichte der neuen Proton-Website.
Protons Anfänge
Unsere Reise beginnt mit Proton Mail.
Als Proton Mail unser einziger Dienst war, schien es für das ungeübte Auge wahrscheinlich so, als hätten wir nur eine einzige öffentliche Website, die wir zur Bewerbung unseres Dienstes und zur Vermittlung unserer Unternehmensvision nutzten. In Wirklichkeit bestand diese einzelne Website jedoch aus drei separaten Websites:
- Unsere Hauptwebseiten waren statische Seiten.
- Der Proton Mail Blog, der WordPress nutzte.
- Der Proton Mail Support-Blog, der ebenfalls WordPress verwendete.
2017, als Proton VPN herauskam, beschlossen wir, eine eigene Proton VPN-Website nach dem gleichen Modell zu erstellen. Das bedeutete, dass wir zwischen Proton Mail und Proton VPN insgesamt sechs Websites verwalteten.
Neben ihrer Anzahl gab es andere Aspekte dieser Websites, die ihre tägliche Verwaltung etwas komplex machten:
- Viele Teile der Proton Mail- und Proton VPN-Websites wurden im Laufe der Zeit Stück für Stück handgefertigt, was es schwierig machte, einige dieser Seiten zu aktualisieren.
- Wir verwendeten unterschiedliche Technologie-Stacks auf unseren statischen Seiten und WordPress-Sites, was das Aktualisieren gemeinsamer Elemente auf allen Seiten, wie Kopf- oder Fußzeilen, ziemlich komplex machte.
- Nur Entwickler konnten den Inhalt auf unseren statischen Seiten aktualisieren. Das machte es schwierig, unsere Website schnell zu aktualisieren, besonders wenn die Entwicklerteams beschäftigt waren.
- Unsere Produkte sind für alle da, weshalb wir lokalisierte Versionen der Proton Mail-Website in 26 Sprachen anbieten. Aber das führt aus technischer Sicht zu vielen Herausforderungen.
So funktionierten unsere Websites, als wir uns nur auf Proton Mail und Proton VPN konzentrierten. Aber selbst als wir Proton VPN starteten, wussten wir, dass wir in Zukunft weitere Dienste einführen würden.
Probleme, die mit dem Wachstum kommen
Proton hat seit seinem Beginn ein explosives Wachstum erlebt, und unsere frühen Websites waren erfolgreiche Wachstumsmotoren für uns. Allerdings wussten wir, dass wir unseren Ansatz ändern müssten, wenn wir weiter wachsen wollen. Wir konnten mehrere Probleme erkennen, die sich rasch näherten und einen grundlegenden Wandel in unserer Herangehensweise an die Entwicklung und Wartung unserer Website erfordern würden.
Mehr Dienste
Am offensichtlichsten war, dass wir mit der Arbeit an Proton Calendar und Proton Drive begannen. Diese Dienste würden ihre eigenen Nutzer haben, die ihre eigenen dienstspezifischen Informationen, Blogbeiträge und Support-Artikel benötigen würden. Laut unserem ursprünglichen Modell sollten wir jeweils dedizierte Websites aufbauen.
Angesichts der täglichen Komplexitäten, die wir beim Verwalten von sechs Websites erlebt haben, wollten wir uns nicht auch noch mit zwölf herumschlagen. Es war offensichtlich, dass wir ein neues Modell brauchen würden, was uns zuerst dazu brachte, über eine einzige Website nachzudenken.
Technologiestapel
Die verschiedenen Bereiche unserer Proton Mail und Proton VPN Websites nutzten unterschiedliche Technologiestapel. Die statischen Seiten verwendeten hauptsächlich einen JavaScript-Stack, und unsere Blogs sowie Support-Blogs waren auf WordPress-Seiten basierend auf PHP und MySQL. Um die Sache weiter zu verkomplizieren, nutzen unsere Webanwendungen React(neues Fenster) — noch ein weiterer Stack, den wir warten mussten.
Die Unterstützung so vieler unterschiedlicher Stacks erforderte ein breites Spektrum an Ingenieursfähigkeiten und bedeutete, dass einige Ingenieure mehr oder weniger spezifischen Projekten zugeordnet waren. Das führte oft zu Engpässen, wenn ein spezifischer Ingenieur nicht verfügbar war.
Als wir in die Zukunft blickten, wollten wir die Anzahl der Technologiestapel, die wir für unsere Websites nutzten, reduzieren. Wenn alle am gleichen Stack arbeiten, haben wir alle das notwendige Wissen und können bei jedem Projekt helfen.
Es war ebenfalls eine Herausforderung, ein hohes Qualitätsniveau zu halten, während wir so viele Stacks unterstützten. Die Sicherheit der Proton-Community und ihrer Daten ist unsere oberste Priorität, weshalb wir so viel Wert auf die Qualität und Sicherheit unserer Dienste legen.
Die Unterstützung und Verwaltung einer so großen Vielfalt an Programmiersprachen und Werkzeugen machte dies schwieriger. Beispielsweise musste jedes Mal, wenn ein Ingenieur den Header oder Footer der Proton Mail-Website änderte, diese Änderung dreimal auf jeder separaten Website (statische Seite, Blog und Support-Blog) angewendet werden. Wenn dieser Ingenieur diese Änderung alleine vornehmen wollte, musste er in der Lage sein, in JavaScript, PHP und MySQL zu arbeiten. Wir wollten dies in Zukunft so weit wie möglich einschränken.
Inhaltsaktualisierungen
Nicht zuletzt war eine unserer größten Herausforderungen, zeitnahe Updates für den Inhalt unserer Websites durchzuführen. Wenn wir eine neue Website gestalten wollten, sollten nicht nur Ingenieure, sondern jeder in der Lage sein, Text hinzuzufügen oder einfache Bearbeitungen vorzunehmen. Mit dem Start immer mehr Dienste wächst die Anzahl der Webseiten und der zu verwaltende Inhalt exponentiell, und es war bereits schwierig, sich nur auf beschäftigte Entwickler zu verlassen, um schnelle Inhaltsänderungen vorzunehmen.
Das war erst der Anfang. Wir müssen auch lokalisierten Inhalt verwalten. Zuvor wurden alle Texte von den Entwicklern in Englisch in der Codebasis beigesteuert. Dieser englische Text wurde verwendet, um eine Übersetzungszeichenfolge zu erstellen. Anschließend übersetzte unser Lokalisierungsteam es mit Hilfe unserer großartigen Lokalisierungsgemeinschaft.
Dieses System hatte einen ernsthaften Mangel. Immer wenn wir den bestehenden Text auf einer Webseite ändern mussten, selbst wenn es so einfach war wie das Hinzufügen eines Kommas, mussten Entwickler den Text in der Codebasis aktualisieren. Diese Aktualisierung veränderte die Übersetzungszeichenfolge, was bedeutete, dass das Lokalisierungsteam die Zeichenfolge so behandeln musste, als wäre sie völlig neu.
Die Verbesserung des gesamten Content-Managements war eine weitere Herausforderung, die wir mit unserer neuen Website angehen wollten.
Wie und warum wir die Proton-Webseite so gestaltet haben, wie wir es getan haben
Nachdem wir alle Herausforderungen unseres aktuellen Systems identifiziert hatten, wollten wir eine Lösung finden, die alle diese Probleme behebt. Es bedurfte einer technischen Lösung, aber auch verbesserter Praktiken aus technischer und organisatorischer Sicht. Hier ist, was wir bisher getan haben und woran wir noch arbeiten.
Gatsby
Eine unserer ersten Entscheidungen war, ein technisches Framework für unsere statische Webseite zu wählen, das unseren Technologiestapel vereinfacht.
Das war nicht schwierig. Unsere Webanwendungen nutzen das React-Framework, und die meisten Ingenieure in unserem Team kennen es bereits und fühlen sich beim Einsatz wohl, was uns dazu veranlasst hat, nach einer Lösung auf Basis von React zu suchen. Das ist der Hauptgrund, warum wir Gatsby(neues Fenster) gewählt haben, um unsere statischen Webseiten zu verwalten. Es ist auch ein weit verbreitetes Framework mit einer großen Community, was die Gewissheit gibt, dass es nicht so bald verschwinden wird.
Wir haben uns früh für Gatsby entschieden, sodass wir überprüfen konnten, ob es für uns funktioniert, indem wir es in einem Testlauf ausprobiert haben. Zuerst haben wir Gatsby benutzt, um einige Seiten für die statische Webseite von Proton VPN zu erstellen. Da die Seite bereits statisch war, konnten wir einfach neue Seiten mit Gatsby bauen und sie unter den bestehenden veröffentlichen. Natürlich gab es einige technische Herausforderungen zu lösen, als wir Gatsby in die statische Seite integrierten, aber diese sind aus Nutzersicht praktisch unsichtbar.
Wir wollten auch systematisieren, wie wir Seiten so weit wie möglich aufbauen, um unsere Agilität bei der Bearbeitung von Webseiteninhalten zu verbessern. Viele unserer alten statischen Webseiten wurden über die Zeit Stück für Stück aufgebaut, während andere kopiert und eingefügt wurden, was bedeutet, dass es keine Einheitlichkeit von Seite zu Seite gab. Das machte die Wartung arbeitsintensiv. Wir dachten, dass der Wechsel zu einem neuen technischen Framework eine gute Gelegenheit wäre, diesen stückweisen Ansatz hinter uns zu lassen.
Wir entschieden uns von Anfang an für eine Komponentenstrategie mit Gatsby. Unsere Produkt- und Designteams haben hart daran gearbeitet, eine Reihe von Komponenten zu definieren und zu erstellen, die wir wiederverwenden können, um in Zukunft neue Seiten zu bauen. Auf diese Weise können wir jede Änderung an einer Komponente überall anwenden, statt dieselbe Änderung mehrfach an verschiedenen Stellen vornehmen zu müssen, wie wir es auf unseren alten Webseiten getan haben.
Diese ersten Experimente bestätigten, dass Gatsby eine effektive Lösung zum Aufbau und zur Pflege unserer neuen statischen Webseite sein würde.
Allerdings waren diese statischen Seiten nur ein Teil unserer öffentlichen Webseiten. Wir mussten auch eine Lösung finden, um unseren Blog und den Support-Blog zu verwalten.
WordPress
Ob wir weiterhin mit WordPress(neues Fenster) arbeiten sollten, war eine knifflige Frage für uns. Um unseren Technologiestapel zu vereinfachen, wäre es logisch gewesen, es aufzugeben und einen anderen Weg zu finden, unsere Blogs und Support-Blogs zu verwalten. Andererseits kennt das Proton-Team WordPress, wie auch die meisten Web-Content-Redakteure im Allgemeinen.
Wir hatten auch viele bestehende Artikel, die von den Proton Mail- und Proton VPN-Blogs und ihren entsprechenden Support-Blogs auf die neue Webseite importiert werden mussten. Wenn wir uns zum Beispiel nur die Proton Mail-Webseite anschauen, haben wir im Juli 2021 mehr als 700 Beiträge veröffentlicht! Die Migration all dieser Inhalte wäre ziemlich herausfordernd gewesen.
Als wir genauer darüber nachdachten, bereitete uns das getrennte Verwalten der Startseiten für jede Website die meisten Schwierigkeiten. In unserer ursprünglichen Konfiguration verwalteten wir tatsächlich vier verschiedene WordPress-Websites: ein Blog und ein Support-Blog sowohl für Proton Mail als auch für Proton VPN. Zusätzlich hatte jede dieser WordPress-Instanzen ihren eigenen Satz an Plugins und dedizierten Themes.
Letztendlich entschieden wir uns, WordPress beizubehalten und die Verwaltung der Startseiten zu vereinfachen.
WordPress Multisite
Nachdem wir uns entschieden hatten, WordPress beizubehalten, war die nächste logische Wahl eine Multisite-Version zu wählen. Wenn du noch nie von einer WordPress Multisite gehört hast, es handelt sich im Grunde um eine Standard-WordPress-Instanz, die so konfiguriert ist, dass du mehrere Unterseiten auf einer einzigen WordPress-Seite verwalten kannst. Das interessierte uns, weil du mit einer Multisite-Instanz Benutzer, Plugins, Themes und Konfigurationseinstellungen über alle Unterseiten hinweg teilen kannst. Allein diese Funktion machte die Verwaltung unserer WordPress-Seiten viel einfacher. Beispielsweise müssen wir mit einer Multisite-Instanz nur einmal einen Button klicken, um WordPress oder ein Plugin für alle seine Unterseiten zu aktualisieren. Früher mussten wir jede Seite einzeln aktualisieren.
Das spart uns offensichtlich viel Zeit im Vergleich zu unserer vorherigen Konfiguration, aber wir dachten, dass wir noch weiter gehen könnten. Unser Traum war es, WordPress als Headless-CMS zu nutzen.
WordPress als Headless
Wir wussten bereits Anfang 2020, dass wir eine bessere Lösung für unsere Websites finden mussten, und wir erstellten einige Blogseiten mit Gatsby unter Verwendung der WordPress REST API als Test. Leider waren die technischen Möglichkeiten zu dieser Zeit nicht optimal. Insbesondere war der Erstellungsprozess zu langsam für unsere Bedürfnisse.
Wir beschlossen, es Anfang 2021 erneut zu versuchen. Wir recherchierten und fanden heraus, dass es mehrere vielversprechende Updates gegeben hatte. Das Gatsby-Team hatte viel Arbeit geleistet, um Gatsby die Nutzung von Inhalten aus WordPress zu ermöglichen. Entscheidend war, dass Plugins(neues Fenster) für Gatsby und WordPress entwickelt wurden, die es ihnen ermöglichen, zusammenzuarbeiten. Diese Plugins optimieren den Build mit Cache-Management und bieten eine Möglichkeit, Artikel aus WordPress in der Vorschau anzuzeigen.
Also erstellten wir einen Proof of Concept mit Artikeln aus dem Proton Mail-Blog, um zu überprüfen, wie ein Headless WordPress CMS funktionieren würde. Zu unserer Freude funktionierte es ziemlich gut. Zusammengefasst stellen wir in unserem Setup eine GraphQL-API von WordPress-Inhalten zur Verfügung, die wir mit Gatsby abfragen können, um den Inhalt zu erhalten und die Seite nach unseren Wünschen zu erstellen. Letztendlich ist es uns gelungen, alle unsere Blogbeiträge und Support-Artikel in WordPress zu statischen Seiten zu machen, die mit Gatsby generiert werden.
Jetzt brauchen wir nur noch ein Tool, um Front-End-Seiten zu erstellen, und wir können Änderungen einmal implementieren und sie auf mehreren Seiten anwenden, statt sie einzeln auf jeder Seite durchzuführen. Fortschritt anzeigen!
Wir waren bereits glücklich darüber, wie sehr wir unseren Entwicklungsprozess vereinfachen konnten – aber wir dachten, es gäbe noch mehr, was wir tun könnten.
Prismic
Wir haben weiter nach Wegen gesucht, das Verwalten von Inhalten auf unseren Webseiten noch einfacher zu gestalten. Idealerweise wollten wir die Ingenieure vollständig aus dem Prozess der Inhaltsaktualisierung herausnehmen.
In unserem alten System mussten Ingenieure jede Aktualisierung der Inhalte auf unseren statischen Seiten umsetzen. Andere interne Teams, wie Wachstum, Inhalt und Design, schickten ihre Änderungen an einen Ingenieur, der dann die Codebasis aktualisierte. Dieses System half dabei, die Codequalität zu erhalten, machte es aber schwierig, bestehende Inhalte zu aktualisieren oder schnell neue Inhalte zu veröffentlichen.
Wir begannen, nach Wegen zu suchen, um dem Content-Team zu ermöglichen, den Text auf unseren statischen Seiten selbst zu verwalten, ohne die Qualität unseres Codes zu gefährden. Wir haben verschiedene Lösungen bewertet, uns letztendlich aber für Prismic(neues Fenster) entschieden. Prismic ist ein Headless-CMS, das es dir ermöglicht, Komponenten zu erstellen, die Redakteure nutzen können, um vollständige Seiten zu bauen. Wir haben noch mehr Aufwand gespart, indem wir die Komponenten, die wir zuerst mit Gatsby definiert und gebaut haben, verwendet haben. Nachdem diese Komponenten konfiguriert waren, konnten wir schnell alle benötigten Webseiten erstellen und die Inhaltspflege an die Content-Redakteure übergeben.
Das Letzte, was es zu erledigen gab, war, diesen Inhalt in Gatsby zu bekommen. Zum Glück stellt Prismic eine GraphQL-API zur Verfügung, genau wie WordPress, was dies einfach machte. Alles, was wir tun mussten, war, die abgefragten Inhalte auf unsere bestehenden Komponenten zu übertragen.
Wo wir stehen
Aktuell nutzt die Proton-Webseite die oben beschriebene Einrichtung, um Proton Calendar, Proton Drive und Proton Mail bereitzustellen. Wir haben unsere Proton Mail-Webseiten zu proton.me migriert und neue Webseiten für Proton Calendar und Proton Drive erstellt. Unsere Proton VPN-Webseite muss noch migriert werden.
Die neue Einrichtung der Proton-Webseite ist ein großer Schritt nach vorne im Vergleich zu unserem Ausgangspunkt, selbst ohne die Migration von Proton VPN. Indem wir Proton Mail, Proton Calendar und Proton Drive auf einer einzigen Seite zusammengebracht haben, haben wir ein einheitliches Ökosystem geschaffen, in dem die Interaktionen zwischen unseren Diensten dazu beitragen, die Privatsphäre unserer Community besser zu schützen.
Aus technischer Sicht steht uns noch mehr Arbeit bevor. Zum Beispiel haben wir derzeit einen einzigen Build-Prozess für die gesamte Webseite und wir setzen täglich innerhalb eines festen Zeitfensters ein Deployment um, um Updates durchzuführen oder Blogartikel zu veröffentlichen.
Das funktioniert gut, aber wir könnten effizienter sein, wenn wir feiner abgestimmte Builds und Deployments hätten. Es gibt einige technische Herausforderungen, die wir bewältigen müssen, um dies zu erreichen, da wir alles intern verwalten. Das ist eines der vielen Probleme, die wir in den kommenden Wochen und Monaten untersuchen wollen.
Wir hoffen, dir hat diese Erklärung gefallen, wie wir die Proton-Webseite aufgebaut haben. Sie wird uns dabei helfen, die Daten und Privatsphäre unserer Community zu schützen und bereitet uns darauf vor, weiteres Wachstum in der Zukunft zu bewältigen.
