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

Posté par (page perso) . Édité par ZeroHeure, Davy Defaud, Benoît Sibaud et Bruno Michel. Modéré par ZeroHeure. Licence CC by-sa.
Tags :
54
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 (+3/-1).

    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 (+14/-0). 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 (+1/-0). 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 (+0/-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 (+3/-0).

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

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

          Posté par . Évalué à -1 (+0/-1).

          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 (+1/-0).

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

  • # Mettre à jour les navigateurs ???

    Posté par . Évalué à 10 (+17/-0).

    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 15 ans !

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

      Posté par . Évalué à 1 (+7/-3).

      Bien vu ! Ce titre est vraiment inapproprié.

      Voici le titre originel :

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

      Je propose les trois titres alternatifs suivants (le deuxième a ma préférence), tout en sachant que le titre originel ne sera peut-être pas mis à jour sur Linuxfr.org, du fait du lien entre le titre et l'URL de la page, combiné au fait que l'URL a commencé à se diffuser.

      • « Mercure : un nouveau protocole Web pour mettre à jour des données en temps réel (« push ») »

      Le titre ci-dessus est le plus court parmi mes propositions, un peu plus court que le titre originel ; j'ai remplacé l'expression « les navigateurs » par « des données », puisqu'il est précisé dans l'article que « Mercure permet de « pousser » en temps réel des données depuis des serveurs vers des navigateurs Web (ou autres clients HTTP) ». Par ailleurs, on sait, au sein du titre, qu'il s'agit d'un protocole pour le web, donc les données y sont afférentes.

      • « Mercure : un nouveau protocole Web pour mettre à jour des données en temps réel par distribution sélective (ou « push ») »

      Le titre ci-dessus est plus long, un peu plus que le titre originel ; il inclut la traduction de « push technology » (cf. plus bas pour détails).

      • « Mercure : un nouveau protocole Web pour mettre à jour des données traitées par des navigateurs, en temps réel, par distribution sélective (ou « push ») »

      Le titre ci-dessus est nettement plus long, très explicite, conforme à l'idée voulue par l'auteur du titre originel (mais restrictif par rapport à l'étendue des possibilités, puisqu'il s'agit de permettre d'exploiter d'autres clients HTTP que les seuls navigateurs) ; je le mentionne pour référence.


      Voici les détails au sujet de la traduction du verbe « to push ». Il se traduit littéralement par « pousser ». Le « Glossaire Celog des termes officiels de l'informatique » (page web) formule une traduction intelligente de l'expression « push technology » : « Distribution sélective » (avec deux synonymes : « diffusion sélective » , « distribution personnalisée »).

      Pour trouver cette traduction convenable de « to push », j'ai consulté les ressources suivantes :

      • l'entrée « push » de Dicofr.com, le « Dictionnaire de l'informatique et d'Internet » ;
      • l'entrée « push » de Jargonf.org, « Le Jargon Français, dictionnaire d'informatique francophone, version 4.2 » ;
      • l'entrée « push » (chercher dans la page) du « Glossaire Celog des termes officiels de l'informatique » (composé notamment des termes retenus par la Commission générale de terminologie et de néologie, il intègre les définitions publiées dans les avis parus dans quelques JO mentionnés, s'étalant de 1997 à 2003). Note : CELOG est un centre d’expertises informatique indépendant spécialisé dans la preuve immatérielle, créé en 1976.
      • [^] # Re: Mettre à jour les navigateurs ???

        Posté par . Évalué à 1 (+5/-1).

        Je note que la page wiki dédiée aux traductions classiques ne contient pas la traduction de « push ».

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

          Posté par . Évalué à -5 (+3/-5). Dernière modification le 29/11/18 à 16:38.

          [ Réflexion à propos de la mise à jour du wiki pour la traduction de « push » ]

          J'ai fait un gros travail d'analyse complémentaire et je propose d'ajouter la ligne suivant dans le wiki :

          • push : [to push] empiler (dans le contexte de l'ajout d'une information sur le haut d'une pile, en mémoire — antonyme : « to pop », dépiler) / distribuer (ou diffuser) sélectivement (dans le contexte d'un serveur qui envoie des données à l'utilisateur, sans sollicitation particulière préalable de celui-ci) ;

          Pour référence (en complément des références fournies au commentaire grand-parent) :

          • l'article Pile (informatique) (section Primitives) propose les termes « empiler » / « dépiler » pour traduire « to push » / « to pop ».

          • je note à propos de « dépiler » que :

            • l'entrée « dépiler » sur CNRTL ne renvoie pas du tout au même concept (je considère que c'est un défaut de mise à jour). En effet, les acceptions proposées (verbe transitif) sont : « abattre les piliers ménagés dans une partie de mine ou de carrière qu'on n'exploite plus ») ; « faire tomber le poil ou les cheveux » (à la forme pronominale : « perdre son poil ») ; « enlever tous les poils [des peaux] en les raclant` » ;
            • il n'y a pas d'entrée « désempiler » sur CNRTL, quel que soit le dictionnaire ;
            • l'entrée « dépiler » du Wictionnaire propose les mêmes acceptions que CNRTL auxquelles s'ajoute celle que nous cherchons : « (Régionalisme) ou (Populaire) Désempiler » ;
            • l'entrée « désempiler » du Wictionnaire indique « faire en sorte que ce qui avait été empilé ne le soit plus ».
          • à propos des substantifs de « to push » et « to pop », il y a quelques difficultés :

            • il y a une difficulté de désambiguïsation avec la traduction du substantif de « to push » (push est un verbe ainsi qu'un nom) : « empilement » sur CNRTL, dans l'acception A, présente une ambiguïté d'interprétation en français, car il s'agit de l'action d'empiler, mais aussi de son résultat (« action d'empiler (des éléments concrets ou abstraits) ; résultat de cette action »), pouvant mener à une interprétation erronée, car « to push » ne revoie qu'à l'action d'empiler, pas au résultat ; il existe aussi « empilage » sur CNRTL, qui est un « synonyme de empilement ».
            • il semble y avoir un manque d'officialisation de l'existence d'un antonyme pour « empilement » ou « empilage » (pour traduire le substantif de « to pop ») :
              • sur CNRTL, en n'en trouve pas ;
              • sur le Wictionnaire, on trouve « dépilage » (qui ne convient pas pour nous) et « dépilement » (ils sont déclarés synonymes et ne le sont que partiellement, seul « dépilement » convient pour notre usage) : « dépilage » ne correspond qu'aux actions de « dépiler une peau » et « dépiler une mine » (ce qui renvoie aux acceptions données par le CNRTL pour « dépiler ») ; je note que dans cet article du Wiktionnaire, on trouve le terme « dépilement » présenté comme un synonyme, alors que les acceptions de ce dernier terme incluent celle du premier, mais avec l'extension au concept du « retrait d’éléments empilés ».
              • je note que les termes suivants n'existent pas dans le Wiktionnaire : « désempilage », « désempilement » ;
    • [^] # Re: Mettre à jour les navigateurs ???

      Posté par . Évalué à 3 (+2/-0). 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 (+11/-0). 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 (page perso) . Évalué à 1 (+1/-0).

          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 (+3/-0).

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

  • # Historique?

    Posté par (page perso) . Évalué à 3 (+1/-0).

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

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

Envoyer un commentaire

Suivre le flux des commentaires

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