Notre retour du Symfony Live 2018

Pour cette 10e édition du Symfony Live Paris, nous avons une nouvelle fois répondu présents et avons eu la chance d’assister à de nombreuses conférences de qualité. Voici notre retour au sujet des conférences auxquelles nous avons assisté, et ce que nous y avons appris.

Section intitulée symfony-4Symfony 4

Les festivités ont commencé par la keynote de Fabien Potencier sur la version 4 de Symfony qui est sortie fin novembre 2017.

Fabien nous a rappelé ce que signifiait Symfony 4 :

• Symfony 3.4 LTS ;
• Moins toutes les fonctionnalités dépréciées supprimées ;
• Moins le LTS (long term support) ;
• Avec PHP 7.1 minimum ;
• Avec une nouvelle façon de travailler avec Flex.

Grâce à l’utilisation de Flex, Symfony 4 ne dépend plus de symfony/symfony 👏 et permet de partir sur une base plus petite, type micro-framework, et d’ajouter ce dont vous avez besoin. Nous avons pu apprendre qu’à partir de juin 2018, Silex (Le micro-framework basé sur les composants de Symfony) ne sera plus maintenu, au profit de cette version 4 qui en remplit le rôle.

Une astuce a été donnée pour faciliter le passage de Symfony 3.4 à Symfony 4.

$ composer fix-recipes

Cette commande va parser le composer.json de votre projet et installer les recettes qui n’ont pas encore été installées.

MakerBundle prend la place de SensioGeneratorBundle qui permet de simplifier énormément la création de différents type de fichiers (commandes, entités, controller, twig extension, event subscriber, …).

Nous avons eu aussi la présentation d’un service payant pour détecter des futures potentielles failles de sécurité liées aux dépendances. Cet outil fonctionne avec un système d’abonnement. À intervalle régulier, il va vérifier que les dépendances de votre projet ne possèdent pas de faille de sécurité. C’est particulièrement utile pour les projets livrés à un client et pour lequel plus aucun développement n’est en cours. La commande security:check n’est donc plus exécutée par l’intégration continue. Cet outil permettra d’être alerté en cas de faille de sécurité sur l’une des dépendances. Cela peut assurer une certaine sérénité après la livraison d’un projet à son client. Il s’agit aussi d’une opportunité d’aider financièrement le projet Symfony, le prix de l’abonnement étant libre.

Section intitulée a-rel-nofollow-noopener-noreferrer-href-https-speakerdeck-com-de-la-tech-architecture-modulaire-grace-a-symfony-et-lecosysteme-open-source-architecture-modulaire-aArchitecture Modulaire

Marc Weistroff a évoqué avec nous la migration de Mopro (closed source) vers AudienceHero (open source) et la méthodologie qu’il a employé.

Nous retiendrons principalement de cette conférence le système de chargement dynamique de module basé sur registerForAutoconfiguration qu’il a utilisé.

Section intitulée a-rel-nofollow-noopener-noreferrer-href-https-welcomattic-github-io-traduire-efficacement-une-app-symfony-traduire-efficacement-une-application-symfony-aTraduire efficacement une application Symfony

Mathieu a eu la chance de pouvoir parler de notre workflow de traduction appliqué aux projets Symfony. L’état de l’art actuel consiste à dé-corréler le code et les traductions le plus possible, en proposant un stockage dédié ou externalisé. Il n’est alors plus nécessaire de faire intervenir un développeur pour modifier un texte en production !

La conférence de Mathieu délivre aussi de nombreux conseils sur l’organisation, les nomenclatures et autres conseils techniques sur l’internationalisation de vos applications.

Section intitulée a-rel-nofollow-noopener-noreferrer-href-https-speakerdeck-com-mykiwi-outils-pour-ameliorer-la-vie-des-developpeurs-symfony-outils-pour-ameliorer-la-vie-des-developpeurs-symfony-aOutils pour améliorer la vie des développeurs Symfony

Romain Gautier nous a présenté les outils mis en place par SensioLabs sur l’ensemble des projets clients. Rien de très révolutionnaire pour nous, mais de bons rappels :

• git ;
• git hook (avec un notamment un post-checkout hook permettant de proposer le composer install automatiquement) ;
• Fixtures (Faker, Alice) ;
• Migrations ;
• Tests ;
• Makefile ;
• Docker ;
• Intégration et déploiement continu.

La mise en place de fixtures avec Alice est aussi notre choix de prédilection. En revanche, il n’est plus nécessaire d’utiliser AliceBundle comme recommandé dans la conférence, nous utilisons simplement Alice qui intègre son propre bridge Symfony.

