Aktuálně máme strukturovaná data (projekty, eventy, hledané role, …) uložená v Airtable, odkud se při každém překladu webu stahují. Tohle řešení má hromadu nevýhod, rádi bychom zkusili od něj odejít. Podrobně:
Airtable neumožňuje dostatečně vynutit integritu vkládaných dat (například povinná pole), takže musíme být hodně defenzivní při jejich načítání a každá chyba v načítání dat znamená, že se nám nepřeloží web. A ty chyby v překladu pak hodně komplikují jakékoliv další práce na webu, například rozbíjí zcela nesouvisející pull requesty, což je matoucí pro vývojáře. I kdybychom byli dokonale defenzivní v načítání dat a „špatná“ data ignorovali, je to blbé workflow pro editory, protože jejich data nenaskočí na webu a musí se pídit po důvodech.
Jelikož přístup k Airtable nejde snadno zařídit pouze pro čtení, znamená to, že kdokoliv chce hackovat na našem webu, potřebuje buď klíče pro čtení i zápis, anebo musí dostat nějaká „testovací“ data. Ani jedno z toho není pěkné.
Varianta s Airtable vyžaduje nějaký „magický čudlík“ pro „uložení dat“, přesněji řečeno pro přenasazení webu. Jde to nějak zařídit, ale není to pro editory tak intuitivní jako mít velké tlačítko Save přímo někde v UI.
Varianta s Airtable nemá jasnou funkci Preview.
Nabízí se využít nějaké headless CMS, například Netlify CMS, a ukládat data přímo v repu (tedy co změna, to commit). Co bychom získali:
Dokonalou kontrolu integrity dat – co změna, to pull request a kompletní test suite, takže lze integritu dat kontrolovat libovolně složitě. A především každý může rozbít pouze svou práci, jeho změny jsou izolované od ostatních.
Preview zdarma – máme klasické workflow s pull requesty.
Jasně definovaný bod uložení. Máme tlačítko Save a víme, kdy se co uloží. Nemůže dojít k tomu, že se web přenasadí uprostřed nějaké změny v Airtable.
Data jsou součástí repa, takže máme jednak mnohem lépe reprodukovatelné buildy (co se sestavilo jednou, sestaví se velmi pravděpodobně i podruhé), jednak nikdo nepotřebuje další API klíče pro běžný vývoj.
Konkrétně do Netlify CMS jde integrovat i vlastní widgety, takže se nabízí možnost napsat například vlastní upload obrázků a podobně.
Můžeme v Netlify CMS povolit editaci kýmkoliv (!), takže by nám libovolní kolemjdoucí mohli posílat návrhy na úpravy dat v Portálu.
Nevýhody:
Duplikace dat. Momentálně máme všechno krásně provázané v Airtable a museli bychom patřičné datasety zkopírovat do repa webu.
Přicházíme o hezkou možnost ad-hoc práce s daty v Airtable, tedy například praktické filtrování, exporty a podobně.
Jak to bude s merge konflikty? Pokud budeme mít v Portálu hodně dat a editoři je budou měnit najednou, nebude se to někde zasekávat kvůli konfliktům?
V rámci tohoto tasku bychom chtěli udělat pilot nasazení nějakého headless CMS, nejspíš Netlify CMS, pro správu dat Portálu dobrovolníka. Bylo by potřeba zkusit integrovat Netlify CMS (inspirace tady), vybrat nějaké dva tři provázané datasety (například eventy, projekty a lidi) a zkusit je ukládat v repu ve formátu YAML s editací v CMS.
PS. Pokud se tohle řešení osvědčí, můžem ho použít pro všechna data webu Česko.Digital. Dávalo by to smysl, jinak budem mít část dat tady a část v Airtable a bude to matoucí.
zoul
commented
2 years ago
Aktuálně máme strukturovaná data (projekty, eventy, hledané role, …) uložená v Airtable, odkud se při každém překladu webu stahují. Tohle řešení má hromadu nevýhod, rádi bychom zkusili od něj odejít. Podrobně:
Nabízí se využít nějaké headless CMS, například Netlify CMS, a ukládat data přímo v repu (tedy co změna, to commit). Co bychom získali:
Nevýhody:
V rámci tohoto tasku bychom chtěli udělat pilot nasazení nějakého headless CMS, nejspíš Netlify CMS, pro správu dat Portálu dobrovolníka. Bylo by potřeba zkusit integrovat Netlify CMS (inspirace tady), vybrat nějaké dva tři provázané datasety (například eventy, projekty a lidi) a zkusit je ukládat v repu ve formátu YAML s editací v CMS.
PS. Pokud se tohle řešení osvědčí, můžem ho použít pro všechna data webu Česko.Digital. Dávalo by to smysl, jinak budem mít část dat tady a část v Airtable a bude to matoucí.
Podrobnější diskuze ve starším ticketu v JIře.