1) Viimeisten 4–5 vuoden aikana olen kokeillut lukuisia Solana-sovellusarkkitehtuureja, ja ajattelin, että on korkea aika kirjoittaa löydökset ylös. Aloittaen vähiten monimutkaisesta ja lisäämällä asteittain lisää monimutkaisuutta. Joten tässä tulee: Solana Application Architecture, ketju.

2) Aloitetaan helposta tilasta. Tältä näyttää todennäköisesti ensimmäinen Solana-sovelluksesi. Yksinkertainen react-käyttöliittymä muodostaa yhteyden RPC:hen. API-palvelinta ei ole tarpeen. RPC on palvelimesi. Alkuvaiheessa nämä olivat täynnä getAccountInfo-tiedostoja, räätälöityä tx-rakennuslogiikkaa jne. Myöhemmin, kun suorituskyky heikkenee, lisäät kerroksia välimuistia ja eräajoa. Tähän astuu sisään getMultipleAccounts. Ehkä lisäät myös websocket-tilaukset + kyselyt reaaliaikaiseen käyttöliittymän päivittämiseen. Tämä arkkitehtuuri mahdollistaa erittäin nopean prototyypityksen. Devopsia on käytännössä nolla. Palvelinkustannukset ovat mitättömiä (pelkkä käyttöönotto Vercelissä jne.). Siinä on kuitenkin muutamia suuria puutteita.

3) Ensimmäinen ongelma, johon törmäät, ovat monimutkaiset kyselyt. Tässä arkkitehtuurissa sinulla on vain tavallinen Solana RPC. Se tarkoittaa, että Solanaa täytyy kohdella samalla tavalla kuin RPC sen paljastaa – kuin NoSQL-tietokantaa, jolla on asenneongelma. Pistekyselyt eivät ole ongelma. Voit jopa olla todella luova PDA:iden kanssa ja käydä läpi ohjelmatietojasi kuin se olisi graafitietokanta. Mutta heti kun sinun täytyy tehdä ensimmäinen GPA, sinulla on maksimikipu. Käyttöliittymä ei ole lainkaan ergonominen. Jos sinulla on mitään dynaamisesti pitkää dataa, sitä ei voi käyttää lainkaan. Riippuen RPC-palveluntarjoajastasi, se voi olla uskomattoman hidasta. Ilman gPA-tiedostoja tämä lähestymistapa on yleensä paljon hitaampi kuin tyypillinen web2-sovellus, jossa on palvelinpuolen renderöinti ja normaali tietokanta.

4) Toinen ongelma, johon törmäät, on transaktioiden rakentamisen logiikan siirrettävyys. Tällä kokoonpanolla kaikki transaktioiden rakentamisen logiikka on joko (a) frontend-koodissa tai (b) kirjastoissa, joita koodisi tuo. (a):n tapauksessa kuka tahansa, joka haluaa rakentaa transaktioita frontendin ulkopuolelta, on maksimaalisessa vaivassa (mukaan lukien sinä, kun tarvitset väistämättä lisää sovelluksia). Tapauksessa (b) kaikki transaktioiden rakentamisen logiikan muutokset vaativat kirjastojulkaisut, kaikkien pakettien päivittämisen ja käyttöliittymän päivitykset. Vahva Anchor-työkalujen, kuten tilin resoluution, hyödyntäminen voi minimoida logiikan siirron määrän – mutta ongelma jatkuu. Tämä vie sinulta ketteryyden ja vaikeuttaa älysopimuspäätelaitteiden vaihtamista samalla kun kaikki Texasin rakennuslogiikan versiot toimivat.

5) Kolmas ongelma, johon törmäät, on se, että käyttöliittymät ovat yleensä huonoja lähettämään tapahtumia, erityisesti uudelleenyrittämislogiikan kanssa. Käyttäjä voi siirtyä pois sivulta, TX lopettaa uudelleenyrittämisen. Suuret kaupat kamppailevat saavuttamisen kanssa. On vaikea selvittää kaukaa, miksi asiat eivät laskeudu.

6) Viimeinen ongelma on, ettet ole ainoa, jolla on tämä arkkitehtuuri. RPC on arvokas, ja sinun täytyy käytännössä paljastaa RPC-URL-osoitteesi frontendissa. Nyt pääset kissa ja hiiri -leikkiin varmistaaksesi, ettei kukaan varasta roolipeliäsi ja nosta kustannuksiasi.

7) Mitä seuraavaksi? Tyypillisesti, vaikka et käsittelisi tx-siirrettävyyttä, joudut vastaamaan listan kyselyihin. gPA on surkea, ja me kaikki tiedämme sen. Voit siis rakentaa hybridiarkkitehtuurin. Tässä arkkitehtuurissa säilytät kyvyn prototyypittää nopeasti, mutta siirrät rumat vaikeat kyselyt API:lle. Hyvä konkreettinen esimerkki tästä on hallinto – sinulla on ehdotuksia, joissa on joukko tunnisteita ("Taloudellinen", "Tekninen" jne.). gPA ei voi tehdä suodatinta tunnisteen mukaan.

