Quando Proton è stata fondata nel 2014, il nostro unico servizio era Proton Mail. Proton VPN(new window), il nostro secondo servizio, è stato lanciato nel 2017, e di recente abbiamo rilasciato Proton Calendar e Proton Drive(new window).
Man mano che crescevamo e lanciavamo nuovi servizi, ci siamo resi conto della necessità di unificare il marchio Proton e i nostri siti web pubblici. Ecco dove inizia la storia del nuovo sito Proton.
L’inizio di Proton
Il nostro viaggio inizia con Proton Mail.
Quando Proton Mail era il nostro unico servizio, probabilmente sembrava a chi non era del settore che avessimo un solo sito web pubblico, che usavamo per promuovere il nostro servizio e condividere la visione della nostra azienda. Ma in realtà, quel singolo sito web era costituito da tre siti separati:
- Le nostre pagine web principali erano pagine statiche.
- Il blog di Proton Mail, che utilizzava WordPress.
- Il blog di Supporto di Proton Mail, che utilizzava anch’esso WordPress.
Nel 2017, quando è stato lanciato Proton VPN, abbiamo deciso di creare un sito web dedicato a Proton VPN seguendo lo stesso modello. Ciò significava che stavamo gestendo sei siti web tra Proton Mail e Proton VPN.
Oltre al loro numero, c’erano altri aspetti di questi siti web che rendevano la loro gestione quotidiana piuttosto complessa:
- Molte parti dei siti web di Proton Mail e Proton VPN erano state create artigianalmente nel tempo, rendendo difficile aggiornare alcune di quelle pagine.
- Utilizzavamo stack tecnologici diversi per le nostre pagine statiche e i siti WordPress, il che rendeva piuttosto complesso aggiornare elementi comuni su tutti i siti, come intestazioni o piè di pagina.
- Solo gli sviluppatori potevano aggiornare i contenuti sulle nostre pagine statiche. Questo rendeva difficile aggiornare rapidamente il nostro sito web, specialmente quando i team di ingegneria erano impegnati.
- I nostri prodotti sono per tutti, motivo per cui abbiamo versioni localizzate del sito Proton Mail in 26 lingue. Ma ciò introduce molte sfide dal punto di vista tecnico.
Ecco come funzionavano i nostri siti web quando ci concentravamo solo su Proton Mail e Proton VPN. Ma anche mentre lanciavamo Proton VPN, sapevamo che in futuro avremmo introdotto ulteriori servizi.
Problemi legati alla crescita
Proton ha sperimentato una crescita esplosiva fin dal suo inizio e i nostri primi siti web sono stati efficaci motori di crescita per noi. Tuttavia, sapevamo che man mano che continuavamo a crescere, avremmo dovuto cambiare il nostro approccio. Potevamo vedere diversi problemi avvicinarsi rapidamente che avrebbero richiesto un cambiamento radicale nel modo di affrontare lo sviluppo e la manutenzione del nostro sito web.
Più servizi
Il più ovvio è che stavamo iniziando a lavorare su Proton Calendar e Proton Drive. Questi servizi avrebbero avuto i loro utenti che avrebbero necessitato di informazioni specifiche per il servizio, post sul blog e articoli di supporto. Secondo il nostro modello originale, avremmo dovuto creare siti web dedicati per entrambi.
Considerando tutte le complessità quotidiane incontrate nella gestione di sei siti web, non volevamo affrontare la gestione di 12. Era evidente che avremmo avuto bisogno di un nuovo modello, ed è questo che ci ha portato inizialmente a considerare un sito web unico.
Tecnologie utilizzate
Le diverse sezioni dei nostri siti web Proton Mail e Proton VPN utilizzavano diverse tecnologie. Le pagine statiche utilizzavano principalmente uno stack JavaScript, e i nostri blog e blog di Supporto erano basati su siti WordPress, PHP e MySQL. Per complicare ulteriormente le cose, le nostre applicazioni web utilizzano React(new window) — un altro stack da mantenere.
Supportare così tanti stack diversi richiedeva un’ampia gamma di competenze ingegneristiche e significava che alcuni ingegneri erano più o meno dedicati a progetti specifici. Questo spesso creava colli di bottiglia quando un ingegnere specifico non era disponibile.
Guardando al futuro, volevamo ridurre il numero di tecnologie utilizzate per i nostri siti web. Se tutti lavoriamo sulla stessa tecnologia, avremo tutti le stesse conoscenze necessarie e potremo aiutare in qualsiasi progetto.
Era anche una sfida mantenere un alto livello di qualità supportando così tanti stack. Mantenere la comunità Proton e i loro dati al sicuro è la nostra priorità assoluta, ed è per questo che poniamo così tanto enfasi sulla qualità e sicurezza dei nostri servizi.
Supportare e gestire una così ampia varietà di linguaggi di programmazione e strumenti rendeva questo compito più difficile. Ad esempio, ogni volta che un ingegnere modificava l’intestazione o il piè di pagina del sito web Proton Mail, quella modifica doveva essere applicata tre volte su ogni sito separato (sito statico, blog e blog di supporto). Se questo ingegnere volesse fare questa modifica da solo, avrebbe dovuto essere in grado di lavorare con JavaScript, PHP e MySQL. Volevamo limitare questo quanto più possibile in futuro.
Aggiornamenti dei contenuti
Ultimo ma non meno importante, una delle nostre sfide maggiori era effettuare aggiornamenti tempestivi ai contenuti dei nostri siti web. Se dovevamo progettare un nuovo sito web, volevamo che chiunque potesse aggiungere testo o fare modifiche semplici, non solo gli ingegneri. Lanciando sempre più servizi, il numero di pagine web e la quantità di contenuti che dobbiamo gestire cresce esponenzialmente, ed era già difficile affidarsi solo a sviluppatori impegnati per applicare cambiamenti rapidi ai contenuti.
Questo era solo l’inizio. Dobbiamo anche gestire contenuti localizzati. In precedenza, tutti i testi erano forniti dagli sviluppatori in inglese nel codice sorgente. Questo testo in inglese veniva utilizzato per creare una stringa di traduzione. Poi il nostro team di localizzazione lo traduceva con l’aiuto della nostra fantastica comunità di localizzazione.
Questo sistema aveva un grave difetto. Ogni volta che dovevamo cambiare il testo esistente su una pagina web, anche se fosse semplice come aggiungere una virgola, gli sviluppatori dovevano aggiornare il testo nel codice sorgente. Questo aggiornamento modificava la stringa di traduzione, il che significava che il team di localizzazione doveva tradurre la stringa come se fosse completamente nuova.
Migliorare la gestione dei contenuti nel suo complesso era un’altra sfida che volevamo affrontare con il nostro nuovo sito web.
Come e perché abbiamo costruito il sito web di Proton in questo modo
Una volta identificate tutte le sfide presentate dal nostro sistema attuale, volevamo trovare una soluzione che le risolvesse tutte. Richiedeva una soluzione tecnica ma anche pratiche migliorate da un punto di vista tecnico e organizzativo. Ecco cosa abbiamo fatto finora e su cosa stiamo ancora lavorando.
Gatsby
Una delle nostre prime decisioni è stata scegliere un framework tecnico per gestire il nostro sito web statico che semplificasse il nostro stack tecnologico.
Non è stato difficile. Le nostre applicazioni web utilizzano il framework React, e la maggior parte degli ingegneri del nostro team lo conosce già e si trova a suo agio nell’usarlo, portandoci a cercare una soluzione basata anche su React. Questa è la ragione principale per cui abbiamo scelto Gatsby(new window) per gestire le nostre pagine web statiche. È anche un framework molto utilizzato con una grande comunità, che garantisce che non scomparirà a breve.
Abbiamo scelto Gatsby fin dall’inizio, così abbiamo potuto verificare che funzionasse per noi facendogli fare una prova. Per prima cosa, abbiamo usato Gatsby per costruire alcune pagine per il sito web statico di Proton VPN. Poiché il sito era già statico, abbiamo potuto semplicemente costruire nuove pagine con Gatsby e pubblicarle insieme a quelle esistenti. Ovviamente, ci sono state alcune sfide tecniche da risolvere quando abbiamo integrato Gatsby nel sito statico, ma sono sostanzialmente invisibili dal punto di vista dell’utente finale.
Volevamo anche sistematizzare il più possibile il modo in cui costruiamo le pagine per migliorare la nostra agilità nella modifica dei contenuti delle pagine web. Molte delle nostre vecchie pagine web statiche sono state costruite pezzo per pezzo nel tempo, mentre altre sono state copiate e incollate, il che significa che non c’era uniformità da pagina a pagina. Questo rendeva la manutenzione molto intensiva. Abbiamo pensato che passare a un nuovo framework tecnico sarebbe stato un buon momento per abbandonare questo approccio frammentario.
Abbiamo deciso di adottare una strategia basata sui componenti fin dall’inizio con Gatsby. I nostri team di Prodotto e Design hanno lavorato duramente per definire e creare un insieme di componenti che possiamo riutilizzare per costruire nuove pagine in futuro. In questo modo, possiamo applicare qualsiasi cambiamento a un componente ovunque invece di dover applicare lo stesso cambiamento più volte in posti diversi come facevamo nei nostri vecchi siti web.
Questi primi esperimenti hanno confermato che Gatsby sarebbe stata una soluzione efficace per costruire e mantenere il nostro nuovo sito web statico.
Tuttavia, queste pagine statiche erano solo una parte dei nostri siti web pubblici. Dovevamo anche trovare una soluzione per gestire il nostro blog e il blog di Supporto.
WordPress
Se dovessimo continuare con WordPress(new window) è stata una domanda difficile per noi. Per semplificare il nostro stack tecnico, sarebbe stato logico eliminarlo e trovare un altro modo per gestire i nostri blog e blog di Supporto. D’altra parte, il team di Proton conosce WordPress, come la maggior parte degli editor di contenuti web in generale.
Avevamo anche molti articoli esistenti da importare nel nuovo sito web dai blog di Proton Mail e Proton VPN e dai rispettivi blog di Supporto. Ad esempio, se guardiamo solo al sito web di Proton Mail, abbiamo realizzato più di 700 post nel luglio 2021! Migrare tutto quel contenuto sarebbe stato davvero una sfida.
Pensandoci meglio, ciò che ci ha creato più difficoltà è stata la gestione separata delle pagine principali per ogni sito. Nella nostra configurazione originale, gestivamo effettivamente quattro diversi siti WordPress: un blog e un blog di supporto sia per Proton Mail che per Proton VPN. Inoltre, ognuna di queste istanze di WordPress aveva il proprio set di plugin e temi dedicati.
Alla fine, abbiamo deciso di mantenere WordPress e semplificare il modo in cui gestiamo le pagine principali.
WordPress Multisito
Una volta deciso di mantenere WordPress, la scelta logica successiva è stata selezionare una versione multisito. Se non hai mai sentito parlare di un WordPress Multisito, è sostanzialmente un’istanza standard di WordPress configurata per permetterti di gestire più sottositi in un unico sito WordPress. Questa possibilità ci interessava perché un’istanza multisito ti permette di condividere utenti, plugin, temi e impostazioni di configurazione tra tutti i sottositi. Questa funzionalità da sola ha reso molto più semplice la gestione dei nostri siti WordPress. Ad esempio, con un’istanza multisito, abbiamo bisogno di premere un solo pulsante per aggiornare WordPress o un plugin per tutti i suoi sottositi. In precedenza, dovevamo aggiornare ogni sito individualmente.
Questo ovviamente ci fa risparmiare molto tempo rispetto alla nostra configurazione precedente, ma pensavamo di poter fare ancora di più. Il nostro sogno era utilizzare WordPress come un CMS headless.
WordPress come headless
Sapevamo già all’inizio del 2020 che avremmo dovuto trovare una soluzione migliore per i nostri siti web e abbiamo costruito alcune pagine di blog con Gatsby utilizzando l’API REST di WordPress come test. Purtroppo, le opzioni tecniche di quel tempo non erano ottimali. Il processo di costruzione, in particolare, era troppo lento per le nostre esigenze.
Abbiamo deciso di riprovare all’inizio del 2021. Abbiamo investigato e scoperto che c’erano stati diversi aggiornamenti promettenti. Il team di Gatsby aveva lavorato molto per permettere a Gatsby di attingere contenuti da WordPress. Soprattutto, sono stati sviluppati plugin(new window) per Gatsby e WordPress, che permettono loro di lavorare insieme. Questi plugin ottimizzano la costruzione con la gestione della cache e forniscono un modo per visualizzare in anteprima gli articoli da WordPress.
Così abbiamo creato un proof of concept con articoli del blog di Proton Mail per verificare come funzionerebbe un CMS WordPress headless. Con nostra grande soddisfazione, ha funzionato abbastanza bene. Per riassumere la nostra configurazione, esponiamo sostanzialmente un’API GraphQL dei contenuti di WordPress che possiamo utilizzare con Gatsby per interrogare e ottenere il contenuto e costruire la pagina come preferiamo. Alla fine, siamo riusciti a ottenere tutti i nostri articoli del blog e gli articoli di supporto in WordPress per generare pagine statiche utilizzando Gatsby.
A questo punto, abbiamo bisogno di utilizzare un solo strumento per costruire pagine front-end e possiamo implementare modifiche una volta e averle applicate su più siti invece di dover passare e implementarle su ogni sito individualmente. Vedi i progressi!
Eravamo già contenti di quanto avessimo potuto semplificare il nostro processo di sviluppo, ma pensavamo che ci fosse ancora di più che potevamo fare.
Prismic
Abbiamo continuato a cercare modi per rendere ancora più semplice la gestione dei contenuti sui nostri siti web. Idealmente, volevamo eliminare completamente gli ingegneri dal processo di aggiornamento dei contenuti.
Con il nostro vecchio sistema, gli ingegneri dovevano implementare ogni aggiornamento dei contenuti sulle nostre pagine statiche. Altri team interni, come Crescita, Contenuti e Design, inviavano le loro modifiche a un ingegnere che aggiornava il codice. Questo sistema aiutava a mantenere la qualità del codice ma rendeva difficile aggiornare i contenuti esistenti o pubblicare nuovi contenuti rapidamente.
Abbiamo iniziato a cercare modi per permettere al team dei Contenuti di gestire autonomamente il testo sui nostri siti statici senza rischiare la qualità del nostro codice. Abbiamo valutato diverse soluzioni, ma alla fine abbiamo deciso di scegliere Prismic(new window). Prismic è un CMS headless che ti permette di creare componenti che gli editor possono utilizzare per costruire pagine complete. Abbiamo risparmiato ancora più sforzo utilizzando i componenti che avevamo definito e costruito inizialmente con Gatsby. Una volta configurati questi componenti, potevamo costruire rapidamente tutte le pagine web di cui avevamo bisogno e affidare la manutenzione dei contenuti agli editor dei contenuti.
L’ultima cosa di cui occuparsi era integrare questi contenuti in Gatsby. Fortunatamente, Prismic espone un’API GraphQL allo stesso modo di WordPress, rendendo il processo semplice. Tutto ciò che dovevamo fare era mappare i contenuti ricercati sui nostri componenti esistenti.
Dove siamo
Attualmente, il sito web di Proton utilizza il sistema descritto sopra per servire Proton Calendar, Proton Drive e Proton Mail. Abbiamo migrato i nostri siti web di Proton Mail su proton.me e costruito nuove pagine web per Proton Calendar e Proton Drive. Il nostro sito web di Proton VPN deve ancora essere migrato.
La nuova configurazione del sito web di Proton è un grande passo avanti rispetto a dove abbiamo iniziato, anche senza la migrazione di Proton VPN. Riunendo Proton Mail, Proton Calendar e Proton Drive su un unico sito, abbiamo costruito un ecosistema unificato dove le interazioni tra i nostri servizi servono a proteggere meglio la privacy della nostra comunità.
Da un punto di vista tecnico, abbiamo ancora molto lavoro davanti a noi. Ad esempio, al momento abbiamo un unico processo di costruzione per l’intero sito web e lo distribuiamo quotidianamente in una finestra fissa per gestire gli aggiornamenti o pubblicare articoli sul blog.
Questo funziona bene, ma potremmo essere più efficienti se avessimo costruzioni e distribuzioni più granulari. Ci sono alcune sfide tecniche che dovremo superare per raggiungere questo obiettivo, poiché stiamo gestendo tutto internamente. Questa è una delle molte questioni che prevediamo di esplorare nelle prossime settimane e mesi.
Speriamo che tu abbia apprezzato questa spiegazione di come abbiamo costruito il sito web di Proton. Ci aiuterà a proteggere i dati e la privacy della nostra comunità e ci prepara a gestire una futura crescita.
