[:fr]La parole est aux speakers : Kevin Dunglas[:]
[:fr]Jusqu’au PHP Tour Montpellier 2018, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils aborderont lors de leur conférence !
La conférence
Maîtriser le composant Serializer de SymfonyLe composant Serializer de Symfony existe depuis la première version de Symfony 2, mais a gagné énormément de fonctionnalités au fil du temps. Au cours de ce talk, je présenterai les fonctionnalités méconnues et pourtant très puissantes de cette bibliothèque. Après un rappel des fondamentaux, nous découvrirons comment le composant permet - de manière transparente - de manipuler tous types d'objets PHP, quelques soient leurs styles : getters / setters, propriétés publiques, proxys.... Nous verrons ensuite les différents formats supportés nativement : JSON, XML, YAML et CSV. Puis nous manipulerons des dates, et évoquerons l'upload de fichiers avec le support des "data: URI". Finalement, nous aborderons quelques cas plus complexes tels que choisir les propriétés à sérialiser / désérialiser grâce aux groupes, gérer les références circulaires, sérialiser des arbres en limitant leur profondeur et mettre à jour des objets déjà existants. |
Salle Jarvis 17/05/2018 15:15-15:55 |
Pourrais-tu nous présenter des cas d’usage du composant serializer ?
Le serializer Symfony permet de transformer n’importe quelle structure de données interne au langage de programmation PHP (objet, tableau associatif…) en un format générique intelligible par d’autres langages ou systèmes (tels que le SGBD). Le composant de Symfony supporte nativement les formats JSON, XML, YAML, CSV mais aussi les « data: » URI.
Il est également capable d’effectuer l’opération inverse, à savoir transformer l’un de ces formats génériques en structure de données PHP (désérialisation). Contrairement à json_decode, qui ne sait créer qu’un tableau associatif ou un object stdClass à partir des données formatées passées en entrée, le composant Symfony est assez intelligent pour recréer les types appropriés (les instances des bonnes classes).
De plus, ce composant est très facile à étendre, par exemple le framework API Platform (que je développe) propose, grâce au composant Serializer, le support de formats d’API hypermédias tels que JSON-LD, JSONAPI et HAL.
En bref, le serializer est très pratique pour créer des API web, mais il peut servir dans tous les cas ou l’on doit manipuler des données pour les faire transiter d’un système à un autre.
Par exemple, j’ai réalisé à l’aide du serializer Symfony un petit outil open source nommé Doctrine JSON ODM.
Cette bibliothèque tire parti des colonnes de type JSON que supportent les SGBDR modernes tels que Postgres 9.4+ et MySQL 5.7.8+ : elle serialize automatiquement en JSON enrichi n’importe quel structure de données PHP avant de la stocker dans la colonne JSON. Quand les données sont récupérées, la bibliothèque va effectuer l’opération inverse, à savoir transformer le JSON enrichi en objets typés PHP.
Ainsi, il devient possible stocker des données très dynamiques dans un SGBD classique, en tirant parti des capacités de type NoSQL des moteurs seulement là où c’est nécessaire. Mieux, il est également possible de requêter le contenu du document lui même, et même de poser des index en son sein.
Grâce au Serializer Symfony, cette opération est complètement transparente pour l’utilisateur final si il utilise déjà l’ORM Doctrine.
Quelles sont les prochaines évolutions prévues sur ce composant ?
Le composant dispose déjà d’énormément de fonctionnalités (parfois méconnues, mais je vous les ferai découvrir lors de ma présentation au PHPTour) et très mature.
À part les habituelles corrections de bugs, le travail principal qui est effectué dessus concerne les performances.
À ce sujet, Guilhem N. est en train de mener un travail formidable, afin de pouvoir générer des normalizers optimisés, à la manière dont le composant Dependency Injection optimisé génère ses containers.
Les premiers benchmarks montrent des améliorations de performance d’environ 30% !
Qu’est-ce qui t’a amené à travailler sur le composant serializer de Symfony ?
J’ai commencé à travailler sur ce composant en développant les premières version de API Platform.
J’avais besoin d’un serializer flexible et performant, et je ne souhaitais pas réinventer la roue (d’ou le choix d’utiliser Symfony comme base).
La bibliothèque JMSSerializer (une alternative populaire au composant de Symfony) ne convenait pas à cause d’un problème de licence (elle est sous licence Apache 2, qui n’est pas compatible avec la licence GPLv2+ utilisée par de nombreux projets open source tel que Drupal ou PHPBB).
De plus utiliser le composant de Symfony permettait de bénéficier de tout ce qui fait la force du framework : des dates de sorties connues à l’avance, une compatibilité ascendante garantie, un chemin de migration balisé lors de la sortie de versions majeures et une pérennité assurée grâce à l’une des communautés les plus larges et solides du monde Open Source (tous langages confondus).
Cependant, le Serializer Symfony était à l’époque un composant (créé par Jordi Boggiano et Lukas Kahwe Smith) très bien pensé mais plutôt minimaliste : pas de gestion des références circulaires, des groupes de sérialisation, des objets complexes, des profondeurs maximales…
Au fil des évolutions d’API Platform, j’ai toujours essayé de faire « redescendre » les briques génériques dans Symfony, cela a donné lieu à l’ajout d’énormément de fonctionnalités dans le Serializer, ainsi qu’à la création de nouveaux composants (PropertyInfo et la version initiale du sous-système d’autowiring par exemple).
De plus, l’excellent niveau technique de la communauté, et en particulier des mainteneurs du projet, a permis d’améliorer ces fonctionnalités par rapport à leurs versions initiales.
Une conférence présentée par
Kévin DUNGLAS |
Kévin est le fondateur de la société autogérée Les-Tilleuls.coop. Il est membre de la core-team Symfony et a créé le framework API Platform. Il est également contributeur à plus d'une centaine de projets Open Source, conférencier et rédacteur d'articles et livres techniques. |
Autres interviews
- [:fr]La parole est aux speakers : Sarah Haïm-Lubczanski[:]
- [:fr]La parole est aux speakers : Romain Monceau [:]
- [:fr]La parole est aux speakers : Ulrich Lusseau[:]
- [:fr]La parole est aux speakers : Arnaud Lemaire[:]
- [:fr]La parole est aux speakers : Joel Wurtz[:]
- [:fr]La parole est aux speakers : Quentin Pautrat[:]
- [:fr]La parole est aux speakers : Julien Vinber[:]
- [:fr]La parole est aux speakers : Edouard Cunibil[:]
- [:fr]La parole est aux speakers : Nicolas Grekas[:]
- [:fr]La parole est aux speakers : Jean Pasdeloup et Romain Cottard[:]
- [:fr]La parole est aux speakers : Frédéric Hardy[:]
- [:fr]La parole est aux speakers : Benoit Jacquemont[:]
- [:fr]La parole est aux speakers : Nicolas Wurtz[:]
- [:fr]La parole est aux speakers : Derick Rethans[:]
- [:fr]La parole est aux speakers : Hannes Van De Vreken[:]
- [:fr]La parole est aux speakers : Cédric Spalvieri[:]
- [:fr]La parole est aux speakers : Michael Bodnarchuk[:]
- [:fr]La parole est aux speakers : Hélène Schapira[:]
- [:fr]La parole est aux speakers : Mathieu Santostefano[:]
- [:fr]La parole est aux speakers : Grégoire Pineau[:]
- [:fr]La parole est aux speakers : Richard Hanna[:]
- [:fr]La parole est aux speakers : Julien Pauli[:]