L’API Platform conference 2025 à Lille

L’édition 2025 de l’API Platform Conference a une saveur particulière : API Platform fête ses 10 ans. Pour l’occasion, la communauté s’est réunie à Lille autour de deux journées intenses de conférences, de retours d’expérience et d’annonces qui vont marquer l’avenir du framework.

Chez Akawaka, nous étions présents pour capter les évolutions clés, prendre la mesure des tendances à venir et surtout partager avec vous ce qui fera la différence demain dans vos projets.

10 ans d’API Platform : un écosystème en pleine maturité

Dans sa keynote d’ouverture, Kévin Dunglas est revenu sur le chemin parcouru : d’un simple bundle Symfony, API Platform est devenu un framework complet qui a donné naissance à des briques majeures comme Mercure et FrankenPHP. Aujourd’hui, l’outil supporte officiellement Symfony comme Laravel et continue de s’ouvrir à de nouveaux usages — jusqu’à intégrer gRPC grâce à FrankenPHP.

L’hommage rendu à Ryan Weaver, voix emblématique de SymfonyCasts et contributeur clé disparu cet été, a aussi rappelé combien l’humain et la transmission sont au cœur de cet écosystème.

API Platform 4.2 : la révolution continue

Antoine Bluchet, release manager d’API Platform, a dévoilé les nouveautés de la version 4.2 :

• Query parameters : les filtres via #[ApiFilter] vivent leurs derniers instants. Place à une approche plus souple et puissante avec des paramètres de requête typés et documentés.
• Metadata mutators : de nouveaux attributs permettent d’ajuster dynamiquement les ressources et opérations.
• JSON Streamer : sérialisation en flux continu, idéale pour les gros volumes de données.
• Performance boost : FrankenPHP en mode worker, deux fois plus rapide que PHP-FPM.
• Interopérabilité renforcée : support OpenAPI amélioré et compatibilité accrue avec Laravel.

Et déjà en ligne de mire : API Platform 5.0 en 2026, qui actera définitivement ces évolutions.

Optimiser la sérialisation avec JsonStreamer

Avec humour et une belle métaphore autour de la gestion d’une librairie, Matthias Arlaud met en avant les limites du serializer Symfony classique : lorsqu’on doit renvoyer des milliers d’objets en JSON, tout est chargé en mémoire avant d’être renvoyé au client. Résultat : ralentissements, voire erreurs out of memory.

La solution ? JsonStreamer, intégré à API Platform 4.2 :

• au lieu de sérialiser tout d’un coup, il “stream” le JSON objet par objet ;
• la mémoire reste stable, peu importe le volume de données ;
• le time-to-first-byte est bien plus rapide, améliorant la perception de performance côté utilisateur.

En pratique, une simple configuration jsonstream: true sur une ressource permet d’activer ce mode. JsonStreamer est donc idéal pour les API qui doivent exposer de gros flux de données (catalogues produits, logs, statistiques…).

Les résultats sont là : plus de 30% de gain de performance et une utilisation plafonnée ; plus le nombre de résultat à récupérer est élevé, plus les gains augmentent.

Retrouvez les slides de Mathias ici => https://www.canva.com/design/DAGyYPxkygw/M1RzOiv8_cMp0Pa7Mh0u4g/view

Redis, un moteur de persistance pour API Platform

Clément Talleu nous a replongés dans l’histoire : stagiaire en 2015 chez Les-Tilleuls.coop, il faisait partie des premiers utilisateurs d’API Platform. Dix ans plus tard, il y contribue directement, notamment avec un object mapper Redis pour PHP.

Redis, base NoSQL clé/valeur ultra-rapide, peut désormais devenir un moteur de persistance natif pour API Platform grâce à php-redis-om. L’intérêt ?

• Exploiter Redisearch pour des recherches textuelles à la vitesse de l’éclair (@name:{toto}).
• Bénéficier d’une syntaxe proche de Doctrine (find(), findByLike()…).
• Utiliser #[ApiResource] et #[RedisOM/Entity] pour brancher directement une entité Redis dans API Platform.

Clément a aussi montré comment gérer filtres, pagination et providers personnalisés pour brancher Redis comme n’importe quelle autre source de données. Un pas de plus vers l’idée d’API Platform agnostique du moteur de persistance.

Normaliser les erreurs pour des APIs plus humaines

“Invalid data” ou “Server error” : qui n’a jamais pesté face à des messages d’erreur vagues ?

