Mercure : un nouveau protocole Web pour mettre à jour les navigateurs en temps réel (« push »)

Posté par  (site Web personnel) . Édité par ZeroHeure, Davy Defaud, Benoît Sibaud et Bruno Michel. Modéré par ZeroHeure. Licence CC By‑SA.
Étiquettes :
55
27
nov.
2018
Internet

J’ai récemment publié un nouveau protocole ouvert nommé Mercure, ainsi qu’une implémentation de référence écrite en Go.

logo du projet mercure

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).

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 !

Le protocole a été conçu pour tirer parti des capacités hypermedia du Web. Il 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 URI ».

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 il 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 JavaScript (ce qui vous évitera d’utiliser des bibliothèques vérolées). Note : IE et Edge nécessitent un Polyfill.

découverte
souscription

Le gestion du protocole a déjà été incluse dans les cadriciels Web Symfony (via ce bundle officiel) et dans la version de développement (master) de API Platform.

Mercure permet de créer ce type de choses :

La spécification, l’implémentation de référence et des exemples d’utilisation dans de nombreux langages (Go, Node, Python et PHP) sont disponibles sur le dépôt du projet (libre, sous licence AGPL).

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.

Aller plus loin

  • # très jeune ?

    Posté par  . Évalué à 4.

    Mercure est très jeune

    Je ne me rends pas compte pour un protocole ce que veut dire très jeune. 6 mois ? 1 an ?

    • [^] # Re: très jeune ?

      Posté par  . Évalué à 10. Dernière modification le 28/11/18 à 10:37.

      Mercure ? dans les 4,5 milliards d'années à peu près ;-)

      • [^] # Re: très jeune ?

        Posté par  . Évalué à 3. Dernière modification le 01/12/18 à 16:36.

        Il parlait de Mercure, la proto-colle, pas la proto-planète!

        -->[]

    • [^] # Re: très jeune ?

      Posté par  . Évalué à -4.

      Mercure est très jeune
      Je ne me rends pas compte pour un protocole ce que veut dire très jeune. ?

      Ça veut dire que c'est innovant, novateur!

      autocritique
      "Dingue! Ces gens qui n'ont rien à dire voire, n'ont pas d'intérêt à un journal et qui postent tout de même un commentaire!" :P

      -->[]

      • [^] # Re: très jeune ?

        Posté par  . Évalué à 5.

        "Moi, quand je n'ai rien à dire, je veux que ça se sache !", Raymond Devos

        • [^] # Re: très jeune ?

          Posté par  . Évalué à -2.

          Yep et personne ne semble avoir compris que je parlais de moi-même. Ils ont sacrifié des points de karma inutilement ;)

  • # Support pour Edge ?

    Posté par  . Évalué à 1.

    Comment vous faîtes pour Edge qui ne supporte pas les SSE ? C'est du polling ?

    • [^] # Re: Support pour Edge ?

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

      Il y a une petite note avant les schémas :

      Note : IE et Edge nécessitent un Polyfill.

    • [^] # Re: Support pour Edge ?

      Posté par  . Évalué à 3. Dernière modification le 28/11/18 à 22:06.

      Comment vous faîtes pour Edge […] ?

      C'est un outil pour navigateur web, donc la question n'a pas de sens.

  • # Mettre à jour les navigateurs ???

    Posté par  . Évalué à 10.

    Parler de "mettre à jour les navigateurs" est très confusant : ça veut dire mettre à jour le logiciel navigateur, ce qui n'est pas le but de ce protocole apparament, mais plutôt de faire du push à ce que j'ai pu comprendre de l'explication (et donc un concurrent de l'API Push du W3D http://www.w3.org/TR/push-api/ )

    BeOS le faisait il y a 20 ans !

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 0.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 0.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à -6. Dernière modification le 29/11/18 à 16:38.

          Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Mettre à jour les navigateurs ???

      Posté par  . Évalué à 3. Dernière modification le 28/11/18 à 17:31.

      A priori, Mercure n'a pas exactement le même objectif que l'API Push. Je cite la FAQ (j'ai juste suivi le lien dans la dépêche) :

      Quelle est la différence entre Mercure et Web Push ?

      L'API Push est principalement conçue pour envoyer des notifications aux appareils mobiles non connectés à l'application. Dans la plupart des implémentations de WebPush, la taille des messages est très limitée. De plus, les messages sont envoyés via les API et les serveurs propriétaires des sociétés créant les navigateurs et les systèmes d'exploitation mobiles.

      Mercure, quant à lui, est conçu pour envoyer des mises à jour en direct aux périphériques actuellement connectés via un site web ou une app mobile. La taille des messages n’est pas limitée, et le message est directement transmis de vos serveurs vers les clients. En bref, utilisez l'API Push pour envoyer des notifications aux utilisateurs hors connexion (qui seront affichées dans les centres de notification de Chrome, d’Android ou iOS) et utilisez Mercure pour recevoir des mises à jour en direct à l’application lorsque l'utilisateur l’utilise.

      • [^] # Re: Mettre à jour les navigateurs ???

        Posté par  . Évalué à 10. Dernière modification le 29/11/18 à 11:22.

        Ce que j'en ai compris :

        Y a trois techno "W3C" qui propose des communication du Serveur vers les Clients Web :

        • Techno Web Push : Orienté mobile hors ligne

          • Les moins : taille très limité, infrastructure assez complexe et lié aux API et serveur propriétaires des navigateurs Web/OS mobile (google/apple). Ce pose donc des questions d'indépendance et de pérennité de la solution dans le temps
          • Le plus : C'est la seul techno qui fonctionne dès que ton navigateur est lancé, que tu soit connecté ou non au site web qui utilise cette techno. (Bref C'est les "Push Notification" adapté au Web).
        • WebSocket : Socket TCP avec ouverture de connexion en "HTTP/1".

          • Les plus : Socket "TCP" Full-duplex, tu fais ce que tu veux avec (tu sérialise comme tu veux tes données).
          • Les moins : Assez bas niveau, tuyauterie à mettre autour. Non compatible avec HTTP/2
        • Server Sent Event (Spec HTML, pas HTTP): Simplement un "Content-Type" spécifique qui indique que les données doivent etre traité tels quels sans entendre la fin de la reponse complète (HTTP Streaming).

          • Les plus : HTTP/2 compatible, Super simple à mettre en place, bon support des navigateurs (https://caniuse.com/#feat=eventsource) et on peut mettre en place un polyfill pour ceux qui le supporte pas nativement.
          • Les moins : text uniquement(UTF8). (Certains diront half-duplex mais vu que c'est compatible http/2 l'overhead de faire des requettes client -> serveur est bien faible par rapport à http/1).

        Bref c'est vraiment cool de voir la technologie Server Sent Event redevenir populaire. La spec est claire, simple et efficace, on est sur du http classique donc ça passe partout, compressible si besoin (gzip) etc… Le seul bémol est si on veut faire passer autre chose que du texte.

        Elle était passez sous les radars de beaucoup trop de monde, WebSocket lui ayant fait de l'ombre. Le fait que HTTP/2 soit incompatible avec Websocket rebats les cartes.

        Quand à Web Push je conseil que pour des cas d'usage très particulier (avoir besoin de faire des push notifications sans avoir besoin d’être connecté au site).

        • [^] # Re: Mettre à jour les navigateurs ???

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

          Oui concernant la limitation au texte pour les Server Sent Events, c'est relativement secondaire. Je suis loin d'être un spécialiste (et j'avoue ne pas être allé vérifier plus en avant), mais ce qui passe dans les événements, c'est fonctionnel entre le serveur et l'application, pas protocolaire.

          Dire "tiens l'URL d'une nouvelle image à charger" ou "il faut aller récupérer cette mise à jour de document" a beaucoup de sens et n'est pas vraiment coûteux. Encore moins avec HTTP/2, mais même… et je dirais même que c'est plus souple. Plutôt que de transiter de facto des données binaires (la plupart du temps plus volumineuses) on a cette restriction de ne pouvoir que donner l'information "ça c'est dispo".

          Je connaissais les Websockets, pour les avoir utilisé. Je ne connaissais pas les Server Sent Events, et j'aime beaucoup.

    • [^] # HS

      Posté par  . Évalué à 4.

      Parler de confusant est assez déroutant… mais je te rejoins sur le fond

      • [^] # Re: HS

        Posté par  . Évalué à 6.

        Je dirais même plus : confusant est malaisant.

        • [^] # Re: HS

          Posté par  . Évalué à 3.

          En effet, quoi qu'on fût…

  • # Historique?

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

    La démo du chat (miaou) avec Mercure ne propose pas d'historique. Est-ce possible de demander la redistribution de messages?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Suivre le flux des commentaires

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