Resumen
Los proveedores de gRPC de Sui ofrecen a las aplicaciones una ruta tipada y de streaming hacia los datos de Sui, pero los modelos de acceso difieren significativamente. Los endpoints públicos de la Fundación pueden servir para prototipos y herramientas de bajo volumen; evalúa sus límites actuales, soporte y términos de producción antes de depender de ellos. Los proveedores de gRPC gestionados operan endpoints compartidos con capacidad documentada, monitoreo y soporte, lo que los convierte en una opción predeterminada práctica para dApps, indexadores y workers de backend. Los nodos dedicados de gRPC de Sui aíslan tu carga de trabajo en infraestructura privada y se justifican cuando el comportamiento en ráfagas, la latencia o los requisitos de cumplimiento superan la capacidad compartida. La evaluación debe priorizar gRPC: confirma el soporte de lectura de LedgerService y StateService, TransactionExecutionService para ExecuteTransaction y SimulateTransaction, y SubscriptionService para SubscribeCheckpoints, SubscribeTransactions y SubscribeEvents. Verifica también los límites de velocidad, las asignaciones de ráfagas, las regiones, la conmutación por error y la comunicación de incidentes antes de mover tráfico de producción. OnFinality proporciona infraestructura gestionada de gRPC y RPC de Sui para mainnet y testnet, con una ruta hacia nodos dedicados cuando las cargas de trabajo necesitan aislamiento. Comienza en /networks/sui para revisar el soporte actual de la red Sui.
Puntos clave
- Adapta el modelo de acceso gRPC al riesgo de la carga de trabajo: público para prototipos, compartido gestionado para la mayoría de las aplicaciones en producción, dedicado para aislamiento.
- Verifica LedgerService, StateService, TransactionExecutionService y SubscriptionService antes de la integración.
- Prueba los límites de velocidad, el comportamiento en ráfagas, la estabilidad del streaming, las regiones y la conmutación por error antes de mover tráfico.
- Los nodos dedicados de gRPC de Sui se justifican por la capacidad predecible y el aislamiento, no solo por un mayor tráfico.
Modelos de acceso a gRPC de Sui: público, gestionado, dedicado
El acceso a gRPC de Sui generalmente se divide en tres categorías. Los endpoints gRPC públicos de la Fundación pueden ser útiles para prototipos, pero verifica los términos de acceso actuales, los límites de velocidad y el soporte antes de usarlos en producción. Los proveedores de gRPC gestionados operan endpoints compartidos con capacidad documentada, monitoreo y soporte, lo que constituye una opción predeterminada práctica para aplicaciones en producción. Los nodos dedicados de gRPC de Sui brindan a tu equipo un endpoint aislado con recursos y configuración dedicados, pero requieren un mayor compromiso operativo o comercial.
Esta guía prioriza gRPC: el JSON-RPC de nodo completo se trata como una superficie heredada o de migración. La elección no consiste en clasificar proveedores; se trata de adaptar el modelo de acceso a los requisitos de la carga de trabajo. Una wallet podría comenzar con capacidad compartida gestionada, mientras que un bot de trading de alta frecuencia o un indexador puede necesitar infraestructura dedicada desde el primer día.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| gRPC público de la Fundación | Endpoints públicos gratuitos, puertos predeterminados, límites de velocidad | Adecuado para prototipos y herramientas de bajo volumen; el uso en producción requiere verificación explícita de límites y soporte |
| gRPC compartido gestionado | Endpoint gestionado por el proveedor, límites de uso, soporte | Equilibra capacidad y sobrecarga operativa para la mayoría de las aplicaciones en producción |
| Nodo dedicado de gRPC de Sui | Endpoint privado, aislamiento de recursos, configuración personalizada | Rendimiento predecible y aislamiento para cargas de trabajo críticas |
Servicios gRPC centrales de Sui que verificar
Un proveedor puede ofrecer acceso gRPC, pero no todos exponen los mismos servicios. Antes de integrar, confirma que el endpoint admita los servicios de los que depende tu carga de trabajo. Para lecturas, LedgerService y StateService son esenciales para consultas de checkpoints, transacciones, objetos y saldos. Para flujos de trabajo de transacciones, TransactionExecutionService debe exponer ExecuteTransaction y SimulateTransaction. Para datos en tiempo real, SubscriptionService debe exponer SubscribeCheckpoints, SubscribeTransactions y SubscribeEvents. Para una guía más amplia de RPC de Sui, consulta /rpc-assistant/sui-rpc-guide.
- Confirma LedgerService para lecturas relacionadas con checkpoints y transacciones.
- Confirma StateService para consultas de estado de objetos y saldos.
- Confirma TransactionExecutionService para ExecuteTransaction y SimulateTransaction.
- Confirma SubscriptionService para flujos de trabajo de streaming.
- Si los clientes generados utilizan métodos envolventes, asócialos de nuevo a estos nombres de servicio y método para evitar sorpresas de integración.
Suscripciones de streaming: checkpoints, transacciones, eventos
El streaming de gRPC de Sui es más valioso cuando necesitas notificaciones de baja latencia de la actividad de la cadena. SubscribeCheckpoints emite nuevos checkpoints a medida que se finalizan, lo que es útil para sincronizar indexadores o monitorear el progreso de la cadena. SubscribeTransactions emite resúmenes de transacciones o datos de transacciones a medida que se procesan los bloques. SubscribeEvents emite datos de eventos para módulos y paquetes Move, lo que suele usarse en paneles DeFi, juegos y sistemas de alerta.
Dado que gRPC usa HTTP/2 y protobuf, estos streams son más eficientes que consultar periódicamente endpoints JSON-RPC. Sin embargo, verifica que el proveedor mantenga estables las suscripciones durante reconexiones y que tu cliente maneje la contrapresión y la lógica de resubscripción.
Para una prueba rápida de humo, usa un marcador de posición como: grpcurl -H "authorization: Bearer $AUTH_TOKEN" $GRPC_ENDPOINT SubscriptionService/SubscribeCheckpoints. Reemplaza ambos marcadores de posición por los valores de tu proveedor y utiliza el stub de cliente generado para la ruta exacta del método.
Planificación de capacidad, límites de velocidad, comportamiento en ráfagas, regiones y soporte
La planificación de capacidad para gRPC de Sui debe comenzar con perfiles de solicitudes, no solo con un número único de RPS. Mide las llamadas normales y pico por método, incluidas las sesiones de streaming y los trabajos de backend. Pregunta al proveedor cómo maneja el tráfico en ráfagas, si se aplican ponderaciones por método o unidades de respuesta, y si las conexiones de streaming cuentan por separado de las llamadas unarias.
Las regiones importan para la latencia hacia validadores y usuarios. Verifica dónde están desplegados los endpoints gRPC y si puedes elegir o fijar una región. Los detalles de soporte que debes comprobar incluyen acceso a registros de solicitudes, paneles de uso, actualizaciones de estado y una ruta de escalado clara durante incidentes.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Límites de velocidad | Límites por método, por IP, por clave y por conexión de streaming | Evita la limitación inesperada durante picos de tráfico |
| Comportamiento en ráfagas | Permiso de ráfagas a corto plazo y política de colas | Los eventos de lanzamiento, acuñación o de mercado pueden superar los límites de estado estable |
| Regiones | Ubicaciones de endpoints, enrutamiento y latencia desde tus usuarios y workers | Las aplicaciones globales necesitan latencia constante |
| Soporte | Página de estado, registros, analíticas de uso y escalado de incidentes | Depurar problemas en producción requiere visibilidad |
Fiabilidad en producción, monitoreo, conmutación por error y comunicación de incidentes
Una dependencia de gRPC de Sui en producción necesita más que un endpoint receptivo. Comprueba la página de estado del proveedor, la comunicación histórica de incidentes y si ofrecen registro a nivel de solicitud o paneles de uso. Tu propio cliente debe implementar reintentos con retroceso exponencial, drenaje de conexiones en errores y lógica de resubscripción para streams.
Planifica la conmutación por error en la capa de aplicación. Usar un segundo proveedor de gRPC o un endpoint de respaldo dedicado puede reducir el tiempo de inactividad durante incidentes del proveedor. Prueba la conmutación por error regularmente, no solo durante una interrupción. Comprueba también cómo comunica el proveedor las ventanas de mantenimiento y si expone un feed de mantenimiento programado.
- Revisa el historial de estado del proveedor y las actualizaciones de incidentes.
- Habilita registros a nivel de solicitud o analíticas de uso si están disponibles.
- Implementa reintentos en el cliente, retroceso y resubscripción de streams.
- Prueba un endpoint o proveedor secundario antes de necesitarlo.
- Confirma cómo se anuncian las ventanas de mantenimiento.
Cuándo se justifica un nodo dedicado de gRPC de Sui
Los nodos dedicados de gRPC de Sui no son simplemente un endpoint compartido más grande. Proporcionan recursos aislados, endpoints privados, configuración personalizada y capacidad predecible que no se ve afectada por otros inquilinos. Esto se justifica cuando tu aplicación tiene requisitos estrictos de latencia, alto rendimiento sostenido, transacciones críticas para el negocio o necesidades de cumplimiento que exigen infraestructura dedicada.
Las señales de que puede ser necesaria infraestructura dedicada incluyen: limitación del endpoint compartido durante horas pico, entrega de streaming inconsistente, incapacidad para cumplir los SLA internos o necesidad de configuraciones de nodo personalizadas. La decisión no consiste en clasificar proveedores; se trata de aislar una carga de trabajo que ha superado la capacidad compartida. Para orientación operativa, consulta /rpc-assistant/sui-rpc-node.
- Alto volumen sostenido de solicitudes o distribución de streaming
- Operaciones de trading, juegos o puentes sensibles a la latencia
- Requisitos de cumplimiento o aislamiento de datos
- Limitación frecuente de capacidad compartida o límites de ráfagas
- Necesidad de configuración o monitoreo personalizado del nodo
Acceso gRPC a la testnet y separación de mainnet
Los endpoints gRPC de la testnet de Sui son valiosos para staging, pruebas de contratos y automatización de QA, pero no son infraestructura de producción. Mantén explícitas las configuraciones de testnet y mainnet, y no trates los datos de testnet como permanentes o garantizados. El faucet oficial de Sui es https://faucet.sui.io; verifica la política y los límites actuales del faucet antes de depender de él para ejecuciones de prueba automatizadas.
Usa /rpc-assistant/sui-testnet-rpc para detalles de RPC específicos de la testnet y mantén las llamadas de testnet separadas de las credenciales de mainnet. El soporte de testnet de Sui de OnFinality debe usarse para desarrollo y staging, no para tráfico de producción.
Próximos pasos: Centro de red de Sui.
Preguntas frecuentes
¿Sui admite gRPC para el acceso a datos en producción?
Sí. Los nodos completos de Sui exponen servicios gRPC que incluyen LedgerService, StateService, TransactionExecutionService y SubscriptionService. Los proveedores gestionados pueden ofrecer endpoints gRPC, pero no todos lo hacen; confirma los métodos específicos que necesitas antes de la integración.
¿Cuál es la diferencia entre proveedores de gRPC de Sui públicos y gestionados?
Los endpoints públicos de la Fundación pueden tener límites de velocidad y términos de soporte diferentes. Los proveedores gestionados operan endpoints compartidos con capacidad documentada, monitoreo, soporte y, a menudo, rutas de actualización más claras. Los nodos dedicados proporcionan infraestructura privada y aislada.
¿Qué métodos gRPC debo probar para el streaming de datos de Sui?
SubscribeCheckpoints, SubscribeTransactions y SubscribeEvents de SubscriptionService son los flujos de trabajo de streaming principales. Prueba que tu cliente pueda reconectarse y reanudar los streams después de interrupciones.
¿Cómo pruebo un endpoint gRPC de Sui antes de comprometerme?
Ejecuta una prueba de humo con grpcurl usando el endpoint y el token de autenticación de tu proveedor, verifica una lectura simple desde LedgerService o StateService y luego prueba cada método de streaming que necesites. Mide la latencia desde tus regiones de despliegue y revisa la página de estado del proveedor y el proceso de soporte.
¿Cuándo debo pasar de gRPC de Sui compartido a dedicado?
Cambia cuando la capacidad compartida limite tu tráfico, el streaming se vuelva inestable durante ráfagas, la latencia no cumpla los SLA internos o necesites configuración personalizada del nodo o aislamiento de datos. Los nodos dedicados se tratan de capacidad predecible, no solo de límites más altos.
¿Puedo usar el gRPC de la testnet de Sui para producción?
No. El gRPC de la testnet es para staging, pruebas de contratos y QA. Trata los datos de la testnet como temporales y mantenlos separados de las credenciales de mainnet. Usa el faucet oficial en https://faucet.sui.io y verifica las políticas actuales.