1) En los últimos 4-5 años he experimentado con montones de arquitecturas de aplicaciones Solana, y pensé que ya era hora de que redactara los resultados. Empezando por lo menos complicado y añadiendo progresivamente más complejidad. Así que allá va: Arquitectura de aplicaciones Solana, un hilo.

2) Empecemos con el modo fácil. Probablemente así sea tu primera app de Solana. Un frontend simple de react establece una conexión con un RPC. No hace falta un servidor API. El RPC es tu servidor. En los primeros días, estos estaban llenos de getAccountInfos, lógica de construcción personalizada de traducción, etc. Más adelante, cuando el rendimiento se resiente, añades capas de caché y procesamiento en lotes. Aquí entra getMultipleAccounts. Quizá también añadas suscripciones a Websocket + sondeos para actualizar la interfaz en directo. Esta arquitectura permite prototipados extremadamente rápidos. Prácticamente no hay DevOps. Costes de servidor insignificantes (solo desplegar en Vercel, etc.). Aunque tiene algunos defectos importantes.

3) El primer problema que enfrentas son consultas complejas. En esta arquitectura, lo único que tienes es el RPC de Solana original. Eso significa que tienes que tratar Solana tal y como lo expone un RPC: como una base de datos NoSQL con un problema de actitud. Las consultas de puntos no son problema. Incluso puedes ser muy creativo con los PDAs para recorrer los datos de tu programa como si fuera una base de datos de grafos. Pero en cuanto necesites hacer tu primer GPA, te espera el dolor máximo. La interfaz no es nada ergonómica. Si tienes algún tipo de dato con longitud dinámica, no se puede usar en absoluto. Dependiendo del proveedor de tu RPC, puede ser increíblemente lento. Incluso sin GPAs, este enfoque suele ser mucho más lento que una app web2 típica con renderizado en el lado del servidor y una base de datos normal.

4) El segundo problema que tienes es la portabilidad de la lógica de construcción de transacciones. Con esta configuración, toda la lógica para construir transacciones está o bien (a) en tu código frontend o (b) en las librerías que tu código importa. En el caso de (a), cualquiera que quiera crear transacciones fuera de tu frontend se enfrentará al máximo dolor (esto te incluye a ti, cuando inevitablemente necesites más app). En el caso de (b) cualquier cambio en la lógica de construcción de transacciones requiere publicaciones de biblioteca, que todos actualicen sus paquetes y luego actualizaciones de la interfaz. Apoyarse mucho en herramientas de Anchor como la resolución de cuentas puede minimizar la cantidad de lógica que hay que portar — pero el problema sigue siendo. Esto te quita agilidad y dificulta cambiar los endpoints de los contratos inteligentes, asegurando que todas las versiones de la lógica de construcción de TX sigan funcionando.

5) El tercer problema es que las interfaces suelen ser malas enviando transacciones, especialmente con la lógica de reintentos. Un usuario puede alejarse de la página, TX deja de intentarlo de nuevo. Grandes cantidades de transacciones tienden a tener dificultades para llegar. Es difícil depurar desde lejos por qué las cosas no aterrizan.

6) El último problema aquí es que no eres el único con esta arquitectura. Un RPC es valioso, y básicamente tienes que exponer la URL de tu RPC en el frontend. Ahora, acabas en un juego del gato y el ratón para asegurarte de que nadie te roba el RPC y sube tus costes.

7) ¿Y ahora qué? Normalmente, aunque no te encargues de la portabilidad de la transferencia, acabas teniendo que atender consultas de lista. gPA es una, y todos lo sabemos. Así que puedes construir una arquitectura híbrida. En esta arquitectura, mantienes la capacidad de prototipar rápidamente, pero empujas las consultas difíciles y feas a una API. Un buen ejemplo concreto de esto es la gobernanza: se están creando propuestas que tienen un conjunto de etiquetas ("Económica", "Técnica", etc.). gPA no puede filtrar por etiqueta.

8) Esta arquitectura no ha solucionado la portabilidad de las transacciones ni la gente que te quita el RPC. Pero a gran escala, al menos puedes resolver el problema de las medias medias lentas o imposibles. Introduce un nuevo problema: los indexadores. Más sobre esto más adelante.

