En el passat, Psono.com funcionava amb Odoo v11. Odoo és un gran CMS però, com vam haver d’aprendre, les actualitzacions són complicades. Especialment el seu mòdul de llocs web ens va generar molts problemes durant les proves. Odoo v11 arribarà al seu final de vida a finals del 2020, així que ens vam veure forçats a trobar una solució.
Vam considerar diferents opcions: actualitzar a Odoo v13 i migrar manualment tot el contingut i les personalitzacions, contractar algú per fer la migració per nosaltres o canviar completament a un nou CMS. Hem decidit migrar completament Psono.com i continuarem utilitzant la v11 darrere un tallafoc per migrar-la més endavant (encara no ho hem decidit).
Les raons d’aquesta decisió van ser:
- Només tenim una petita quantitat de contingut que hem de migrar per a Psono.com. Principalment algunes entrades de blog.
- Una migració a Odoo v13 reproduiria el mateix problema d’aquí a dos anys quan la v13 arribi al seu EOL, potencialment amb molta més informació per migrar.
- No estàvem gaire contents amb les capacitats de personalització dels llocs web d’Odoo v11. Tot és extremadament complex amb les plantilles emmagatzemades a la base de dades.
- Els costos. Contractar algú per fer la migració ens costaria almenys 5.000 dòlars (USD), potencialment més.
- La comunitat d’Odoo era molt activa, però amb els canvis de llicència i la migració de funcionalitats i connectors a solucions de pagament posant-ho tot darrera un mur de pagament, la comunitat està morta.
- Psono.com és principalment una web estàtica. Si necessitéssim contingut dinàmic, el podríem aconseguir amb APIs.
El viatge
Un cop presa la decisió de migrar, havíem de triar quin framework utilitzar. Hi ha frameworks clàssics com hugo que ja havíem utilitzat, però la seva funcionalitat és limitada. Buscant alternatives, vam trobar algunes solucions al món node/react.
Volia escriure aquí "excel·lents solucions", però no penso que res, en l’estat actual i trencat del desenvolupament frontend, mereixi aquest títol. Trencat, pregunteu? Recordeu quan els desenvolupadors podien crear una web amb un index.html i una etiqueta script per carregar jQuery i ja podien començar a desenvolupar? Ara necessites npm o yarn, entendre package.json, scripts de webpack, frameworks moderns com angular o react (que porten el seu propi client incorporat), JSX o typescript. Funcions com el hot reloading no funcionen de forma fiable (arxiu no monitoritzat, alguns canvis requereixen reinici complet, o el hot reloading s’executa massa aviat i has d’actualitzar manualment igualment), així que acabes matant servidors de desenvolupament i esperant minuts perquè tornin a estar actius (almenys en projectes grans). (Trobo a faltar prémer F5 i tenir-ho tot allà sense problemes!). Sense comptar un nou framework o eina, com a mínim cada mig any, mentre que les eines antigues són abandonades diàriament. Podria emplenar pàgines senceres parlant del mal estat actual del desenvolupament frontend. Bé, tornem al tema.
En absència d’alternatives raonables, les millors opcions (en el moment d’escriure això) eren next.js i gatsby. Almenys això suggerien alguns articles. Tots dos són igualment populars si comparem estrelles Github o commits. L’única diferència que vam veure durant l’avaluació inicial era la necessitat d’un component servidor per next.js, mentre que gatsby genera llocs estàtics (Si us plau, no em mateu si hi ha una opció d’executar next.js sense servidor actiu! :D).
Així doncs, vam fer proves amb Gatsby i semblava correcte. El següent pas va ser buscar un tema. Gatsby és una utilitat "nova", així que tots els temes que trobàvem estaven encara en un estat molt bàsic. Trenta minuts i trenta dòlars després vam tenir un tema visualment atractiu que cobria almenys alguns dels components necessaris i vam començar a modificar-lo.
Per allotjar la web, avui dia pots triar entre múltiples proveïdors, com ara Firebase, Netlify, Cloudflare, Vercel, simple emmagatzematge de GCP Cloud o AWS Cloudfront, servidors propis, contenidors Docker sobre Kubernetes (havia d’esmentar-ho!), ... (Recordeu els vells temps on només contractaves un espai web per 5 € al mes amb PHP i una BD MySQL :D ... però això ja seria per a un altre article...)
Després de comparar-los, llegir crítiques i explorar possibles combinacions (com Cloudflare davant de Firebase), inicialment vam provar Cloudflare. Com a grans fans del seu servei, era una opció natural, però per desgràcia la seva utilitat wrangler donava problemes. Primer llençava un error constant i després no podíem autenticar-nos... Els errors inicials van desaparèixer l'endemà (potser una bash nova ho va solucionar), però el problema d’autenticació va persistir. Crec que vaig fer algun error i, després d’unes hores llegint la seva documentació i provant solucions, ho vaig deixar córrer.
Netlify era un altre candidat, però cal connectar-lo a un proveïdor git i deixar que construeixi el projecte (volíem utilitzar GitLab CI) o pujar manualment el resultat de la build. Potser tenen algun lloc on pujar el build via API, però jo no el vaig trobar. Una altra alternativa seria un repositori on pugem el build generat, però això semblava innecessàriament complex... Un altre problema per mi és el seu model de preus: cobren per membre (!!!) una quantitat considerable. Recorda que això és per a un lloc estàtic! Frases com "4× amplada de banda" em fan venir mals records de les èpoques del "fair use webhosting", quan et tancaven si usaves massa...
Com a quart servei vam provar Firebase (que té l’avantatge de ser gratuït per l'amplada de banda i peticions que necessitem) i tot va funcionar a la primera. Les seves capacitats de redirecció són una mica limitades, així que adaptar URLs antigues a d’altres més boniques va ser una mica pesat, però després d’algunes regles de redirecció tot funcionava. Els seus preus semblen raonables i només et cobren pels recursos. S’hauria d’evitar fer servir serveis extra per no quedar atrapat pel proveïdor, però només necessitàvem hosting.
També vam mirar Vercel ràpidament, però el requisit d’iniciar sessió amb un compte de Github i després donar permís de "Actuar en el meu nom" em va tirar enrere abans fins i tot de registrar-me.
El blog va ser el més difícil de migrar. Al final vam copiar tot el contingut manualment. Això no ho recomano si tens un blog gran, però el nostre només tenia quinze entrades. Gatsby suporta múltiples mecanismes, però volíem alguna cosa senzilla, que una persona sense coneixements tècnics fos capaç de crear noves entrades. Vam decidir fer-ho amb markdown i vam haver d’aprendre a indicar a Gatsby que llegeixi pàgines markdown. El funcionament ens va portar mig dia, entre el tractament d’imatges i tot plegat. Personalitzar el tema del blog i les imatges un altre mig dia.
Un cop migrat tot el contingut i modificat a fons el tema, vam automatitzar el desplegament amb Gitlab CI, així que amb una simple empenta (push) es disparava la nostra pipeline de construcció i es desplegava tot a Firebase.
Per què Gitlab i no Github? Github lidera per raons històriques. Actualment tenen almenys el 80% dels desenvolupadors i projectes. Gitlab, en canvi, ofereix funcionalitats. Per això en el passat ja vam decidir utilitzar Gitlab: no hi havia gairebé desenvolupament de noves funcions a Github durant anys. Això ha canviat radicalment des que Microsoft va comprar Github i Github Actions són un punt d’inflexió, però a Github encara li queda molt camí si vol competir amb Gitlab. Així, per nosaltres, que tenim tots els projectes a Gitlab, va ser natural utilitzar-ho també per aquest projecte.
La conclusió
I aquí estem ara:
- Gatsby com a CMS
- Tema comercial
- Blog amb markdown
- Gitlab CI per a desplegaments automàtics
- Hosting amb Firebase
Estem molt contents amb el resultat i el nou web té molt millor aspecte!
