Tidligere var Psono.com drevet af Odoo v11. Odoo er et fantastisk CMS, men som vi måtte lære, er opdateringer svære. Især deres hjemmeside-modul gav mange problemer under vores test. Odoo v11 når enden af livet ved udgangen af 2020, så vi blev tvunget til at finde en løsning.
Vi overvejede forskellige muligheder, enten opdatering til Odoo v13 og manuel migrering af alt indhold og tilpasninger selv, at hyre nogen til at gøre migreringen for os, eller at migrere fuldstændigt til et nyt CMS. Vi har besluttet at migrere Psono.com fuldstændigt og vil fortsætte med at bruge v11 bag en firewall og migrere senere (vi har endnu ikke besluttet hvornår).
Årsagerne bag denne beslutning var:
- Vi har kun en meget lille mængde indhold, som vi skulle migrere for Psono.com. Hovedsageligt nogle blogindlæg.
- En migrering til Odoo v13 ville reproducere det samme problem om to år, når v13 når sin EOL, potentielt med meget mere data at migrere.
- Vi var ikke så tilfredse med tilpasningsmulighederne i Odoo v11's hjemmesider. Alt var ekstremt komplekst med deres skabeloner, der blev gemt i databasen.
- Omkostningerne. At hyre nogen til at gøre migreringen ville koste os mindst 5000 USD, potentielt mere.
- Odoo's community var meget aktiv, men med udviklingen i de sidste år med licensændringer og migration af funktionalitet og plugins til betalte løsninger og placering af alt bag en betalingsmur, er communityet dødt.
- Psono.com er hovedsageligt en statisk hjemmeside med statisk indhold. Hvis vi havde brug for dynamisk indhold, kunne vi trække det ind med API'er.
Rejsen
Efter at have besluttet at migrere væk, skulle vi beslutte, hvilken ramme vi skulle bruge. Der er klassiske rammer som f.eks. Hugo, som vi brugte, men deres funktionalitet er begrænset. Mens vi ledte efter alternativer, fandt vi nogle løsninger i node / react-verdenen.
Jeg ville skrive her "fremragende løsninger", men jeg synes ikke, at noget i den nuværende ødelagte frontendudvikling fortjener den titel. Ødelagt spørger du? Husk tiderne, hvor udviklere kunne oprette en hjemmeside med en index.html og et script-tag til at indlæse jQuery og kunne begynde at udvikle hjemmesider? Nu har du brug for npm eller yarn, du skal forstå package.json, webpack-scripts, moderne rammer som angular eller react, som alle bringer deres egen klient med sig. JSX eller TypeScript. Funktioner som hot reloading fungerer ikke pålideligt (fil overvåges ikke, nogle ændringer kræver en fuld genstart, eller hot reloading udløses for tidligt, så du alligevel skal opdatere manuelt), så du ender med at dræbe udviklingsservere og vente minutter på, at de kommer op igen (i det mindste i større projekter). (Jeg savner at trykke på F5 og så bare have alt der uden problemer!). For ikke at nævne et nyt framework eller værktøj mindst hver halve år, hvor gamle værktøjer opgives dagligt. Jeg kunne nemt fylde sider med mig, der brokker mig over den nuværende tilstand af frontendudvikling. Anyway, tilbage til det faktiske emne.
I mangel af fornuftige alternativer var de bedste muligheder (på tidspunktet for at jeg skrev dette) next.js og gatsby. I det mindste er det, hvordan nogle artikler promoverede dem. Begge er lige populære, hvis du sammenligner Github-stjerner eller commits. Den eneste forskel, som vi kunne se under en indledende evaluering, er kravet om en serverkomponent for next.js, mens gatsby opretter statiske sider (Vær venlig ikke at dræbe mig nu, hvis der er en mulighed for at køre next.js uden aktiv server! :D)
Så vi legede lidt med Gatsby og det så fint ud. Som et næste skridt gik vi videre og ledte efter et tema. Gatsby er en "ny" utility, så alle temaer, vi kunne finde, var stadig i en meget grundlæggende tilstand. Tredive minutter og tredive bucks senere havde vi et visuelt tiltalende tema, der dækkede i det mindste nogle af de nødvendige komponenter, og vi begyndte at tilpasse det.
Som hosting muligheden kan du i dag vælge mellem flere udbydere, nemlig Firebase, netlify, Cloudflare, Vercel, simple GCP Cloud storage eller AWS Cloudfront, egne servere, docker containere kørende på Kubernetes (jeg måtte nævne det!), ... (Husk de gamle tider, hvor du bare lejede et webspace for $5 om måneden med PHP og en MySQL DB :D ... men det er til en anden artikel...)
Efter at have sammenlignet dem, læst nogle anmeldelser og tjekket mulige kombinationer (som Cloudflare foran Firebase), prøvede vi indledningsvis Cloudflare. Som store fans af deres service var det et naturligt valg, men desværre havde deres wrangler utility problemer. Først kastede det altid en fejl, og derefter kunne vi ikke autentificere ... de første fejl forsvandt næste dag (måske gjorde en ny bash tricket), men autentificeringsproblemet bestod. Jeg tror, at jeg må have lavet en fejl og gav op efter et par timer med at læse deres dokumentation og prøve forskellige løsninger.
Netlify var en anden kandidat, men du enten nødt til at forbinde det til en git udbyder og lade dem bygge det (vi ville bruge GitLab CI) eller manuelt uploade build-udgangen. Måske har de en mulighed et sted for at uploade build-udgangen gennem API, men jeg kunne ikke finde en. Et alternativ ville have været et repo, hvor vi faktisk push build-udgangen, men det virkede unødvendigt komplekst... Et andet problem for mig er deres prismodel. De opkræver pr. medlem (!!!) et ret betydeligt beløb. Husk, at dette er til en statisk hjemmeside. Udtalelser som "4× båndbredde" udløser dårlige minder om "fair use webhosting"-tider, hvor folk ville sparke dig ud, hvis du brugte for meget...
Som fjerde service prøvede vi Firebase (som som en fordel er gratis for vores mål båndbredde og anmodninger) og alt fungerede ud af boksen. Deres omdirigeringsevner er lidt begrænsede, så mapping af gamle URL'er til smukkere var lidt kedeligt, men et par omdirigeringsregler senere fungerede alt. Deres prissætning virker rimelig, og du bliver opkrævet for serverressourcer. Man bør holde sig væk fra alle deres ekstra tjenester for at undgå vendor lock-in, men vi havde kun brug for hosting.
Vi tjekkede også kort vercel, men deres krav om at logge ind med en Github konto og derefter en tilladelse med "Act on my behalf" slog mig fra selv før tilmelding.
Bloggen var den sværeste at migrere. Vi endte med at kopiere alt indhold manuelt. Det er ikke noget, du bør gøre med en større blog, men vores blog havde kun femten indlæg. Gatsby understøtter flere mekanismer, men vi ønskede noget simpelt, som nogen uden teknisk baggrund ville være i stand til at oprette nye blogindlæg. Vi besluttede at gå med markdown og skulle derfor lære, hvordan man instruerer gatsby til at læse markdown sider. Den faktiske mekanisme tog os omkring en halv dag med al billedhåndtering. Et pænt blogindlægstema og billeder tog en anden halv dag.
Efter at have migreret alt indhold og yderligere tilpasset temaet kraftigt automatiserede vi vores deployment med Gitlab CI, så en simpel push ville udløse vores build pipeline og implementere alt til Firebase.
Hvorfor Gitlab og ikke Github? Github har føringen af historiske årsager. De har i øjeblikket mindst 80% af alle udviklere og projekter. Gitlab leverer på den anden side funktioner. Derfor besluttede vi tidligere at gå med Gitlab, da der i årevis ikke var nogen reel udvikling i Github. Dette har nu dramatisk ændret sig, siden Microsoft købte Github, og Github Actions er en milepæl, men Github har stadig en lang vej at gå, hvis de vil konkurrere med Gitlab. Så for os, der hoster alle deres projekter på Gitlab, var det et naturligt valg at bruge det til dette projekt også.
Konklusionen
Og det er her, vi er nu:
- Gatsby som CMS
- Kommercielt tema
- Markdown drevet blog
- Gitlab CI til automatiserede deployment
- Firebase Hosting
Vi var ret tilfredse med dette resultat, og den nye hjemmeside ser meget bedre ud!
