Symfony 8.1 HTTP-less : pour un projet neuf, pas pour un worker existant.

Symfony 8.1 sort une nouveauté qui donne envie de l'adopter partout : « HTTP-Less Symfony Applications ». Un kernel sans HTTP, deux bundles extraits de FrameworkBundle, et le réflexe immédiat de vouloir tout alléger avec.

L'annonce dit bien ce que c'est. Elle dit beaucoup moins pour quel projet c'est fait. Ce billet tranche : un cas où le kernel HTTP-less vaut le coup, un cas où il fait perdre du temps, et le sort de l'app full-stack existante, qui n'a rien à décider.

Ce que 8.1 met en place

Trois briques, posées sans superlatif.

ServicesBundle regroupe les services de base du conteneur : event dispatcher, filesystem, clock, processeurs de variables d'environnement. Il vit dans le composant symfony/dependency-injection.

ConsoleBundle (dans symfony/console) apporte la couche ligne de commande : enregistrement des commandes, résolveur d'arguments, listener d'erreurs.

Le troisième élément est un socle de kernel sans HTTP : AbstractKernel et KernelTrait, dans Symfony\Component\DependencyInjection\Kernel.

Le ressort commun, c'est l'attribut #[RequiredBundle] : un bundle déclare ceux à charger avant lui, et le kernel les résout par réflexion.

foreach ((new \ReflectionClass($class))->getAttributes(RequiredBundle::class) as $attribute) {
    $required = $attribute->newInstance();
    // ... le bundle requis est ajouté à la liste de chargement
}

C'est ce ressort qui fait tenir les deux cas qui suivent. La PR de Nicolas Grekas le résume : « Shrinking FrameworkBundle for the first time. » Symfony glisse d'un framework qui contient des libs vers des libs qui peuvent former un framework.

Le cas qui justifie le kernel HTTP-less : un projet neuf

Le terrain du kernel HTTP-less, c'est le projet qui n'a jamais eu de HTTP. Un outil en ligne de commande, un consumer de file dédié, une fonction serverless, un microservice de calcul.

On part alors d'un config/bundles.php minimal.

return [
    Symfony\Component\Console\ConsoleBundle::class => ['all' => true],
];

ServicesBundle se charge seul, parce que ConsoleBundle le déclare en #[RequiredBundle]. Le résultat : un conteneur Symfony, l'injection de dépendances et les commandes, sans une seule classe HTTP en mémoire. C'est ce scénario que l'annonce vise.

Le cas où il ne sert à rien, pour l'instant : un worker existant

Vient alors une idée tentante : réutiliser ce kernel pour un worker Messenger, qui ne sert aucune requête. En pratique, pas encore.

Le déménagement de FrameworkBundle ne fait que commencer. 8.1 n'a descendu que deux cartons : ServicesBundle et ConsoleBundle. La configuration de messenger et de scheduler reste dans l'extension framework:, donc dans FrameworkBundle. Aucun MessengerBundle ni RoutingBundle autonome à ce jour.

Un kernel HTTP-less pour un worker devrait alors réimporter FrameworkBundle, juste pour configurer Messenger. Le bénéfice disparaît, et il reste un deuxième kernel à maintenir pour à peu près le même conteneur. Le calcul est vite fait : on ne gagne rien.

Et l'app full-stack existante ? Rien à décider

Pour une app déjà en production, la question ne se pose même pas. FrameworkBundle déclare lui-même les deux nouveaux bundles.

#[RequiredBundle(ServicesBundle::class)]
#[RequiredBundle(ConsoleBundle::class, ignoreOnInvalid: true)]
class FrameworkBundle extends Bundle

Le kernel HTTP, via MicroKernelTrait, hérite désormais du même KernelTrait que le kernel générique : il résout ces attributs au démarrage. ServicesBundle et ConsoleBundle sont donc déjà chargés, en plus de ceux listés dans config/bundles.php. Aucune migration, aucune ligne à écrire.

ServicesBundle est entré sans frapper, et c'est précisément ce qu'on attend d'une bonne fondation. Seul réflexe à éviter : l'ajouter à la main dans config/bundles.php. Ce serait un doublon.

Le mot de la fin

La règle tient en une phrase : le kernel HTTP-less est fait pour ce qui naît sans HTTP, pas pour amincir ce qui en a déjà. Pour l'existant, le découplage travaille en dessous, sans rien demander au-dessus.

FrameworkBundle a livré ses deux premiers bundles. Routing, messenger et twig n'ont pas quitté les lieux. La trajectoire est posée ; reste à savoir quel carton partira au prochain tour, et ce qu'il rendra enfin possible.