Validators DAO modernise le client TypeScript Yellowstone Geyser gRPC de Solana Stream SDK ; NAPI-RS améliore performances et stabilité des flux fréquents

ELSOUL LABO B.V. (siège : Amsterdam, Pays-Bas ; PDG : Fumitake Kawasaki) et Validators DAO annoncent une mise à jour majeure du client TypeScript de « Solana Stream SDK », framework de streaming Solana open source. Le client TypeScript Yellowstone Geyser gRPC peut désormais exploiter NAPI-RS, une implémentation native en Rust.

Cette mise à jour accroît la marge de traitement et la stabilité de Solana Stream SDK pour les charges de streaming à haute fréquence, tout en préservant l’expérience de développement TypeScript. Le système est conçu pour rester stable et résister aux pannes, même lors des pics de trafic et des rafales continues d’événements. Le code de démarrage ne se limite plus à de simples exemples de connexion : il est restructuré comme un socle « Production-Ready », destiné aux opérations réelles et à l’extensibilité.

Les flux Solana sont employés dans des domaines où la réactivité en temps réel crée directement de la valeur : trading, surveillance, analyse et décisions opérationnelles. De nombreux environnements de développement réels reposent en parallèle sur les technologies web ; TypeScript s’y impose par la vitesse de développement, la maintenabilité, la souplesse des équipes et la facilité de transmission.

Il ne suffit donc pas de pouvoir traiter les flux avec TypeScript : les flux à haute fréquence doivent pouvoir y être traités de façon réaliste et durable, sans s’effondrer au fil d’une exploitation prolongée.

Un streaming à haute fréquence reçoit, traite, filtre et décode en continu les données, tout en exécutant simultanément la logique en aval. Dans ces conditions, un parcours Node.js monothread est sujet à la contre-pression lors des rafales ou des brèves pointes de charge.

En pratique, cela se traduit souvent par une latence accrue, une accumulation des traitements, des événements abandonnés et des reconnexions fréquentes. TypeScript excelle par sa vitesse de développement et sa maintenabilité, mais l’enjeu opérationnel central reste la capacité à préserver une marge de traitement suffisante lors des pics. La présente mise à jour y répond directement.

Jusqu’ici, Solana Stream SDK employait NAPI-RS principalement dans son client TypeScript Shreds gRPC. La mise à jour étend la prise en charge de NAPI-RS — natif Rust — au client TypeScript Yellowstone Geyser gRPC largement utilisé.

Une part bien plus grande du pipeline de streaming peut ainsi bénéficier d’une exécution native à faible surcoût, tout en conservant une interface TypeScript. Les benchmarks internes montrent une nette amélioration de la tolérance à la contre-pression lors des pics, avec une marge de traitement multipliée jusqu’à environ quatre fois. L’essentiel n’est pas le multiplicateur lui-même, mais le passage à un comportement qui évite l’effondrement sous forte charge et peut servir de base opérationnelle fiable.

Contrairement à des solutions comme WebAssembly (WASM), NAPI exécute directement le code natif et permet une latence plus faible ainsi qu’un débit supérieur. Dans Solana Stream SDK, NAPI-RS joue un rôle central pour relever les performances des flux en temps réel sans sacrifier l’expérience de développement TypeScript.

Geyser gRPC est une interface centrale pour recevoir à faible latence les flux de transactions, les mises à jour de comptes et les événements de slots. Les retards ou pertes de données se traduisent directement par des occasions de trading manquées, une surveillance et des décisions opérationnelles retardées, et des coûts de développement et d’exploitation supérieurs.

Rendre cette interface centrale exploitable concrètement avec TypeScript et résistante aux pics ne relève pas seulement de la vitesse. Cela réduit les frictions du développement comme de l’exploitation et permet aux équipes d’améliorer continuellement leurs systèmes sans changer de stack ni réécrire leur logique centrale.

Le code de démarrage servait auparavant surtout à tester rapidement la connexion. Dans les opérations réelles, déconnexions, reconnexions, continuité du flux, doublons ou pertes, filtrage des abonnements et contrôle des pics sont toutefois inévitables.

Si la structure initiale est trop légère, ces exigences réelles sont souvent ajoutées plus tard au cas par cas, ce qui déforme l’architecture et augmente le coût de maintenance à long terme. La mise à jour réorganise le code de démarrage comme un socle capable de répondre dès l’origine aux contraintes opérationnelles réelles.

Côté TypeScript, les responsabilités sont clairement séparées afin de rendre explicites les points d’extension. Le point d’entrée reste minimal et centré sur le câblage et le démarrage, tandis que la logique de traitement est isolée dans des handlers. Des hooks comme onTransaction et onAccount définissent précisément où insérer une logique personnalisée.

La logique de trading ou de détection, les politiques de filtrage et les destinations de sortie peuvent ainsi être modifiées localement et de manière prévisible. Les abonnements sont désormais définis uniformément en TypeScript plutôt que dans des fichiers JSON, ce qui améliore lisibilité et sûreté des types. Des constructions claires comme CommitmentLevel.PROCESSED réduisent la dérive entre la configuration du code et le comportement à l’exécution.

Dans un streaming à haute fréquence, la vitesse ne suffit pas : la résilience est tout aussi essentielle. La mise à jour conserve des mécanismes intégrés tels que le contrôle de la contre-pression — files bornées et journalisation des abandons —, les métriques des événements reçus, traités et abandonnés, le maintien des connexions par ping/pong, le backoff exponentiel et la récupération des données manquantes fondée sur from_slot.

Il ne s’agit pas d’améliorations facultatives, mais des exigences de base d’un système de streaming en production. Considérer le code de démarrage comme « Production-Ready », c’est intégrer ces principes dès le début plutôt que les ajouter après coup.

Cette mise à jour s’adresse aux développeurs qui souhaitent exploiter des flux Solana en temps réel et en production avec TypeScript, aux équipes qui créent avec Yellowstone Geyser gRPC des systèmes de détection, de trading et de surveillance à faible latence, ainsi qu’aux développeurs confrontés aux pics de charge ou aux reconnexions. Son objectif est d’accroître la viabilité opérationnelle du streaming en TypeScript sans sacrifier ses avantages naturels.

Les mises à jour de Solana Stream SDK sont disponibles sur GitHub. Les retours sont bienvenus sur GitHub ou sur le Discord officiel de Validators DAO.

ERPC fournit une infrastructure de streaming Solana dans plusieurs régions. Avec le code de démarrage de Solana Stream SDK, les développeurs peuvent valider directement le comportement dans de véritables environnements Geyser gRPC. L’essai gratuit d’ERPC permet aussi d’évaluer ensemble le SDK et l’infrastructure de streaming dans des conditions proches de la production. Le site officiel d’ERPC fournit de plus amples informations.

Discord officiel de Validators DAO : https://discord.gg/C7ZQSrCkYR Solana Stream SDK (GitHub) : https://github.com/ValidatorsDAO/solana-stream Site officiel d’ERPC : https://erpc.global/fr/