AFUP AFUP Day 2020 Baromètre Planète PHP

La parole est aux speakers : Kévin Dunglas

Jusqu’au Forum PHP 2019, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

Mercure, et PHP s'enamoure enfin du temps réel

Mercure est un protocole réseau qui permet aux serveurs de « pousser » très facilement des mises à jour en temps réel. C'est un remplaçant moderne de WebSocket, qui dispose d'une caractéristique qui va particulier intéresser les développeurs PHP : contrairenement à WebSocket, Mercure a été conçu dès l'origine pour fonctionner avec les plateformes qui ne peuvent pas maintenir de connections persistentes, telles que PHP, ou le "serverless".

Le protocole, qui a actuellement le statut d'Internet Draft, est donc très simple à utiliser avec notre langage préféré. Côté client, il est nativement supporté par tous les navigateurs navigateurs modernes, sans même avoir besoin d'un SDK ou d'un paquet NPM.

Mercure, contrairement à WebSocket, tire parti au maximum de HTTP/2 et de HTTP/3. Il est auto-découvrable, et a été conçu dès le départ pour être utilisé avec les API REST et GraphQL. Il dispose d’un mécanisme d’autorisation, supporte la re-connexion automatique et la récupération des messages perdus en cas de problème réseau.

Depuis quelques mois, Mercure est officiellement implémenté par API Platform et Symfony. Au cours de cette présentation, nous découvrirons ce nouveau protocole et ses intégrations PHP.

Katherine Johnson
24/10/2019
16:25-17:05

Tu es l’auteur du protocole Mercure ainsi que de son implémentation de référence, qu’est-ce qui t’a donné envie de faire tout ça ?

L’idée m’est venue alors que je travaillais d’un côté sur le support de GraphQL dans API Platform et de l’autre sur un meilleur support de HTTP/2 pour Symfony (cf ma conférence de l’an passée au Forum PHP).

Côté API Platform, je cherchais un moyen de supporter les subscriptions GraphQL. Grâce aux subscriptions un client peut s’abonner aux modifications apportées aux ressources. Dès qu’une ressource surveillée est modifiée, le serveur “pousse” en temps réel la nouvelle version aux clients, qui peuvent instantanément l’afficher.

La spécification GraphQL est agnostique du transport utilisé (le mécanisme de “push”), mais la plupart des implémentations utilisent WebSockets. Seulement API Platform est écrit en PHP… qui n’est pas du tout adapté à WebSockets. Premier problème : PHP – par design – n’est pas conçu pour maintenir des connexions persistantes et ne permet pas de partager un contexte entre plusieurs connexions simultanées. Second problème : WebSockets est un protocole différent de HTTP, il faut donc pouvoir basculer d’un protocole à l’autre en ré-utilisant la connexion TCP sous-jacente (via l’en-tête HTTP Upgrade). Mais, dans la plupart des configurations, PHP n’a pas accès directement à cette connexion TCP. C’est le serveur web (Apache, NGINX…) qui la maintient, et il n’est pas possible de l’”hijacker” pour basculer vers le protocole Websockets. Il existe bien des solutions comme Ratchet, qui contournent le problème en permettant d’implémenter des serveurs websockets exposés directement sur le réseau (sans serveur web frontal donc), mais elles sortent du setup standard qui fait la force de PHP, et sont bien moins performantes que les technologies conçues pour ce type d’usages (comme C, Rust ou Go).

En parallèle, côté Symfony, je travaillais sur le composant WebLink qui permet au framework de déclencher des Server Push, une nouveauté introduite par HTTP/2. Au cours de mes recherches sur HTTP/2, je me suis rendu compte que WebSockets et HTTP/2 ne faisaient pas bon ménage : HTTP/2 contient les primitives qui permettent de rendre obsolète WebSockets (multiplexing via les streams, support amélioré des connexions persistantes…), et il interdit le mécanisme d’upgrade. De fait – bien qu’une récente RFC vise à rendre compatible HTTP/2 et WebSockets (qui n’est pour le moment supportée par défaut par aucun navigateur)  – dans la plupart des cas il n’y a plus d’intérêt à basculer vers un autre protocole tel que WebSockets, beaucoup plus dur à implémenter et à sécuriser que HTTP.

