Symfony

API Platform 3.2 est arrivé en octobre 2023 avec trois changements qui ont fait avancer le modèle d’état : les erreurs sont devenues des ressources, les sous-ressources sont revenues sous une forme qui s’intègre vraiment dans l’architecture, et le dernier point d’extension hérité — les event listeners — a été formellement remplacé. Les erreurs comme ressources Avant la 3.2, la gestion des erreurs était en dehors du modèle de ressources. Les exceptions étaient interceptées par un event listener Symfony et converties en réponse, avec un contrôle limité sur la forme de la sortie. ...

Quatre mois après la 3.0, API Platform 3.1 est arrivé avec le premier lot de fonctionnalités construites sur le nouveau modèle d’état. Tous les changements ne sont pas spectaculaires, mais l’un d’eux résout un problème qui a engendré beaucoup de contournements alambiqués en 2.x : votre ressource API n’a plus besoin d’être votre entité Doctrine. La séparation ressource/entité En 2.x, API Platform fonctionnait mieux quand votre ressource API et votre modèle de persistance étaient la même classe. Utiliser un DTO comme surface API était possible via le système Input/Output DTO, mais ce système a été supprimé en 3.0 — il compliquait le modèle d’état sans apporter suffisamment de bénéfices. ...

API Platform 3.0 est arrivé en septembre 2022 avec Symfony 6.1 comme prérequis strict et une architecture de base qui ne ressemblait en rien à la 2.x. Le guide de migration est long. La raison pour laquelle il est long est intéressante. L’ancien modèle avait une fuite conceptuelle. DataProviderInterface et DataPersisterInterface étaient appelés pour chaque requête HTTP, mais le provider recevait le contexte de l’opération comme un indice — pas comme un contrat. Un provider de collection et un provider d’item étaient des interfaces distinctes, mais les deux vivaient dans le même seau mental : “choses qui retournent des données.” La couche HTTP savait ce qui était demandé ; le provider devait reconstruire cette connaissance à partir d’indices passés dans le tableau $context. ...

On a migré une plateforme de microservices médias vers Symfony 6 début 2022. Douze services, la plupart consommant des messages depuis RabbitMQ via Swarrot. Symfony 6 a rendu Messenger plus central que jamais, et pendant la planification de la migration un développeur a posé la question évidente : pourquoi ne pas migrer en même temps ? Ça vient avec le framework. Ça a de la logique de retry, du support AMQP natif, de la documentation first-party. Notre setup ressemblait à de l’artisanat par comparaison. ...

Symfony 6.0 est sorti le 29 novembre 2021. La caractéristique définissante : PHP 8.1 est le minimum. Pas supporté, requis. L’équipe de releases a attendu que PHP 8.1 sorte, puis a coupé Symfony 6.0 le lendemain. Ce n’est pas juste un bump de version. C’est un engagement à construire contre le langage actuel plutôt que le plancher historique. Le système de sécurité, enfin reconstruit Le composant de sécurité Symfony a deux systèmes. L’ancien (AnonymousToken, GuardAuthenticatorInterface, un enchevêtrement d’interfaces qui vous faisaient implémenter des méthodes dont vous n’aviez pas besoin) avait été déprécié. 6.0 le supprime entièrement. ...

Symfony 5.4 est sorti le 29 novembre 2021, le même jour que Symfony 6.0 et un jour après PHP 8.1. Pas un hasard. 5.4 est la version LTS, et son rôle est de porter autant que possible le jeu de fonctionnalités de 6.0 tout en conservant la compatibilité 5.x. C’est aussi la première version de Symfony qui comprend réellement les fonctionnalités de PHP 8.1. Support des enums PHP 8.1 a introduit les enums natifs. Symfony 5.4 les embrasse immédiatement : ...

Chaque mise à jour de contenu sur la plateforme crée une révision. C’est délibéré : les éditeurs ont besoin d’un historique sur lequel ils peuvent revenir, et la plateforme a besoin d’une piste d’audit. Ce que personne n’avait anticipé, c’était le rythme. Certains articles passent par quarante sauvegardes en un seul après-midi. Une pièce à fort trafic accumule des centaines de révisions sur sa durée de vie. Après quelques mois, la table de révisions avait plusieurs millions de lignes. ...

Symfony 5.0 est sorti le 21 novembre 2019, le même jour que la 4.4. Là où la 4.4 mise sur la stabilité et une longue fenêtre de support, la 5.0 ouvre un nouveau chapitre : plus de code déprécié, PHP 7.2.5 minimum, et quelques nouveaux composants qui comblent enfin des lacunes accumulées depuis des années. Le composant String La gestion des chaînes en PHP est notoirement éparpillée : des fonctions avec préfixe par-ci (str_), avec suffixe par-là (strpos), un support d’encodage incohérent, et rien d’orienté objet en vue. Le composant String enveloppe tout ça dans une API fluide orientée objet avec support Unicode : ...

Symfony 4.4 et 5.0 sont tous les deux sortis le 21 novembre 2019. La 4.4 est la LTS : même ensemble de fonctionnalités que la 5.0, couche de dépréciation intégrée, et une longue fenêtre de support pour les équipes qui ne peuvent pas suivre chaque release. La fonctionnalité qui mérite d’être mise en avant est arrivée en 4.2 et a mûri tout au long des 4.3 et 4.4 : HttpClient. ...

Symfony 4.0 est sorti le 30 novembre 2017, le même jour que la 3.4. La date de sortie commune est à peu près la seule chose qu’ils ont en commun. 4.0, c’est une philosophie différente. La Symfony Standard Edition, ce point de départ monolithique qui embarquait tout et vous laissait retirer ce dont vous n’aviez pas besoin, a disparu. À sa place : un microframework qui grandit. Flex Symfony Flex est un plugin Composer qui change la façon dont on installe les packages Symfony. Avant Flex, ajouter un bundle impliquait : l’installer via Composer, l’enregistrer dans AppKernel.php, ajouter la config dans config/, mettre à jour le routing si nécessaire. Quatre étapes, toutes manuelles. ...