1) Za posledních 4-5 let jsem experimentoval s hromadou aplikačních architektur Solany a řekl jsem si, že je nejvyšší čas napsat výsledky. Začínáme s nejméně komplikovanými a postupně přidáváme složitost. Tak tedy: Solana Application Architecture, vlákno.

2) Začněme v snadném režimu. Takto pravděpodobně vypadá vaše první aplikace Solana. Jednoduchý frontend Reactu navazuje spojení s RPC. API server není potřeba. RPC je váš server. V začátcích byly tyto dokumenty plné getAccountInfos, zakázkové logiky pro výstavbu a podobně. Později, když výkon trpí, přidáte vrstvy cachování a dávkování. A teď přichází getMultipleAccounts. Možná byste také přidali odběry websocketu + polling pro živou aktualizaci uživatelského rozhraní. Tato architektura umožňuje extrémně rychlé prototypování. Devops prakticky neexistuje. Zanedbatelné náklady na servery (stačí nasadit na Vercel atd.). Má ale pár zásadních nedostatků.

3) Prvním problémem, na který narazíte, jsou složité dotazy. V této architektuře máte jen vanilla Solana RPC. To znamená, že Solanu musíte brát tak, jak ji RPC vystavuje – jako NoSQL databázi s problémem s postojem. Dotazy na body nejsou problém. Můžete být dokonce velmi kreativní s PDA, abyste procházeli data programu jako v grafové databázi. Ale jakmile budeš muset udělat první GPA, čeká tě maximální bolesti. Rozhraní není vůbec ergonomické. Pokud máte jakákoli dynamicky dlouhá data, nelze je vůbec použít. V závislosti na vašem poskytovateli RPC to může být neuvěřitelně pomalé. I bez GPA je tento přístup mnohem pomalejší než typická web2 aplikace s serverovým renderováním a běžnou databází.

4) Druhým problémem, na který narazíte, je přenosnost logiky konstrukce transakcí. V tomto nastavení je veškerá logika pro konstruování transakcí buď (a) ve vašem frontendovém kódu, nebo (b) v knihovnách, které váš kód importuje. V případě (a) je každý, kdo chce vytvářet transakce mimo frontend, na maximum (včetně vás, když nevyhnutelně potřebujete další aplikaci). V případě (b) jakékoli změny v logice konstrukce transakcí vyžadují publikaci knihovny, aktualizaci balíčků všech a následné aktualizace uživatelského rozhraní. Silné spoléhání se na nástroje Anchor, jako je řešení účtů, může minimalizovat množství logiky, kterou je třeba přenášet – ale problém zůstává. To vás připravuje o agilitu a ztěžuje změnu koncových zařízení chytrých kontraktů, přičemž všechny verze logiky vaší budovy v Texasu fungují.

5) Třetí problém, na který narazíte, je fakt, že UI obecně špatně odesílají transakce, zejména pokud jde o logiku opakovaných pokusů. Uživatel může stránku opustit, TX přestane opakovat. Velké množství transakcí má tendenci mít problém se zviditelnit. Je těžké z dálky zjistit, proč věci nefungují.

6) Poslední problém je, že nejste jediný, kdo má tuto architekturu. RPC je cenné a v podstatě musíte zpřístupnit svou RPC URL ve frontendu. Teď se můžete ocitnout ve hře na kočku a myš, abyste se ujistili, že vám nikdo neukradne RPC a nezvýší vaše náklady.

7) Tak co bude dál? Obvykle, i když neřešíte přenosnost přenosu, nakonec musíte řešit dotazy na seznam. GPA je hrozná a všichni to víme. Takže můžete vytvořit hybridní architekturu. V této architektuře si zachováváte možnost rychlého prototypování, ale obtížné dotazy přesouváte do API. Pěkným konkrétním příkladem je správa – vznikají návrhy, které mají sadu štítků ("Ekonomické", "Technické" atd.). GPA nemůže filtrovat podle štítku.

8) Tato architektura nevyřešila přenosnost transakcí ani to, že vám lidé přebírají RPC. Ale ve velkém měřítku můžete alespoň vyřešit problém pomalých/nemožných GPA. Přináší to nový problém – indexery. O tom později.

