Psono.com ora alimentato da Gatsby

In passato Psono.com era gestito da Odoo v11. Odoo è un ottimo CMS ma, come abbiamo dovuto imparare, gli aggiornamenti sono difficili. In particolare il loro modulo per il sito web ha causato molti problemi durante i nostri test. Odoo v11 raggiungerà la fine della sua vita utile entro la fine del 2020, quindi eravamo costretti a trovare una soluzione.

Abbiamo preso in considerazione diverse opzioni: aggiornare a Odoo v13 e migrare manualmente tutto il contenuto e le personalizzazioni, assumere qualcuno per fare la migrazione per noi, o migrare completamente verso un nuovo CMS. Abbiamo deciso di migrare completamente Psono.com e continueremo a utilizzare v11 dietro un firewall per migrarlo in seguito (non abbiamo ancora deciso).

Le ragioni dietro questa decisione sono state:

• Abbiamo solo una piccola quantità di contenuto che avremmo bisogno di migrare per Psono.com. Principalmente alcuni post del blog.
• Una migrazione a Odoo v13 riprodurrebbe lo stesso problema tra due anni quando v13 raggiunge la sua fine della vita utile, potenzialmente con molti più dati da migrare.
• Non eravamo troppo soddisfatti delle capacità di personalizzazione dei siti web di Odoo v11. Tutto è estremamente complesso con i loro modelli memorizzati nel database.
• I costi. Assumere qualcuno per fare la migrazione ci costerebbe almeno 5000 USD, potenzialmente di più.
• La comunità di Odoo era molto attiva, tuttavia con lo sviluppo negli ultimi anni di cambi di licenza e migrazione di funzionalità e plugin a soluzioni a pagamento, mettendo tutto dietro un muro di pagamento, la comunità è morta.
• Psono.com è principalmente un sito web statico con contenuti statici. Se avessimo bisogno di contenuti dinamici, potremmo recuperarli con le API.

Il viaggio

Dopo aver deciso di migrare, dovevamo decidere quale framework utilizzare. Ci sono i framework classici come ad esempio Hugo che abbiamo utilizzato, ma la loro funzionalità è limitata. Mentre cercavamo alternative, abbiamo trovato alcune soluzioni nel mondo di node / react.

Volevo scrivere qui "soluzioni eccellenti", ma non penso che nulla nello stato attuale frammentato dello sviluppo frontend meriti quel titolo. Frammentato, chiedete? Ricordate i tempi in cui gli sviluppatori potevano creare un sito web con un index.html e un tag script per caricare jquery ed erano in grado di iniziare a sviluppare siti web? Ora avete bisogno di npm o yarn, dovete capire package.json, script webpack, framework moderni come angular o react che portano tutti il loro client con loro. JSX o typescript. Funzionalità come il riavvio a caldo non funzionano in modo affidabile (file non monitorato, alcune modifiche richiedono un riavvio completo, o il riavvio a caldo viene attivato troppo presto, quindi devi comunque aggiornare manualmente) finisci per uccidere i server di sviluppo e aspettare minuti che tornino su (almeno nei progetti più grandi). (Mi manca premere F5 e avere tutto lì senza problemi!). Per non parlare di un nuovo framework o strumento almeno ogni sei mesi in cui i vecchi strumenti vengono abbandonati quotidianamente. Potrei facilmente riempire pagine con me che mi lamento dello stato attuale dello sviluppo frontend. Comunque, torniamo all'argomento reale.

In assenza di alternative sensate, le migliori opzioni (al momento della scrittura) sarebbero next.js e gatsby. Almeno è così che alcuni articoli li promuovevano. Entrambi sono ugualmente popolari se si confrontano le stelle di Github o i committenti. L'unica differenza che abbiamo notato durante una valutazione iniziale è la necessità di un componente server per next.js, mentre gatsby crea siti statici (Per favore non uccidetemi ora se c'è un'opzione per far funzionare next.js senza server attivo! :D)

Quindi abbiamo fatto qualche esperimento con Gatsby e sembrava ok. Come passo successivo siamo andati avanti e abbiamo cercato un tema. Gatsby è una "nuova" utilità, quindi tutti i temi che abbiamo trovato erano ancora in uno stato molto basico. Trenta minuti e trenta dollari dopo avevamo un tema visivamente attraente che copriva almeno alcuni dei componenti richiesti e abbiamo iniziato a modificarlo.

