1) De siste 4-5 årene har jeg eksperimentert med mange Solana-applikasjonsarkitekturer, og jeg tenkte det var på høy tid å skrive ned funnene. Starter med minst komplisert og legger til gradvis mer kompleksitet. Så her kommer det: Solana Application Architecture, en tråd.

2) La oss starte med lett modus. Dette er sannsynligvis hvordan din første Solana-app ser ut. Et enkelt React-frontend etablerer en forbindelse til en RPC. Det er ikke behov for en API-server. RPC-en er serveren din. I begynnelsen var disse fulle av getAccountInfos, skreddersydd logikk for tx-konstruksjon, osv. Senere, når ytelsen lider, legger du til lag med caching og batching. Her kommer getMultipleAccounts. Kanskje du også legger til websocket-abonnementer + polling for å live oppdatere brukergrensesnittet. Denne arkitekturen muliggjør ekstremt rask prototyping. Det er praktisk talt ingen devops. Ubetydelige serverkostnader (bare deploy på Vercel, osv). Den har imidlertid noen store svakheter.

3) Det første problemet du støter på er komplekse spørringer. I denne arkitekturen har du bare den vanlige Solana RPC-en. Det betyr at du må behandle Solana slik en RPC eksponerer det – som en NoSQL-database med holdningsproblem. Punktforespørsler er ikke noe problem. Du kan til og med være veldig kreativ med PDA-er for å navigere programdataene dine som om det var en grafdatabase. Men så snart du må ta din første GPA, får du maksimal smerte. Grensesnittet er ikke ergonomisk i det hele tatt. Hvis du har noen form for dynamisk lengde data, kan det ikke brukes i det hele tatt. Avhengig av din RPC-leverandør kan det gå utrolig sakte. Selv uten gPA-er er denne tilnærmingen mye tregere enn en typisk web2-app med server-side rendering og en vanlig database.

4) Det andre problemet du møter er portabiliteten i transaksjonskonstruksjonslogikken. Med dette oppsettet er all logikk for å konstruere transaksjoner enten (a) i frontend-koden din eller (b) i biblioteker som koden din importerer. I tilfellet (a) vil alle som ønsker å bygge transaksjoner utenfor frontend få maksimal smerte (dette inkluderer deg, når du uunngåelig trenger flere apper). I tilfelle (b) krever endringer i transaksjonskonstruksjonslogikken bibliotekpubliseringer, alle oppdaterer pakkene sine, og deretter oppdateringer av brukergrensesnittet. Å lene seg tungt på Anchor-verktøy som kontooppløsning kan minimere mengden logikk som må porteres rundt – men problemet gjenstår. Dette fratar deg smidighet, og gjør det vanskelig å bytte smartkontrakt-endepunkter samtidig som alle versjoner av TX-bygningens logikk fortsetter å fungere.

5) Det tredje problemet du støter på er at brukergrensesnitt generelt er dårlige til å sende inn transaksjoner, spesielt med retry-logikk. En bruker kan navigere bort fra siden, TX slutter å prøve på nytt. Store mengder transaksjoner har en tendens til å slite med å lande. Det er vanskelig å feilsøke på avstand hvorfor ting ikke lander.

6) Det siste problemet her er at du ikke er den eneste med denne arkitekturen. En RPC er verdifull, og du må i praksis eksponere RPC-URL-en din i frontend. Nå ender du opp i et katt-og-mus-spill for å sørge for at ingen stjeler RPC-en din og øker kostnadene dine.

7) Så hva er det neste? Vanligvis, selv om du ikke adresserer transaksjonsportabiliteten, ender du opp med å måtte adressere listeforespørsler. gPA suger, og det vet vi alle. Så du kan bygge en hybridarkitektur. I denne arkitekturen beholder du muligheten til å prototype raskt, men skyver de stygge vanskelige spørringene inn i et API. Et godt konkret eksempel på dette er styring – du får forslag som blir laget med et sett tagger på seg ("Økonomisk", "Teknisk" osv.). gPA kan ikke filtrere etter tagg.

8) Denne arkitekturen har ikke løst portabilitet av transaksjoner, eller folk som drar i RPC-en din. Men i stor skala kan du i det minste løse problemet med trege/umulige gPA-er. Det introduserer et nytt problem – indeksere. Mer om dette senere.