9) Nakonec tu máme to, co bych nazval "enterprise" Solana stack. Už Solanu nepovažujete za NoSQL databázi. Místo toho to bereš jako event bus. Frontend o datovém modelu Solany nic neví. Server vytváří transakce a předá je uživatelskému rozhraní k podpisu, poté je posílá přímo Solaně. Tuto událost považuje za událost a čeká, až se to vrátí zpět k indexátorům, což změní základní data. Toto nastavení má skvělou přenosnost transakcí – kdokoli může použít čisté parametry a získat zpět transakce/instrukce. To vytváří extrémně svižné uživatelské rozhraní – co se týče samotného uživatelského rozhraní, je to v podstatě web2. SSR můžete plně využít. RPC je odstraněn – nikdo vám nemůže ukrást kredity. Ale toto uspořádání má své problémy

10) První problém, na který narazíte, je bolest indexeru. I když se to v posledních letech zlepšilo (díky týmům Triton, Helius a StreamingFast), stále pravidelně biju našeho indexera klíčem. Přijdeš o zprávy. Když zmeškáte zprávu, vaše uživatelské rozhraní se dostane do zvláštního stavu (například: poslal jsem vám NFT, na řetězec jste ho obdržel, v databázi mi stále říká, že ho stále vlastním). Tyto typy problémů jsou frustrující na ladění. Je to tvoje vina? Je to váš poskytovatel dat? Kdo ví! Tak je pryč vaše odpoledne.

11) Další problém, na který narazíte, je načasování. Když přímo používáte RPC pro všechno, umožňují vám předat závazky a pracovat s nejnovějšími daty. U indexeru je to všechno manuální. To znamená, že když konstruujete transakce, můžete je vytvářet na základě zastaralých dat. Vrátíte transakci, která je odsouzena k neúspěchu. Problém se zastaralými daty můžete vyřešit pomocí poskytovatelů dat, kteří vám poskytují extrémně rychlá data (např. laserový proud Helius). Ale pak je potřeba řešit reorganizace ručně. Například data, která indexujete, musí být odindexována, pokud tato fakturace nakonec neprošla. To je noční můra.

12) Můžete "hacknout" časování tím, že transakce sestavujete pouze z dat z RPC a indexovaná data používáte jen pro UI. Ale uživatelé budou mít stále problémy s možnými nesrovnalostmi mezi rozhraním a řetězcem. Např. frontend říká, že toto NFT vlastním a mohu ho převést, pak na mě backend křičí a říká, že nemůžu.

13) Poslední problém, na který narazíte v tomto nastavení, je cena, a pokud budeme melodramatické, "smrt decentralizace." Snem web3 bylo nemuset nasadit spoustu centralizovaných serverů. Teď už máte nasazenou infrastrukturu na pozici hlavního architekta ve web2 firmě. Stojí to peníze. Stojí to čas. A všechno je velmi centralizované. Jak decentralizovaný je váš protokol, když je nejlepší způsob, jak s ním komunikovat, přes web2 API? A na Solaně je asi 72 vývojářů, kteří by věděli, jak s ní komunikovat i bez toho API.

14) Nakonec nehodlám zemřít na žádných kopcích kolem decentralizace. To, co je nejlepší pro uživatele, bývá obvykle nejlepší volbou. "Podnikové" nastavení vede k rychlým, moderním webovým aplikacím a čistému oddělení problémů. Na druhou stranu to zvyšuje náklady na devops a dělá vás méně obratnými. Doporučuji většině startupů začít metodou direct-to-rpc, pokud nestavíte něco, co musí být explicitně rychlé nebo má složitou dotazovací sémantiku. Čas na uvedení na trh je klíčový. Později můžeš vždy najmout středně pokročilého inženýra a hodit ho do indexačního dungeonu.

15) Fin. Pokud někdo z vás našel lepší řešení, dejte vědět. To jsou všechny věci, které jsem zkoušel. V poslední době mě docela baví experimentovat s enterprise nastavením.