Symfony Live 2019, on vous dit tout : JOUR 1

Technique

2 avr, 2019

Nous y voilà, le Symfony Live 2019, se déroulant du 28 au 29 mars 2019.

image1 symfonylive Symfony Live 2019, on vous dit tout : JOUR 1
On a pris notre petit déjeuner, des photos, on se place sur nos sièges (premiers rangs) et on écoute attentivement le discours d’ouverture.

Petite émotion pour les 10 ans de la conférence cette année. Pour l’occasion, une vidéo retraçant tous les moments passés depuis sa création nous est présentée, donnant un petit coup de vieux à tous ceux qui suivent cette conférence depuis pratiquement le début.

Ensuite, présentation de l’ensemble des sponsors, des différents espaces disponibles, des informations sur la conférence (d’ailleurs notons que 1% du prix des billets est versé à l’association “Tout le monde contre le Cancer”).

image2 symfonylive Symfony Live 2019, on vous dit tout : JOUR 1

Après quelques minutes, la conférence est officiellement lancée. Fabien Potencier s’approche de la scène.

#Keynote – Fabien Potencier

image3 symfonylive Symfony Live 2019, on vous dit tout : JOUR 1

Pour cette keynote 2019, pas d’annonce importante, mais un retour aux basiques. Fabien Potencier souhaite parler d’un sujet qui nous touche tous : la création et l’envoi d’emails.

Actuellement, il existe déjà des solutions en PHP comme : phpmailer, swiftmailer ou encore zendmailer. Chez DISKO, on utilise pratiquement tout le temps swiftmailer pour nos projets.

Fabien souhaite refondre cette partie-là dans Symfony avec comme objectif de pouvoir créer et envoyer des emails le plus simplement possible.

Symfony Mime

C’est ainsi qu’il nous présente le composant Symfony Mime (pour créer un email).

Quelques différences comme :
– La suppression des setters pour la majorité des méthodes.
– Une librairie plus légère (2ko VS 16ko pour swiftmailer).
– Un nombre d’objets sérialisés plus faible (7 objets VS 38 objets).
– Mise à jour des headers le plus tard possible.
– Gestion de tous les cas qu’on retrouve chez ses concurrents comme PHPmailer, Swiftmailer ou Zendmailer (embed, attach…).
– Possibilité de créer les emails avec Twig en faisant des alias pour les fichiers attachés ou liés. Gestion du markdown, CSS inline, inky…

Symfony Mailer

Voici le deuxième composant (pour envoyer les emails). Il permet l’abstraction des envois en HTTP, SMTP ou API suivant le provider mail.

Le conseil de Fabien est d’utiliser le HTTP ou le SMTP car on garde la gestion du body alors que côté API, le body est créé par le provider.
Voici une liste des providers les plus populaires :
– Amazon SES
– Gmail
– Mandrill
– Mailgun
– Postmark
– Sendgrid

Chez DISKO on utilise majoritairement Gmail pour nos tests durant les développements et Mandrill pour les sites en production.

Le composant apporte l’unification des comportements provider, la facilité de switcher de DSN, mais aussi l’envoi en Synchrone (via le transport directement) ou Asynchrone (via le mailer si on passe un bus et une config utilisant AMQP). Le petit plus, c’est que le composant intègre le support d’une enveloppe (non géré par swiftmailer), qui permet de changer ou rediriger l’envoi d’email à une personne si besoin pour du dev.

Mais pourquoi Symfony réinvente la roue ?

Le gros avantage, c’est d’avoir essayé de prendre en compte tout ce qu’il y a dans Symfony. Pour la rétro-compatibilité mais aussi parce que les mailers existants ne font même pas 10% de ce que fait Symfony Mailer.

DISKO utilisera Symfony Mailer sur les projets Symfony dans le futur.
Merci Fabien.

#Démystifier React et Redux avec Symfony et Webpack Encore – Titouan Galopin

image4 symfonylive Symfony Live 2019, on vous dit tout : JOUR 1