Mettre en place des migrations est simple avec Doctrine migration. Il a été souligné que l’utilisation du rollback avec la méthode down n’est finalement jamais utilisé… En plus des changements de schéma, c’est tous les changements de données qu’il faudrait être capable d’annuler, et cela n’est pas aisé, la recommandation est donc de ne plus coder cette méthode !

L’utilisation d’un fichier Makefile permet de simplifier les commandes saisies par les développeurs, de les grouper, et d’automatiser beaucoup de choses dans un projet, au profit d’un README d’une seule ligne. Avec un fichier Makefile, il sera par exemple possible de faire make install pour installer correctement le projet. La pratique n’est pas nouvelle, mais vous trouverez de très bons exemples sur le Github de Romain.

Section intitulée design-applicatif-et-architectureDesign applicatif et architecture

Un retour d’expérience d’OpenClassrooms sur le développement d’une application durant quatre ans avec le pattern Clean Architecture.

Durant sa présentation, Romain Kuzniak a comparé quatre types de pattern de manière didactique, en nous présentant leurs avantages et inconvénients :

Section intitulée a-rel-nofollow-noopener-noreferrer-href-https-github-com-romainkuzniak-symfony-mvc-mvc-aMVC

Avantages	Inconvénients
Simple	Difficile à tester
Séparation Domaine / Présentation	Pas de séparation de l’infrastructure
	À l’origine, design pour GUI
	Indice de changement : BAD

Section intitulée a-rel-nofollow-noopener-noreferrer-href-https-github-com-romainkuzniak-symfony-n-tiers-service-layer-aService Layer

Avantages	Inconvénients
Séparation Data / Domaine / Présentation	Pas de réutilisabilité indépendante
Séparation Domaine / Présentation	Pas de séparation de l’infrastructure
	Ne propose pas de gestion séparée des règles métier et applicatives
	Indice de changement : MEDIUM

Section intitulée a-rel-nofollow-noopener-noreferrer-href-https-github-com-romainkuzniak-symfony-ddd-domain-driven-design-ddd-aDomain Driven Design (DDD)

Avantages	Inconvénients
Grande ré-utilisabilité	Beaucoup de classes
Séparation métier / applicatif / présentation	Coût de développement
Séparation de l’infrastructure (Framework, DB, …)	Pas de SRP dans la couche application
	Indice de changement : GOOD

Section intitulée a-rel-nofollow-noopener-noreferrer-href-https-github-com-romainkuzniak-symfony-clean-architecture-clean-architecture-aClean Architecture

Avantages	Inconvénients
Grande ré-utilisabilité	Encore plus de classes
Séparation data / métier / applicatif / présentation	Coût de développement
Séparation de l’infrastructure (Framework, DB, …)	Peu de littérature
Principes S.O.L.I.D	Indice de changement : EXCELLENT
Architecture montrant son intention

Section intitulée conclusionConclusion

Il ne faut pas appliquer bêtement un design pattern. Il faut avant tout se poser quelques questions comme, par exemple, quelle va être la durée du projet, pour ensuite choisir quel type d’architecture. Pour des petits projets, il n’y a aucun intérêt à faire du DDD ou de la clean architecture. Pour les très gros projets, la question de faire de la Clean Architecture peut faire sens.

Section intitulée mutation-testingMutation Testing

Cette conférence met en évidence le coût que peut avoir un projet si nous ne nous préoccupons peu ou pas de sa qualité. Un bug détecté durant la phase de développement mais non traité sera très vite très coûteux, sous différentes formes :

• coûts de debug ;
• coûts de réparation ;
• dette technique.

À priori, pour des applications à maintenir sur le long terme, il est préférable d’aller vers un maximum de tests (intelligemment). Au-delà de ça, même avec un code testé, peut-on être persuadé d’avoir des tests fiables ?

Le but des mutations est d’introduire plusieurs bugs dans notre application par le biais de différents mutants, afin de valider que nos tests détectent bien ce changement de comportement !

Exemple de mutation :

Original	Mutant
$this->count++	$this->count--
true	false
> 0	< 0

Une fois que les mutations ont été ajoutées dans le code, l’outil va relancer les tests et s’assurer que les mutants sont bien « morts », c’est à dire que la suite de tests ne passe plus.

Bien que le mutation testing ne soit pas vraiment nouveau en PHP, Théo Fidry nous a montré comment nous pouvons les mettre en place avec infection/infection.

