In het verleden werd Psono.com aangedreven door Odoo v11. Odoo is een geweldig CMS, maar zoals we hebben moeten leren, zijn updates moeilijk. Vooral hun website-module veroorzaakte veel problemen tijdens onze tests. Odoo v11 zal eind 2020 het einde van zijn levensduur bereiken, dus we waren gedwongen om een oplossing te vinden.
We dachten aan verschillende opties: ofwel upgraden naar Odoo v13 en handmatig alle inhoud en aanpassingen zelf migreren, iemand inhuren om de migratie voor ons te doen, of compleet migreren naar een nieuw CMS. We hebben besloten om Psono.com volledig te migreren en zullen v11 blijven gebruiken achter een firewall en later migreren (we hebben nog geen beslissing genomen).
De redenen achter die beslissing waren:
- We hebben slechts een zeer kleine hoeveelheid inhoud die we zouden moeten migreren voor Psono.com. Voornamelijk enkele blogposts.
- Een migratie naar Odoo v13 zou hetzelfde probleem reproduceren over twee jaar wanneer v13 het einde van zijn levensduur bereikt, mogelijk met veel meer gegevens om te migreren.
- We waren niet erg blij met de aanpassingsmogelijkheden van Odoo v11-websites. Alles is extreem complex met hun templates die in de database worden opgeslagen.
- De kosten. Iemand inhuren om de migratie uit te voeren zou ons minstens 5000 USD kosten, mogelijk meer.
- De Odoo-gemeenschap was erg actief, maar door de ontwikkelingen in de afgelopen jaren van licentie wisselingen en het migreren van functionaliteit en plug-ins naar betaalde oplossingen en het plaatsen van alles achter een betaalmuur is de gemeenschap dood.
- Psono.com is voornamelijk een statische website met statische inhoud. Als we dynamische inhoud nodig zouden hebben, konden we deze via API's inladen.
De reis
Na de beslissing om te migreren moesten we beslissen welk framework we zouden gebruiken. Er zijn klassieke frameworks zoals bijvoorbeeld Hugo die we gebruikten, maar hun functionaliteit is beperkt. Terwijl we naar alternatieven zochten, vonden we enkele oplossingen in de Node/React-wereld.
Ik wilde hier "uitstekende oplossingen" schrijven, maar ik denk niet dat iets in de huidige gebroken staat van frontend ontwikkeling die titel verdient. Gebroken, vraag je? Herinner je je de tijden dat ontwikkelaars een website konden maken met een index.html en een script-tag om jQuery te laden en konden beginnen met het ontwikkelen van websites? Nu heb je npm of yarn nodig, moet je package.json, webpack-scripts begrijpen, moderne frameworks zoals Angular of React die allemaal hun eigen client met zich meebrengen. JSX of TypeScript. Features zoals hot reloading werken niet betrouwbaar (bestand niet gecontroleerd, sommige wijzigingen vereisen een volledige herstart, of hot reloading wordt te vroeg geactiveerd zodat je handmatig moet verversen), dus je eindigt met het doden van ontwikkelingsservers en wacht minuten totdat ze opnieuw zijn geladen (ten minste bij grotere projecten). (Ik mis het indrukken van F5 en dan gewoon alles zonder problemen!). Om nog maar te zwijgen van een nieuw framework of tool minstens om de zes maanden waar oude tools dagelijks worden verlaten. Ik zou gemakkelijk pagina's kunnen vullen met mijn geklaag over de huidige staat van frontend ontwikkeling. Terug naar het eigenlijke onderwerp.
Bij afwezigheid van verstandige alternatieven zouden de beste opties (op het moment dat ik dit schrijf) next.js en Gatsby zijn. Ten minste, zo werden ze gepromoot in enkele artikelen. Beide zijn even populair als je kijkt naar Github-sterren of commits. Het enige verschil dat we konden ontdekken tijdens een eerste evaluatie is de vereiste van een servercomponent voor next.js, terwijl gatsby statische sites creëert (alsjeblieft, dood me nu niet als er een optie is om next.js zonder actieve server te draaien! :D).
Dus we speelden wat met Gatsby en het zag er goed uit. Als volgende stap gingen we op zoek naar een thema. Gatsby is een "nieuwe" utility, dus alle thema's die we konden vinden waren nog in een zeer basisstadium. Dertig minuten en dertig dollar later hadden we een visueel aantrekkelijk thema dat ten minste een deel van de vereiste componenten had en we begonnen het aan te passen.
Als hostingoptie kun je tegenwoordig kiezen tussen meerdere providers, namelijk Firebase, Netlify, Cloudflare, Vercel, eenvoudige GCP Cloud-opslag of AWS Cloudfront, eigen servers, Docker-containers die op Kubernetes draaien (ik moest het noemen!), ... (Herinner je je de oude tijden waarin je gewoon een webruimte zou huren voor $5 per maand met PHP en een MySQL-DB :D ... maar dat is voor een ander artikel...).
Na het vergelijken ervan, het lezen van enkele recensies en het controleren van mogelijke combinaties (zoals Cloudflare voor Firebase) probeerden we in eerste instantie Cloudflare. Als grote fans van hun service was dit een natuurlijke keuze, maar helaas had hun Wrangler utility problemen. Eerst gaf het altijd een error en toen konden we niet authentiseren ... De aanvankelijke fouten verdwenen de volgende dag (misschien hielp een nieuwe bash), maar het authenticatieprobleem bleef bestaan. Ik geloof dat ik een fout heb gemaakt en gaf het op na een paar uur het lezen van hun documentatie en het proberen van verschillende oplossingen.
Netlify was een andere kandidaat, maar je moet het verbinden met een git-provider en hen het laten bouwen (wij wilden GitLab CI gebruiken) of het handmatig uploaden van de build-output. Misschien hebben ze ergens een optie om de build-output via een API te uploaden, maar ik kon er geen vinden. Een alternatief zou zijn een repo waar we de build-output daadwerkelijk naar pushen, maar dat leek onnodig complex... Een ander probleem voor mij is hun prijsmodel. Ze rekenen per lid (!!!) een behoorlijk bedrag. Houd in gedachten dat dit voor een statische website is. Uitspraken zoals "4× bandbreedte" roepen slechte herinneringen op aan "fair use webhosting"-tijden waar mensen je zouden kicken als je te veel gebruikt...
Als vierde service probeerden we Firebase (wat als voordeel gratis is voor onze doel-bandbreedte en verzoeken) en alles werkte out-of-the-box. Hun omleidingsmogelijkheden zijn enigszins beperkt, dus het mappen van oude URL's naar mooiere werd een tikkeltje vervelend, maar een paar omleidingsregels later werkte alles. Hun prijs lijkt redelijk en je wordt per serverbron belast. Men moet zich verre houden van al hun extra services om vendor lock-in te voorkomen, maar we hadden alleen hosting nodig.
We hebben ook kort Vercel gecontroleerd, maar hun vereiste om in te loggen met een Github-account en vervolgens een toestemming met "Handelen namens mij" deed me afhaken.
De blog was het moeilijkst te migreren. We eindigden met het handmatig kopiëren van alle inhoud. Dit is niets wat je moet doen met een grotere blog, maar onze blog had maar vijftien berichten. Gatsby ondersteunt meerdere mechanismen, maar we wilden iets eenvoudigs waarmee iemand zonder technische achtergrond nieuwe blogposts zou kunnen maken. We kozen voor markdown en moesten dus leren hoe we Gatsby instructie konden geven om markdown-pagina's in te lezen. Het eigenlijke mechanisme kostte ons ongeveer een halve dag met alle beeldverwerking. Een mooi blogpost-thema en afbeeldingen namen nog een halve dag in beslag.
Na het migreren van alle inhoud en het verder zwaar aanpassen van het thema, hebben we onze deployment geautomatiseerd met GitLab CI, zodat een eenvoudige push onze build-pipeline zou triggeren en alles zou uitrollen naar Firebase.
Waarom GitLab en niet GitHub? GitHub heeft een voorsprong om historische redenen. Ze hebben momenteel op zijn minst 80% van alle ontwikkelaars en projecten. GitLab daarentegen levert features. Daarom hebben we in het verleden besloten om met GitLab te gaan, omdat er jarenlang geen echte featureontwikkeling was bij GitHub. Dit is nu dramatisch veranderd sinds Microsoft GitHub heeft gekocht en GitHub Actions een mijlpaal zijn, maar GitHub heeft nog een lange weg te gaan als ze willen concurreren met GitLab. Dus voor ons, die al hun projecten op GitLab hosten, was het een natuurlijke keuze om het ook voor dit project te gebruiken.
De conclusie
En hier zijn we nu:
- Gatsby als CMS
- Commercieel thema
- Markdown-aangedreven blog
- GitLab CI voor geautomatiseerde deployments
- Firebase Hosting
We waren behoorlijk tevreden met dit resultaat en de nieuwe website ziet er veel beter uit!