8) Tämä arkkitehtuuri ei ole ratkaissut transaktioiden siirrettävyyttä tai sitä, että ihmiset vetävät RPC:si pois. Mutta laajassa mittakaavassa voit ainakin ratkaista hitaiden/mahdottomien gPA:iden ongelman. Se tuo mukanaan uuden ongelman – indeksoijat. Lisää tästä myöhemmin.

9) Lopuksi sinulla on se, mitä kutsuisin "yritys"-Solana-pinoiksi. Et enää käsittele Solanaa NoSQL-tietokantana. Sen sijaan kohtelet sitä kuin tapahtumabussia. Frontend ei tiedä mitään Solanan datamallista (frontend). Palvelin rakentaa transaktiot ja välittää ne käyttöliittymälle allekirjoitettavaksi, ja lähettää ne sitten Solanalle itselleen. Se käsittelee tätä tapahtumana ja odottaa, että se leviää takaisin indeksaattoreihin, jotka muuttavat taustalla olevaa dataa. Tässä kokoonpanossa on erinomainen transaktioiden siirrettävyys – kuka tahansa voi käyttää API:asi puhtailla parametreilla ja saada takaisin transaktioita/ohjeita. Se tekee käyttöliittymästä erittäin nopean – käyttöliittymän osalta tämä on käytännössä web2:ta. Voit hyödyntää SSR:ää täysimääräisesti. RPC on abstrakti – kukaan ei voi varastaa krediittejäsi. Mutta tässä kokoonpanossa on omat ongelmansa

10) Ensimmäinen ongelma, johon törmäät, on indeksointikipu. Vaikka tämä on helpottunut viime vuosina (kiitos Tritonin, Heliuksen ja StreamingFastin tiimeille), päädyn silti säännöllisesti voittamaan indeksoijamme jakoavaimella. Tulet kaipaamaan viestejä. Kun missaat viestin, käyttöliittymäsi menee outoon tilaan (esim. lähetin sinulle NFT:n, ketjussa sait sen, tietokannassani lukee, että omistan sen edelleen). Tällaiset ongelmat ovat raivostuttavia debugata. Onko se sinun syysi? Onko se sinun datantarjoajasi? Kuka tietää! Siinä meni iltapäiväsi.

11) Seuraava ongelma, johon törmäät, on ajoitus. Kun käytät RPC:tä suoraan kaikkeen, voit suorittaa sitoumuksia ja käsitellä viimeisimmät tiedot. Indeksoijalla kaikki tapahtuu manuaalisesti. Tämä tarkoittaa, että kun rakennat transaktioita, voit rakentaa niitä vanhentuneen datan pohjalta. Palautat tapahtuman, joka on tuomittu epäonnistumaan. Vanhentuneen datan ongelman voi ratkaista käyttämällä datantarjoajia, jotka tarjoavat erittäin nopeaa dataa (esim. Helius-laservirta). Mutta sitten sinun täytyy hoitaa uudelleenjärjestelyt manuaalisesti. Eli indeksoimasi data täytyy poistaa indeksoinnista, jos se ei oikeasti mennyt läpi. Tämä on painajainen.

12) Voit "hakkeroida" ajoitusongelmia rakentamalla transaktioita vain RPC:n datalla, ja käyttämällä indeksoituja tietoja vain käyttöliittymän syöttämiseen. Mutta käyttäjillä on silti ongelmia mahdollisten epäjohdonmukaisuuksien kanssa käyttöliittymän ja ketjun välillä. Eli frontend sanoo, että omistan tämän NFT:n ja voin siirtää sen, sitten backend huutaa minulle ja sanoo, etten voi.

13) Viimeinen ongelma, johon törmäät tässä asetelmassa, on kustannukset, ja jos ollaan melodramaattisia, "hajauttamisen kuolema." Web3:n unelma ei ollut joutua ottamaan käyttöön valtavasti keskitettyjä palvelimia. Nyt olet ottanut käyttöön tarpeeksi infrastruktuuria saadaksesi pääarkkitehdin työn web2-liikkeessä. Se maksaa. Se vie aikaa. Ja kaikki on hyvin keskitettyä. Kuinka hajautettu protokollasi on, jos paras tapa olla vuorovaikutuksessa sen kanssa on web2-API:n kautta? Ja Solanalla on noin 72 kehittäjää, jotka osaisivat olla vuorovaikutuksessa sen kanssa ilman sitä API:ta.

14) Lopulta en aio kuolla missään hajauttamisen ympärillä. Se, mikä on käyttäjille parasta, on yleensä paras valinta. "Yritys"-asetelma johtaa nopeita, moderneja verkkosovelluksia ja selkeään ongelmaerotteluun. Huonona puolena se lisää devops-kustannuksia ja tekee sinusta vähemmän ketterän. Suosittelen, että useimmat startupit aloittavat suoraan RPC:hen -menetelmällä, ellei kyseessä ole jotain, jonka täytyy olla nopeaa tai jossa on monimutkaista kyselysemantiikkaa. Markkinoille pääsy on avainasemassa. Voit aina palkata keskitasoisen insinöörin myöhemmin ja heittää hänet indeksointiluolastoon.

15) Fin. Jos joku teistä on löytänyt paremman ratkaisun, kertokaa siitä. Nämä ovat kaikki asioita, joita olen kokeillut. Olen viime aikoina nauttinut yritysjärjestelmän säätämisestä.