React

Pour commencer, Titouan nous présente les concurrents de React (Angular, VueJs…) en nous expliquant qu’ils sont tous basés sur le MVVM et de l’utilisation du pattern Observable / Listener. Conséquence ? Il est difficile de debug, de reproduire un bug…

De l’autre côté, il y a React, qui est basé sur un One Way Data Flow. Dès que le modèle est modifié, on recréée une vue à partir du modèle, la vue n’intervient pas sur elle-même et n’a donc plus de conséquence sur le modèle.

N’oublions pas que React est une librairie et non un framework. Il sert uniquement à générer des interfaces utilisateurs. Chaque interface est découpée en composants, et chaque composant décrit une partie de l’interface.

Ce qu’il faut retenir, c’est qu’un composant est composé d’un état, de propriétés et d’un mode d’affichage en HTML.
Côté code :
– this.state permet d’utiliser l’état
– this.property.xxx permet d’utiliser la propriété xxx (qui est une sorte de paramètre du composant qu’un utilisateur externe peut modifier)
– la méthode render() permet la génération HTML

A chaque fois qu’on va modifier soit l’état soit une propriété, React va relancer le render et recréer le HTML. Ce n’est pas totalement du javascript, c’est un langage appelé JSX : du javascript dans lequel on va pouvoir injecter des composants react qui s’apparentent à du HTML (sans vraiment en être).

React va donc entretenir un arbre de composants. Lors d’un changement d’état, seul les composants concernés seront mis à jour (performance ++). Webpack, encore, permet de builder et compiler plus facilement du React.

Redux

Sous React, on a One Component = One State Object

Mais problème : les composants ont tous leurs états qui leur sont propres et ne peuvent pas interagir entre eux. Redux permet de centraliser les états et donc de gérer plus simplement la synchronisation entre les différents composants d’une application.

Avec Redux, nous avons un état global en plus par composant (en plus de l’état et des propriétés). L’état global permet ainsi de synchroniser les propriétés et les états et donc de regénérer les vues. On ouvre ainsi la possibilité d’interaction entre les composants.

A l’agence, on utilise du React Native pour la gestion des applications mobiles. Le principe est le même, rien de nouveau pour nous, mais c’est toujours bien de reposer les bases comme l’a fait Titouan.

#Des apps Symfony sous stéroïdes grâce à Vue.js, Mercure et Panther ! – Kévin Dunglas

image5 symfonylive Symfony Live 2019, on vous dit tout : JOUR 1

Retour sur le talk très riche de Kevin Dunglas qui aborde la façon de développer des applications Symfony modernes, tout en tirant profit de la puissance des nouveaux frameworks front comme Vue.js.

Accompagné d’une démo, l’objectif était de faire un clone de joind.in en seulement 40 minutes. Ici, plus question de faire des applications traditionnelles à la papa via une architecture MVC classique. Côté back, on se concentre uniquement sur la couche métier qu’on va exposer via une API, qui pourra ensuite être consommée par une application web, une application mobile, ou encore des objets connectés…

image11 symfonylive Symfony Live 2019, on vous dit tout : JOUR 1

Cette architecture orientée API présente de nombreux avantages : en plus de découpler complètement la partie back du front, elle permet de déléguer un certain nombre de traitements à la partie client et donc indirectement d’alléger et d’améliorer les performances côté serveur.

Grâce à l’outil API Platform, l’API web est implémentée en seulement quelques minutes.

Vue.js peut quant à lui être très facilement intégré à Twig grâce à Symfony Encore (pour un découplage parfait entre le backend et le frontend, on pourra développer notre application vue.js à part et interroger notre API en utilisant une librairie comme Axios).

Facile à prendre en main, il nous permettra de découper notre interface en composants web réutilisables. La gestion des formulaires est également simplifiée grâce à un système de liaison de données bidirectionnelle entre le DOM et les données JavaScript.