Clément Herreman a plaidé pour l’adoption de la RFC 7807 (Problem Details for HTTP APIs). Cette norme définit un format JSON clair et universel :

• type : code unique de l’erreur (machine-readable),
• title : titre compréhensible par un humain,
• detail : description du cas concret,
• instance : identifiant unique de l’erreur.

Avec API Platform, même les erreurs deviennent des ressources : on peut définir une ErrorResource, les documenter dans OpenAPI et même les enrichir de contexte.

Clément recommande aussi de laisser les titres d’erreurs en anglais (codes uniques) et de déléguer la traduction côté front. Résultat : des APIs plus explicites pour les développeurs front, moins de tickets de support et des utilisateurs mieux armés face aux problèmes.

Multi-tenant avec PostgreSQL

De plus en plus d’applications SaaS doivent gérer plusieurs clients (tenants) sur une même base, tout en garantissant l’isolation des données.

Mehdi Zaidi a présenté une architecture multi-tenant PostgreSQL avec Symfony et API Platform :

• un schéma par client (tenant), généré à la volée lors de l’onboarding ;
• des vues matérialisées et un owner_id pour tracer l’appartenance des données ;
• un DatabaseManager custom capable de créer bases, tables et utilisateurs SQL spécifiques pour la sécurité.

Il a aussi abordé la question des migrations : appliquées sur la base principale, elles évitent de multiplier les opérations sur chaque schéma client. Résultat : une approche scalable et pragmatique pour gérer des dizaines (voire centaines) de tenants.

Composer : sécurité et bonnes pratiques

Créateur de Composer, Nils Adermann a livré un message clair : la chaîne d’approvisionnement PHP est une cible privilégiée. Attaques par typosquatting, packages malveillants, comptes compromis…

Parmi ses conseils :

• Utiliser composer audit et roave/security-advisories pour identifier les vulnérabilités.
• Ne jamais supprimer un tag publié (les machines l’ont peut-être déjà téléchargé).
• S’appuyer sur composer update --minimal-changes ou --patch-only pour limiter les risques lors des mises à jour.
• Toujours committer le composer.lock (et ne jamais déployer sans).

Il a aussi présenté Conductor, un outil de Private Packagist conçu spécifiquement pour fiabiliser les mises à jour Composer, là où Dependabot ou Renovate peuvent parfois créer du bruit.

Bases de données à grande échelle

Le terme legacy est souvent mal défini. Cela peut faire référence à du vieux code, à du code sans tests. Ou même du code qui génère desComment scaler une base SQL sans sombrer dans la complexité ?

Tobias Petry a partagé ses retours :

• Commencer simple : scale up (plus grosse machine) avant de complexifier.
• La réplication en lecture améliore la scalabilité mais introduit des problèmes de consistance.
• Le sharding (partition horizontale) est puissant mais dangereux en self-hosted : difficile à maintenir en cas de panne.

Il cite des solutions comme Vitess (YouTube) ou Citus (PostgreSQL), mais recommande de rester pragmatique : le sharding est le “graal”, mais à utiliser uniquement pour des cas critiques de volumétrie.

180 000 requêtes par seconde avec PHP

Xavier Leune a mené une démo impressionnante : atteindre 180k requêtes HTTP/s depuis PHP.

Sa recette :

• exploiter curl_multi pour exécuter des requêtes en parallèle ;
• réduire le “busy looping” en utilisant curl_multi_select ;
• tirer parti de HTTP/2 (multiplexing) et HTTP/3/QUIC (UDP + chiffrement natif), plus efficaces que HTTP/1.1.

En poussant plus loin, il a exploré le multithreading (via pcntl_fork ou pecl/parallel) et l’usage de mémoire partagée (shmop). Une plongée bas niveau qui prouve que PHP, bien optimisé, peut rivaliser avec des outils spécialisés en charge réseau.

De Apache à FrankenPHP

Enfin, Yoan Bernabeu a raconté sa migration d’une infra traditionnelle Apache + Nginx + Symfony vers FrankenPHP.

Objectif : simplifier et réduire les coûts. Résultat :

• plus besoin de load balancer Apache/Nginx ;
• HTTPS géré nativement ;
• une architecture allégée, plus transparente et plus économique.

Un témoignage concret qui confirme que FrankenPHP n’est pas qu’un concept expérimental, mais une vraie alternative en production.