9) Til slutt har du det jeg vil kalle "enterprise" Solana-stakken. Du behandler ikke lenger Solana som en NoSQL-database. I stedet behandler du det som en eventbuss. Frontenden vet ingenting om Solanas datamodell. Serveren konstruerer transaksjoner og sender dem til brukergrensesnittet for signering, og sender dem deretter til Solana selv. Den behandler dette som en hendelse og venter på at det skal overføres tilbake til indeksererne, noe som vil endre de underliggende dataene. Dette oppsettet har god transaksjonsportabilitet – hvem som helst kan treffe API-et ditt med rene parametere og få tilbake transaksjoner/instruksjoner. Det gir et ekstremt raskt brukergrensesnitt – så langt UI-en er bekymret, er dette i bunn og grunn web2. Du kan utnytte SSR fullt ut. RPC-en er abstrahert bort – ingen kan stjele kredittene dine. Men dette oppsettet har sine problemer

10) Det første problemet du vil støte på er indekseringssmerter. Selv om dette har blitt bedre de siste par årene (takket være Triton-, Helius- og StreamingFast-teamene), ender jeg fortsatt opp med å slå indekseren vår med en skiftenøkkel jevnlig. Du vil gå glipp av meldinger. Når du går glipp av en melding, havner brukergrensesnittet ditt i en merkelig tilstand (eksempel: Jeg sendte deg en NFT, på kjede mottok du den, og i databasen min står det at jeg fortsatt eier den). Denne typen problemer er frustrerende å feilsøke. Er det din feil? Er det dataleverandøren din? Hvem vet! Der røk ettermiddagen din.

11) Det neste problemet du vil støte på er timing. Når du bruker RPC direkte til alt, lar de deg oppfylle forpliktelser og håndtere de nyeste dataene. Med en indekser er alt dette manuelt. Dette betyr at når du konstruerer transaksjoner, kan du bygge dem basert på utdaterte data. Du returnerer en transaksjon som er dømt til å mislykkes. Du kan løse problemet med utdaterte data ved å bruke dataleverandører som gir deg ekstremt raske data (f.eks. Helius-laserstrøm). Men så må du håndtere omorganiseringer manuelt. Altså, data du indekserer må ikke indekseres hvis den behandlingen faktisk ikke gikk gjennom. Dette er et mareritt.

12) Du kan "hacke" tidsproblemer ved kun å konstruere transaksjoner ved å bruke data fra RPC-en, og kun bruke dine indekserte data til å mate UI-en. Men brukerne vil fortsatt ha problemer med potensielle inkonsekvenser mellom brukergrensesnittet og kjeden. Altså frontend sier at jeg eier denne NFT-en og kan overføre den, så roper backend til meg og sier at jeg ikke kan.

13) Det siste problemet du støter på med dette oppsettet er kostnad, og hvis vi skal være melodramatiske, «desentraliseringens død». Drømmen til web3 var å slippe å sette opp haugevis av sentraliserte servere. Nå har du installert nok infrastruktur til å få en hovedarkitektjobb i et web2-firma. Det koster penger. Det koster tid. Og alt er veldig sentralisert. Hvor desentralisert er protokollen din hvis den beste måten å samhandle med den på er via et web2-API? Og det er rundt 72 utviklere på Solana som vet hvordan de skal samhandle med det uten det API-et.

14) Til syvende og sist kommer jeg ikke til å dø på noen bakker rundt desentralisering. Det som er best for brukerne, er som regel det beste valget. "Enterprise"-oppsettet fører til raske, moderne webapper og en tydelig adskillelse av oppgaver. På den negative siden øker det devops-kostnaden og gjør deg mindre smidig. Jeg anbefaler at de fleste oppstartsbedrifter starter med direkte-til-RPC-metoden, med mindre du bygger noe som eksplisitt må være raskt eller har kompleks spørringssemantikk. Time to market er nøkkelen. Du kan alltid ansette en ingeniør på mellomnivå senere og kaste dem i indekseringsdungeonen.

15) Fin. Hvis noen av dere har funnet et bedre oppsett, gi meg beskjed. Dette er alle tingene jeg har prøvd. Jeg koser meg ganske godt med å eksperimentere med enterprise-oppsettet i det siste.