image7 symfonylive Symfony Live 2019, on vous dit tout : JOUR 1

Nous découvrons également Symfony Panther, une librairie PHP compatible avec BrowserKit et qui permet, sans rien avoir à installer, de tester de bout en bout ses applications sur un vrai navigateur (alors que le composant BrowserKit ne fait que simuler le comportement d’un navigateur et ne permet pas non plus de tester son code Javascript).

Enfin, cerise sur le gâteau avec la démonstration du protocole Mercure permettant de pousser des données en temps réel vers des navigateurs web (ou autres clients HTTP), en utilisant la technologie server sent events supportée par tous les navigateurs.

image8 symfonylive Symfony Live 2019, on vous dit tout : JOUR 1

#État de l’art d’Elasticsearch avec Symfony – Damien Alexandre

image9 symfonylive Symfony Live 2019, on vous dit tout : JOUR 1

Pour la partie ElasticSearch, nous avons eu droit à une présentation de l’outil qui met en avant les problèmes que nous pouvons rencontrer avec ce logiciel. Puis les solutions que nous pouvons mettre en place pour nous permettre de mieux l’appréhender.

Tout d’abord, parlons des bases d’ElasticSearch.
C’est à dire ? Tout d’abord, ce logiciel est un outil, pas une solution. C’est une base de données en NoSQL avec des index inversés et distribués. Il n’y a aucune transaction ou interaction entre les “tables”.

Pas besoin d’installer ElasticSearch sur notre projet car ce dernier nécessite uniquement une requête HTTP. Nous avons juste besoin d’un serveur disposant d’ES, auprès duquel nous ferons la requête.

Pour faciliter la liaison entre notre projet et ES, nous pouvons installer des paquets PHP. ElasticSearch possède ses propres paquets officiels, nommés elasticsearch.elasticsearch-php.
Mais il existe également d’autres paquets, avec
ruflin/elastica et madiwithlove/elasticsearcher (malheureusement ce dernier est bloqué en version 5.x alors que ES va bientôt passer en version 7).

Dans Symfony, il existe un Bundle maintenu qui va nous permettre de configurer la liaison entre ES et Symfony dans les fichiers de configuration du framework, ce Bundle est nommé friendodsymfony/elastica-bundleIl existe d’autres librairies, mais elle ne sont plus à jour voire mortes.

Damien Alexandre nous a donc conseillé d’utiliser Elastica car il va être directement intégré dans Symfony, et nous permettra de mieux configurer notre recherche grâce à l’implantation de doctrine.

Par la suite, il nous est conseillé de ne plus utiliser les tableaux mais bel et bien des objets, que nous appelons DTO (Data Transfert Object). Nous les créons grâce au serializer de Symfony que nous allons passer à notre JSON, ainsi nous pouvons envoyer à ES, le DTO. Mais pour obtenir un réel gain de performance, il vaut mieux utiliser Jane, qui est un autre composant de Symfony pour créer des DTO avec ObjectSerializer.

Lorsque nous allons configurer notre recherche (le fichier analyser et mapping.), il est recommandé  de les créer en .yml, car cela sera plus facile à lire et plus facile à concevoir (le JSON n’est pas fait pour les humains). Pour éviter que des crash se produisent dans les environnements de production, nous les développeurs, nous devons créer une queue lors de l’indexation des différentes ressources. Ainsi, nous n’utiliserons pas l’ensemble de la mémoire et les coeurs de la machine lors de notre indexation.

Lorsque nous créons un nouveau document sur ES (un document est une table en base de données SQL). Nous devons nous poser les bonnes questions, quelles sont les informations utiles à la recherche ? et celles que nous voulons afficher lorsque nous allons remonter les résultats ? Ces questions auront pour effet de ne pas indexer tout un objet mais seulement les parties utiles. Nous allons gagner en performance lors d’un indexage.

