1) In de afgelopen 4-5 jaar heb ik met een hoop Solana-toepassingsarchitecturen geëxperimenteerd, en ik dacht dat het hoog tijd was om de bevindingen op te schrijven. Te beginnen met de minst gecompliceerde en geleidelijk meer complexiteit toe te voegen. Dus hier gaan we: Solana Toepassingsarchitectuur, een thread.

2) Laten we beginnen met de gemakkelijke modus. Dit is waarschijnlijk hoe je eerste Solana-app eruitziet. Een eenvoudige react-frontend, die een verbinding maakt met een RPC. Er is geen api-server nodig. De RPC is je server. In de vroege dagen waren deze vol met getAccountInfos, op maat gemaakte tx-constructielogica, enz. Later, wanneer de prestaties lijden, voeg je lagen van caching en batching toe. Enter getMultipleAccounts. Misschien voeg je ook websocket-abonnementen + polling toe om de UI live bij te werken. Deze architectuur maakt extreem snel prototypen mogelijk. Er is vrijwel geen devops. Verwaarloosbare serverkosten (gewoon implementeren op vercel, enz.). Het heeft echter een paar grote tekortkomingen.

3) Het eerste probleem dat je tegenkomt zijn complexe queries. In deze architectuur heb je alleen de standaard Solana RPC. Dat betekent dat je Solana moet behandelen zoals een RPC het blootstelt -- als een NoSQL-database met een houdingprobleem. Puntqueries zijn geen probleem. Je kunt zelfs super creatief worden met PDA's om je programmadatabase te doorlopen alsof het een grafdatabase is. Maar zodra je je eerste gPA moet doen, ben je in voor maximale pijn. De interface is helemaal niet ergonomisch. Als je enige vorm van dynamisch lengte-gegevens hebt, kan het helemaal niet worden gebruikt. Afhankelijk van je RPC-provider kan het ongelooflijk traag zijn. Zelfs zonder gPA's is deze aanpak meestal veel trager dan je typische web2-app met server-side rendering en een normale database.

4) Het tweede probleem dat je tegenkomt is de draagbaarheid van de logica voor het construeren van transacties. Met deze opzet is alle logica voor het construeren van transacties ofwel (a) in je frontendcode ofwel (b) in bibliotheken die je code importeert. In het geval van (a) is iedereen die transacties buiten je frontend wil construeren in voor maximale pijn (dit geldt ook voor jou, wanneer je onvermijdelijk meer app nodig hebt). In het geval van (b) vereisen wijzigingen in de logica voor het construeren van transacties publicaties van bibliotheken, dat iedereen hun pakketten bijwerkt en vervolgens UI-updates. Zwaar leunen op Anchor-tools zoals accountresolutie kan de hoeveelheid logica die moet worden overgezet minimaliseren -- maar het probleem blijft bestaan. Dit berooft je van wendbaarheid en maakt het moeilijk om smart contract-eindpunten te wijzigen terwijl je ervoor zorgt dat alle versies van je TX-bouwlogica blijven functioneren.

5) Het derde probleem waar je tegenaan loopt, is het feit dat UIs over het algemeen slecht zijn in het indienen van transacties, vooral met retry-logica. Een gebruiker kan de pagina verlaten, TX stopt met opnieuw proberen. Grote hoeveelheden transacties hebben vaak moeite om te landen. Het is moeilijk om van een afstand te debuggen waarom dingen niet landen.

6) Het laatste probleem hier is dat jij niet de enige bent met deze architectuur. Een RPC is waardevol, en je moet in wezen je RPC-URL in je frontend blootstellen. Nu beland je in een kat-en-muis spel om ervoor te zorgen dat niemand je RPC steelt en je kosten verhoogt.

7) Wat is de volgende stap? Typisch, zelfs als je de tx-portabiliteit niet aanpakt, moet je uiteindelijk lijstquery's aanpakken. gPA is waardeloos, en dat weten we allemaal. Dus je kunt een hybride architectuur bouwen. In deze architectuur behoud je de mogelijkheid om snel prototypes te maken, maar duw je de lelijke moeilijke queries naar een API. Een mooi concreet voorbeeld hiervan is governance -- je hebt voorstellen die worden aangemaakt met een set tags erop ("Economisch", "Technisch", enz.). gPA kan niet filteren op tag.

8) Deze architectuur heeft de draagbaarheid van transacties niet opgelost, of mensen die je RPC onderbreken. Maar op schaal kun je tenminste het probleem van trage/onmogelijke gPAs oplossen. Het introduceert wel een nieuw probleem -- indexers. Meer hierover later.