Section intitulée a-rel-nofollow-noopener-noreferrer-href-https-speakerdeck-com-nicolasgrekas-tirer-le-maximum-du-moteur-php-7-lexemple-de-symfony-tirer-le-maximum-du-moteur-php-7-aTirer le maximum du moteur PHP 7

Cette conférence a pour but de montrer la grande évolution des performances de PHP, mais aussi celles de Symfony 4, avec ce benchmark à l’appui.

Nicolas Grekas nous a fait un retour sur le travail qu’il a effectué pour améliorer les performances de Symfony avec PHP 7. Sur certaines fonctions par exemple, ajouter un \ devant le nom de la fonction va améliorer énormément les performances.

Depuis PHP 7.0, certaines fonctions sont directement remplacées par des opcodes plus optimisés (au lieu de passer par des fonctions internes un peu plus gourmandes), produisant un code beaucoup plus rapide. Pour que cela fonctionne, ces fonctions doivent être référencées dans l’espace de noms racine au moment de la compilation. Par exemple, les opcodes compilés par PHP pour l’instruction suivante is_array([]); seront différents:

Sans \ :

line     #* E I O op                           fetch          ext  return  operands
-------------------------------------------------------------------------------------
   5     0  E >   INIT_NS_FCALL_BY_NAME
         1        SEND_VAL_EX                                              array
         2        DO_FCALL                                      0
   9     3      > RETURN                                                   1

Avec \ :

line     #* E I O op                           fetch          ext  return  operands
-------------------------------------------------------------------------------------
   5     0  E >   TYPE_CHECK                                    7  ~0      array
         1        FREE                                                     ~0
   9     2      > RETURN                                                   1

Vous pouvez retrouver la liste des fonctions disponibles sur cette PR. D’ailleurs, depuis quelque temps, nous pouvons retrouver cette astuce appliquée sur les PR de Symfony.

Cependant, ajouter un backslash devant toutes les autres fonctions PHP n’a aucun intérêt. Il vaut mieux garder son code lisible.

Il a aussi pu nous montrer qu’avoir un gros fichier sera plus long à compiler qu’un fichier avec plusieurs require à l’intérieur 👍 !

Cette technique est utilisée depuis la version 3.4 de Symfony pour compiler le conteneur d’injection de dépendances. Néanmoins, cette optimisation ne devrait pas impacter votre façon de travailler car, de nos jours, nous utilisons l’autoloader de Composer et nous ne faisont plus de require à la main.

Lorsque nous utilisons PHP en CLI, l’opcode n’est pas utilisé (car il n’existe pas de mémoire partagée comme avec PHP-FPM), mais il est tout à fait possible de pouvoir le stocker (dans un fichier) soi-même.

Nicolas nous a aussi expliqué l’intérêt des tableaux statiques. Ce sont des tableaux qui ne comportent aucune variable. Ces tableaux sont fortement optimisés par PHP lors de la compilation. Un gros travail d’optimisation dans Composer a pu être effectué grâce à ces techniques.

Section intitulée a-rel-nofollow-noopener-noreferrer-href-https-slideshare-net-samuelroze-symfony-messenger-queues-workers-more-symfony-messenger-aSymfony Messenger

Samuel Roze a introduit lors de cette conférence le nouveau composant très demandé, Messenger.

Ce composant pourrait à terme remplacer des librairies existantes déjà présentes dans la communauté (Swarrot ou RabbitMqBundle).

Ce composant sera disponible dans la version 4.1 en « experimental », c’est-à-dire qu’il ne sera pas couvert par la « BC Promise », la promesse de rétro-compatibilité entre les versions.

Ce nouveau composant sera maintenu par la Core Team et va bénéficier du même tooling que les autres composants, avec des releases mineures tous les 6 mois, une documentation sur symfony.com, etc. L’objectif est qu’il soit extrêmement simple à utiliser et à configurer.

Il est composé comme cela :

• Message : Objet PHP qui doit être sérialisable ;
• Message Bus : Le cœur du composant ;
• Message Handler : La classe qui recevra les messages. C’est ici qu’il pourra y avoir la logique métier. Mais il faut voir ces handlers comme points d’entrée de votre application, au même titre qu’un controller (et donc ne pas y coder toute la logique) ;
• Adapters : ils permettent de faire transiter les messages via différents logiciels (RabbitMQ, Kafka, SQS, etc.) ;
• Worker : une commande, qui est un daemon qui récupère les messages via l’adapter, et les fait passer au handler.