Pour que nos documents soient toujours à jour par rapport à nos données stockées en base, nous pouvons implémenter en Symfony des BUS (des évènements Doctrine) qui vont insérer en même temps dans le document les nouvelles données que ES va pouvoir faire remonter dans les recherches. Ces BUS peuvent être faits en Asynchrone si vous le souhaitez.

Pour finir, Damien Alexandre nous a donné quelques conseils pour que l’on puisse gagner un peu plus en performance.

Pourquoi est-ce lent ? C’est notre PHP qui a une vitesse de traitement très lente. Pour ce faire, il vaut mieux créer des BULK avec Doctrine, serializer nos données lors de l’envoi sur ES. Mais également réaliser des tests avec BlackFire.io, pour nous permettre de repérer les problèmes éventuels lors des indexations et d’utiliser les fonctions iterate de Doctrine. C’est ainsi que nous pouvons avoir un code PHP optimisé pour ES.

Mais nous pouvons aller encore plus loin. Côté ES, nous pouvons utiliser les refresh_interval et augmenter la valeur de base ainsi que désactiver les réplicats. Car quand nous indexerons, le problème de performance viendra principalement de cette endroit. Nous pouvons installer un noeud ES (un node) sur le serveur PHP, afin de faire des appels sur le localhost du serveur. De ce fait, le temps de réponse sera beaucoup plus rapide que si nous devions passer par un serveur extérieur. Pour nous permettre de monitorer le serveur d’elasticsearch, nous pouvons utiliser ICU, qui est un module ES permettant de mieux supporter les langues lors des recherches, il indexe le “c” cédille par exemple.

Pour finir, présentation de Kibana, un IDE pour ElasticSearch, qui va nous permettre d’utiliser les fonctions d’ES beaucoup plus facilement.

#HTTP/3 : C’est une question de transport ! – Benoit Jacquemont

image10 symfonylive Symfony Live 2019, on vous dit tout : JOUR 1

Lors de cette présentation, Benoît Jacquemont nous explique que le principal ennemi dans notre métier est la latence. HTTP/3 va essayer de répondre à cette problématique en la minimisant.

Qu’est-ce que HTTP/3 ? C’est une évolution de HTTP/2 car il l’utilise dans son intégralité mais en utilisant QUIC (au lieux de TCP + TLS).

Pourquoi QUIC a-t-il été implanté dans cette nouvelle version de HTTP ? Car la connexion avec TCP se faisait en mode Syn, Syn Ack Ack, c’est à dire une connexion en trois étapes séquentielles puis vient le TLS qui va ajouter des étapes supplémentaires. Ainsi, lorsque nous effectuerons une requête HTTP, nous aurons un problème de latence dû aux étapes intermédiaires de TCP + TLS.

image6 symfonylive Symfony Live 2019, on vous dit tout : JOUR 1

QUIC quant à lui est basé sur UPD. Il permet d’établir une connexion et de la chiffrer en seulement trois étapes, ce qui a pour effet de réduire la latence. Par contre, nous devrons gérer les problèmes éventuels que TCP intègre et que UDP ne possède pas, tels que la gérance de la perte des paquets lors d’un établissement de la connexion.

Par contre, par rapport à TCP+TLS, QUIC prendra en charge les paquets qui ont pu être chargés complètement, puis affichera par la suite les derniers paquets. Ce que HTTP/2 avec TCP/IP n’exécute pas puisqu’il est obligé d’attendre que tous les paquets soient arrivés pour afficher la page. Lorsque nous changeons de réseau (de la 4g nous passons à la wifi), HTTP/2 ne sera pas capable d’afficher la page car il aura perdu des paquets, alors qu’avec HTTP/3 ce ne sera pas le cas car il pourra afficher les premiers éléments, puis par la suite afficher le reste.

Le défi de QUIC est l’optimisation, car il consomme beaucoup de charge CPU de par sa jeunesse, comparé à TCP et TLS, qui existent depuis plus de 20 ans et sont donc plus éprouvés.

#Des images au cordeau pour vos applications Symfony – Mathieu Santostefano

