✨ Rencontre SQLI

le 17 septembre 2025

Le 16 septembre 2025, l’antenne parisienne de l’AFUP a lancé la nouvelle saison des meetups PHP. Pour cette rentrée, la communauté s’est retrouvée dans les locaux de SQLI Digital Experience à Levallois-Perret, avec un programme axé sur la communication temps réel et la developer experience.

Le meetup de septembre de l’AFUP Paris s’est tenu chez SQLI Digital Experience, marquant le lancement de la saison 2025-2026. Comme à chaque rencontre, l’événement a rassemblé la communauté PHP autour de deux présentations techniques, mais aussi de discussions, d’échanges et de moments conviviaux.

Pour rappel, l’AFUP (Association Française des Utilisateurs de PHP) organise chaque mois des meetups à Paris (hors période estivale). Ces soirées sont l’occasion de découvrir de nouveaux sujets autour de PHP et de ses écosystèmes — qu’il s’agisse de frameworks, de bases de données, d’outils DevOps ou même de méthodologies comme l’agilité.

L’association vit grâce à ses membres et ses partenaires :

  • Speakers qui viennent partager leurs retours d’expérience,
  • Sponsors qui accueillent les événements dans leurs locaux,
  • Bénévoles qui animent la communauté et proposent des formats (mentorat, conférences, forums, etc.).

En parallèle, l’AFUP propose également deux grandes conférences annuelles : le Forum PHP, qui se tiendra les 9 et 10 octobre 2025 à l’Hôtel New York – Disneyland Paris, et le PHP Tour. Ces rendez-vous sont devenus incontournables pour toute personne qui s’intéresse à l’évolution de PHP et de son écosystème.

Chez SQLI, la soirée a démarré par une présentation de l’entreprise et de ses activités autour du digital, du e-commerce et des architectures PHP à grande échelle, avant de laisser la place aux talks techniques.

1️⃣ Server-Sent Events et ZeroMQ – par Amaury Bouchard

La première présentation a mis en lumière une alternative élégante aux websockets : les Server-Sent Events (SSE).

Concept : un flux unidirectionnel du serveur vers le client, basé sur HTTP, simple à mettre en place et compatible avec la majorité des navigateurs.

Cas pratique : Amaury a montré comment intégrer SSE avec ZeroMQ, une bibliothèque de messagerie haute performance. L’exemple choisi était un petit logiciel de chat temps réel, démontrant la simplicité et la robustesse du couple SSE + ZMQ.

Enjeux : cette combinaison permet de construire des applications réactives sans tomber dans la complexité des websockets, tout en s’appuyant sur une infrastructure éprouvée.

SSE en deux minutes

  • Quoi ? Un canal unidirectionnel (serveur → client) au-dessus de HTTP/1.1.
  • Pourquoi ? Plus simple que WebSocket quand on n’a pas besoin d’upstream permanent (chat, notifications, métriques live, logs…).
  • Comment ? Le serveur répond en text/event-stream, garde la connexion ouverte, envoie des événements formatés ; le client se reconnecte tout seul si la connexion coupe.
  • Bonus : on peut multiplier les flux logiques via le champ event: (multiplexage).

Client minimal (navigateur)

<ul id="log"></ul>
<script>
  const ul = document.getElementById('log');
  const es = new EventSource('/events'); // endpoint SSE

  // Événement par défaut
  es.onmessage = (e) => {
    const li = document.createElement('li');
    li.textContent = e.data; // payload texte
    ul.appendChild(li);
  };

  // Multiplexage : écouter un type d’événement nommé
  es.addEventListener('chat', (e) => {
    const { user, text } = JSON.parse(e.data);
    const li = document.createElement('li');
    li.textContent = `[${user}] ${text}`;
    ul.appendChild(li);
  });
</script>

Serveur minimal (PHP “didactique”)

<?php
header('Content-Type: text/event-stream');
header('Cache-Control: no-cache');
header('Connection: keep-alive');

// Boucle d'émission
while (true) {
    $payload = ['ts' => time(), 'msg' => 'tick'];
    // event optionnel pour multiplexage
    echo "event: tick\n";
    echo "data: " . json_encode($payload) . "\n\n";
    @ob_flush(); @flush();
    // Garder la cadence et le CPU bas
    sleep(2);
}

Format d’un événement SSE

event: <nom-optionnel>
id: <cursor-optionnel>
retry: <ms-optionnel>
data: <ligne-1>
data: <ligne-2>
<ligne-vide>

Pourquoi ça marche bien en PHP

  • Pas besoin d’infrastructure dédiée : c’est HTTP.
  • Facile à déployer derrière un reverse-proxy.
  • Le client gère la reconnexion (EventSource).