9) Ten slotte heb je wat ik de "enterprise" Solana-stack zou noemen. Je behandelt Solana niet langer als een NoSQL-database. In plaats daarvan behandel je het als een event bus. De frontend weet niets van het datamodel van Solana. De server construeert transacties en geeft deze door aan de UI voor ondertekening, en stuurt ze vervolgens naar Solana zelf. Het beschouwt dit als een gebeurtenis en wacht tot deze terugkomt bij indexers die de onderliggende gegevens zullen wijzigen. Deze opzet heeft een geweldige transactiedraagbaarheid - iedereen kan je API aanroepen met schone parameters en transacties/instructies terugkrijgen. Het zorgt voor een extreem snelle UI - voor zover de UI zich zorgen maakt, is dit in wezen web2. Je kunt volledig profiteren van SSR. De RPC is geabstraheerd - niemand kan je credits stelen. Maar deze opzet heeft zijn problemen.

10) Het eerste probleem waar je tegenaan loopt, is indexer pijn. Hoewel dit de afgelopen paar jaar is verlicht (dankzij de teams van Triton, Helius en StreamingFast), eindig ik nog steeds regelmatig met een moersleutel onze indexer te slaan. Je zult berichten missen. Wanneer je een bericht mist, komt je UI in een vreemde staat (voorbeeld: ik heb je een NFT gestuurd, op de blockchain heb je het ontvangen, in mijn database staat dat ik het nog steeds bezit). Dit soort problemen zijn frustrerend om te debuggen. Is het jouw schuld? Is het jouw dataleverancier? Wie weet! Daar gaat je middag.

11) Het volgende probleem waar je tegenaan zult lopen is timing. Wanneer je de RPC direct voor alles gebruikt, laten ze je verplichtingen doorgeven en omgaan met de nieuwste gegevens. Met een indexer is dit allemaal handmatig. Dit betekent dat wanneer je transacties aan het opstellen bent, je ze zou kunnen opstellen op basis van verouderde gegevens. Je retourneert een transactie die gedoemd is om te falen. Je kunt het probleem van verouderde gegevens oplossen door gebruik te maken van gegevensleveranciers die je extreem snelle gegevens geven (bijv. Helius laser stream). Maar dan moet je handmatig omgaan met reorgs. Met andere woorden, gegevens die je indexeert moeten worden on-indexed als die tx niet daadwerkelijk is doorgegaan. Dit is een nachtmerrie.

12) Je kunt "hacken" rond timingproblemen door alleen transacties te construeren met gegevens van de RPC, en alleen je geïndexeerde gegevens te gebruiken om de UI van voeding te voorzien. Maar dan zullen gebruikers nog steeds problemen hebben met mogelijke inconsistenties tussen de UI en de keten. Bijvoorbeeld, de frontend zegt dat ik deze NFT bezit en het kan overdragen, maar de backend schreeuwt tegen me en zegt dat ik dat niet kan.

13) Het laatste probleem dat je tegenkomt met deze opzet is de kosten, en als we melodramatisch zijn "de dood van decentralisatie." De droom van web3 was om geen tonnen gecentraliseerde servers te hoeven inzetten. Nu heb je genoeg infrastructuur ingezet om een lead architectenfunctie bij een web2-bedrijf te krijgen. Het kost geld. Het kost tijd. En het is allemaal heel gecentraliseerd. Hoe gedecentraliseerd is jouw protocol als de beste manier om ermee te interageren via een web2 API is? En er zijn ongeveer 72 ontwikkelaars op Solana die weten hoe ze ermee kunnen interageren zonder die API.

14) Uiteindelijk ga ik niet vechten voor decentralisatie. Wat het beste is voor de gebruikers, blijkt vaak de beste keuze te zijn. De "enterprise" opzet leidt tot snelle, moderne webapps en een duidelijke scheiding van verantwoordelijkheden. Aan de andere kant voegt het devops-kosten toe en maakt het je minder wendbaar. Ik raad de meeste startups aan om te beginnen met de direct-to-rpc-methode, tenzij je iets bouwt dat expliciet snel moet zijn of complexe query-semantiek heeft. Tijd tot markt is cruciaal. Je kunt altijd later een middenniveau engineer aannemen en ze in de indexeringskelder stoppen.

15) Fin. Als iemand van jullie een betere setup heeft gevonden, laat het me weten. Dit zijn allemaal dingen die ik heb geprobeerd. Ik geniet er behoorlijk van om de enterprise setup de laatste tijd uit te proberen.