Meteor 3.5 permet aux développeurs de remplacer SockJS par uWebSockets.js via une simple variable d'environnement, promettant une réduction notable des coûts de CPU, de RAM et de garbage collection pour les applications qui s'appuient fortement sur les appels de méthodes.

Pourquoi ce changement est important

Depuis son lancement, Meteor a acheminé chaque message DDP (Distributed Data Protocol) via SockJS, une solution de repli en JavaScript qui fonctionne partout mais qui n'a jamais été conçue pour la vitesse pure. La nouvelle version découple la couche de transport, exposant un point d'extension qui accepte n'importe quelle implémentation WebSocket conforme aux attentes de DDP. Configurer DDP_TRANSPORT=uws au lancement remplace l'option par défaut par uWebSockets.js, un serveur basé sur C/C++ reconnu pour son débit élevé.

L'aspect performance

Les benchmarks fournis avec la version montrent :

  • Utilisation du CPU en baisse de 9 %
  • Consommation de RAM en baisse de 11 %
  • Temps de pause du garbage collection réduit de 26 %
  • Débit multiplié par 1,6 dans les micro-benchmarks

Ces gains apparaissent lorsqu'une application effectue de nombreux appels de méthodes de type RPC. Le transport lui-même ne devient un goulot d'étranglement qu'une fois la logique métier de l'application optimisée, ce qui signifie que le passage à uWebSockets.js peut se traduire directement par une réduction des coûts de serveur.

Comment l'essayer dès aujourd'hui

Aucun binaire séparé n'est requis — juste Meteor 3.5. Lancez l'application avec :

DDP_TRANSPORT=uws meteor run

Le serveur uWebSockets.js écoute sur son propre port (par défaut 5001). Lorsque plusieurs instances Meteor partagent un même hôte, chacune doit se voir attribuer un uws.port distinct via METEOR_SETTINGS pour éviter les collisions.

Qui en bénéficie, et qui ne verra peut-être pas de grande différence

  • Charges de travail intensives en RPC – les services qui appellent de nombreuses méthodes par requête peuvent économiser des cycles CPU et de la mémoire, atténuant ainsi les pressions liées à la mise à l'échelle.
  • Applications centrées sur le Pub/Sub – la majeure partie de la latence dans les modèles de publication/abonnement provient des calculs de différence de données (data-diff) et non du transport, l'amélioration de la vitesse est donc modeste.

Le changement est optionnel ; SockJS reste l'option par défaut, préservant la compatibilité avec les environnements où les WebSockets natifs ne sont pas disponibles.

Compromis et précautions

Changer de transport ajoute une petite étape opérationnelle : la gestion d'un port supplémentaire et la garantie qu'il n'entre pas en conflit avec d'autres services. Comme uWebSockets.js est un module natif, il apporte les considérations habituelles liées aux dépendances binaires — des outils de compilation doivent être présents sur l'hôte de déploiement, et toute mise à jour future de la bibliothèque devra être testée par rapport au code source de l'application.

Quelle est la suite pour la couche de transport de Meteor

En exposant une frontière claire, Meteor invite désormais la communauté à expérimenter des transports alternatifs — que ce soit pour des exigences de sécurité spécialisées, des extensions de protocole personnalisées ou un affinement supplémentaire des performances. La rapidité avec laquelle des implémentations tierces apparaîtront indiquera si ce modèle modulable deviendra une partie durable de l'architecture de Meteor.

À retenir : Le transport DDP modulable de Meteor 3.5 vous permet de remplacer l'ancienne pile SockJS par uWebSockets.js en une seule commande, offrant un débit jusqu'à 1,6 fois supérieur et des économies de ressources mesurables pour les applications intensives en RPC, tout en laissant la configuration existante intacte pour les charges de travail qui n'ont pas besoin de ce gain de performance.