Come opzione di hosting oggigiorno si può scegliere tra diversi provider, come Firebase, netlify, Cloudflare, Vercel, semplice storage GCP Cloud o AWS Cloudfront, server propri, container docker in esecuzione su Kubernetes (dovevo menzionarlo!), (Ricordate i vecchi tempi in cui si affittava uno spazio web per 5 dollari al mese con PHP e un database MySQL :D ... ma questo è per un altro articolo...)

Dopo averli confrontati, letto alcune recensioni e valutato possibili combinazioni (come Cloudflare davanti a Firebase) abbiamo provato inizialmente Cloudflare. Come grandi fan del loro servizio è stata una scelta naturale, ma purtroppo la loro utility wrangler aveva problemi. Prima dava sempre un errore e poi non siamo riusciti ad autenticare ... Gli errori iniziali sono spariti il giorno dopo (forse un nuovo bash ha fatto il trucco), ma il problema dell'autenticazione persisteva. Credo di aver commesso qualche errore e mi sono arreso dopo un paio di ore a leggere la loro documentazione e provare diverse soluzioni.

Netlify era un altro candidato, ma devi collegarlo a un provider git e lasciarli costruire (volevamo utilizzare GitLab CI) o caricare manualmente l'output di build. Forse hanno un'opzione da qualche parte per caricare l'output di build tramite un'API, ma non sono riuscito a trovarla. Un'alternativa sarebbe stata un repository in cui effettivamente pushiamo l'output della build, ma sembrava inutilmente complesso ... Un altro problema per me è il loro modello di prezzo. Addebitano per membro (!!!) una somma abbastanza consistente. Tieni presente che questo è per un sito web statico. Dichiarazioni come "4× la larghezza di banda" evocano brutti ricordi dei tempi dell'hosting web "fair use" in cui ti cacciavano se usavi troppo ...

Come quarto servizio abbiamo provato Firebase (che come vantaggio è gratuito per la nostra larghezza di banda e richieste target) e tutto ha funzionato perfettamente. Le loro capacità di reindirizzamento sono un po' limitate, quindi mappare vecchi URL a quelli più belli è diventato un po' noioso ma dopo un paio di regole di reindirizzamento tutto funzionava. Il loro prezzo sembra ragionevole e si paga per le risorse del server. Bisognerebbe stare lontani da tutti i loro servizi extra per evitare il lock-in del fornitore, ma avevamo solo bisogno di hosting.

Abbiamo anche brevemente controllato Vercel, ma il loro requisito di login con un account Github e poi un permesso con "Agire per mio conto" mi ha fatto desistere ancor prima di iscrivermi.

Il blog è stato il più difficile da migrare. Abbiamo finito per copiare tutto il contenuto manualmente. Non è qualcosa che dovresti fare con un blog più grande, ma il nostro blog aveva solo quindici post. Gatsby supporta più meccanismi, ma volevamo qualcosa di semplice che qualcuno senza background tecnico potesse usare per creare nuovi post del blog. Abbiamo deciso di utilizzare markdown e quindi abbiamo dovuto imparare come istruire gatsby a leggere le pagine markdown. Il meccanismo effettivo ci ha richiesto circa mezza giornata con tutta la gestione delle immagini. Un bel tema per il blog e le immagini un'altra mezza giornata.

Dopo aver migrato tutto il contenuto e modificato pesantemente il tema, abbiamo automatizzato il nostro deployment con Gitlab CI, quindi un semplice push avrebbe attivato la nostra pipeline di build e avrebbe distribuito tutto su Firebase.

Perché Gitlab e non Github? Github ha il primato per ragioni storiche. Attualmente ha almeno l'80% di tutti gli sviluppatori e i progetti. Gitlab d'altra parte offre funzionalità. Ecco perché in passato abbiamo deciso di andare con Gitlab, poiché non c'era un vero sviluppo di funzionalità in Github per anni. Questo è cambiato drasticamente da quando Microsoft ha acquistato Github e Github Actions sono una pietra miliare, ma Github ha ancora molta strada da fare se vuole competere con Gitlab. Quindi per noi che ospitiamo tutti i nostri progetti su Gitlab è stata una scelta naturale usarlo anche per questo progetto.

La conclusione

Ecco dove siamo ora:

• Gatsby come CMS
• Tema commerciale
• Blog alimentato da Markdown
• Gitlab CI per le distribuzioni automatizzate
• Firebase Hosting

Siamo stati abbastanza contenti di questo risultato e il nuovo sito web ha un aspetto molto migliore!