Pour la petite histoire, bien que Mercure ait été initialement conçu afin d’implémenter les subscriptions GraphQL dans API Platform… personne ne l’a encore fait ! Si vous êtes en manque d’idées pour le Hacktoberfest, n’hésitez pas !

Quel est l’atout de Mercure par rapport à d’autres protocoles comme Websocket ?

Donc, au croisement de ces deux travaux, est né une idée : peut-être serait-il possible d’utiliser les nouvelles possibilités apportées par HTTP/2 pour proposer un protocole pour “pousser” des données d’un serveur vers un client. Ce protocole pourrait servir pour le mutations GraphQL, mais aussi pour toutes les API asynchrones ou de streaming (le serveur envoie les nouveautés vers le client, dès qu’elles sont disponibles), et même – pour la plupart des cas d’usage – remplacer WebSockets. Au fil des itérations, ce protocole est devenu Mercure. Ses avantages ?

    • contrairement au polling simple (l’action d’appeler une URL à intervalle régulier pour savoir si les données ont changées) :
      • il est performant, et encore plus quand utilisé avec HTTP/2
      • il permet d’économiser la batterie des périphériques recevant les push
      • il permet de faire du vrai temps réel
    • contrairement à WebSocket :
      • il est extrêmement facile à implémenter
      • côté serveur, un simple POST vers un “hub” Mercure (ou l’envoie d’un Server-Sent Event pour les langages n’ayant pas besoin de Hub, on y reviendra) suffit
      • côté client, parce que Mercure utilise les SSE, un événement JavaScript est déclenché dès qu’un message est reçu par le serveur, et l’on peut enregistrer une fonction de rappel pour y réagir
      • il est de haut niveau, et va, de manière transparente pour le développeur
      • se reconnecter automatiquement après un perte de réseau
      • récupérer les messages perdus pendant la coupure
      • il bénéficie d’un mécanisme d’autorisation (envoie de messages sécurisés à certains clients uniquement) natif
      • il utilise une simple connexion HTTP, donc passe tous les pare-feux, et bénéficie des capacités natives du protocole, telle que l’authentification
    • contrairement à Pusher, Firebase, AppSync et autre solutions propriétaires :
      • il est un protocole ouvert, publié via l’IETF
      • il ne nécessite aucun SDK ou paquet NPM, et est intégralement supporté par 100% des navigateurs modernes
      • l’implémentation de référence est disponible sous forme de logiciel libre

Cerise sur le gâteau, Mercure propose un mécanisme (optionnel) de hub, inspiré par celui du protocole WebSub (un protocole de “push” serveur à serveur qui venait d’être standardisé par le W3C). Grâce à ce Hub, il est possible d’utiliser Mercure extrêmement facilement même depuis les langages – tels que PHP – non-conçus pour pouvoir maintenir des connexions persistantes. C’est aussi un énorme avantage pour les architectures “serverless”, qui souffrent globalement des mêmes limitations que PHP (durée des connexions limitées, impossibilité de partager un contexte entre plusieurs connexions…).

Tu as créé le framework API Platform et le protocole Mercure, tu maintiens plusieurs composants Symfony, tu as travaillé sur la bibliothèque de cache React ESI… Quel est le prochain projet auquel tu réfléchis ?

Le prochain projet est déjà dans les cartons, et sera annoncé très prochainement ! Il s’appelle Vulcain (c’est un compagnon de Mercure) et il tire lui aussi partie des nouvelles capacités fournies par HTTP/2. Vulcain va permettre d’obtenir le même gain en terme de performances que ceux apportés par GraphQL (et même, en réalité, d’aller encore plus vite), tout en respectant totalement les principes des architectures REST, en autorisant à nouveau à utiliser toutes les capacités du protocoles HTTP qui sont gâchées par GraphQL (cache HTTP, URLs etc…).

En bref, grâce à Vulcain et à HTTP/2, vous allez pouvoir rendre vos API REST tout aussi rapides (voir plus rapides) que les APIs GraphQL ; tout en conservant la simplicité de REST / HTTP et en continuant à pouvoir utiliser vos outils préférés rendus inutilisables par GraphQL tels que Varnish, Kong, goaccess, etc…

