Psono.com toimii nyt Gatsbyn avulla

Aiemmin Psono.com toimi Odoo v11:n avulla. Odoo on erinomainen CMS, mutta kuten jouduimme oppimaan, päivitykset ovat hankalia. Erityisesti heidän verkkosivumoduulinsa aiheutti paljon ongelmia testauksen aikana. Odoo v11:n elinkaari päättyy vuoden 2020 lopussa, joten meidän oli pakko löytää ratkaisu.

Pohdimme erilaisia vaihtoehtoja: joko päivittää Odoo v13:een ja siirtää kaikki sisältö ja räätälöinnit itse, palkata joku tekemään siirron puolestamme tai siirtyä kokonaan uuteen CMS:ään. Päätimme siirtää Psono.comin kokonaan pois Odoosta ja jatkaa v11:n käyttöä palomuurin takana sekä siirtää se myöhemmin (emme ole vielä päättäneet).

Tähän päätökseen johtaneet syyt:

• Meillä on hyvin vähän sisältöä, joka pitäisi siirtää Psono.comiin. Lähinnä joitain blogipostauksia.
• Siirto Odoo v13:een toistaisi saman ongelman kahden vuoden päästä, kun v13:n elinkaari päättyy, mahdollisesti paljon suuremmalla datamäärällä.
• Emme olleet kovin tyytyväisiä Odoo v11:n verkkosivujen räätälöintimahdollisuuksiin. Kaikki on hyvin monimutkaista, kun heidän pohjansa tallennetaan tietokantaan.
• Kustannukset. Siirron teettäminen maksaisi meille vähintään 5000 USD, mahdollisesti enemmän.
• Odoon yhteisö oli aiemmin hyvin aktiivinen, mutta viime vuosien lisenssivaihdokset, toimintojen ja liitännäisten siirtäminen maksullisiksi sekä kaiken laittaminen maksullisen seinän taakse ovat tappaneet yhteisön.
• Psono.com on pääosin staattinen sivusto, jossa on staattista sisältöä. Jos tarvitsemme dynaamista sisältöä, voimme hakea sen rajapinnoilla.

Matka

Kun päätös siirtyä pois Odoosta oli tehty, piti valita sopiva kehys. On olemassa perinteisiä runkoja kuten esim. hugo, jota olemme aiemmin käyttäneet, mutta niiden ominaisuudet ovat rajallisia. Etsiessämme vaihtoehtoja löysimme ratkaisuja node / react -maailmasta.

Halusin kirjoittaa tähän "erinomaisia ratkaisuja", mutta en usko, että mikään nykyaikaisen frontend-kehityksen rikkinäisessä tilassa ansaitsee tuota nimitystä. Rikkinäinen, kysyt? Muistatko ajan, jolloin kehittäjät pystyivät tekemään sivun index.html:llä ja script-tagilla lataamaan jqueryn ja aloittamaan kehittämisen? Nyt tarvitset npm:n tai yarnin, sinun pitää ymmärtää package.json, webpackin skriptit, modernit framewot kuten Angular tai React, joilla kaikilla on omat clientit mukanaan. JSX tai typescript. Ominaisuudet kuten hot reloading eivät toimi luotettavasti (tiedostoa ei seurata, jotkin muutokset vaativat koko restartin, tai hot reload käynnistyy liian aikaisin ja joutuu joka tapauksessa päivittämään käsin) eli lopulta päätyy tappamaan kehityspalvelimia ja odottamaan minuuttikaupalla, että ne palaavat (ainakin isommissa projekteissa). (Kaipaan aikaa kun painoi F5 ja kaikki oli heti paikalla ongelmitta!) Ja mainitsematta jää, että uusia kehyksiä tai työkaluja tulee vähintään puolen vuoden välein, kun vanhoja hylätään päivittäin. Voisin helposti täyttää sivuja valittamalla frontend-kehityksen nykytilasta. Mutta takaisin aiheeseen.

Kun järkeviä vaihtoehtoja ei ollut, parhaat valinnat (kirjoitushetkellä) olivat next.js ja gatsby. Ainakin niin muutamat artikkelit suosittelivat niitä. Molemmat ovat yhtä suosittuja jos vertaa Githubin tähtiä tai committeja. Ainoa selkeä ero, jonka huomasimme alustavassa vertailussa, oli se, että next.js vaatii palvelinkomponentin, kun taas gatsby tuottaa täysin staattisia sivuja (Älkää nyt tappako jos next.js:llä on joku tapa toimia myös ilman aktiivista palvelinta! :D)

Kokeilimme Gatsbya ja se vaikutti hyvältä. Seuraavaksi etsimme teemaa. Gatsby on "uusi" väline, joten kaikki löytämämme teemat olivat vielä aika alkeellisia. Kolmenkymmenen minuutin ja kolmenkymmenen taalan jälkeen meillä oli visuaalisesti miellyttävä teema, jossa oli ainakin osa tarvitsemistamme komponenteista ja aloimme muokata sitä.

