AFUP AFUP Day 2021 Baromètre Planète PHP

La parole est aux speakers : Kévin Dunglas

Jusqu’à l’AFUP Day 2021, 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

Arrêt du support de Server Push par Chrome : qu'est-ce que ça change pour l'écosystème PHP ?

Google a récemment annoncé qu’il allait retirer le support de Server Push de son navigateur vedette. Server Push est une technologie faisant partie des standards HTTP/2 et HTTP/3 qui permet d’améliorer les performances des sites et applications web. Server Push est largement implémenté dans l’écosystème PHP : il est supporté nativement par la plupart des serveurs web ainsi que par des outils populaires tels que Symfony et API Platform. C’est aussi le coeur de la spécification Vulcain qui permet de créer des API web très performantes et facile à mettre en cache.

Les ingénieurs de chez Google proposent d’utiliser trois technologies pour remplacer Server Push, qui seraient d’après-eux plus simple d’utilisation comme d’implémentation, et permettrait des gains de performance quasi-similaires à ceux de Server Push. Ces technologies sont les liens de type Preload, le code de retour HTTP « 103 Early Hints » et l’API JavaScript WebTransport. L’écosystème PHP ainsi que Vulcain supportent déjà les deux premières. La troisième pourrait permettre à terme - si elle est adoptée par les navigateurs et serveurs web - de proposer une alternative moderne (bien que bas niveau) à WebSocket.

Au cours de cette présentation, nous découvrirons les cas d’usage de chacune de ces technologies, nous les comparerons avec Server Push, et nous verrons comment les utiliser en PHP (côté client comme côté serveur). Nous verrons ensuite comment Vulcain en tire partie.

Lille
28/05/2021
10:10-10:50

Pour remplacer Server Push, tu nous parles d’une technologie qui proposerait une alternative moderne à WebSocket. Même si cette technologie est bas niveau, ne va-t-elle pas concurrencer le protocole Mercure que tu as mis en place ?

WebTransport est une expérimentation visant à ajouter à la plateforme web une API de très bas niveau, reposant sur QUIC, qui permet de créer des connexions où l’arrivée du message est garantie (à la TCP) ou non (à la UDP). Cette nouvelle API pourrait à terme remplacer les WebSockets, en réglant une partie des problèmes de WebSockets (compatibilité avec HTTP/3, modèle de sécurité natif…).

Mercure est un protocole de beaucoup plus haut niveau reposant sur HTTP (et en particulier les Server Sent Events) qui permet de très facilement de faire du “broadcast” de messages depuis un ou plusieurs serveurs vers l’ensemble des clients connectés.

Les deux technologies n’ont pas les mêmes cas d’usage et devraient plutôt être complémentaires :

  • WebTransport est adapté quand on souhaite un contrôle total et très précis de ce qui transite sur le réseau (jeux vidéo, live streaming vidéo…). Ce contrôle total permettra d’optimiser l’usage du réseau beaucoup plus finement que ce qu’il est possible de faire avec Mercure, mais vient avec une complexité beaucoup plus importante pour les développeurs.
  • Mercure en revanche est extrêmement simple à prendre en main, toute la complexité (autorisation, reconnexion en cas de perte de réseau, récupération des messages perdus en cas de déconnexion…) est “masquée” par les implémentations : côté serveur, une simple requête POST vers un “hub” permet d’envoyer un message qui est instantanément reçu sous la forme d’un évènement JavaScript dans tous les navigateurs actuellement sur le site. C’est particulièrement utile pour envoyer aux navigateurs les mises à jour des données qu’ils sont en train d’afficher (par exemple le stock d’un produit où les commentaires sous un article).

En bref WebTransport sera une brique permettant de construire des applications très optimisées pour des cas d’usage spécifiques, alors que Mercure est une solution clef en main qui répond aux besoins classiques en évitant au développeur de réinventer la roue.

Il y a 10 ans tu ouvrais ton premier repository pour authentifier un utilisateur. Aujourd’hui, si tu devais coder à nouveau un repository utilisateur, qu’est-ce qui changerait ?

Ce qui changerait, c’est que je ne le recoderais probablement pas de zéro ! J’essaierais de m’appuyer sur les standards en la matière que sont OpenID Connect et OAuth, et très certainement sur les briques de services qui implémentent ces spécifications tel que le logiciel libre Keycloack.

Dans certains cas – quand l’utilisateur ne s’authentifiera que depuis le site web, qu’il n’y a pas d’app mobile ou de connexion depuis des applications tierces – des solutions plus minimalistes suffisent. Les frameworks web populaires tels que Symfony et Laravel proposent désormais des briques bien conçues, testées et auditées pour gérer l’authentification et l’autorisation.

Il y a 2 ans, à l’AFUP Day Lille 2019, tu nous présentais la bibliothèque Panther. La version 1.0 est sortie récemment, quels sont les changements notoires que l’on trouve sur cette nouvelle version ?

Ça tombe bien que tu poses la question, car je viens justement de publier un article à ce sujet ! Je vous laisse le découvrir en anglais et en français.

Le speaker

Kévin DUNGLAS
Kévin DUNGLAS
Kévin est le créateur du framework API Platform ainsi que des projets Mercure et Vulcain. Il est également membre de la Core Team Symfony et a co-fondé la société autogérée Les-Tilleuls.coop.

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 :