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.
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 :
- une application de chat app en 25 lignes de Python et 35 de JS
- synchronisation en temps réel d'une Progressive Web App et d'une app mobile React Native
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 Yves (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é ?
[^] # Re: Impressionnant !
Posté par giorgiolino . Évalué à 5.
Salut @Yves.
Concernant
C'est déjà fait --> https://datatracker.ietf.org/doc/draft-dunglas-mercure/
# Courtier de message?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Quel est la différence avec ce que propose ActiveMQ et les autres messages brokers du même genre?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Courtier de message?
Posté par Kévin Dunglas (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).
[^] # Re: Courtier de message?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
C'est trivial avec les connecteurs d'ActiveMQ (http://activemq.apache.org/ajax.html ou http://activemq.apache.org/websockets.html), de Pulsar (https://pulsar.apache.org/docs/latest/clients/WebSocket/) ou RabbitMQ (https://www.rabbitmq.com/web-stomp.html).
Qu'est-ce que Mercure apporte de nouveau ou de plus? Peut être pour Kafka qui ne semble pas avoir de connecteur intégré?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Courtier de message?
Posté par barmic . Évalué à 3. Dernière modification le 28 novembre 2018 à 07:35.
Les connecteurs que tu présente utilisent websocket ou du long polling. Mercure remplacé websocket avec à minima l'intérêt de fonctionner en http 2 et 3.
Donc on pourrait voir apparaître des connecteurs mercure pour activemq ou rabbitmq, c'est juste pas les même couches réseau.
[^] # Re: Courtier de message?
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
Je n'ai pas trop suivi: pourquoi les websockets c'est pas bien?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Courtier de message?
Posté par barmic . Évalué à 4.
C'est pas compatible http 2 ni http 3 par exemple.
[^] # Re: Courtier de message?
Posté par devnewton 🍺 (site web personnel) . Évalué à -2. Dernière modification le 28 novembre 2018 à 10:43.
Du coup, http[23], c'est le mal!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Très intéressant !
Posté par Stéphane ESCAICH (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 Kévin Dunglas (site web personnel) . Évalué à 1.
Oops 🤭. Merci pour les corrections !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Coquilles typographiques
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
# Pas mal du tout
Posté par Christophe B. (site web personnel) . Évalué à 5.
Bon c'est pas trop ma spécialité mais j'aimerais juste comprendre un peu plus :
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 Tonton Th (Mastodon) . Évalué à 5. Dernière modification le 28 novembre 2018 à 09:11.
Pourquoi est-ce une « bonne chose » ?
[^] # Re: Pas mal du tout
Posté par El Titi . Évalué à 5.
Charles Bronson est mort ?
On me dit jamais rien à moi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.