Et Vulcain pourra être implémenté très facilement même par les API existantes, et même si elles sont écrites en PHP !

Le speaker

Kévin DUNGLAS
Kévin DUNGLAS
Kévin est le fondateur de la société autogérée Les-Tilleuls.coop. Il est membre de la core team Symfony, a créé le framework API Platform et le protocole Mercure. Il est également contributeur à plus d’une centaine de projets Open Source.

Autres interviews

En poursuivant votre navigation sur ce site, vous acceptez l’utilisation des cookies pour améliorer votre navigation. plus d'infos

1. Qu’est-ce qu’un cookie?

Un Cookie est un petit fichier texte enregistré sur votre terminal (ordinateur, tablette, smartphone, etc.), à l’occasion de la consultation d’un service en ligne grâce à votre logiciel de navigation. Il permet à son émetteur d’identifier le terminal dans lequel il est enregistré, pendant la durée de validité ou d’enregistrement du Cookie. Lors de la consultation de notre site Internet, des informations relatives à la navigation de votre terminal sont susceptibles d'être enregistrées dans ces fichiers dits "Cookies". Ces derniers sont installés sur votre terminal, sous réserve des choix que vous auriez exprimés concernant les Cookies et que vous pouvez modifier à tout moment.

2. A quoi servent les cookies émis sur notre site ?

Seul l’émetteur d’un cookie est susceptible de lire ou de modifier les informations qui y sont contenues.
Les cookies utilisés sur notre site permettent :

3. Vos choix concernant les cookies

Vous disposez de différents moyens pour gérer les cookies. Tout paramétrage que vous pouvez entreprendre sera susceptible de modifier votre navigation sur notre site et sur Internet en général et vos conditions d'accès à certains services de notre site nécessitant l'utilisation de cookies. Vous pouvez à tout moment exprimer et modifier vos souhaits en matière de cookies, par les moyens décrits ci-dessous. L'accord sur les cookies L'enregistrement d'un cookie dans un terminal est essentiellement subordonné à la volonté de l'utilisateur du terminal, que celui-ci peut exprimer et modifier à tout moment et gratuitement à travers les choix qui lui sont offerts par son logiciel de navigation. Si vous avez accepté dans votre logiciel de navigation l'enregistrement de cookies dans votre terminal, les cookies intégrés dans les pages et contenus que vous avez consultés pourront être stockés temporairement dans un espace dédié de votre terminal. Ils y seront lisibles uniquement par leur émetteur.

Le refus des cookies Si vous refusez l'enregistrement de cookies dans votre terminal, ou si vous supprimez ceux qui y sont enregistrés, vous ne pourrez plus bénéficier d'un certain nombre de fonctionnalités qui sont néanmoins nécessaires pour naviguer dans certains espaces de notre site. Tel serait le cas si vous tentiez d'accéder à votre compte ou à votre abonnement qui nécessite de vous identifier. Tel serait également le cas lorsque nous, ou nos prestataires, ne pourrions pas reconnaître, à des fins de compatibilité technique, le type de navigateur utilisé par votre terminal, ses paramètres de langue et d'affichage ou le pays depuis lequel votre terminal semble connecté à Internet. Le cas échéant, nous déclinons toute responsabilité pour les conséquences liées au fonctionnement dégradé de nos services résultant de l'impossibilité pour nous d'enregistrer ou de consulter les cookies nécessaires à leur fonctionnement et que vous auriez refusés ou supprimés. Les choix offerts par votre logiciel de navigation Vous pouvez configurer votre logiciel de navigation de manière à ce que des cookies soient enregistrés dans votre terminal ou, au contraire, qu'ils soient rejetés, soit systématiquement, soit selon leur émetteur. Vous pouvez également configurer votre logiciel de navigation de manière à ce que l'acceptation ou le refus des cookies vous soient proposés ponctuellement, avant qu'un cookie soit susceptible d'être enregistré dans votre terminal. Pour la gestion des cookies et de vos choix, la configuration de chaque navigateur est différente. Elle est décrite dans le menu d'aide de votre navigateur, qui vous permettra de savoir de quelle manière modifier vos souhaits en matière de cookies. Selon votre navigateur, consultez le lien ci-dessous pour configurer votre navigateur et refuser les cookies :