# Un Serializer sous stéroïdes
# Je veux un serializer sous stéroïdes
# Le composant Serializer, au présent et au futur ?

## Abstract

La sérialisation joue un rôle essentiel dans tout système d'information, et en particulier dans le contexte d'une application web, car elle constitue un des pivots du cycle requête/réponse HTTP. C'est pourquoi le composant Serializer de Symfony est l'un des plus critiques pour nos applications.

Les besoins évoluents, et depuis sa création, le Serializer se retrouve confronté à de nouvelles problématiques. En effet, sa capacité à traiter un grand volume de données tout en restant performant et flexible est devenu critique.

C'est pourquoi de nouveaux outils sont apparus au fil du temps, permettant chacun, d'améliorer une partie du Serializer de manière indépendante.

Quels sont ces outils ? Et comment les orchestrer afin d'obtenir une version du Serializer sous stéroïdes ? C'est ce que nous aborderons lors de cette conférénce.

## Plan global

[Mathias] 1. Explication ce que c'est qu'un Serializer
[Mathias] 2. Existant: un component, les dates et les deux trois evenements importants
[Baptiste] 3. Limites:
[Baptiste] - AbstractObjectNormalizer design (à cause du design actuel, à cause de la BC policy qu'on aime tant bah on est pas mal bloqués)
[Baptiste] - Reflection / caching -> souvent un bottleneck de nos applications
[Baptiste] - Typing -> souvent limités
[Baptiste] - Par design, pas de streaming -> OOM
[Mathias] 4. Plus on a de metadata, plus on peut faire des trucs de ouf (exemples list vs dict pour JSON)
[Mathias] - Pour résoudre limites typing: TypeInfo
[Mathias] - comparé à PropertyInfo > limité aux properties
[Mathias] - TypeInfo gère tout: paramètres, retour de méthode/function, string
[Mathias] - Factory Type::list()
[Mathias] - Generics / Templates*
[Baptiste] - En vrai c'est un peu un truc internal, peu de chances que vous vous en serviez tous les jours
[Baptiste] 5. Impact sur le Serializer ?
[Baptiste] - Résolu le typing -> oui mais non, il faut l'intégrer dans le serializer actuel
[Baptiste] - PR retrocompat TypeInfo / Serializer
[Baptiste] - À vous de faire des PRs pour leverage toutes les nouvelles features qui pourraient être intégrées
[Baptiste] - Screens PR TypeInfo avec les idées
[Mathias] - MAIS pas reflection / caching / stream -> à cause du design actuel, à cause de la BC policy qu'on aime tant bah on est pas mal bloqués
[Mathias] - Pour aller vite, ce qu'on peut faire c'est "recomposer le serializer"
[Baptiste] 6. Normalization: AutoMapper
[Baptiste] - Fonctionnement 
[Baptiste] - Mapper ? AST (nikic/php-parser) > Normalizer
[Baptiste] - Extensions ?
[Baptiste] - Pourquoi c'est mieux
[Mathias] 7. JsonEncoder
[Mathias] - Encoding
[Mathias] - Streaming
[Mathias] - Perf
[Mathias] - Generation de code
[Mathias] - Pourquoi c'est mieux
[Baptiste] 8. POC JsonEncoder + AutoMapper (remplacer le Serializer dans MapRequestPayload?)
[Baptiste] - Le reve serait d'avoir une nouvelle implem' du SerializerInterface (bundles)
[Baptiste] - Exemple de code avec tout? GIF?
[Baptiste] - Bench !