Limite naturelle : pas d’upstream (client → serveur). Pour envoyer un message, on utilise une requête HTTP classique (AJAX/Fetch), et on laisse le push aux SSE.

Ajouter ZeroMQ : structurer les flux

ZeroMQ (ØMQ) est une lib de messagerie très performante offrant des patterns prêts à l’emploi :

  • REQ/REP – requête/réponse (RPC simple)
  • PUSH/PULL – file de travail (pipeline)
  • PUB/SUB – diffusion (broadcast vers abonnés)

Idée clé du talk :

  • Les navigateurs écoutent via SSE.
  • Le serveur applicatif s’abonne à un broker PUB/SUB (ZeroMQ).
  • Les messages entrants (formulaires, API) sont poussés (PUSH) au broker, qui publie (PUB) vers tous les contrôleurs SSE.

Schéma (texte)

[Client HTTP] --POST /message--> [Controller "message"] --PUSH--> [Broker ØMQ] --PUB--> [Controller "events"] --SSE--> [Navigateur(s)]

Esquisse côté broker (PHP + ext-zmq)

$context = new ZMQContext();

// Réception des messages applicatifs
$pull = new ZMQSocket($context, ZMQ::SOCKET_PULL);
$pull->bind('tcp://*:5557');

// Diffusion vers les consommateurs SSE
$pub = new ZMQSocket($context, ZMQ::SOCKET_PUB);
$pub->bind('tcp://*:5556');

while (true) {
    $msg = $pull->recv();          // attend un message
    $pub->send($msg);              // broadcast
}

Contrôleur “events” (consomme le PUB, émet des SSE)

header('Content-Type: text/event-stream');
header('Cache-Control: no-cache');

$context = new ZMQContext();
$sub = new ZMQSocket($context, ZMQ::SOCKET_SUB);
$sub->connect('tcp://broker:5556');
$sub->setsockopt(ZMQ::SOCKOPT_SUBSCRIBE, ''); // tout

while (true) {
    $msg = $sub->recv(); // JSON {user, text}
    echo "event: chat\n";
    echo "data: $msg\n\n";
    @ob_flush(); @flush();
}

Contrôleur “message” (reçoit un POST, pousse vers le broker)

$user = trim($_POST['user'] ?? '');
$text = trim($_POST['text'] ?? '');
if ($user !== '' && $text !== '') {
    $context = new ZMQContext();
    $push = new ZMQSocket($context, ZMQ::SOCKET_PUSH);
    $push->connect('tcp://broker:5557');
    $push->send(json_encode(['user' => $user, 'text' => $text]));
}
http_response_code(204);

Notes pratiques & pièges évités

  • SSE côté proxy : autoriser les connexions longues et le flush (désactiver la compression sur ce chemin, garder X-Accel-Buffering: no sous Nginx si besoin).
  • Back-pressure : émettre à un rythme raisonnable et flusher pour ne pas accumuler (sinon mémoire).
  • Multiplexage : utilisez event: pour distinguer des flux (chat, metrics, alerts).
  • Reconnexion : EventSource tente automatiquement ; côté serveur, rester idempotent et prévoir un retry: si nécessaire.
  • Sécurité : valider/sanitizer tous les messages, ne jamais diffuser brut des entrées utilisateur.

Résumé

  • SSE = push serveur → navigateur, simple et fiable, parfait pour le diff live.
  • ZeroMQ = colle applicative pour router/diffuser proprement les messages.
  • Ensemble, on obtient un chat temps réel minimaliste, clair et extensible — sans monter une stack WebSocket complète.

2️⃣ Formats de configuration et Symfony – par Nicolas Grekas

La deuxième intervention était animée par Nicolas Grekas, figure incontournable du framework Symfony.

Sujet : un tour d’horizon des formats de configuration disponibles dans Symfony — YAML, XML et PHP.

Points clés :

YAML, longtemps favori pour sa lisibilité, présente des limites de maintenabilité.

XML, plus verbeux, garde des cas d’usage précis.

PHP gagne en popularité car il offre la puissance du langage, la complétion et l’intégration IDE.

Approche DX (Developer Experience) : la discussion a montré comment le choix du format influe directement sur la productivité et l’expérience des équipes.

Le constat

  • Trois formats historiques coexistent : YAML, XML, PHP (config fluide générée depuis l’arbre de configuration).
  • Cette pluralité alourdit la découverte (doc, onglets multiples), multiplie les options, et augmente la charge cognitive pour nouveaux et anciens.
  • DX : le choix du format impacte l’onboarding, l’outillage IDE, la navigation/refactor, les patchs Flex et la collaboration (équipes QA, non-PHP, etc.).

Ce que chaque format apporte (et coûte)