image12 symfonylive Symfony Live 2019, on vous dit tout : JOUR 1

Le poids des images est un problème récurrent pour les applications web. D’autant plus depuis que les supports et formats se sont démultipliés. A quoi cela sert d’avoir une image en ultra HD sur un écran de 320 pixels ? Rien… et c’est là qu’entrent en jeu les images responsives.

Le principe est simple : disposer de formats d’images suivant les tailles d’écran, afin de diminuer le poids de celles-ci et améliorer l’expérience utilisateur. On ne fait pas juste du redimensionnement via du CSS, non non non ! Il faut recréer des images avec les formats intermédiaires, tout en gérant le DPR (Device Pixel Ratio).

Le DPR est le ratio que prend un pixel physique VS un pixel virtuel. De base, le ratio est à 1, mais par exemple, avec le Retina, il est à 2 et sur les Galaxy S8 à 4.

Un outil intéressant que nous présente Mathieu : Responsive Break Points.

Il permet de générer un bout de code HTML pour une image en gérant les breakpoints, car oui contrairement au responsive (qui est géré en CSS), l’image responsive est gérée en HTML, pour que le navigateur ait l’information le plus rapidement possible.

Ce sont les attributs html srcset et sizes de <img> qui gèrent les breakpoints et les sizes de l’image. L’ordre de srcset n’est pas important, alors que dans sizes, c’est primordial. srcset peut s’appliquer sur une balise source également.

Le navigateur va charger l’image à la bonne taille en fonction du contexte (connexion réseau, taille d’écran, DPR…), c’est lui qui choisit, mais faut-il encore qu’il ait du choix !

Comment gérer ses images en production ? Et comment faire lors d’un upload ?
La solution vient de la librairie Glide, développé par PHP League, qui permet de manipuler des images et de les signer pour prévenir des attaques “mass image-resize”.

Glide apporte un bundle pour Symfony. On peut aussi utiliser LiipImagineBundle, mais elle ne gère pas la signature automatique. Ou utiliser Rokka.io qui est édité par Liip. Ou encore Thumbor, cloudinary

Chez DISKO, on utilise la plupart du temps LiipImagineBundle, en ajoutant notre sécurité par-dessus pour contrer les attaques. Mais la présentation de Mathieu nous a convaincus de passer sous Glide.

#Du développement à la production, une architecture grandissante – Kévin Dejour  et Philippe Vincent-Royol

Kévin et Philippe nous rappellent les règles de la haute disponibilité :
– Une infrastructure solide et performante
– Des prévisions pour les défaillances
– Une gestion des pics de charge
– Une garantie du CA
– Une préservation de l’image de la société

En avons-nous toujours besoin ? La réponse est OUI.
Car contrairement à des magasins physiques où il faut marcher un long moment pour comparer des produits, sur le web la concurrence est très forte. Pour vous donner une idée, il faut 5 secondes à un client pour changer de site. La moindre seconde a une importance considérable sur le chiffre d’affaires que peut générer un site internet.

Le dev est responsable en grande partie de cela. 2 effets :

L’effet papillon

« Le battement d’ailes d’un papillon au Brésil peut-il provoquer une tornade au Texas ? »

C’est le fait que le moindre détail négligé impactera le business de la société. En tant que dev chez DISKO, nous faisons attention à de nombreux métriques et indicateurs comme le nombre de requêtes, le temps de rendu, la mémoire utilisée, assets, images, redirections etc. Gérer tout cela permet de soulager le serveur et d’augmenter le chargement de la page.

L’effet JT

C’est lorsqu’un grand nombre de personnes arrive sur le site après une diffusion au JT par ex.
Le risque majeur est qu’il tombe face au nombre imprévu et exponentiel des visites.

Si on prend 3 sites A, B et C et que seul C s’est préparé à ce cas de figure en amont avec une architecture idéale, le jour du JT, A et B tomberont et auront +0% de CA, alors que C fera +640% de CA. Pour un rappel général, une bonne architecture c’est : Varnish, Redis, Cache HTTP… avec multi-serveurs frontaux, multi-load balancer etc.

