Tidligere ble Psono.com drevet av Odoo v11. Odoo er et flott CMS, men som vi har lært, er oppdateringer vanskelige. Spesielt deres nettsidemodul forårsaket mye trøbbel under vår testing. Odoo v11 vil nå slutten av sin levetid ved slutten av 2020, så vi ble tvunget til å finne en løsning.
Vi vurderte forskjellige alternativer, enten ved å oppgradere til Odoo v13 og manuelt migrere alt innhold og tilpasninger selv, ansette noen til å gjøre migreringen for oss, eller migrere helt til et nytt CMS. Vi har besluttet å migrere Psono.com fullstendig bort og vil fortsette å bruke v11 bak en brannmur og migrere senere (vi har ikke bestemt oss ennå).
Etter å ha besluttet å migrere bort, måtte vi bestemme hvilket rammeverk vi skulle bruke. Det finnes klassiske rammeverk som f.eks. hugo som vi har brukt, men deres funksjonalitet er begrenset. Mens vi lette etter alternativer, fant vi noen løsninger i node / react verdenen.
Jeg ønsket å skrive her "utmerkede løsninger", men jeg tror ikke at noe i dagens ødelagte tilstand av frontend utvikling fortjener den tittelen. Ødelagt spør du? Husker du tiden da utviklere kunne lage et nettsted med en index.html og script tag for å laste jquery og kunne begynne å utvikle nettsteder? Nå trenger du npm eller yarn, du må forstå package.json, webpack-skript, moderne rammeverk som angular eller react som alle bringer sin egen klient med seg. JSX eller typescript. Funksjoner som hot reloading fungerer ikke pålitelig (filen overvåkes ikke, noen modifikasjoner trenger en full restart, eller hot reloading trigges for tidlig slik at du må oppdatere manuelt uansett) så du ender opp med å drepe utviklingsservere og vente minutter på at de skal være tilbake (i hvert fall i større prosjekter). (Jeg savner å trykke F5 og så bare ha alt der uten noen problemer!). For ikke å nevne et nytt rammeverk eller verktøy minst hver halvår hvor gamle verktøy forlates daglig. Jeg kunne lett fylle sider med å klage over dagens tilstand av frontend-utvikling. Uansett, tilbake til selve emnet.
I fravær av fornuftige alternativer, var de beste alternativene (på tidspunktet for skrivingen) next.js og gatsby. I hvert fall slik noen artikler promoterte dem. Begge er like populære hvis man sammenligner Github-stjerner eller commits. Den eneste forskjellen vi kunne merke under en initial evaluering er kravet om en serverkomponent for next.js, mens gatsby lager statiske nettsteder (Vennligst drep meg ikke nå hvis det er et alternativ å kjøre next.js uten aktiv server! :D)
Så vi lekte litt med Gatsby og det så bra ut. Som neste skritt gikk vi videre og lette etter et tema. Gatsby er et "nytt" verktøy, så alle temaene som vi kunne finne, var fortsatt i en veldig grunnleggende tilstand. Tretti minutter og 30 dollar senere hadde vi et visuelt tiltalende tema som dekket i det minste noen av de nødvendige komponentene, og vi begynte å endre det.
Som hostingalternativ kan du nå velge mellom flere leverandører, nemlig Firebase, netlify, Cloudflare, Vercel, enkel GCP cloud-lagring eller AWS Cloudfront, egne servere, dockercontainere som kjører på Kubernetes (jeg måtte nevne det!), ... (Husker du den gamle tiden hvor du ville leie et webområde for $5 i måneden med PHP og en MySQL DB :D ... men det er for en annen artikkel...)
Etter å ha sammenlignet dem, lest noen anmeldelser og sjekket mulige kombinasjoner (som Cloudflare foran Firebase) prøvde vi opprinnelig ut Cloudflare. Som store fans av tjenesten deres var det et naturlig valg, men dessverre hadde deres wrangler verktøy problemer. Først kastet den alltid en feil, og så var vi ikke i stand til å autentisere ... De første feilene var borte dagen etter (kanskje en ny bash gjorde trikset), men autentiseringsproblemet vedvarte. Jeg tror at jeg må ha gjort en feil og ga opp etter noen timers lesing av deres dokumentasjon og prøving av forskjellige løsninger.
Netlify var en annen kandidat, men du må enten koble den til en git-leverandør og la dem bygge det (vi ønsket å bruke GitLab CI) eller manuelt laste opp byggeutdataene. Kanskje de har et alternativ et sted å laste opp byggeutdataene gjennom en API, men jeg kunne ikke finne en. Et alternativ ville ha vært et depot hvor vi faktisk skyver byggeutdataene, men det virket unødvendig komplekst ... Et annet problem for meg er deres prismodell. De tar betalt per medlem (!!!) en ganske betydelig sum. Husk at dette er for et statisk nettsted. Utsagn som "4× båndbredde" trigger dårlige minner om "rettferdig bruk webhosting"-tider hvor folk ville sparke deg hvis du brukte for mye...
Som fjerde tjeneste prøvde vi Firebase (som som en fordel er gratis for vår målbandbredde og forespørsler) og alt fungerte ut av boksen. Deres omdirigeringsmuligheter er litt begrenset, så det ble litt kjedelig å mappe gamle URL-er til mer vakre, men etter et par omdirigeringsregler fungerte alt. Deres prising virker rimelig og du blir belastet for serverressurser. Man bør holde seg unna alle deres ekstra tjenester for å unngå leverandørlåsing, men vi trengte bare hosting.
Vi sjekket også kort vercel, men deres krav om å logge inn med en Github-konto og deretter en tillatelse med "Handle på mine vegne" kastet meg av selv før jeg registrerte meg.
Bloggen var den vanskeligste å migrere. Vi endte opp med å kopiere innholdet manuelt. Det er ingenting du bør gjøre med en større blogg, men bloggen vår hadde bare femten innlegg. Gatsby støtter flere mekanismer, men vi ønsket noe enkelt som noen uten teknisk bakgrunn kunne opprette nye blogginnlegg med. Vi bestemte oss for å gå med markdown, og som sådan måtte vi lære hvordan vi skulle instruere gatsby til å lese markdown-sider. Den faktiske mekanismen tok oss omtrent en halv dag med all bildebehandling. Et fint blogginnleggstema og bilder tok en annen halv dag.
Etter å ha migrert alt innhold og endret temaet kraftig, automatiserte vi vår distribusjon med Gitlab CI, slik at en enkel push ville utløse vår byggelinje og distribuere alt til Firebase.
Hvorfor Gitlab og ikke Github? Github har ledelsen av historiske grunner. De har for øyeblikket minst 80% av alle utviklere og prosjekter. Gitlab på sin side leverer funksjoner. Derfor valgte vi for noen år siden å gå med Gitlab, da det ikke var noen reell funksjonsutvikling i Github i årevis. Dette har nå endret seg dramatisk siden Microsoft kjøpte Github og Github Actions er en milepæl, men Github har fortsatt en lang vei å gå hvis de vil konkurrere med Gitlab. Så for oss som har alle prosjektene sine på Gitlab, var det et naturlig valg å bruke det for dette prosjektet også.
Og det er der vi er nå:
Vi var ganske fornøyde med dette utfallet og den nye nettsiden ser mye bedre ut!