Psono.com drivs nu av Gatsby

Tidigare drevs Psono.com av Odoo v11. Odoo är ett bra CMS, men som vi fick lära oss är uppdateringar svåra. Speciellt deras webbmodul orsakade mycket problem under våra tester. Odoo v11 kommer att nå sin livslängds slut vid årsskiftet 2020, så vi var tvungna att hitta en lösning.

Vi tänkte på olika alternativ, antingen att uppdatera till Odoo v13 och manuellt migrera allt innehåll och anpassningar själva, anlita någon att göra migreringen åt oss, eller migrera bort helt till ett nytt CMS. Vi beslutade oss för att migrera bort Psono.com helt och hållet och kommer att fortsätta använda v11 bakom en brandvägg och migrera det senare (vi har inte bestämt oss ännu).

Anledningarna bakom det beslutet var:

• Vi har bara en mycket liten mängd innehåll som vi skulle behöva migrera för Psono.com. Främst några blogginlägg.
• En migration till Odoo v13 skulle återupprepa samma problem om två år när v13 når sin EOL, potentiellt med mycket mer data att migrera.
• Vi var inte så nöjda med anpassningsmöjligheterna i Odoo v11:s webbplatser. Allt är extremt komplext med deras mallar som lagras i databasen.
• Kostnaderna. Anlita någon att göra migreringen skulle kosta oss minst 5000 USD, potentiellt mer.
• Odoo's community var mycket aktiv, men med utvecklingen under de senaste åren av licensbyten och migrering av funktionalitet och plugins till betalda lösningar och att sätta allt bakom en betalvägg är communityn död.
• Psono.com är främst en statisk webbplats med statiskt innehåll. Om vi skulle behöva dynamiskt innehåll kunde vi dra in det med API:er.

Resan

Efter att ha tagit beslutet att migrera bort måste vi besluta vilket ramverk. Det finns klassiska ramverk som t.ex. hugo som vi använde men deras funktionalitet är begränsad. När vi letade efter alternativ hittade vi några lösningar i node / react-världen.

Jag skulle vilja skriva här "utmärkta lösningar", men jag tror inte att något i det nuvarande trasiga tillståndet av frontend-utveckling förtjänar den titeln. Trasigt frågar du? Kommer du ihåg tiderna då utvecklare kunde skapa en webbplats med en index.html och script tag för att ladda jquery och kunde börja utveckla webbplatser? Nu behöver du npm eller yarn, du måste förstå package.json, webpack-skript, moderna ramverk som angular eller react som alla har sin egen klient med sig. JSX eller typescript. Funktioner som hot reloading fungerar inte pålitligt (filen övervakas inte, vissa ändringar kräver en full omstart, eller hot reloading triggas för tidigt så du måste ändå manuellt uppdatera) så du slutar med att döda utvecklingsservrar och väntar minuter för att de ska startas om (åtminstone i större projekt). (Jag saknar att trycka på F5 och sedan bara ha allt där utan några problem!). För att inte nämna ett nytt ramverk eller verktyg minst varje halvår där gamla verktyg överges dagligen. Jag skulle lätt kunna fylla sidor med att klaga på det nuvarande tillståndet av frontend-utveckling. Hur som helst, tillbaka till själva ämnet.

I avsaknad av förnuftiga alternativ var de bästa alternativen (vid tidpunkten för mitt skrivande) next.js och gatsby. Åtminstone var det så vissa artiklar marknadsförde dem. Båda är lika populära om du jämför Github stjärnor eller commits. Den enda skillnaden som vi kunde se under en inledande utvärdering är kravet på en serverkomponent för next.js, medan gatsby skapar statiska webbplatser (snälla döda mig inte nu om det finns ett alternativ att köra next.js utan aktiv server! :D)

Så vi lekte lite med Gatsby och det såg bra ut. Som ett nästa steg gick vi vidare och letade efter ett tema. Gatsby är ett "nytt" verktyg, så alla teman som vi kunde hitta var fortfarande i ett mycket grundläggande tillstånd. Trettio minuter och trettio dollar senare hade vi ett visuellt tilltalande tema som täckte åtminstone några av de nödvändiga komponenterna och vi började modda det.

