V minulosti byl Psono.com poháněn Odoo v11. Odoo je skvělý CMS, ale jak jsme se museli naučit, aktualizace jsou obtížné. Zejména modul webu způsobil při našem testování mnoho problémů. Odoo v11 dosáhne svého konce života na konci roku 2020, takže jsme byli nuceni najít řešení.
Přemýšleli jsme o různých možnostech, buď aktualizovat na Odoo v13 a ručně migrovat veškerý obsah a přizpůsobení sami, najmout někoho, kdo by migraci pro nás provedl, nebo úplně migrovat na nový CMS. Rozhodli jsme se úplně migrovat Psono.com a budeme nadále používat v11 za firewall a později jej migrovat (ještě jsme se nerozhodli).
Důvody pro toto rozhodnutí byly:
- Máme pouze velmi malé množství obsahu, které bychom potřebovali migrovat pro Psono.com. Hlavně některé příspěvky na blogu.
- Migrace na Odoo v13 by znovu vytvořila stejný problém za dva roky, když v13 dosáhne svého EOL, potenciálně s mnohem více daty k migraci.
- Nebyli jsme příliš spokojeni s možnostmi přizpůsobení webových stránek Odoo v11. Všechno je extrémně složité s jejich šablonami uloženými v databázi.
- Náklady. Najmutí někoho, kdo by migraci provedl, by nás stálo nejméně 5000 USD, případně více.
- Komunita Odoo byla velmi aktivní, ale s vývojem v posledních letech, změnami licencí a migrací funkcionalit a pluginů k placeným řešením a umístěním všeho za paywall je komunita mrtvá.
- Psono.com je především statická webová stránka se statickým obsahem. Pokud bychom potřebovali dynamický obsah, mohli bychom ho získat přes API.
Cesta
Po rozhodnutí o úplné migraci jsme museli rozhodnout, který framework použít. Existují klasické frameworky jako např. Hugo, který jsme používali, ale jeho funkcionalita je omezená. Při hledání alternativ jsme našli některá řešení ve světě node / react.
Chtěl jsem zde napsat "vynikající řešení", ale nemyslím si, že by v současném rozbitém stavu vývoje frontendu něco zasloužilo tento titul. Rozbité, ptáte se? Pamatujete si časy, kdy vývojáři mohli vytvářet webové stránky s index.html a tagem script pro načtení jQuery a byli schopni začít vyvíjet weby? Nyní potřebujete npm nebo yarn, potřebujete rozumět package.json, webpack skriptům, moderním frameworkům jako angular nebo react, které všechny přinášejí své vlastní klienty. JSX nebo typescript. Funkce jako hot reloading nefungují spolehlivě (soubory nejsou monitorovány, některé úpravy potřebují plné restartování nebo hot reloading je spuštěn příliš brzy, takže musíte stejně ručně obnovit stránku), takže nakonec zabíjíte servery pro vývoj a čekáte minuty, než se znovu spustí (alespoň ve větších projektech). (Chybí mi stisk klávesy F5 a mít všechno tam bez jakýchkoli problémů!). Nemluvě o novém frameworku nebo nástroji alespoň každého půl roku, kdy jsou staré nástroje denně opouštěny. Mohu snadno zaplnit stránky mými stížnostmi na současný stav vývoje frontendu. Každopádně, zpět k samotnému tématu.
V absenci rozumných alternativ byly nejlepší možnosti (v době, kdy jsem to psal) next.js a gatsby. Alespoň tak je některé články propagovaly. Oba jsou stejně populární, pokud porovnáte hvězdy na Githubu nebo commity. Jediný rozdíl, který jsme mohli během počátečního hodnocení spatřit, je požadavek na serverovou komponentu pro next.js, zatímco Gatsby vytváří statické stránky (Prosím, nezabíjejte mě, pokud existuje možnost spustit next.js bez aktivního serveru! :D)
Tak jsme si trochu pohráli s Gatsby a vypadalo to dobře. Jako další krok jsme se pustili do hledání tématu. Gatsby je „nová“ utilita, takže všechna témata, která jsme našli, byla stále ve velmi základním stavu. O třicet minut a třicet dolarů později jsme měli vizuálně atraktivní téma, které pokrylo alespoň některé z požadovaných komponent, a začali jsme ho upravovat.
Jako hostingové možnosti můžete dnes vybírat mezi několika poskytovateli, konkrétně Firebase, Netlify, Cloudflare, Vercel, jednoduchým úložištěm GCP Cloud nebo AWS Cloudfront, vlastními servery, docker kontejnery běžícími na Kubernetes (musel jsem to zmínit!), ... (Pamatujete si staré časy, kdy jste si jednoduše pronajali webový prostor za 5 dolarů měsíčně s PHP a MySQL DB :D ... ale to je na jiný článek...)
Po porovnání, čtení několika recenzí a kontrole možných kombinací (jako Cloudflare před Firebase) jsme nejprve vyzkoušeli Cloudflare. Jako velcí fanoušci jejich služby to byla přirozená volba, ale bohužel měl jejich nástroj wrangler problémy. Nejprve to vždy vyhazovalo chybu a pak jsme nebyli schopni se ověřit ... Počáteční chyby zmizely další den (možná pomohlo nové bash okno), ale problém s ověřením přetrvával. Věřím, že jsem musel udělat nějakou chybu a po několika hodinách čtení jejich dokumentace a zkoušení různých řešení jsem to vzdal.
Netlify bylo dalším kandidátem, ale buď ho musíte připojit k poskytovateli git a nechat je postavit (chtěli jsme použít GitLab CI), nebo ručně nahrát výsledek sestavení. Možná mají někde možnost nahrávat výstup sestavení přes API, ale nic jsem nenašel. Alternativou by bylo repo, kam bychom vlastně nahrávali výstup sestavení, ale to se zdálo zbytečně složité... Dalším problémem pro mě je jejich cenový model. Účtují si za člena (!!!) docela významnou částku. Pamatujte, že tohle je pro statickou webovou stránku. Prohlášení jako „4× šířka pásma“ vyvolávají špatné vzpomínky na časy „férového využití webhostingu“, kdy vás lidi vyhazovali, když jste použili příliš ...
Jako čtvrtou službu jsme vyzkoušeli Firebase (což je výhodou zdarma pro naši cílovou šířku pásma a požadavky) a vše fungovalo bez problémů. Jejich možnosti přesměrování jsou trochu omezené, takže mapování starých URL na krásnější se stalo trochu únavným, ale po několika pravidlech přesměrování vše fungovalo. Zdá se, že jejich ceny jsou rozumné a účtují vám za serverové zdroje. Měl byste se vyhnout všem jejich extra službám, abyste se vyhnuli závislosti na dodavateli, ale my jsme potřebovali pouze hosting.
Také jsme krátce zkontrolovali Vercel, ale jejich požadavek na přihlášení s Github účtem a povolení s „Jednejte mým jménem“ mě odradily ještě před registrací.
Největší problém při migraci byl blog. Nakonec jsme všechny obsahy přenesli ručně. To není nic, co byste měli dělat s větším blogem, ale náš blog měl pouze patnáct příspěvků. Gatsby podporuje více mechanismů, ale chtěli jsme něco jednoduchého, co by někdo bez technického zázemí mohl použít k vytváření nových příspěvků na blog. Rozhodli jsme se pro markdown, a proto jsme se museli naučit, jak Gatsby instruovat, aby četl markdownové stránky. Samotný mechanismus nás stál asi půl dne se všemi manipulacemi s obrázky. Pěkné téma blogu a obrázky další půl den.
Po migraci veškerého obsahu a dalším masivním upravení tématu jsme automatizovali náš nasazovací proces s Gitlab CI, takže jednoduché pushnutí by spustilo naši sestavovací linii a nasadilo vše na Firebase.
Proč Gitlab a ne Github? Github má historicky navrch. V současnosti má minimálně 80 % všech vývojářů a projektů. Na druhou stranu Gitlab nabízí funkce. To je důvod, proč jsme se v minulosti rozhodli jít s Gitlabem, protože v Githubu nebyl po léta žádný skutečný vývoj funkčnosti. To se nyní dramaticky změnilo, jelikož Microsoft koupil Github a Github Actions jsou milník, ale Github má ještě dlouhou cestu, pokud chce soutěžit s Gitlabem. Takže pro nás, kteří hostují všechny své projekty na Gitlabu, to byla přirozená volba použít jej pro tento projekt také.
Závěr
A zde jsme nyní:
- Gatsby jako CMS
- Komerční téma
- Blog poháněný Markdownem
- Gitlab CI pro automatizovaná nasazení
- Firebase Hosting
Byli jsme s tímto výsledkem velmi spokojeni a nová webová stránka vypadá mnohem lépe!
