Journal Mercure : un nouveau protocole web pour mettre à jour les navigateurs en temps réel ("push")

Posté par  (site Web personnel) . Licence CC By‑SA.
52
27
nov.
2018

Cher journal,

J'ai récemment publié un nouveau protocole (ouvert) nommé Mercure, ainsi qu'une implémentation de référence écrite en Go (libre, sous licence AGPL).

Mercure permet de "pousser" en temps réel des données depuis des serveurs vers des navigateurs web (ou autres clients HTTP). La spécification et l'implémentation sont disponibles sur GitHub.

Le projet peut être considéré comme un remplaçant de WebSocket (bien que le protocole soit de plus haut niveau), et des solutions propriétaires telles que Pusher.

Contrairement à WebSocket, Mercure est compatible avec HTTP/2 et HTTP/3 (le nouveau venu annoncé la semaine dernière par l'IETF).

Le protocole a été conçu pour tirer parti des capacités hypermédia du web, et est un parfait complément des API web du même nom.
Il est auto-découvrable (pour ce faire, il utilise la RFC "Web Linking"). Il est également compatible avec les "souscriptions" GraphQL.

Il dispose d'un mécanisme d'autorisation, permet la reconnexion automatique du client en cas de coupure réseau et la récupération des messages ratés, permet de souscrire à plusieurs sujets (topics), et d'utiliser des patterns de sujets via les "templated URIs".

Grâce à un système de hub, il fonctionne avec toutes les technologies serveur, même celles incapables de maintenir des connexions persistantes avec le client telles que les architectures "serverless", PHP, ou les scripts (Fast)CGI. Et supporte les fortes charges.
Pour publier une mise à jour, une simple requête HTTP vers le hub suffit.

Côté client, Mercure utilise uniquement les Server-sent events et le protocole HTTP, de ce fait il est compatible avec tous les navigateurs modernes (jusqu'à IE 7), passe les pare-feux, et ne nécessite aucune dépendance JS (ce qui vous évitera d'utiliser des bibliothèques vérolées). Note : IE et Edge nécessitent un Polyfill.

découverte
souscription

Le support du protocole a déjà été inclus dans les frameworks web Symfony (via ce bundle officiel : https://github.com/symfony/mercure-bundle) et dans la version de développement (master) de API Platform.

Mercure permet de créer ce type de choses :

La spec, l'implémentation de référence et des exemples d'utilisation dans de nombreux langages (Go, Node, Python, PHP) sont disponibles sur le dépôt du projet : https://mercure.rocks

Une présentation plus détaillée du projet est disponible en français sur le site de la société coopérative Les-Tilleuls.coop.

Mercure est très jeune (bien que déjà utilisé par quelques projets en production). Tous les retours, critiques et autres revues seront très utiles !

  • # Impressionnant !

    Posté par  (site Web personnel) . Évalué à 3.

    Je ne sais que dire car ça dépasse mes connaissance :-D

    La description est à elle seule impressionnante. Soit tu es très fort techniquement, soit tu es très doué en marketing :-p En tout cas, bravo !

    En fait, j’avais juste une question : Ce nouveau protocole, ouvert, si bien intégré aux protocoles et langages existants, ne serait-il pas un parfait candidat à une normalisation via le W3C ? As-tu fait des démarches en ce sens ? Ont-elles eu le résultat escompté ?

  • # Courtier de message?

    Posté par  (site Web personnel) . Évalué à 2.

    Quel est la différence avec ce que propose ActiveMQ et les autres messages brokers du même genre?

    Incubez l'excellence sur https://linuxfr.org/board/

    • [^] # Re: Courtier de message?

      Posté par  (site Web personnel) . Évalué à 4.

      Les brokers AMQP, RabbitMQ, Kafka, Google PubSub et consorts sont conçus pour faire du messaging de serveur à serveur.

      Mercure (bien qu'il fonctionne aussi pour du serveur à serveur), et surtout adapté pour du serveur vers client.

      En gros, ce n'est pas possible (ou c'est compliqué / de la bidouille) de s'abonner à des messages AMQP directement depuis un navigateur web, ou une appli mobile, à travers internet.

      Mercure, en revanche, est spécialisé pour ce cas d'usage.

      D'ailleurs rien n'empêche d'abonner un hub mercure sur une queue RabbitMQ, ou Kafka, et de transmettre ces messages aux clients via les SSE (on a un projet qui fonctionne comme ça).

  • # Très intéressant !

    Posté par  (site Web personnel) . Évalué à 2.

    Très alléchant ce descriptif ! J'ai hâte de tester.

    Merci pour le partage.

    Quelques coquilles :
    reconnection -> reconne x ion
    connection -> conne x ion
    celles incapable -> celles incapable s
    sont disponible -> sont disponible s

    • [^] # Re: Très intéressant !

      Posté par  (site Web personnel) . Évalué à 1.

      Oops 🤭. Merci pour les corrections !

    • [^] # Coquilles typographiques

      Posté par  . Évalué à 1.

      Ce commentaire identifie des coquilles et propose des corrections, qui concernent le journal, ainsi que la dépêche. Je mets ça ici pour ne pas encombrer les commentaires sous la dépêche.

      Les 4 coquilles relevées par Stéphane ESCAICH sont toujours présentes (dans le journal et la dépêche). J'ai identifié quelques coquilles complémentaires. Je fais une synthèse en les listant toutes ici. Je mets les corrections en gras dans un formatage Teletype.

      • 1 correction : « […] permet la reconnection reconnexion automatique […] »
      • 5 corrections (noter l'ajout d'une virgule) : « […] même celles incapable incapables de maintenir des connections connexions persistantes avec le client , tel telles que les architectures "serverless" […]. Et Il supporte les fortes charges. »
      • 1 correction : « […] (ce que qui vous évitera d'utiliser […] »
      • 1 correction : « […] sont disponible disponibles sur le dépôt du projet […] »
  • # Pas mal du tout

    Posté par  (site Web personnel) . Évalué à 5.

    Bon c'est pas trop ma spécialité mais j'aimerais juste comprendre un peu plus :

    Il dispose d'un mécanisme d'autorisation, permet la reconnection automatique du client en cas de coupure réseau et la récupération des messages ratés, permet de souscrire à plusieurs sujets (topics), et d'utiliser des patterns de sujets via les "templated URIs".

    En gros cela permet à un serveur d'envoyer un message aux postes clients et de faire réagir le navigateur
    ( ce que l'on faisait au temps des terminaux avec wall (write all) )

    Le besoin est plus que nécessaire … vu que le navigateur devient le "terminal" par défaut de nos jours (ce qui est une bonne chose) et souvent il y a besoin de communiquer depuis le serveur vers les "clients"

    Et en plus c'est asynchrone … bravo

    pfff … encore un truc a étudier …

    • [^] # Re: Pas mal du tout

      Posté par  (site Web personnel) . Évalué à 5. Dernière modification le 28/11/18 à 09:11.

      vu que le navigateur devient le "terminal" par défaut de nos jours (ce qui est une bonne chose)

      Pourquoi est-ce une « bonne chose » ?

      * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.