Le composant Symfony Runtime, introduit dans Symfony 5.3, a modernisé le démarrage des applications PHP en séparant la logique d'initialisation de celle du contrôleur frontal. Auparavant, le fichier public/index.php contenait une grande partie de l'infrastructure de l'application, ce qui posait des problèmes de maintenance et de propagation des mises à jour du code de démarrage.

Grâce à Runtime, le code d'amorçage est désormais géré par un composant Composer dédié, permettant ainsi des mises à jour plus fluides via la gestion des dépendances. Cette architecture découplée est particulièrement avantageuse car elle permet aux applications Symfony de s'exécuter dans divers environnements, qu'il s'agisse des serveurs PHP traditionnels (PHP-FPM) ou de solutions plus modernes comme FrankenPHP, Swoole ou ReactPHP, sans modifier le contrôleur frontal.

Le principal avantage architectural de Symfony Runtime réside dans sa capacité à désolidariser le processus de démarrage de l'application de son modèle d'exécution. Cela signifie qu'une même application peut s'adapter à différents types d'environnements d'exécution, y compris les processus PHP à longue durée de vie, sans nécessiter de réécrire sa logique d'initialisation. Cette flexibilité ouvre la voie à une portabilité accrue des applications Symfony sur une gamme plus large de plateformes.

Les Fibers, introduites dans PHP en novembre 2021, sont une primitive bas niveau permettant un mécanisme de stack switch coopératif, souvent comparé à une suspension d'appel téléphonique où l'état complet (variables, pile d'appels) est préservé. Contrairement aux generators, elles permettent à n'importe quelle fonction, à n'importe quelle profondeur d'appel, de suspendre l'exécution via Fiber::suspend(), sans nécessiter une propagation manuelle du yield. Cette caractéristique est cruciale pour les bibliothèques asynchrones comme Amphp ou ReactPHP, qui encapsulent les Fibers pour offrir une API synchrone à l'utilisateur final, évitant ainsi le problème des colored functions.

Bien que souvent associées à tort au multi-threading ou à l'asynchrone pur, les Fibers restent mono-threadées et ne gèrent pas elles-mêmes les opérations d'entrée/sortie. Leur rôle se limite à fournir un outil de contrôle d'exécution précis, laissant aux bibliothèques le soin de gérer les attentes (sockets, timers, etc.). Leur minimalisme et leur explicitement en font une solution puissante mais peu visible dans le code applicatif classique, où elles opèrent en coulisses.

L'API des Fibers, volontairement épurée, repose sur quelques méthodes clés : Fiber::__construct(), Fiber::start(), Fiber::suspend() et Fiber::resume(). Cette simplicité reflète leur nature de mécanisme brut, conçu pour être intégré dans des couches d'abstraction supérieures plutôt que directement utilisé par les développeurs. Leur adoption discrète dans des frameworks comme Symfony s'explique par cette philosophie de conception.

Tout est dans le titre

Un concurrent de Node et Deno

Tout est dans le titre

Une tentative de clarification de l'auteur... que de complexité dans le vocabulaire :-)