Retour sur l’AFUP Day Toulouse & Tours 2021 !

Par Matthéo et Mathieu, Lead Developers à l’Agence Dn’D

Comme chaque année, l’AFUP ouvre ses portes aux passionnés de PHP. Cette année, l’Agence Dn’D a participé aux éditions de Tours et Toulouse se tenant le vendredi 11 juin 2021. Compte-tenu de la situation sanitaire actuelle, les conférences se déroulaient à distance en visio, ce qui n’a pas empêché les intervenants de distiller des informations toutes plus intéressantes les unes que les autres !

De nombreux sujets ont été abordés durant ces différentes sessions. Les thématiques concernaient les évolutions technologiques de notre quotidien, la vie en agence, l’architecture des projets, ou des sujets plus spécifiques tels que la reconversion professionnelle dans le milieu du web.

Dans cet article nous allons nous focaliser sur 2 conférences marquantes de cette édition : le Protocole HTTP/3 et le Legacy !

HTTP/3: C’est une question de transport !

Cette conférence a été menée par Benoît Jacquemont, CTO chez notre partenaire Akeneo. Le sujet traitait du protocole HTTP/3, remplaçant du HTTP/2.
Depuis toujours, HTTP se base sur le protocole TCP amenant son lot de problématiques. À l’heure actuelle voici comment fonctionne HTTP/2 avec TPC.
Avant d’effectuer une requête HTTP, une demande de connexion est réalisée via TCP en plusieurs étapes :

• 1.

Navigateur vers Client

• : Sync

• 2.

Client vers Navigateur

• : Sync ACK

• 3.

Navigateur vers Client

: ACK

De base, les échanges TCP sont en clair, c’est pour cette raison que l’on utilise TLS en plus afin de les chiffrer. Cela a pour effet d’ajouter 3 échanges supplémentaires entre le navigateur et le client.

Les latences d’échange de messages TCP (source : researchgate.net)

Cela pose deux problématiques :

• 1. Un problème de

bande-passante

• ,

• 2. Un problème de

latence

.

La problématique de bande-passante correspond à la quantité de données transmises, cela peut donc facilement être résolue par l’utilisation de connexions plus puissantes telle que la fibre optique par exemple. La latence, quant à elle, dépend d’une notion universelle compliquée à résoudre : la vitesse de la lumière (vitesse à laquelle les données vont être transmises !).

Les différentes releases de HTTP ont toujours été constituées dans un unique but : réduire et optimiser les latences dues à TCP. L’idée derrière cette nouvelle release HTTP/3 est de remplacer TCP par un protocole appelé QUIC se basant sur UDP. C’est pour cela que HTTP/3 n’est pas une nouvelle version de HTTP mais simplement HTTP/3 = HTTP/2 + QUIC.

Ce protocole n’est pas nouveau et est déjà utilisé depuis les années 2013 par certains navigateurs tel que Chrome sur ses solutions comme Gmail, Meet ou encore Drive. Fondamentalement HTTP/3 ne changent pas les sémantiques mises en place par HTTP/2, ce qui permet un implémentation facilitée. Cependant, plusieurs choses sont à prendre en compte comme la compatibilité avec les infrastructures réseaux :

• Varnish : ne supporte toujours pas QUIC. C’est un sujet en cours de discussion depuis 3 ans afin de décider comment l’implémenter.
• NGINX : l’implémentation est en cours sur leur branche de développement et est prête à être livrée dans la release stable.
• H2O : solution de serveur web principalement utilisé par le CDN Fastly (en phase expérimentale).
• Apache : pas de communication à l’heure actuelle sur ce sujet.
• Firewall : les port TCP 80/443 sont généralement ouverts mais bloquent potentiellement les autres, dont ceux utilisés par QUIC.
• CDN : la plupart des CDN actuels utilisent déjà ce protocole en interne.
• CPU : sur UNIX, les premiers benchmarks font ressortir une consommation CPU supérieure de 30 % pour la lecture des paquets UDP contrairement aux paquets TCP.

Quel est donc l’intérêt de QUIC vis-à-vis de TCP ?

—

QUIC, contrairement à TCP, intègre directement le chiffrement et le transport des données dans le même échange, supprimant ainsi les 3 échanges supplémentaires dû à l’utilisation de TLS.

TCP découpe en paquets le message envoyé initialement, cependant si différents problèmes comme ceux relatifs au réseau sont rencontrés, les paquets n’arrivent pas dans le bon ordre. TCP dispose des capacités nécessaires pour les ranger, mais cela prend du temps et implique que tous les paquets doivent être réceptionnés avant d’afficher la ressource. De son côté, QUIC utilise UDP pour gérer plus facilement et efficacement la transmission des paquets.

En termes de fonctionnement, TCP utilise le noyau de l’OS pour reconstruire les paquets et a donc un lien très fort avec le réseau. Par exemple, dans le cas d’un changement de réseau, cela entraîne une perte de paquet, ce qui a pour conséquence de devoir recommencer l’ensemble du processus (cas que l’on renconre quand on passe sur nos téléphone du WIFI à la 4G par exemple). Le navigateur est alors contraint d’attendre que tous les paquets TCP soient disponibles avant de pouvoir afficher les informations. QUIC ne se base pas sur le réseau, mais sur le navigateur et le serveur, ce qui permet d’éviter les pertes problématiques comme expliquées avec TCP. Avec TCP, la page ne s’affichera donc que si tous les paquets sont présents.

