La migration d’un projet Symfony utilisant Webpack Encore vers Vite avec Reprise a permis de réduire significativement les temps de build, passant de 75–100 secondes à une quinzaine, tout en supprimant 583 packages npm. Reprise, successeur officiel de Webpack Encore, agit comme une interface entre Symfony et Vite, déléguant la majorité des tâches de build à Vite, qui gère nativement des fonctionnalités comme Sass, TypeScript ou React.

La migration mécanique a été simplifiée grâce à la rétrocompatibilité offerte par Reprise, avec des étapes comme la suppression du bundle Webpack Encore et l’ajout de Reprise via Composer, ainsi que l’intégration de Vite. Les configurations complexes de Webpack, souvent longues de centaines de lignes, ont été réduites à une cinquantaine de lignes dans Vite, où les loaders et plugins sont désormais gérés par défaut.

Cependant, la migration a révélé des défis liés aux dépendances implicites du projet avec Webpack, comme des comportements spécifiques au runtime ou des "webpack-ismes" difficiles à anticiper. Malgré cela, l’adoption de Reprise a permis d’améliorer l’efficacité du développement, notamment avec la mise en place du hot reload dans une stack Docker, tout en préparant le projet à une évolution future plus stable.

Cet article explique comment déployer une application Symfony avec Docker et FrankenPHP, une alternative moderne à l’architecture traditionnelle Nginx/PHP-FPM. L’auteur souligne les avantages de Docker pour garantir un environnement reproductible entre développement et production, évitant ainsi les problèmes de configuration manuelle. FrankenPHP, basé sur Caddy, simplifie l’architecture en servant directement les applications PHP, réduisant la complexité des conteneurs.

L’auteur détaille une configuration avec deux services principaux : FrankenPHP pour exécuter Symfony et MariaDB pour la base de données, orchestrés via Docker Compose. Le projet suit une structure classique Symfony, avec un Dockerfile pour l’environnement PHP et un fichier compose.yaml pour définir les services. Cette approche permet une mise en œuvre flexible et adaptable selon les besoins du projet.

L’article explique comment implémenter un chiffrement au niveau des champs dans une application Symfony/Doctrine pour se conformer au RGPD, en évitant de polluer le domaine métier. L’auteur souligne que le chiffrement transparent des données (TDE) ne suffit pas, car il ne protège pas contre les accès internes malveillants ou les failles comme les injections SQL. La solution proposée consiste à chiffrer les données sensibles (emails, numéros de téléphone, etc.) avant leur stockage en base, en utilisant soit un type DBAL personnalisé, soit un lifecycle subscriber, sans modifier les entités.

Le type DBAL personnalisé, comme EncryptedStringType, s’intègre naturellement entre PHP et la base de données, chiffrant les données lors de l’écriture et les déchiffrant à la lecture, sans que le domaine n’ait à gérer cette logique. Cette approche maintient une séparation claire des responsabilités, où le chiffrement reste une préoccupation d’infrastructure. L’article détaille l’implémentation technique, notamment l’injection des dépendances et l’enregistrement du type dans Doctrine.