Posts

API Platform 3.3 est sorti en avril 2024 avec un ensemble d’ajouts ciblés. Aucun d’eux ne remodèle l’architecture — la 3.2 avait déjà clos ce chapitre. Ce que la 3.3 apporte, c’est du contrôle sur des choses qui étaient soit codées en dur soit nécessitaient un contournement : les headers de réponse, la visibilité des liens sur les sous-ressources, et les webhooks dans la spec générée. Configuration déclarative des headers Avant la 3.3, définir des headers de réponse personnalisés nécessitait soit un processor personnalisé qui modifiait l’objet réponse, soit un event listener Symfony sur kernel.response. Les deux approches fonctionnaient mais vivaient en dehors de la définition de la ressource. ...

Symfony 7.0 est sorti le 29 novembre 2023, le même jour que 6.4. Le pattern tient : la version X.0 coupe le code déprécié et élève le plancher PHP. 7.0 exige PHP 8.2 et supprime tout ce que 6.4 avait marqué comme déprécié. La suppression la plus visible : les annotations Doctrine. @Route, @ORM\Column, @Assert — disparus. Les attributs PHP natifs sont l’approche recommandée depuis Symfony 5.2. 7.0 rend juste ça officiel. ...

Symfony 6.4 est sorti le 29 novembre 2023. C’est une LTS avec une histoire : quatre composants qui sont sortis en expérimental dans des versions précédentes sont maintenant stables. Le plus important, c’est AssetMapper. AssetMapper La gestion frontend moderne dans Symfony, ça voulait dire Webpack Encore. Encore fonctionne : il gère la transpilation, le bundling, le versioning, le hot reload. Il nécessite aussi Node.js, une étape de build séparée, et une quantité non négligeable de configuration pour ce qui est souvent un frontend assez modeste. ...

PHP 8.3 est sorti le 23 novembre. Une version discrète par les standards PHP : pas de bouleversement à la taille des enums, pas de JIT. Ce qu’elle apporte, c’est un ensemble ciblé d’améliorations qui comblent des lacunes de longue date dans le système de types et ajoutent des fonctions qui auraient dû exister depuis des années. Les constantes de classe typées Les constantes de classe n’ont jamais été typées depuis leur introduction. PHP 8.3 corrige ça : ...

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. ...

PHP 8.2 est sorti le 8 décembre. Les classes readonly font les gros titres. La dépréciation des propriétés dynamiques, elle, demande votre attention concrète. Les propriétés dynamiques dépréciées PHP a toujours permis d’ajouter des propriétés à des objets sans les déclarer dans la classe : class User {} $user = new User(); $user->name = 'Alice'; // aucune déclaration, aucune erreur... jusqu'ici En 8.2, ça déclenche un avertissement de dépréciation. En PHP 9.0, ce sera une erreur fatale. Le délai de grâce existe, mais le compteur tourne. ...

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. ...

J’ai utilisé Vagrant pendant des années. Un Vagrantfile par projet, une box de base partagée, un script de provision qui marchait le mardi mais pas le jeudi. La promesse était simple : des environnements reproductibles pour tout le monde dans l’équipe. La réalité était plus compliquée. Les années Vagrant Le setup avait du sens à l’époque. Une VM par projet, provisionnée avec des scripts shell ou Ansible, partagée via un Vagrantfile versionné. L’onboarding était théoriquement vagrant up et c’est terminé. ...

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. ...