Les premiers benchmarks indiquent un gain de temps au chargement de l’ordre de 50 %.

Les caractéristiques de TCP/TLS et celles de QUIC

Quelles sont les nouveautés à venir ?

—

Le support des librairies, par exemple la librairie cURL qui implémente la compatibilité QUIC depuis sa version v7.66. La date de release n’a pas encore été officiellement communiquée cependant depuis le 27 mai 2021, QUIC a été standardisé via le RFC 9000. Nous pouvons donc nous attendre à une accélération de la mise en place de ce protocole et espérer une sortie fin 2021 – début 2022 !

Dompter le “legacy”

Voici un sujet récurrent dans la quasi-totalité des entreprises digitales et technologiques : le Legacy. Au fur et à mesure de la vie d’un projet, les temps de développement ont tendance à augmenter : cela est notamment dû à la complexité grandissante et à l’augmentation de la quantité des tests réalisés. Nous avons pu avoir un retour d’expérience fort intéressant sur la manière dont cela peut-être géré et les outils/méthodes mis en œuvre pour traiter ce sujet.

État des lieux

—

Dans un premier temps, il faut dresser un bilan de l’existant :

• Évaluer la dette technique (via la mise en place d’un SonarQube par exemple).
• Créer des MCD (= Modèle Conceptuel de Données) afin d’identifier ce que fait l’application. Cela permet également de recouper avec le métier les informations sur les différentes fonctionnalités.
• Cerner les fonctionnalités qui ont le moins de dépendances.
• Mettre en place, si ce n’est pas déjà le cas, de tests E2E (= End-to-End). Dans ce cas de figure, il peut être judicieux d’utiliser Cypress ou Quanta afin d’éviter les régressions sur des chemins critiques.
• Identifier les fichiers les plus souvent mis à jour.

Le “smoke testing”

—

L’intérêt de cette méthode est de tester la disponibilité sur un maximum d’URLs en GET du site web. L’objectif visé est de n’obtenir uniquement des “200” sur chacune des URLs testées.

Les avantages sont multiples :

• Éviter les régressions,
• Identifier les effets de bords,
• Une mise en place rapide,
• Réduction des risques et des dépendances de code.

L’inconvénient est que l’ensemble des éléments n’est pas testé, ne serait-ce que parce que seules les URLs accessibles en GET sont vérifiées.

Le “golden master”

—

Lors de la refonte d’un projet (bien souvent en parallèle), des modifications peuvent être apportées au code. Cela crée alors 2 cycles de vie pour le projet : l’un en cours de vie et l’autre en refactorisation. Le but d’un “golden master” est de conserver une version figée de son code et de s’y référer en permanence, afin de s’assurer de ne faire que de la refactorisation.
L’entrée et la sortie doivent être identiques entre le “golden master” et la refactorisation. C’est à ce moment-là que l’on va pouvoir écrire des tests unitaires si ce n’est pas déjà en place.

Les test unitaires

—

Les tests unitaires ont pour but de tester le bon fonctionnement d’une portion de code (une classe par exemple). L’avantage est qu’ils sont simples à écrire et poussent le développeur à respecter le principe de responsabilité unique (SOLID). En clair, si un test unitaire ne peut pas être écrit, c’est que le code est mal conçu.

Les test E2E

—

Les tests End-to-End représentent une véritable documentation vivante. En les utilisant, on offre la possibilité à une équipe métier (pas uniquement des développeurs) de créer des scénarios de tests et de s’assurer qu’au fil de la refactorisation, ils restent valides.

Les ADR

—

L’intérêt des ADR est d’avoir une documentation toujours à jour, consultable et éditable aussi bien par l’équipe technique que métier. Il s’agit plus d’une méthodologie de documentation que d’un outil en tant que tel. Si vous souhaitez en savoir plus sur le sujet, n’hésitez pas à consulter l‘article de Stack-Labs “Les ADR pour garder une trace de tous les choix d’architecture”.

Le mot de la fin concernant le Legacy

—

La refactorisation est un sujet long et assez coûteux ! Elle doit être progressive car il n’est pas envisageable de figer une plateforme sur des mois, voire des années. L’utilisation de Strangler Pattern associée à des tests de non-régression et E2E sont alors nécessaires afin de parvenir au but final : se débarrasser du Legacy.

Conclusion

Ce fut un réel plaisir de participer à cette édition de l’AFUP Day Toulouse & Tours 2021 ! Merci aux équipes organisatrices de l’événement et aux différents intervenants qui ont transmis de précieuses informations pour mener à bien des projets digitaux dans les meilleures conditions. Si vous souhaitez visionner les autres conférences de l’événement, n’hésitez pas à consulter les replays disponibles sur la chaîne YouTube de l’AFUP ainsi que l’ensemble des présentations sur le site de l’AFUP !

Vous avez un projet de développement E-Commerce ?

Spécialisé dans le E-Commerce, Dn’D accorde une attention particulière aux meilleures pratiques de développement technologique. Grâce à nos équipes certifiées sur des solutions reconnues telles qu’Adobe Commerce (Magento Commerce) ou encore OroCommerce, nous vous accompagnons dans le conseil, la conception, la maintenance de vos sites E-Commerce B2C et B2B. N’hésitez pas à nous contacter via le formulaire ci-dessous !