Local-first aplikace se z akademických debat nad CRDT posunuly do běžného webového stacku. V prohlížeči dnes může běžet SQLite ve WASM a s omezeními kolem persistence také PGlite, tedy Postgres zkompilovaný do WASM. PostgreSQL lze replikovat do klienta po vybraných datových výřezech a knihovny jako Automerge nebo Yjs řeší souběžné úpravy dokumentů. Nejde ale o jednu architekturu. Lokální databáze, replika čtení z PostgreSQL a CRDT model řeší jiné problémy a mají jiné provozní limity.

Local-first není návrat k desktopu

Když Ink & Switch v roce 2019 popsali local-first software, nešlo o nostalgii po aplikacích, které ukládaly soubory na disk. Podstatná byla kombinace dvou světů: odezva a vlastnictví dat z desktopového softwaru, spolupráce a více zařízení z cloudu. Uživatel má pracovat i bez sítě, data nemají zmizet jen proto, že dodavatel vypnul službu, a synchronizace má pomáhat, ne rozhodovat o každém kliknutí.

V běžné webové aplikaci se tím rozpadne jasná hranice mezi klientem, serverem a databází. Klasický model je jednoduchý: server drží pravdu, databáze hlídá integritu, klient posílá požadavky. Local-first z klienta dělá repliku části aplikačního stavu. Pro uživatele je to příjemné, pro architekturu nepohodlné.

Novější nástroje dávají tomuto modelu použitelnější podobu pro webové týmy. Oficiální projekt SQLite poskytuje WebAssembly/JavaScript API pro použití SQLite v moderních prohlížečích. PGlite balí Postgres do WASM. Electric Postgres Sync replikuje vybrané části PostgreSQL do lokálních klientů. Automerge a Yjs stojí na CRDT a míří hlavně na souběžnou editaci dokumentů, textu, whiteboardů a podobných struktur.

Jedna nálepka tedy kryje několik různých modelů. První je lokální databáze v klientu. Druhý je synchronizace čtení nad relační databází. Třetí je CRDT model, kde se konflikt řeší přímo v datovém typu. Zaměňovat je vede ke špatným rozhodnutím.

Databáze v prohlížeči řeší hlavně latenci

Nejpřístupnější cesta k local-first chování je uložit data blíž k UI. Neřešíte hned synchronizaci mezi více zařízeními ani slučování konfliktů. Jen nechcete čekat na síťový round-trip při každém čtení. Pro mnoho aplikací je to rozumný první krok.

Praktický příklad ukázal Notion. V červenci 2024 popsal, jak v prohlížeči nasadil WASM SQLite jako lokální cache. Podle interního měření se navigace mezi stránkami zrychlila globálně o 20 %, v regionech s vyšší latencí ještě víc. Je to měření dodavatele, ne nezávislý benchmark. Důležitější je architektonická pointa: cache v prohlížeči se může chovat jako skutečná lokální databáze, ne jen jako několik objektů v IndexedDB.

Notionův blog zároveň dobře ukazuje provozní cenu. Tým řešil více tabů, požadavek na cross-origin isolation i pomalejší první načtení kvůli stažení a inicializaci WASM knihovny. Nakonec zavedl architekturu se SharedWorkerem, který řídí přístup k databázi, a pro pomalejší zařízení nechal závodit lokální čtení proti API. Právě tyto detaily se za zkratkou „SQLite v prohlížeči“ snadno ztratí.

PGlite posouvá problém k Postgresu ve WASM. Projekt popisuje PGlite jako Postgres zkompilovaný do WASM, použitelný v prohlížeči, Node.js, Bun i Deno. Podporuje běh v paměti, IndexedDB, OPFS AHP a v serverových runtimech i nativní souborový systém. V dokumentaci k souborovým systémům je vidět hlavní omezení: IndexedDB varianta pracuje se soubory uloženými jako bloby v IndexedDB a po dotazu flushuje změny zpět. relaxedDurability vrátí výsledek dřív a flush odloží. OPFS AHP běží ve workeru a používá access-handle pool. Prohlížečová persistence tedy není detail pod čarou, ale součást návrhu.

PGlite benchmarky proto nemá smysl číst jako důkaz, že „Postgres v prohlížeči je rychlý“ obecně. Spíš ukazují, kde se platí za trvanlivý zápis. V testech autorů na M2 MacBooku Air vyšel insert malého řádku v paměťovém režimu na 0,058 ms, přes IndexedDB na 21,041 ms a s relaxedDurability na 0,085 ms. Čísla nelze přenést na každou aplikaci, prohlížeč ani zařízení, ale rozdíl mezi SQL enginem a trvanlivým zápisem je z nich vidět jasně.

Lokální SQL dává smysl, když chcete rychlé čtení, offline procházení dat, fulltext, lokální filtrování nebo menší zátěž backendu. Neznamená to hotovou local-first aplikaci. Znamená to, že klient má vlastní databázi. Synchronizace je další problém.

