1) Negli ultimi 4-5 anni ho sperimentato con un sacco di architetture di applicazioni Solana, e ho pensato che fosse giunto il momento di scrivere i risultati. Iniziando con la meno complicata e aggiungendo progressivamente più complessità. Quindi ecco: Architettura delle Applicazioni Solana, un thread.

2) Iniziamo con la modalità facile. Probabilmente questo è l'aspetto della tua prima app Solana. Un semplice frontend in react, stabilisce una connessione a un RPC. Non c'è bisogno di un server API. L'RPC è il tuo server. Nei primi giorni, questi erano pieni di getAccountInfos, logica di costruzione tx su misura, ecc. Più tardi, quando le prestazioni iniziano a soffrire, aggiungi strati di caching e batching. Entra in gioco getMultipleAccounts. Forse aggiungi anche sottoscrizioni websocket + polling per aggiornare in tempo reale l'interfaccia utente. Questa architettura consente una prototipazione estremamente veloce. Praticamente non ci sono operazioni di devops. Costi server trascurabili (basta distribuire su vercel, ecc). Ha però alcuni difetti principali.

3) Il primo problema che incontri sono le query complesse. In questa architettura, hai solo il vanilla Solana RPC. Ciò significa che devi trattare Solana come un RPC lo espone -- come un db NoSQL con un problema di atteggiamento. Le query puntuali non sono un problema. Puoi anche essere molto creativo con i PDA per attraversare i dati del tuo programma come se fosse un database a grafo. Ma non appena hai bisogno di fare il tuo primo gPA, sei in un mare di guai. L'interfaccia non è affatto ergonomica. Se hai qualche tipo di dati a lunghezza dinamica, non può essere utilizzata affatto. A seconda del tuo fornitore RPC, può essere incredibilmente lenta. Anche senza gPA, questo approccio tende ad essere molto più lento rispetto alla tua tipica app web2 con rendering lato server e un database normale.

4) Il secondo problema che incontri è la portabilità della logica di costruzione delle transazioni. Con questa configurazione, tutta la logica per costruire transazioni è o (a) nel tuo codice frontend o (b) in librerie che il tuo codice importa. Nel caso di (a), chiunque voglia costruire transazioni al di fuori del tuo frontend si troverà in una grande difficoltà (questo include te, quando inevitabilmente avrai bisogno di più app). Nel caso di (b), qualsiasi modifica alla logica di costruzione delle transazioni richiede la pubblicazione delle librerie, tutti devono aggiornare i loro pacchetti e poi ci sono aggiornamenti dell'interfaccia utente. Fare ampio uso degli strumenti Anchor come la risoluzione degli account può ridurre la quantità di logica che deve essere portata in giro -- ma il problema rimane. Questo ti priva di agilità e rende difficile cambiare gli endpoint dei contratti intelligenti assicurando che tutte le versioni della tua logica di costruzione TX continuino a funzionare.

5) Il terzo problema che si presenta è il fatto che le interfacce utente sono generalmente scarse nel sottoporre transazioni, specialmente con la logica di ripetizione. Un utente può allontanarsi dalla pagina, la TX smette di riprovare. Grandi quantità di transazioni tendono a faticare a completarsi. È difficile fare debug da lontano per capire perché le cose non si completano.

6) L'ultimo problema qui è che non sei l'unico ad avere questa architettura. Un RPC è prezioso e fondamentalmente devi esporre il tuo URL RPC nel tuo frontend. Ora, ti ritrovi a giocare a un gioco del gatto e del topo per assicurarti che nessuno stia rubando il tuo RPC e aumentando i tuoi costi.

7) E quindi, cosa c'è dopo? Tipicamente, anche se non stai affrontando la portabilità delle transazioni, finisci per dover affrontare le query delle liste. gPA fa schifo, e lo sappiamo tutti. Quindi puoi costruire un'architettura ibrida. In questa architettura, mantieni la capacità di prototipare rapidamente, ma spingi le brutte e difficili query in un'API. Un bel esempio concreto di questo è la governance: hai proposte che vengono create e che hanno un insieme di tag su di esse ("Economico", "Tecnico", ecc.). gPA non può filtrare per tag.

8) Questa architettura non ha risolto la portabilità delle transazioni, né il problema delle persone che interrompono il tuo RPC. Ma su larga scala, puoi almeno risolvere il problema dei gPA lenti/impossibili. Introduce però un nuovo problema: gli indexer. Maggiori dettagli su questo più avanti.

