U prošlosti je Psono.com bio pogonjen od strane Odoo v11. Odoo je odličan CMS, no kako smo morali naučiti, ažuriranja su teška. Posebno je njihov modul za web stranicu uzrokovao mnogo problema tijekom našeg testiranja. Odoo v11 će doseći kraj životnog vijeka do kraja 2020., pa smo bili prisiljeni pronaći rješenje.
Razmišljali smo o različitim opcijama, bilo da nadogradimo na Odoo v13 i ručno migriramo sav sadržaj i prilagodbe sami, unajmimo nekoga da napravi migraciju za nas ili da u potpunosti prijeđemo na novi CMS. Odlučili smo u potpunosti migrirati Psono.com, a Odoo v11 ćemo nastaviti koristiti iza vatrozida i migrirati ga kasnije (još nismo odlučili).
Razlozi iza te odluke su bili:
- Imamo vrlo malu količinu sadržaja koji bismo trebali migrirati za Psono.com. Uglavnom neke blog postove.
- Migracija na Odoo v13 bi za dvije godine ponovno uzrokovala isti problem kada v13 dosegne kraj životnog vijeka, potencijalno s puno više podataka za migraciju.
- Nismo bili previše zadovoljni mogućnostima prilagodbe Odoo v11 web stranica. Sve je iznimno komplicirano jer se njihovi predlošci pohranjuju u bazu podataka.
- Troškovi. Unajmljivanje nekoga za migraciju bi nas koštalo barem 5000 USD, potencijalno i više.
- Odoo zajednica je bila vrlo aktivna, no sa razvojem tijekom proteklih godina kroz promjenu licence, migraciju funkcionalnosti i dodataka na plaćena rješenja te stavljanje svega iza paywalla zajednica je zamrla.
- Psono.com je uglavnom statička web stranica sa statičkim sadržajem. Ako nam zatreba dinamički sadržaj, mogli bismo ga povući preko API-ja.
Putovanje
Nakon što smo donijeli odluku o migraciji, morali smo odabrati okvir (framework). Postoje klasični okviri poput npr. Hugo koji smo već koristili, ali im je funkcionalnost ograničena. Tražeći alternative pronašli smo neka rješenja u node / react svijetu.
Htio sam ovdje napisati "izvrsna rješenja", no ne mislim da išta u trenutnom slomljenom stanju frontend razvoja zaslužuje taj naziv. Pitate što ne valja? Sjetite se vremena kada su developeri mogli izraditi web stranicu s index.html i script tagom za učitavanje jQueryja i mogli odmah početi razvijati stranice? Sada vam treba npm ili yarn, trebate razumjeti package.json, webpack skripte, moderne okvire kao angular ili react koji svi donose vlastiti klijent. JSX ili typescript. Značajke poput "hot reloading" ne rade pouzdano (datoteka se ne prati, neke izmjene traže potpuni restart, ili se hot reloading pokrene prerano pa ionako morate ručno osvježiti stranicu) pa na kraju ubijate development servere i čekate minute da se ponovno pokrenu (barem u većim projektima). (Nedostaje mi pritisnuti F5 i imati sve spremno bez ikakvih problema!). A da ne spominjem kako svakih pola godine dolazi novi framework ili alat, a stari se svakodnevno napuštaju. Lako bih mogao ispuniti stranice jadikovkama o trenutnom stanju frontend razvoja. Uglavnom, vratimo se na samu temu.
U nedostatku razumnih alternativa, najbolje opcije (u trenutku pisanja) bile su next.js i gatsby. Tako su ih barem neki članci promovirali. Obje su jednako popularne ako usporedite Github zvjezdice ili commitove. Jedina razlika koju smo mogli primijetiti tijekom početne procjene je potreba za serverskom komponentom kod next.js, dok gatsby stvara statičke stranice (Molim vas nemojte me sada "ubiti" ako postoji opcija za pokretanje next.js bez aktivnog servera! :D)
Malo smo se poigrali s Gatsbyjem i sve je izgledalo u redu. Sljedeći korak bio je pronaći temu. Gatsby je "novo" oruđe pa su sve teme koje smo pronašli bile još uvijek u vrlo osnovnom stanju. Trideset minuta i trideset dolara kasnije, imali smo vizualno privlačnu temu koja je pokrivala barem neke od potrebnih komponenti i krenuli smo s prilagodbama.
Danas možete birati između mnogo pružatelja hostinga, od Firebasea, Netlifya, Cloudflarea, Vercela, jednostavnog GCP Cloud Storage ili AWS Cloudfronta, vlastitih servera, docker kontenera na Kubernetesu (morao sam ga spomenuti!), ... (Sjetite se starih vremena kada biste samo iznajmili web prostor za 5 dolara mjesečno s PHP-om i MySQL bazom :D ... no to je za neki drugi članak...)
Nakon usporedbe, čitanja recenzija i provjere mogućih kombinacija (npr. Cloudflare ispred Firebasea), najprije smo isprobali Cloudflare. Kao veliki obožavatelji njihovih usluga to je bio logičan odabir, ali nažalost njihov wrangler alat imao je problema. Prvo je stalno izbacivao pogrešku, a zatim se nismo mogli autentificirati ... Početne pogreške nestale su idući dan (možda je pomogla nova bash verzija), ali je problem s autentikacijom ostao. Vjerujem da sam negdje pogriješio i odustao nakon nekoliko sati čitanja dokumentacije i isprobavanja različitih rješenja.
Netlify je bio još jedan kandidat, ali ili ga morate povezati s git pružateljem i dopustiti im da ga grade (mi smo željeli koristiti GitLab CI) ili ručno učitati rezultat izgradnje. Možda imaju negdje opciju za učitavanje build-a kroz API, no nisam našao. Alternativa bi bila repo gdje zapravo guramo build output, no to se činilo bespotrebno kompleksno... Još jedan problem je njihov model cijena. Naplaćuju po članu (!!!) prilično izdašno. Imajte na umu da je to za statičku stranicu. Izjave poput "4x bandwidth" kod mene bude loše uspomene na "fair use webhosting" vremena kad bi vas izbacili ako previše koristite ...
Kao četvrti servis isprobali smo Firebase (koji je besplatan za našu ciljanu potrošnju i broj zahtjeva) i sve je radilo odmah. Njihove mogućnosti preusmjeravanja su nešto ograničene, pa je mapiranje starih URL-ova na ljepše postalo malo zamorno, ali nakon nekoliko pravila za preusmjeravanje sve je bilo u funkciji. Cijene se čine razumnima i naplaćuje se korištenje servera. Treba izbjegavati sve njihove dodatne servise kako se ne biste zaključali kod dobavljača, ali nama je trebao samo hosting.
Također smo ukratko pogledali Vercel, no njihova potreba da se prijavite putem Github računa i da potom date dozvolu "Act on my behalf" me odbila čak i prije same registracije.
Blog je bio najteži za migraciju. Na kraju smo sav sadržaj kopirali ručno. To nikako ne biste htjeli raditi kod većih blogova, ali naš je imao samo petnaest postova. Gatsby podržava više metoda, ali željeli smo nešto jednostavno tako da netko i bez tehničkog znanja može stvoriti novi blog post. Odlučili smo se za markdown i morali naučiti kako zadati gatsbyju da čita markdown stranice. Sama procedura je trajala pola dana s rješavanjem slika, a još pola dana je otišlo na pronalazak lijepe teme za blog i slike.
Nakon što smo migrirali sav sadržaj i dodatno znatno modificirali temu, automatizirali smo deployment preko Gitlaba CI tako da bi jednostavan push pokrenuo build pipeline i sve deployao na Firebase.
Zašto Gitlab a ne Github? Github prednjači povijesno. Trenutno ima najmanje 80% svih developera i projekata. Gitlab, s druge strane, nudi funkcionalnosti. Zato smo mi prije nekoliko godina odlučili koristiti Gitlab jer na Githubu nije bilo stvarnog razvoja funkcionalnosti godinama. To se sada drastično promijenilo nakon što je Microsoft kupio Github i Github Actions su veliki iskorak, ali Github još mora prijeći dug put ako želi konkurirati Gitlabu. Za nas koji hostamo sve projekte na Gitlabu, bilo je prirodno koristiti ga i za ovaj projekt.
Zaključak
I evo gdje smo sada:
- Gatsby kao CMS
- Komercijalna tema
- Blog na markdownu
- Gitlab CI za automatizirana izdanja
- Firebase Hosting
Prilično smo zadovoljni ovakvim ishodom, a nova web stranica izgleda puno bolje!
