J’ai récemment publié un nouveau protocole ouvert nommé Mercure, ainsi qu’une implémentation de référence écrite en Go.
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.
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 :
- une application de discussion instantanée en 25 lignes de Python et 35 de JavaScript ;
- synchronisation en temps réel d’une Progressive Web App et d’une application mobile React Native.
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
- Journal à l’origine de la dépêche (276 clics)
- Dépôt GitHub du projet (289 clics)
- Présentation complète avec exemples (434 clics)
# très jeune ?
Posté par Jarvis . Évalué à 4.
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 Tit . Évalué à 10. Dernière modification le 28 novembre 2018 à 10:37.
Mercure ? dans les 4,5 milliards d'années à peu près ;-)
[^] # Re: très jeune ?
Posté par FantastIX . Évalué à 3. Dernière modification le 01 décembre 2018 à 16:36.
Il parlait de Mercure, la proto-colle, pas la proto-planète!
-->[]
[^] # Re: très jeune ?
Posté par Gabin_2 . Évalué à -4.
Ç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 windu.2b . Évalué à 5.
"Moi, quand je n'ai rien à dire, je veux que ça se sache !", Raymond Devos
[^] # Re: très jeune ?
Posté par Gabin_2 . É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 xryl669 . Évalué à 1.
Comment vous faîtes pour Edge qui ne supporte pas les SSE ? C'est du polling ?
[^] # Re: Support pour Edge ?
Posté par Benoît Laurent (site web personnel) . Évalué à 3. Dernière modification le 28 novembre 2018 à 14:20.
Il y a une petite note avant les schémas :
[^] # Re: Support pour Edge ?
Posté par Kerro . Évalué à 3. Dernière modification le 28 novembre 2018 à 22:06.
C'est un outil pour navigateur web, donc la question n'a pas de sens.
# Mettre à jour les navigateurs ???
Posté par dinomasque . É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 Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -6. Dernière modification le 29 novembre 2018 à 16:38.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mettre à jour les navigateurs ???
Posté par Franck Routier (Mastodon) . Évalué à 3. Dernière modification le 28 novembre 2018 à 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) :
[^] # Re: Mettre à jour les navigateurs ???
Posté par Tangi Colin . Évalué à 10. Dernière modification le 29 novembre 2018 à 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
WebSocket : Socket TCP avec ouverture de connexion en "HTTP/1".
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).
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 riri le breton (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 bobble bubble . Évalué à 4.
Parler de confusant est assez déroutant… mais je te rejoins sur le fond
[^] # Re: HS
Posté par Kerro . Évalué à 6.
Je dirais même plus : confusant est malaisant.
[^] # Re: HS
Posté par FantastIX . Évalué à 3.
En effet, quoi qu'on fût…
# Historique?
Posté par devnewton 🍺 (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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.