Electric nechává zdroj pravdy v PostgreSQL

Druhá cesta je bližší týmům, které už mají relační backend a nechtějí přepisovat doménovou logiku do CRDT modelu. Electric staví Postgres Sync jako engine pro synchronizaci čtení: připojí se k PostgreSQL, čte logical replication stream a přes HTTP doručuje klientům vybrané podmnožiny dat. V jeho terminologii se jim říká shapes, tedy datové výřezy.

Výhoda je v tom, že se nemusí měnit zápisová cesta. Postgres zůstává autoritativní databáze, backend dál řeší zápisy, autorizaci a doménová pravidla. Klient dostane lokální repliku jen toho, co potřebuje pro konkrétní view nebo uživatele. Shape je v Electricu typicky subset jedné tabulky daný tabulkou, volitelným WHERE a výběrem sloupců.

Složitější relační filtry přes další tabulky vyžadují opatrnější návrh. Dokumentace sice popisuje subqueries, ale shape pořád obsahuje řádky z kořenové tabulky, ne automaticky celou relační strukturu. Subqueries jsou navíc označené jako preview a zapínají se přes ELECTRIC_FEATURE_FLAGS=allow_subqueries,tagged_subqueries. Electric tak může zmenšit objem replikovaných dat, ale přístupová práva musí zůstat vynucená na serverové straně.

Důležitý detail je v dokumentaci k zápisům. Electric výslovně říká, že řeší synchronizaci čtení, nikoli synchronizaci zápisů. Neurčuje tedy, jak se lokální změny dostanou zpět do PostgreSQL. Můžete použít běžné online zápisy přes API, optimistic state, persistentní optimistic state nebo synchronizaci přes databázi, tedy through-the-database sync pattern. To je hranice produktu, ne detail implementace.

Pokud aplikace potřebuje skutečné offline zápisy, které se po reconnectu spolehlivě sloučí s prací jiných zařízení, musí slučování konfliktů řešit samostatně. Electric pomůže dostat data z PostgreSQL do klienta, ale nepromění doménový model v bezpečně replikovatelný systém.

PGlite má pro Electric vlastní sync plugin, zatím popsaný jako alpha. Umí synchronizovat shape z Electricu do tabulky v PGlite a v multi-table režimu zachovat transakční konzistenci napříč tabulkami. Lokální zápisy ani conflict resolution zatím nepodporuje. U větších shape je potřeba počítat i s dalšími omezeními alpha verze, například s tím, že plugin nesynchronizuje více shapes do stejné tabulky.

CRDT nejsou databázová zkratka

Třetí přístup se od klasického relačního modelu vzdaluje nejvíc. CRDT dovolují, aby více replik přijímalo změny nezávisle, a po výměně aktualizací skončily ve stejném stavu. Hodí se pro textové editory, dokumenty, plátna, seznamy, nástroje pro práci se znalostmi a spolupráci v IDE. Proto se kolem nich točí Automerge, Yjs, editorové integrace i produkční systémy typu Zed.

Automerge modeluje dokument jako JSON-like strukturu a ukládá změny tak, aby je šlo později přehrát a sloučit. V Automerge 3.0 autoři popisují snížení paměťové režie díky tomu, že in-memory reprezentaci přiblížili columnar formátu používanému na disku a při přenosu. To je dobrá připomínka, že CRDT neřeší jen teorii, ale i cenu historie, metadat a paměti.

Yjs je zralá volba hlavně pro kolaborativní editory. Jeho model shared types je pro vývojáře příjemnější než psát vlastní replikační protokol a kolem Yjs vznikl ekosystém providerů a editorových integrací. I tady ale platí, že CRDT řeší jen určitý typ konfliktu. Umí sloučit dvě souběžné editace textu nebo mapy. Samy od sebe nezaručí, že objednávka nepřejde do neplatného stavu, že dva uživatelé nevytvoří stejný identifikátor v doménovém smyslu, nebo že se zachová referenční integrita přes několik tabulek.

V debatě o local-first se často směšují dvě různé věci. Strong eventual consistency není totéž jako silná konzistence v databázovém smyslu. Klasická práce Marca Shapira a dalších o Conflict-free Replicated Data Types řeší konvergenci replik po doručení aktualizací. Doménové invarianty musíte vynutit zvlášť.

Proto se ve výzkumu objevují práce jako LoRe, ConLoc nebo Synql, které se snaží spojit local-first model s bezpečností invariantů, selektivní koordinací nebo relačními omezeními. Pro běžný webový tým jsou zatím důležitější jako popis problému než jako návod k implementaci.

Produkční systémy bývají hybridy

Produkční systémy málokdy sedí čistě do jedné kategorie. Figma je dobrý příklad. V blogu o tom, jak funguje její multiplayer, popisuje model, ve kterém server určuje pořadí změn a klienti drží repliku dokumentu. Figma nepoužila klasický OT pro celý problém a konflikt stejné vlastnosti objektu řeší jednoduše: vyhraje poslední změna podle serverového pořadí. Pro designový dokument je to přijatelný kompromis. Pro účetní systém by to bylo nepřijatelné.