Nykyään voit valita hosting-ratkaisuksi monia tarjoajia, esimerkiksi Firebase, netlify, Cloudflare, Vercel, GCP Cloud Storage tai AWS Cloudfront, omat palvelimet, docker-kontit Kubernetesin päällä (pakko mainita!), ... (Muistatko vanhat ajat, kun vuokrasit web-tilan viidellä eurolla kuukaudessa, mukana PHP ja MySQL :D ... mutta se on jo toinen tarina...)

Vertailun, muutamien arvioiden lukemisen ja mahdollisten yhdistelmien (esim. Cloudflare Firenbasen edessä) tarkastelun jälkeen kokeilimme ensin Cloudflarea. Olemme heidän palvelujensa suuria faneja, joten se tuntui luonnolliselta valinnalta, mutta valitettavasti heidän wrangler-työkalunsa aiheutti ongelmia. Ensin se antoi jatkuvasti virheitä eikä autentikointi onnistunut... Alkuperäiset virheet katosivat seuraavana päivänä (ehkä uusi bash auttoi), mutta autentikointiongelma jatkui. Uskon tehneeni jonkin virheen ja luovuin parin tunnin dokumentaation lukemisen ja eri ratkaisujen kokeilun jälkeen.

Netlify oli toinen vaihtoehto, mutta sinun pitää joko yhdistää se git-palveluun, jolloin he rakentavat puolestasi (itse halusimme käyttää Gitlab CI:tä) tai ladata rakennettu sivu manuaalisesti. Ehkä heillä on mahdollisuus ladata sivu API:n kautta, mutta en löytänyt sitä. Vaihtoehtona olisi ollut reposti, johon työntää lopputulos, mutta se tuntui tarpeettoman monimutkaiselta... Toinen ongelma oli heidän hinnoittelumallinsa. He veloittavat jäsenkohtaisesti (!!) melkoisen summan. Muista, että kyseessä on staattinen sivusto. Lauseet kuten "4× kaistanleveys" tuovat mieleen huonot muistot "fair use" -webhotelliajoista, jolloin sivuston käyttö katkaistiin jos käyttö ylitti rajan...

Kolmantena palveluna kokeilimme Firebasea (joka meidän tarpeille on ilmainen), ja kaikki toimi suoraan laatikosta. Heidän uudelleenohjausmahdollisuutensa ovat vähän rajalliset, joten vanhojen URL-osoitteiden mappaaminen kauniimpiin oli vähän työlästä, mutta parin redirect-säännön jälkeen kaikki toimi kuten piti. Hinnoittelu vaikuttaa kohtuulliselta ja maksat palvelinresurssien mukaan. Kaikista heidän lisäpalveluistaan kannattaa pysyä erossa, jottei jää toimittajaloukkuun, mutta tarvitsimme vain web-hosting-palvelun.

Katsastimme myös nopeasti Vercelin, mutta heidän vaatimuksensa kirjautua Github-tunnuksella ja antaa lupa "Act on my behalf" pelotti jo ennen rekisteröintiä.

Blogi oli hankalin osa siirtää. Päädyimme kopioimaan kaiken sisällön käsin. Tämä ei tietenkään kannata isommassa blogissa, mutta meidän blogissa oli vain viisitoista kirjoitusta. Gatsby tukee monia tapoja, mutta halusimme yksinkertaisen ratkaisun, jossa uusi blogipostaus onnistuu myös teknisestä taustasta riippumatta. Päädyimme käyttämään markdownia ja opettelimme, miten gatsby konfiguroidaan lukemaan markdown-sivuja. Varsinaisen toteutuksen rakentamiseen kului noin puoli päivää, kun kuvien käsittelykin saatiin mukaan. Kaunis blogiteema ja kuvat veivät vielä puoli päivää.

Kun kaikki sisältö oli siirretty ja teema muokattu reilusti, automatisoimme julkaisun Gitlab CI:llä, niin että pelkkä push käynnistää build-pipeline:n ja julkaisee kaiken Firebaseen.

Miksi Gitlab eikä Github? Githubilla on historiallisista syistä johtoasema. Heillä on tällä hetkellä vähintään 80 % kehittäjistä ja projekteista. Gitlab sen sijaan keskittyy ominaisuuksiin. Siksi olemme aiemmin valinneet Gitlabin, koska Githubissa ei ollut vuosiin kehitystyötä uusille ominaisuuksille. Tämä on nyt muuttunut dramaattisesti Microsoftin ostettua Githubin, ja Github Actions on iso askel eteenpäin, mutta matkaa on silti vielä jos Github haluaa päästä Gitlabin tasolle. Me, jotka hoidamme kaikki projektimme Gitlabissa, jatkoimme luonnollisesti myös tämän projektin kanssa Gitlabin käyttöä.

Yhteenveto

Ja tässä olemme nyt:

• Gatsby CMS:nä
• Kaupallinen teema
• Markdown-pohjainen blogi
• Gitlab CI automaattisia julkaisuja varten
• Firebase Hosting

Olemme todella tyytyväisiä lopputulokseen ja uusi sivu näyttää paljon paremmalta!