Le blog

Retour sur le Symfony Con Berlin

Publié le 12 décembre 2016

Il y a quelques jours, une partie de notre équipe (Kévin Dunglas, Hamza Amrouche et moi-même) s'est déplacée outre-Rhin afin d'assister à l'événement Symfony que beaucoup de développeurs attendaient avec impatience : le Symfony Con, qui se tenait du 29 novembre au 3 décembre au Mercure Moa Hotel. Voici un retour sur les deux jours de conférences :

Berlin" title="Berlin

Les keynotes #

Cet événement s'est ouvert avec une keynote de Fabien Potencier qui nous a présenté Sensiocloud. Kezako ? L’idée derrière Sensiocloud est de fournir une sur-couche à platform.sh afin d'offrir aux utilisateurs un système qui prend en charge tout le déploiement de vos applications de manière automatisée dès lors que vous pushez sur votre dépôt.

En quelques mots, cette solution permet de configurer de manière assez fine, une architecture complète (optimisée pour Symfony bien sûr) et de déployer votre application couplée à des outils comme Redis, RabbitMQ, PostgreSQL, MySQL, MongoDB, ElasticSearch… instantanément (ou presque) et de le servir sur une URL. Il faut y voir une espèce d’Heroku du Symfony, conçu pour embarquer de manière optimisée un environnement Sensio. 

La promesse intéressante, c’est la volonté de fournir un service avec un SLA de 99.9% (00.1% de chance que ça tombe pour les plus novices du terme). Une belle promesse si on veux commencer à penser déploiement automatisé en production sur du cloud. C’est de moins en moins utopique et on souhaite y arriver en tout cas ! 

Lors de la deuxième keynote, le créateur de Symfony nous a présenté Flex.

Avec Flex, on part d’un squelette tout nu d’un projet Symfony, et avec une ligne de commande on choisit de compléter le squelette à partir de boiler plates. Ai-je besoin d’un Symfony standard avec tout ce qui s’ensuit, ou peut-être juste du minimum pour servir un micro-service sur lequel je rajoute la console Symfony ? Peut-être que je n’ai besoin que d’un outil pour faire du REST ? En bref, avec Flex, on retire le superflu et il n'y a plus besoin de faire du nettoyage de projet. Rien n’empêche de faire appel a Composer comme avant et de rajouter vos composants, mais l’idée c’est de donner accès aux outils les plus utilisés en quelques lignes de commandes.

Autre détail qui a son importance : le fonctionnement de Flex implique une petite modification dans la manière d’instancier les bundles. Il n'y a plus de AppKernel new bundle(), tout se passe dans un fichier à part. Les configurations spécifiques peuvent maintenant être gérées au sein du composer.json de manière automatisée. Pour installer un composant, rien ne change au contraire de la désinstallation ! Plus besoin d’aller chercher les bouts de config à droite à gauche, l’outil s’en occuper tout seul ! En une seule ligne de commande, le service n’est plus. Avec Flex, on met vraiment en avant le découplage des composants, et surtout, pour une personne nouvelle à Symfony et si le bundle est bien fait, il n’aura jamais à mettre les mains dans le cambouis, c’est plug and play.

Les conférences #

2 jours, 2 tracks. J’ai eu le plaisir d’assister aux talks suivants le premier jour :

et ceux-ci le jour suivant :

Vous pouvez également vous rendre sur https://joind.in/event/symfonycon-berlin-2016 ou vous retrouverez la plupart des slides et leurs retours. En résumé, ce que je retiens des talks : 

  • FOSUserBundle est un bon outil, mais dont il faut savoir se passer. Il possède aussi beaucoup de défauts et de problèmes soulevés. Malheureusement, l'équipe de mainteneurs manque de temps donc l'appel est simple : venez aider ! 
  • Si vous intervenez et développez pour l’Open Source, essayez de penser à l’inter-operabilité des modules que vous développez pour pouvoir l’utiliser n’importe ou que ce soit sur Symfony, Drupal, Zend, eZ publish...
  • Si vous avez des développements nécessitant la mise en place de flux de (ce que que vous voulez en fait) validation, d’états, ou garantir un ordre d’execution, penchez vous sur le composant workflow de Symfony.
  • Une alternative au CRUD, le CQRS (Command Query Responsibility Segregation). C'est un peu complexe à prendre en main mais cela offre une véritable séparation de l’accès aux données et de l’ajout/modification de celles-ci permettant une performance accrue tant dans l’étape de récupération des données que dans celle d'écriture. En effet, la structure que le pattern avance permet de vraiment dissocier la manière dont les différentes données devront être traitées et de toujours être au plus optimisé. (pour plus d'infos, n'hésitez pas à consulter les slides de Samuel Roze ou encore de lire l’excellent article de Martin Fowler).
  • L’autoWiring est top pour concevoir des POC et prototypes lorsque l’on sait que l’on aura pas mal de changements à venir sans perdre de temps à constamment intervenir sur le branchement des services. De plus, il permet aux débutants de ne pas se préoccuper des dépendances. Encore quelques améliorations pour offrir un peu plus de souplesse et il sera parfait !

Si vous n’avez pas pu assister aux conférences et que vous souhaitez que nous approfondissions un sujet n’hésitez pas ! Nous ferons de notre mieux, soit pour écrire un article qui lui soit dédié, ou éventuellement de prévoir un talk lors d’un sfpot si vous êtes à Lille ;) 

Encore bravo et merci à Sensiolabs pour l'organisation ! Nous avons hâte de découvrir le contenu du prochain Symfony Con qui se tiendra en Roumanie ! 

Le blog

Pour aller plus loin