Zed jde jiným směrem. V textu o tom, jak CRDT tvoří základ multiplayer editace, popisuje textový buffer jako datovou strukturu navrženou pro souběžné úpravy. V roce 2025 pak oznámil DeltaDB, systém pro historii na úrovni operací v editoru. Veřejné detaily zatím nestačí na hlubší technický rozbor, ale směr je zřejmý: spolupráce lidí a agentů v IDE potřebuje jemnější historii než commit v Gitu.

Tyto příklady jsou užitečné hlavně tím, že netvrdí totéž. Figma řadí změny serverem. Notion používá SQLite jako cache. Electric drží Postgres jako zdroj pravdy a replikuje čtení. Automerge uchovává historii dokumentu. Pod stejnou nálepkou jsou různé kompromisy.

Bezpečnost se musí řešit už při návrhu repliky

O local-first se často mluví jako o cestě k lepšímu soukromí, protože data žijí na zařízení uživatele. Samotná lokální databáze to ale nezaručuje. Pokud klient drží repliku dat, musíte vědět, kdo smí jakou shape dostat, jak dlouho replika zůstává v zařízení, co se stane po odhlášení, jak se řeší ztracené zařízení a jak se mažou data, která už uživatel nemá vidět.

Electric v dokumentaci ukazuje, že produkční nasazení má shape requesty typicky vést přes backend nebo autorizační proxy. Service ID, token nebo secret nemají skončit přímo v klientovi. U klientů v prohlížeči proto dává smysl, aby shape request procházel přes backend nebo autorizační proxy, která server-side určí tabulku, sloupce a hlavní WHERE.

Sync endpoint není běžné REST API s jednou odpovědí. Je to proud změn z databáze do klientů. Chyba v autorizaci proto neznamená jen špatnou odpověď na jeden request, ale dlouhodobě špatně distribuovaná data.

End-to-end šifrování je další oblast, kde nestačí obecná deklarace. Electric umí synchronizovat ciphertext stejně jako plaintext, ale správu klíčů a šifrování před odchodem z klienta nechává na aplikaci. Produkty jako Anytype staví identitu a šifrování přímo do produktu. To je ale širší architektura než přidání lokální databáze do webové aplikace.

Kde se local-first vyplatí

Local-first má největší smysl tam, kde uživatel opakovaně pracuje se stejným datovým prostorem, síťová latence je vidět a offline režim není jen marketingová položka. Typicky jde o editory, projektové nástroje, knowledge base, CRM pro práci v terénu, analytické UI nad omezeným subsetem dat nebo nástroje, kde má uživatel otevřených více tabů a očekává okamžitou odezvu.

Pro aplikaci, která jen posílá formulář do backendu a čeká na potvrzení platby, local-first mnoho nepřinese. Pro systém, kde každá změna vyžaduje koordinaci s externí službou, bankou nebo skladovým stavem, bude offline zápisová cesta drahá a snadno zavádějící. Lokální čtení může pořád dávat smysl, ale nesmí se tvářit jako plná offline editace.

Praktické rozhodování začíná otázkou, co přesně bolí. Pokud jde hlavně o čtení, dává smysl lokální cache přes SQLite WASM nebo PGlite a měření cold startu, více tabů a invalidace. Pokud už máte Postgres a potřebujete real-time repliku do klienta, Electric je kandidát pro synchronizaci čtení. Pokud stavíte kolaborativní editor nebo canvas, sáhnete spíš po Yjs, Automerge nebo podobné CRDT knihovně. Každý z těchto kroků řeší jiný problém.

Server zůstává, jen nemusí být u každého kliknutí

Local-first reaguje na slabinu mnoha webových aplikací: příliš mnoho práce čeká na síť a příliš mnoho dat existuje jen na serveru provozovatele. Nové nástroje dávají vývojářům víc možností než před několika lety. SQLite může běžet ve WASM, PGlite umožňuje spustit Postgres v prohlížeči i serverových runtimech, PostgreSQL může živit lokální repliku vybraného subsetu a CRDT knihovny jsou použitelné i mimo výzkumné prototypy.

Složitost tím nezmizí. Přesune se do úložiště prohlížeče, synchronizačního logu, konfliktového modelu, migrací schématu, autorizace shape, obnovy po pádu a testů pro odpojení, změněné pořadí zpráv, více tabů i starší verze klienta.

Proto local-first nedává smysl jako architektura, na kterou se má přepsat všechno. U formulářových, transakčních a silně koordinovaných aplikací často stačí převzít menší princip: data, která uživatel potřebuje k práci, mají být co nejblíž místu, kde se s nimi pracuje. Server zůstává důležitý. Jen už nemusí stát v cestě každému čtení.