9) Por último, tienes lo que yo llamaría la pila Solana "empresarial". Ya no tratas Solana como una base de datos NoSQL. En cambio, lo estás tratando como un autobús de eventos. El frontend no sabe nada del modelo de datos de Solana. El servidor construye las transacciones y las pasa a la interfaz para firmar, luego las envía directamente a Solana. Trata esto como un evento y espera a que se propague de nuevo a los indexadores, lo que cambiará los datos subyacentes. Esta configuración tiene una gran portabilidad de transacciones: cualquiera puede acceder a tu API con parámetros limpios y recuperar transacciones/instrucciones. Hace que la interfaz sea extremadamente ágil — en lo que a la interfaz respecta, esto es básicamente web2. Puedes aprovechar al máximo el SSR. El RPC se abstrae — nadie puede robarte los créditos. Pero esta configuración tiene sus problemas

10) El primer problema que tendrás es el dolor del indexador. Aunque esto se ha aliviado en los últimos años (gracias a los equipos de Triton, Helius y StreamingFast), sigo acabando golpeando a nuestro indexador con una llave inglesa con regularidad. Perderás mensajes. Cuando te pierdes un mensaje, tu interfaz entra en un estado extraño (por ejemplo: te envié un NFT, en cadena lo recibiste, mi base de datos dice que sigo siendo el propietario). Este tipo de problemas son frustrantes de depurar. ¿Es culpa tuya? ¿Es tu proveedor de datos? ¡Quién sabe! Ahí se va tu tarde.

11) El siguiente problema que tendrás es el timing. Cuando usas directamente el RPC para todo, te permiten pasar compromisos y gestionar los datos más recientes. Con un indexador, todo esto es manual. Esto significa que cuando construyes transacciones, podrías estar construyéndolas basándote en datos desactualizados. Devuelves una transacción condenada al fracaso. Puedes solucionar el problema de los datos desactualizados usando proveedores de datos que te proporcionan datos extremadamente rápidos (por ejemplo, el flujo láser Helius). Pero entonces tienes que encargarte manualmente de las reorganizaciones. Es decir, los datos que indexas deben ser desindexados si ese mensaje no llegó a pasar. Esto es una pesadilla.

12) Puedes "hackear" problemas de tiempo construyendo transacciones solo usando datos del RPC, y usando tus datos indexados solo para alimentar la interfaz. Pero entonces, los usuarios seguirán teniendo problemas con posibles inconsistencias entre la interfaz y la cadena. Por ejemplo, el frontend dice que soy el propietario de este NFT y que puedo transferirlo, y luego el backend me grita y dice que no puedo.

13) El último problema con este montaje es el coste, y si estamos siendo melodramáticos, "la muerte de la descentralización". El sueño de web3 era no tener que desplegar montones de servidores centralizados. Ahora has desplegado suficiente infraestructura para conseguir un puesto de arquitecto principal en una empresa web2. Cuesta dinero. Eso cuesta tiempo. Y todo está muy centralizado. ¿Qué tan descentralizado es tu protocolo si la mejor forma de interactuar con él es a través de una API web2? Y hay como 72 desarrolladores en Solana que sabrían cómo interactuar con ella sin esa API.

14) En última instancia, no voy a morir en ninguna batalla sobre la descentralización. Lo que sea mejor para los usuarios suele ser la mejor opción. La configuración "empresarial" conduce a aplicaciones web rápidas y modernas y a una separación limpia de preocupaciones. Por otro lado, añade coste de devops y te hace menos ágil. Recomiendo que la mayoría de las startups empiecen con el método directo a RPC, a menos que estés construyendo algo que necesite ser rápido o que tenga una semántica de consulta compleja. El momento de lanzamiento al mercado es clave. Siempre puedes contratar a un ingeniero de nivel medio más adelante y meterlo en la mazmorra de indexación.

15) Fin. Si alguno de vosotros ha encontrado una configuración mejor, que me lo hagáis saber. Estas son todas las cosas que he probado. Últimamente me está gustando bastante trastear con la configuración empresarial.