Bienvenue à l'AFUP Day 2021 Lille !

Dans de nombreux frameworks PHP la notion de service s'est imposée. Nous avons tous dû déclarer de telles classes, et pourtant, la notion n'est pas évidente. Au jour le jour, on se demande ce que l'on met dedans, comment structure, comment diviser. Souvent, on cherche à les nommer et on ne trouve pas. Et parfois, on peste qu'ils sont difficiles à tester... Mais au fond, c'est quoi un service ? Est-ce qu'on ne bourrerait pas trop de choses dans cette notion ? Ou au contraire, est-ce qu'on n'oublierait pas l'essentiel ?

Ensemble, nous allons chercher et découvrir des réponses concrètes. Parfois via des patterns à redécouvrir, parfois via des best practices, et avec beaucoup de retours d'expériences bonnes ou mauvaises.

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.

Sortez vos casques, nous allons faire un tour sur ce chantier en cours qu'est la migration des applications Arte vers Kubernetes. Avant d'avoir des applications scalables et résilientes, un chantier d'infrastructure est nécessaire. Cependant, pour sortir d'un hébergement classique et entrer dans l'univers Kubernetes, nous devons nous poser les bonnes questions : quels en seront les avantages et inconvénients ? Est-ce que ce changement est vraiment nécessaire ? Quelles sont les étapes à suivre afin d'y parvenir ? Ce sont ces questions auxquelles nous avons tenté de répondre, afin de nous préparer au mieux à cette migration.

La majorité d’entre vous connaît ce constat, il suffit d’ouvrir les yeux sur l’open space : on dénombre peu de femmes en informatique… Et moi, en tant que femme, je souhaitais juste faire de l’info sans me laisser pousser la barbe.

Si je pouvais tout recommencer, quels conseils me donnerais-je pour faciliter mon parcours ? Des études à la vie active, du POC à la MEP, comment lever les points de blocage qui viennent se mettre dans le parcours d'une femme ?

Migrer une application d'un framework maison vers Symfony est devenu un classique dans le monde PHP. L'équipe PrestaShop a commencé une telle migration en 2016 avec la difficulté supplémentaire que l'application est un CMS open source PHP fondé en 2007.

Le chantier est immense, et nous procédons donc par étapes. C'est ici que l'introduction de CQRS dans notre architecture nous a grandement aidé à mettre en place une communication efficace entre les composants migrés et les composants legacy. Cette frontière est flexible et permet de remplacer un à un les composants legacy par des composants modernes avec une grande facilité.

Plutôt que de présenter CQRS qui a déjà été introduit, étudié et décrit par de nombreuses autre conférences, je propose d'aborder "le vif du sujet": les difficultés, les pièges, les erreurs que nous avons commises ... et (heureusement) les résultats positifs amenés par l'usage de CQRS.

Les situations de compétition ("race condition" en Anglais) sont un problème récurrent en informatique. Elles existent à tous les niveaux, depuis le noyau linux, jusqu'a votre application en passant par la base de données.

Elles se caractérisent par un résultat différent selon l'ordre dans lequel agissent les acteurs du système. Une situation de compétition peut survenir dès que plusieurs acteurs tentent d'accéder au même moment à une ressource partagée (fichier, ligne dans une base de données, etc.) et qu'au moins l'un d'entre eux est susceptible de modifier son état.

Des solutions existent depuis très longtemps pour pallier ces problèmes. Symfony a introduit le composant Lock dans sa version 3.4, puis le composant Semaphore dans sa version 5.2.

Cette conférence a pour objectif de vous fournir les bons outils pour éviter toutes race condition, en utilisant le composant Lock ou Semaphore en fonction des situations rencontrées.

Depuis quelques années déjà, beaucoup d'entre nous avons vu passer ou utiliser des jetons un peu spéciaux : les JSON Web Tokens ou JWT. Ce standard de jeton est très pratique pour faire transiter de l'information de manière fiable. Ces jetons sont souvent utilisés pour assurer l'authentication auprès de de web services, de micro-services ou de SSO dans le cadre d'OpenID Connect. De plus, on voit beaucoup de JWS (des jetons signés), mais ce n'est pas la seule implémentation qui existe. En réalité, la spécification JWT est nettement plus vaste que ce que l'on peut penser. Je vous propose de découvrir des aspects de JWT moins connus que l'utilisation classique.

Vous avez peut-être déjà entendu parlé de RDF: Resource Description Framework. C'était peut-être en implémentant les "rich snippets" pour Google, ou bien en cherchant de détails sur cette bête étrange qu'est JSON-LD qui est exposé par ApiPlatform? Dans cette présentation vous allez comprendre d'où ce framework vient, ces différents formats (RDFa, Turtle, JSON-LD), ces différences fondamentales avec la majorité des structures de données d'aujourd'hui, ces usages anciens et nouveaux et comment l'utiliser en pratique.

PHP Collection est une bibliothèque utilitaire fonctionnelle pour PHP supérieure à 7.1.3.

C'est similaire à d'autres bibliothèques de collections basées sur des tableaux PHP classiques, mais avec un mécanisme "lazy" (paresseux) sous le capot qui s'efforce de faire le moins de travail possible tout en étant aussi flexible que possible.

Des fonctions comme array_map (), array_filter () et array_reduce () sont excellentes, mais elles créent de nouveaux tableaux et tout est executé directement avant de passer à l'étape suivante. La librarie PHP Collection exploite les générateurs, les itérateurs et les "yield" PHP pour vous permettre de travailler avec de très grands ensembles de données tout en maintenant l'utilisation de la mémoire aussi faible que possible.

Par exemple, imaginez que votre application a besoin de traiter un fichier journal de plusieurs gigaoctets tout en tirant parti des méthodes de cette bibliothèque pour analyser le fichier. Au lieu de lire et de stocker le fichier entier en mémoire à la fois, cette bibliothèque peut être utilisée pour ne conserver qu'une petite partie du fichier en mémoire à un moment donné et executer des opérations sur l'ensemble des données.

Vous pouvez trouver le lien de cette librairie ici: https://github.com/loophp/collection