| Format | Atouts | Limites / Frictions | | ----------------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | YAML | Simple, concis, connu au-delà de PHP, facile à lire/partager | Typage implicite, références “moches” (const/enum), tooling dépendant de plugins, erreurs d’indentation | | XML | Très explicite, schématisable, utilisé par des écosystèmes (ex. Sylius/Sulu) | Verbeux, peu apprécié pour la config sémantique d’app | | PHP (config fluide) | Références typiées, complétion IDE, refactor robuste | Verbeux, moins “diffable”, incompatible avec les recettes Flex (patch automatique compliqué) |

Point clé : Flex sait patcher YAML/XML de manière déterministe ; pas du code PHP arbitraire. C’est un verrou important côté DX et écosystème.

Direction proposée (travail en cours)

  1. Déprécier XML pour les configs sémantiques (ex. framework, messenger, …) et les routes côté application, au profit de PHP (déjà adopté en interne côté Symfony).

    • Garder XML là où il reste structurel et interop (ex. déclarations de services fournies par des bundles, cas spécifiques d’écosystèmes).

  2. Conserver YAML comme format majeur côté application : lisible, stable, largement compris (équipes multi-langages, QA, tooling CI/CD).

  3. Ne pas “tuer” PHP : le format PHP fluide reste l’option la plus typée et agréable en IDE pour qui le veut — mais sans casser Flex.

Nouveautés / chantiers en profondeur

A. “Ressources” de compilation (au-delà des services)

Introduire la notion de ressource (classes porteuses de métadonnées utiles) connues du container à la compilation :

  • Exemple : entités avec contraintes de validation (attributs), métadonnées de sérialisation, etc.
  • But : découvrir et figer ces infos à la compilation (au lieu d’une réflexion au runtime), pour des démarrages plus rapides et une DX plus robuste (moins de magie tardive).

B. Attributs compilés (et pas seulement au runtime)

  • Aujourd’hui, les attributs marchent à l’exécution via réflexion.
  • Travail en cours : collecter les attributs à la compilation, générer les mappings (validation, serialization…) et réduire la charge runtime.

C. Étendre/override proprement les métadonnées… sans XML imposé

  • Cas réels (ex. Sylius/Sulu) : on étend les contraintes de validation via YAML/XML.
  • Objectif : offrir une alternative moderne (classes “support” dédiées, attributs compilés) pour étendre les modèles sans enfermer les projets dans XML.

D. Tableaux PHP avec autocomplétion forte

  • Exploration : décrire l’arbre de config de manière à ce que des tableaux PHP bénéficient d’une autocomplétion IDE riche (clés valides selon la profondeur, doc inline).
  • Collaboration active avec les équipes d’IDE (ex. PhpStorm) pour mieux supporter commentaires/doc et clés imbriquées → DX du tableau grandement améliorée.

Points DX débattus (et arbitrages)

  • Performance YAML vs PHP : différences négligeables à l’usage (parse au build/cache).
  • Lisibilité : YAML reste compact pour la config d’app ; PHP gagne en refactor et en typage.
  • Équipes non-PHP : YAML demeure universel (QA, ops, docs).
  • Flex : argument décisif pour garder YAML/XML là où les recettes doivent patcher les projets automatiquement.

Ce qui pourrait changer “visiblement”

  • Moins d’onglets et d’ambiguïtés dans la doc (réduction des formats recommandés selon le type de configuration).
  • XML reculé là où il n’apporte pas d’avantage direct (config sémantique & routing d’app).
  • Attributs compilés + ressources : des builds plus rapides, des bundles plus prévisibles.
  • Autocomplétion plus “intelligente” pour les tableaux PHP (meilleure découverte des clés et valeurs possibles).

Résumé

  • Pas de “guerre de religion” : YAML reste confortable et interop ; PHP est fort en IDE ; XML recule là où il n’est plus utile.
  • Les efforts portent sur la DX globale : Flex, doc, outils, compilation des attributs et formats plus sûrs.
  • Cap : simplifier les choix, réduire la dispersion, et accélérer la boucle dev grâce à des métadonnées compilées et une autocomplétion nettement améliorée.

3️⃣ Au-delà des talks : la valeur du meetup

Au-delà des sujets techniques, l’événement a confirmé l’importance des meetups pour :

Rencontrer la communauté PHP parisienne et échanger sur les bonnes pratiques.

Découvrir des approches concrètes à travers du code live, sans slides superflus.

Créer du lien entre experts, débutants et curieux, dans une ambiance conviviale.

📌 Conclusion

Entre temps réel simplifié grâce à SSE/ZMQ et réflexion sur la DX dans Symfony, ce premier meetup de la saison a posé des bases solides pour les prochains rendez-vous. Un grand merci à SQLI pour l’accueil et aux speakers pour leur énergie et leurs démonstrations concrètes.

👉 Rendez-vous le mois prochain pour la suite des rencontres AFUP Paris !