A l’agence, nous incitons toujours nos clients à aller vers la meilleure architecture possible en fonction des budgets afin de garantir une performance maximale.

#Les meilleurs bundles et outils pour vos applications Symfony – Danielle Kayumbi Bonkoto

Au fil des missions qu’elle a pu réaliser chez ses clients, Danielle s’est constitué une base de données exhaustive des packages et outils essentiels pour la réalisation d’applications robustes et performantes. Cette présentation s’est organisée autour des enjeux pour lesquels nous devons intégrer ces outils dans notre quotidien et comment bien les choisir.

Pourquoi faut-il utiliser les outils et les bundles de la communauté ?
Quelque soit le contexte dans lequel on se trouve (Monolithe, Micro service, simple projet), utiliser les bons outils permettra de développer des applications robustes, de qualité et surtout optimiser les coûts.

image13 symfonylive Symfony Live 2019, on vous dit tout : JOUR 1Extrait de la présentation Symfony Live

Qu’y a-t-il dans ce fameux catalogue ?

Deux grandes catégories :
– Les outils/bundles nécessaires à l’infrastructure du projet
– Et ceux nécessaires à la couverture fonctionnelle

Avant même de commencer à coder, installons plusieurs outils :

Les outils d’analyse

– Code sniffer pour la Syntaxe / PSR, outils PHP CS FIXER
– phpmd (Php Mess Detector) : Bug, complexité…
– Php Stan (Static Analysis Tool) : détection des erreurs avant même l’exécution.

Ces outils pourront être automatisés grâce aux hooks git :
– Locaux pre-commit, post-commit…).
– Distants (pre-receive, post-receive…)

En local, il existe GrumPHP permettant de générer automatiquement les hooks.

Pour les tests, on utilisera les outils qui ne sont plus à présenter pour la plupart :

– Phpunit (Tests unitaires)
– Behat (Tests fonctionnels)
– Panther (Tests fonctionnels navigateurs)
– Codeception (Tests unitaires)

Nous avons la chance d’avoir une communauté oeuvrant activement pour faciliter la vie des développeurs. Ne pas réinventer la roue doit être le mantra de chacun de nous.

Au sein des repositories principaux packagist et Recipes Server Symfony, vous pouvez trouver un large choix de packages qui vous aideront dans vos développements.

Rappel des bundles les plus intéressants :
– AliceBundle & Faker (pour gérer les fixtures)
– DoctrineFixturesBundle (pour gérer les fixtures)
– ApiPlatform (pour construire des API)
– NelmioApiBundle (génère de la doc au format OpenAPI)
– Guzzle (consommer des API)
– CSA GUZZLE (consommer des API, mais avec du log, cache…)
– HttpClient (appel Http concurrent à Guzzle)
– JWTAuthentificationBundle (authentification par jeton JWT)
– HWIOAuthBundle (authentification clie oauth)
– OAuth2Server (pour faire son propre serveur oauth)
– StofDoctrineExtensionsBundle (pour gérer des slug, time…)
– Doctrine Migration (pour faire des migrations)
– FosElasticaBundle (intégration d’elasticsearch)
– AlgoliaSearchBundle (intégration d’algolia)
– OneUpFlySystemBundle (gestion des médias)
– Glide (gestion des redimensions des images)
– SonataAdminBundle (création de BO riche)
– EasyAdminBundle (création de BO simple)
– RabbitMqBundle (gestion AMQP)
– EnqueueBundle  (gestion AMQP)
– Composant Messenger  (gestion AMQP)
– Cloud AMQP (solution Sass)
– Monolog (monitoring)
– Sentry (crash reporting real time)

Pour nous aider à faire notre choix, des métriques (nombre de téléchargement, date de dernier commit, stars…) sont disponibles.

Laisser un commentaire.