Som hosting-alternativ kan du numera välja mellan flera leverantörer, nämligen Firebase, netlify, Cloudflare, Vercel, enkel GCP Cloud Storage eller AWS Cloudfront, egna servrar, docker-kontainrar som körs på Kubernetes (jag var tvungen att nämna det!), ... (Kom ihåg de gamla dagarna då du bara skulle hyra en webbplats för $5 i månaden med PHP och en MySQL-databas :D ... men det är för en annan artikel...)

Efter att ha jämfört dem, läst några recensioner och kollat in möjliga kombinationer (som Cloudflare framför Firebase) provade vi initialt Cloudflare. Som stora fans av deras tjänst var det ett naturligt val, men tyvärr hade deras wrangler verktyg problem. Först kastade det alltid ett fel och sedan kunde vi inte autentisera ... De initiala felen var borta nästa dag (kanske gjorde en ny bash tricket), men autentiseringsproblemet kvarstod. Jag tror att jag måste ha gjort något fel och gav upp efter ett par timmars läsning av deras dokumentation och provade olika lösningar.

Netlify var en annan kandidat, men du måste antingen ansluta det till en git-leverantör och låta dem bygga det (vi ville använda GitLab CI) eller manuellt ladda upp byggutgången. Kanske har de ett alternativ någonstans att ladda upp byggutgången genom API, men jag kunde inte hitta något. Ett alternativ skulle ha varit ett repo där vi faktiskt pushar byggutgången, men det verkade onödigt komplext ... Ett annat problem för mig är deras prismodell. De tar betalt per medlem (!!!) en ganska betydande summa. Tänk på att detta är för en statisk webbplats. Uttalanden som "4× bandbredd" utlöser dåliga minnen av "rättvis användning webhosting"-tider där folk skulle sparka ut dig om du använder för mycket...

Som fjärde tjänst provade vi Firebase (som en fördel är gratis för vår målbandbredd och förfrågningar) och allt fungerade direkt. Deras omdirigeringsmöjligheter är lite begränsade, så att mappa gamla URL:er till vackrare blev lite tråkigt, men ett par omdirigeringsregler senare fungerade allt. Deras prissättning verkar rimlig och du debiteras för serverresurser. Man bör hålla sig borta från alla deras extratjänster för att undvika leverantörsinlåsning, men vi behövde bara hosting.

Vi kollade också kortfattat på Vercel, men deras krav på att logga in med ett Github-konto och sedan en tillstånd med "Agera på mina vägnar" stötte bort mig innan jag ens registrerade mig.

Bloggen var den svåraste att migrera. Vi slutade med att kopiera över allt innehåll manuellt. Det är inget du borde göra med en större blogg, men vår blogg hade bara femton inlägg. Gatsby stöder flera mekanismer, men vi ville ha något enkelt som någon utan teknisk bakgrund skulle kunna skapa nya blogginlägg med. Vi beslutade att gå med markdown och därför var vi tvungna att lära oss hur man instruerar Gatsby att läsa markdown-sidor. Den faktiska mekanismen tog oss cirka en halv dag med all bildhantering. Ett trevligt bloggtema och bilder ytterligare en halv dag.

Efter att ha migrerat allt innehåll och kraftigt moddat temat automatiserade vi vår distribution med GitLab CI, så en enkel push skulle utlösa vår byggpipeline och distribuera allt till Firebase.

Varför GitLab och inte Github? Github har ledningen av historiska skäl. De har för närvarande åtminstone 80% av alla utvecklare och projekt. GitLab å andra sidan levererar funktioner. Det är därför vi tidigare bestämde oss för att gå med GitLab, eftersom det inte fanns någon verklig funktionsutveckling på Github på flera år. Detta har nu dramatiskt förändrats sedan Microsoft köpte Github och Github Actions är en milstolpe, men Github har fortfarande en lång väg att gå om de vill konkurrera med GitLab. Så för oss som hostar alla sina projekt på GitLab var det ett naturligt val att använda det för detta projekt också.

Slutsatsen

Och där är vi nu:

• Gatsby som CMS
• Kommersiellt tema
• Blogg som drivs med markdown
• GitLab CI för automatiserade distributioner
• Firebase Hosting

Vi var ganska nöjda med detta resultat och den nya webbplatsen ser mycket bättre ut!