Le composant bénéficie d’un panel sur la toolbar de debug, mais aussi d’une commande afin de pouvoir consommer les messages :

$ bin/console messenger:consume-messages messenger.default_receiver

Ce composant est très prometteur et semble simple à mettre en place et à utiliser. Il lui manque encore quelques fonctionnalités (mise en place de Retry, par exemple) mais nul doute qu’il évoluera rapidement et deviendra une référence dans la communauté.

Section intitulée a-rel-nofollow-noopener-noreferrer-href-https-speakerdeck-com-dunglas-rest-vs-graphql-illustrated-examples-with-the-api-platform-framework-rest-ou-graphql-exemples-illustres-avec-symfony-et-api-platform-aREST ou GraphQL ? Exemples illustrés avec Symfony et API Platform

Cette conférence a pour but de faire une comparaison entre REST et GraphQL, même si nous y voyons clairement la préférence de Kévin Dunglas pour la version REST.

Sur API-Platform, GraphQL est maintenant supporté mais non activé par défaut. Kévin a voulu nous montrer API-Platform par des exemples basés sur de la récupération de données, de la pagination, du tri, du filtrage de données, des changements d’état… Avec les mêmes résultats en GraphQL ou REST.

Il n’y a pas vraiment de gagnant, beaucoup de facteurs peuvent entrer en jeu sur le choix de l’utilisation de GraphQL ou REST même si les deux peuvent cohabiter ensemble sans problème.

Les différences importantes que nous pouvons retenir sont les logs et le cache :

Section intitulée cacheCache

Avec REST, nous pouvons avoir du cache Varnish, mais pas avec GraphQL car il utilise la méthode POST. Avec GraphQL, il est nécessaire d’utiliser du cache applicatif, type Redis.

Section intitulée logsLogs

Avec GraphQL, nous avons seulement un seul endpoint /graphql donc difficile de pouvoir identifier les requêtes, contrairement à REST. Bien sûr, il est tout-à-fait possible de pouvoir les identifier en passant un paramètre en string qui est le nom de l’opération effectuée.

GraphQL est de base moins sysadmin compliant, et nécessitera de mettre en place beaucoup d’outillage pour avoir un niveau de monitoring équivalent à une API REST.

Section intitulée a-rel-nofollow-noopener-noreferrer-href-https-slides-com-gheb-neat-plus-ultra-uc-un-ia-neat-plus-ultra-aUn IA neat plus ultra

Cette année, il y avait une « unconference », et nous avons pu assister à ce super talk sur le machine Learning.

Grégoire Hébert nous a expliqué ce qu’est le « machine learning » grâce à un exemple simple : un tamagochi. Le but est d’apprendre à une machine à se nourrir. Nous avons donc pu entraîner un réseau de neurone en PHP pour nourrir, amuser et faire dormir ce petit animal.

Dans la première partie du talk, Grégoire nous a d’abord parlé de la théorie. Puis dans une deuxième partie, il nous a montré comment implémenter un algorithme en PHP.

Grâce à cet exemple simple, basique, on se dit que faire du Machine Learning en PHP n’est pas très compliqué. Ce qu’il faut, c’est beaucoup de données et du temps (CPU) pour entraîner la machine.

Grégoire a écrit un Tweet pour présenter son intervention :

Merci aux 80 personnes qui sont venu voir mon talk au #Symfony_Live !
Vous pouvez retrouver mes slides sur le machine learning ici : https://t.co/ucDUFQQojo Je vous rajoutes les liens des slides : https://t.co/S2ghNSBs2lhttps://t.co/owW0M95Hehhttps://t.co/2WjMeZlZ0W pic.twitter.com/QScUKsdbwZ — Grégoire Hébert (@gheb_dev) 30 mars 2018

Section intitulée en-conclusionEn conclusion

Deux jours qui ont été passionnants et enrichissants ! 😘

Nous saluons une belle organisation, et une sélection des talks plus à notre goût que les années précédentes. Si nous cherchons la petite bête, la salle de conférence n’avait pas suffisamment de places assises (c’est la rançon du succès), et les espaces sponsors bruyants de chaque côté n’aidaient pas à la concentration ! Nous sommes, malgré ces deux détails, extrêmement contents d’avoir pu participer à cette édition de Symfony Live ! Nous n’avons pas pu parler de tous les talks mais vous en retrouverez les contenus sur ce dépôt.

---

Cet article porte sur la conférence SymfonyLive Paris 2018.