9) Infine, hai quello che chiamerei lo stack "enterprise" di Solana. Non stai più trattando Solana come un database NoSQL. Invece, lo stai trattando come un bus di eventi. Il frontend non sa nulla del modello di dati di Solana. Il server costruisce le transazioni e le passa all'interfaccia utente per la firma, poi le invia a Solana stessa. Lo tratta come un evento e attende che si propaghi di nuovo agli indexer che cambieranno i dati sottostanti. Questa configurazione ha una grande portabilità delle transazioni - chiunque può colpire la tua API con parametri puliti e ricevere indietro transazioni/istruzioni. Rende l'interfaccia utente estremamente reattiva -- per quanto riguarda l'interfaccia utente, questo è fondamentalmente web2. Puoi sfruttare appieno il SSR. L'RPC è astratto -- nessuno può rubare i tuoi crediti. Ma questa configurazione ha i suoi problemi.

10) Il primo problema che incontrerai è il dolore dell'indicizzatore. Anche se questo è stato alleviato negli ultimi due anni (grazie ai team di Triton, Helius e StreamingFast), finisco ancora per colpire il nostro indicizzatore con una chiave inglese regolarmente. Ti perderai dei messaggi. Quando perdi un messaggio, la tua interfaccia utente entra in uno stato strano (esempio: ti ho inviato un NFT, sulla blockchain lo hai ricevuto, nel mio database dice che lo possiedo ancora). Questi tipi di problemi sono frustranti da debug. È colpa tua? È colpa del tuo fornitore di dati? Chi lo sa! Ecco che se ne va il tuo pomeriggio.

11) Il prossimo problema che incontrerai è il tempismo. Quando utilizzi direttamente l'RPC per tutto, ti permettono di passare gli impegni e gestire i dati più recenti. Con un indicizzatore, tutto questo è manuale. Ciò significa che quando stai costruendo transazioni, potresti costruirle basandoti su dati obsoleti. Restituisci una transazione destinata a fallire. Puoi risolvere il problema dei dati obsoleti utilizzando fornitori di dati che ti offrono dati estremamente veloci (es. Helius laser stream). Ma poi devi gestire manualmente i reorg. Cioè, i dati che indicizzi devono essere disindicizzati se quella tx non è effettivamente andata a buon fine. Questo è un incubo.

12) Puoi "aggirare" i problemi di temporizzazione costruendo sempre transazioni utilizzando dati dall'RPC e usando solo i tuoi dati indicizzati per alimentare l'interfaccia utente. Ma poi, gli utenti avranno comunque problemi con potenziali incoerenze tra l'interfaccia utente e la catena. Ad esempio, il frontend dice che possiedo questo NFT e posso trasferirlo, poi il backend mi urla contro e dice che non posso.

13) L'ultimo problema che incontri con questa configurazione è il costo, e se vogliamo essere melodrammatici "la morte della decentralizzazione." Il sogno del web3 era di non dover distribuire tonnellate di server centralizzati. Ora hai distribuito abbastanza infrastruttura da ottenere un lavoro come architetto principale in un'azienda web2. Costa soldi. Costa tempo. Ed è tutto molto centralizzato. Quanto è decentralizzato il tuo protocollo se il modo migliore per interagire con esso è tramite un'API web2? E ci sono circa 72 sviluppatori su solana che saprebbero come interagire con esso senza quell'API.

14) In definitiva, non morirò su nessuna collina riguardo alla decentralizzazione. Ciò che è meglio per gli utenti tende a essere la scelta migliore. La configurazione "enterprise" porta a webapp moderne e veloci e a una chiara separazione delle preoccupazioni. D'altra parte, comporta costi di devops e ti rende meno agile. Raccomando alla maggior parte delle startup di iniziare con il metodo diretto a rpc, a meno che non stiate costruendo qualcosa che ha esplicitamente bisogno di essere veloce o di avere semantiche di query complesse. Il tempo di immissione sul mercato è fondamentale. Puoi sempre assumere un ingegnere di livello medio in seguito e metterlo nel dungeon dell'indicizzazione.

15) Fin. Se qualcuno di voi ha trovato un setup migliore, fatemelo sapere. Queste sono tutte le cose che ho provato. Mi sto divertendo molto a sperimentare con il setup aziendale ultimamente.