Sortie de Mercure 0.14 : nouvelles fonctionnalités et amélioration des performances

Read the original version of this post

Nous l’évoquions déjà dans notre Twitter Space de vendredi dernier, nous sommes ravis de vous annoncer la disponibilité immédiate de la version 0.14 du hub Mercure.rocks ! 

Mercure est une solution libre et open-source pour créer des applications temps réel. Avec Mercure, vous poussez en toute sécurité des données vers tous vos utilisateurs connectés grâce à une simple requête POST. Aucune bibliothèque tierce ou SDK n'est nécessaire : le navigateur (ou tout autre type de client) reçoit les données par le biais d'un composant serveur que nous appelons hub, et émet un événement JavaScript auquel votre code peut s'abonner.

Mercure est une technologie de plus en plus populaire. Il vient d'atteindre 3 000 étoiles sur GitHub et est désormais utilisé pour des projets de haut vol par des organisations telles que l'ONU, l'UEFA, Lush, Intermountain Healthcare ou encore le groupe M6.

Le protocole est également utilisé par des projets publics à fort trafic tels que Mail.tm, un service de messagerie électronique qui aide les utilisateurs à se protéger contre les spams, les bots, le phishing ou d’autres abus en ligne sans exposer leur véritable adresse électronique. Mail.tm envoie environ 8 millions de notifications par jour en utilisant un seul hub Mercure sur un serveur à 6,90 €/mois (voir l'étude de cas complète postée sur notre blog). Ce type de déploiement est une vraie mine d'or pour optimiser au maximum le hub ! Et grâce à l'équipe derrière Mail.tm et à la communauté, c'est ce qui a été fait pendant le développement de cette version !

Tout d'abord, nous avons amélioré l'utilisation de la mémoire et corrigé certaines fuites, notamment au niveau du logger et de l'intégration Prometheus. Après ces premières améliorations, nous avons détecté que l'utilisation du CPU s’envolait lorsqu'un grand nombre d'abonnés étaient connectés. Kevin Burns a proposé un patch qui améliore considérablement l'utilisation du CPU, notamment en cas de charges très élevées. Sous le capot, le correctif de Kevin utilise une nouvelle bibliothèque Go qu'il a créée pour l’occasion, skipfilter, qui combine des skip lists avec des roaring bitmaps. Selon les benchmarks écrits par Kevin, le nouvel algorithme est 20 à 50% plus efficace que le précédent. Ce patch a réduit l'utilisation du CPU sur la machine exécutant le hub Mercure de Mail.tm de 100% à ~10% !

Mercure prend en charge l'envoi de mises à jour uniquement aux clients autorisés. Pour ce faire, le client doit fournir un JSON Web Token (JWT) au hub. Ce JWT doit contenir une liste de topics (ou un sélecteur de topics) auxquels le client peut s'abonner et recevoir des mises à jour privées.

Si le champ (claim) expiration `exp` standard du JWT est défini, le token ne peut plus être accepté une fois qu’il a expiré.

À partir de Mercure 0.14, les clients Mercure sont automatiquement déconnectés lorsque le JWT expire. Grâce au système de réconciliation natif fourni par Mercure (via les Server-Sent events), après la déconnexion, le client se reconnectera automatiquement et récupérera les événements manqués lors de la déconnexion, à condition qu'un nouveau JWT non expiré ait été généré.

Lors de l'utilisation de l'autorisation, le JWT peut être transmis au hub Mercure par le biais d'un cookie nommé mercureAuthorization ou de l'en-tête HTTP Authorization.

Parfois, il peut être pratique d'avoir plusieurs hubs Mercure sur le même domaine. Malheureusement, cela crée un conflit de nom à cause du nom fixe du cookie. Avec Mercure 0.14, le nom du cookie peut maintenant être configuré, pour permettre l'utilisation de plusieurs hubs sur le même domaine.

Depuis le départ, Mercure supporte la transmission du JWT au hub en utilisant un cookie ou un l’en-tête HTTP Authorization. Il est maintenant également possible d'utiliser un paramètre de requête nommé authorization. Cette nouvelle méthode est difficile à sécuriser et son utilisation est déconseillée. L'utilisation d'un cookie ou de l'en-tête Authorization devrait toujours être préférée, mais elle peut être pratique pour des scénarios complexes inter-domaines.

Pour utiliser cette méthode en toute sécurité, la connexion doit être chiffrée (ce qui est requis par la spécification Mercure), et il faut veiller à ne pas loguer le JWT. Le hub Mercure.rocks expurge par défaut le paramètre de requête authorization  (ainsi que les cookies et l'en-tête Authorization). Pour ce faire, nous avons ajouté de nouveaux filtres de logs à Caddy, le serveur web que nous utilisons.

En parlant de Caddy, Mercure 0.14 est maintenant construit sur la base de Caddy 2.5. Consultez le changelog de Caddy pour découvrir toutes les nouvelles fonctionnalités apportées ! Vous pouvez toutes les utiliser avec Mercure en personnalisant le fichier Caddy fourni.

Rappel : le hub Mercure est également disponible sous forme de middleware HTTP pour Go, qui peut être intégré dans n'importe quelle application (typiquement des serveurs web) écrite en Go.

Quelques changements introduits dans la version 0.14 peuvent nécessiter une mise à jour de vos clients. N'oubliez pas de lire le guide de mise à jour !

Même si les modifications sont mineures et ne devraient pas affecter la plupart des utilisateurs, nous prenons la rétrocompatibilité très au sérieux, et il est possible d'activer la compatibilité avec les anciennes versions du protocole public en définissant la nouvelle directive protocol_version_compatibility introduite dans la version 0.14.

La version managée de Mercure.rocks ainsi que la version haute disponibilité sont déjà construites sur la base de la v0.14 et supportent toutes les fonctionnalités listées dans cet article.

Si vous utilisez la version managée, vous pouvez passer à la dernière version directement à partir de la page des paramètres. Les nouveaux projets sont directement créés en l'utilisant. Les utilisateurs de la version haute disponibilité peuvent télécharger les binaires et les images Docker via les canaux de mise à jour habituels.

De nombreuses et nombreux spécialistes des APIs asynchrones, de Mercure ou des applications en temps réel comme Fran Mendez (le créateur d'AsyncAPI), Pauline Vos (experte en Websockets), Francis Lavoie (Core Team de Caddy), Brian Mc Cluskey (expert Mercure) et Kévin Dunglas interviendront la semaine prochaine à la API Platform Conference 2022. 

Il est encore temps d'acheter vos billets, rejoignez-nous à Lille ou en ligne !

Comme d'habitude, n'hésitez pas à signaler tout dysfonctionnement sur GitHub et si vous souhaitez découvrir Mercure ou être aidé·e dans la création de votre application en temps réel, contactez-nous !