Existuje to už někde?¶

Přirozená otázka, když čteš návrh, který zní ambiciózně. Krátká odpověď:

Což je zároveň dobrá i špatná zpráva. Dobrá, protože se tu nevymýšlí žádná nová fyzika — všechny mechanismy někde běží v produkci. Špatná, protože to nezkoumané je právě ta integrace.

Přehled¶

Sledování závislostí cache¶

Drupal — ten nejzajímavější pro tebe¶

Tohle je PHP, běží to na obřích webech a je to staré přes deset let.

Drupal 8 zavedl u každého vykresleného kusu stránky tři věci:

• cache tags — node:5, user:12. Na čem to závisí.
• cache contexts — url.path, languages, a hlavně user.permissions. Tedy přesně to „oprávnění je dimenze klíče, ne dodatek".
• max-age — jak dlouho to platí.

A co je podstatné: Render API je automaticky probublává stromem komponent nahoru. Blok si řekne, na čem závisí, a stránka to posbírá, aniž by to někdo psal ručně. To je ta samá myšlenka jako ze scénáře 2 — seznam závislostí vzniká sám tím, že se stránka staví.

Rozdíl proti tomuhle návrhu: Drupal invaliduje aktivně (smaže, co má tag), zatímco tady se porovnávají generace a nemaže se nic. Obojí jde; volba mezi nimi se řešila v kole 1.

drupal.org — Cache API, cache tags

Fastly a Next.js — totéž o patro výš¶

Fastly má surrogate keys: odpověď se označí klíči a pak se maže „všechno s klíčem produkt-8842". Používá to půlka velkých webů.

Next.js má revalidateTag() nad svojí datovou cache, což je ta samá věc uvnitř aplikace.

Značkování závislostí zkrátka není nic exotického. Je to mainstream — jen se skoro nikde nedotáhne až k tomu, aby značky uměla vyrobit sama deklarace komponenty.

Fastly — surrogate keys · Next.js — revalidateTag

Přírůstkové výsledky dotazů¶

Tady je akademická linie a je nejblíž jádru celého návrhu.

Noria¶

Výzkumný projekt z MIT (OSDI 2018). Myšlenka: web se pořád ptá na to samé. Tak proč se ptát znovu? Noria drží dotazy aplikace jako materializované pohledy, které se při zápisu přírůstkově aktualizují místo aby se přepočítávaly.

Je to tenhle návrh dotažený do konce — místo „zjisti, co je neplatné, a spočítej to znovu" rovnou „udržuj to pořád platné".

Cena je stejná jako tady: aby to šlo, dotazy se musí znát dopředu. Nelze poslat libovolné SQL. Což je přesně to omezení z kola 3, jen z druhé strany.

Paper: Noria — dynamic, partially-stateful dataflow · github.com/mit-pdos/noria

ReadySet a Materialize¶

Komerční pokračování. ReadySet vyrostl přímo z Noria a tváří se jako cache před Postgres nebo MySQL, která rozumí dotazům. Materialize dělá totéž pro streamovaný SQL.

Že z výzkumu vznikly dva produkty, je docela dobrý signál, že ta myšlenka není bláznivá.

readyset.io · materialize.com

Koherence cache ve velkém¶

TAO je grafové úložiště Facebooku — entity a typované hrany mezi nimi, s vlastní vrstvou cache. Tedy typovaný graf v produkci pro miliardy uživatelů, jen postavený na jiných kompromisech.

Zajímavější je ale to, co Meta publikovala o invalidaci cache — mimo jiné že si vyrobili nástroje na to, aby uměli dokázat, že invalidace neselhala. Ne otestovat. Dokázat.

Což je nepříjemně dobrá ilustrace účtu Z z kola 8: když to dělá firma, která na tom má peníze, tak zjistí, že samotný mechanismus je ta menší část práce.

TAO paper (USENIX ATC '13) · k invalidaci psali na engineering.fb.com (2022) — odkaz neuvádím, doména se odsud nedá ověřit

Omezený dotazovací jazyk¶

GraphQL persisted queries jsou přesně M5: klient nesmí poslat libovolný dotaz, jen odkázat na dotaz, který je předem uložený a schválený. Sekundárně to řeší i bezpečnost.

A cost analysis — GitHub API počítá každému dotazu jeho cenu a limity jsou v bodech, ne v počtu volání. Takže „dotaz má mít spočítanou cenu" je věc, která reálně funguje na jednom z největších API na světě.

Jenže i tam platí účet H: cena se počítá ze struktury dotazu, ne z toho, kolik dat tam bude za rok.

GitHub GraphQL — resource limitations

Obsahový model¶

Sanity je z headless CMS nejblíž. Má dokumenty s typovaným schématem, skutečné reference (ne kopie), vlastní dotazovací jazyk GROQ a datasety.

Contentful má typy obsahu, reference a environments — což jsou v podstatě větve obsahu, tedy blízko workspace.

Payload a Directus dělají totéž open source, Payload v TypeScriptu nad vlastní databází.

Co žádný z nich nedělá: připnout ve chvíli publikace i verzi design systému a komponent. Publikuje se obsah. Že se pod ním mezitím změnil frontend, je problém frontendu.

sanity.io/docs/groq · contentful — environments

Přišpendlení celého stavu¶

Nápad „publikace vytvoří neměnný seznam všeho, z čeho je to složené" není z CMS světa. Je z buildů.

Nix dělá přesně tohle pro celý operační systém: každý balíček je identifikovaný obsahem svých vstupů, takže „stejná definice = stejný výsledek, navždy". Obrazy kontejnerů dělají chudší variantu téhož.

Scénář 4 — redesign, který změní loňskou stránku — je v podstatě problém, který Nix řeší od roku 2003. Jen pro obsah webu to skoro nikdo neudělal.

nixos.org

Design tokeny¶

Style Dictionary (Amazon) je zavedený nástroj: tokeny se definují jednou a generují se z nich proměnné pro CSS, iOS, Android. Verzuje se to jako balíček.

Což mimochodem potvrzuje závěr kola 6: tokeny jsou artefakt design systému s vlastním životním cyklem, ne řádky v obsahovém schématu.

styledictionary.com

Co nikde není pohromadě¶

Ani jeden z těch systémů nedělá tohle najednou:

• závislosti cache odvozené z deklarace komponenty, ne psané ručně
• release, který připne i vzhled — komponenty, tokeny, renderer
• jazyky publikované nezávisle a fallback jako verzované pravidlo
• AI, která smí instancovat, ale ne rozšiřovat prostor možností

Nejblíž jsou v jednotlivostech Drupal (závislosti), Sanity (model), Nix (přišpendlení) a Noria (dotazy). Dohromady to nemá nikdo.

Co si z toho vzít¶

Že to jde. Že se dá u každého kusu ukázat, kde to běží a s jakými kompromisy. A že práce, která tady zbývá, není vymýšlení — je to skládání a testování hranic.

Což je jiná práce, než jaká vypadá z popisu. Míň nápaditá, těžší na odhad, a přesně to je ta věc, kterou účty U a Z nepřiznaně odkládají do budoucna.