✨ Meetup SQLI

der 17. September 2025

Am 16. September 2025 startete die Pariser Niederlassung der AFUP die neue Saison der PHP-Meetups. Zum Schulanfang traf sich die Community in den Räumlichkeiten der SQLI Digital Experience in Levallois-Perret mit einem Programm, das sich auf Echtzeitkommunikation und Entwicklererfahrung konzentrierte.

Das AFUP Paris-Treffen im September fand in der SQLI Digital Experience statt und markierte den Start der Saison 2025-2026. Wie bei jedem Treffen brachte die Veranstaltung die PHP-Community bei zwei technischen Präsentationen sowie Diskussionen, Austausch und geselligen Momenten zusammen.

Zur Erinnerung: Die AFUP (Französische Vereinigung der PHP-Benutzer) organisiert monatliche Treffen in Paris (außer im Sommer). Diese Abende bieten die Gelegenheit, neue Themen rund um PHP und seine Ökosysteme zu entdecken – ob Frameworks, Datenbanken, DevOps-Tools oder auch Methoden wie Agilität.

Der Verein lebt von seinen Mitgliedern und Partnern: - Referenten, die ihr Feedback weitergeben, - Sponsoren, die Veranstaltungen in ihren Räumlichkeiten ausrichten, - Ehrenamtlichen, die die Community leiten und Formate anbieten (Mentoring, Konferenzen, Foren etc.).

Gleichzeitig bietet die AFUP zwei große jährliche Konferenzen an: das PHP Forum, das am 9. und 10. Oktober 2025 im Hotel New York – Disneyland Paris stattfindet, und die PHP Tour. Diese Veranstaltungen sind für alle, die sich für die Entwicklung von PHP und seinem Ökosystem interessieren, unverzichtbar geworden.

Bei SQLI begann der Abend mit einer Präsentation des Unternehmens und seiner Aktivitäten in den Bereichen Digital, E-Commerce und groß angelegte PHP-Architekturen, bevor es zu technischen Vorträgen kam.

1️⃣ Server-Sent Events und ZeroMQ – von Amaury Bouchard

Die erste Präsentation hob eine elegante Alternative zu Websockets hervor: Server-Sent Events (SSE).

Konzept: ein Einwegfluss vom Server zum Client, basierend auf HTTP, einfach einzurichten und mit den meisten Browsern kompatibel.

Praxisbeispiel: Amaury demonstrierte die Integration von SSE mit ZeroMQ, einer leistungsstarken Messaging-Bibliothek. Als Beispiel diente eine kleine Echtzeit-Chat-Software, die die Einfachheit und Robustheit der Kombination aus SSE und ZMQ demonstrierte.

Herausforderungen: Diese Kombination ermöglicht es, reaktive Anwendungen zu erstellen, ohne in die Komplexität von Websockets zu verfallen und gleichzeitig auf einer bewährten Infrastruktur zu basieren.

SSE in zwei Minuten

  • Was? Ein unidirektionaler Kanal (Server → Client) über HTTP/1.1. * Warum? Einfacher als WebSocket, wenn kein permanenter Upstream (Chat, Benachrichtigungen, Live-Metriken, Logs etc.) benötigt wird. * Wie? Der Server antwortet in „text/event-stream“, hält die Verbindung offen und sendet formatierte Ereignisse; der Client stellt die Verbindung selbstständig wieder her, wenn die Verbindung abbricht. * Bonus: Sie können die logischen Abläufe über das Feld „event:“ multiplizieren (Multiplexing).

Minimaler Client (Browser)

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

  // Standardereignis es.onmessage = (e) => { const li = document.createElement('li'); li.textContent = e.data; // Nutzlasttext ul.appendChild(li); };

  // Multiplexing: Auf einen benannten Ereignistyp hören es.addEventListener('chat', (e) => { const { user, text } = JSON.parse(e.data); const li = document.createElement('li'); li.textContent = `[${user}] ${text}`; ul.appendChild(li); });</script>

Minimalserver („pädagogisches“ PHP)

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

// Schleife ausgeben while (true) { $payload = ['ts' => time(), 'msg' => 'tick']; // optionales Ereignis für Multiplexing echo "event: tick\n"; echo "data: " . json_encode($payload) . "\n\n"; @ob_flush(); @flush(); // Bildrate und CPU niedrig halten sleep(2); }

Format einer SSE-Veranstaltung

Ereignis:<nom-optionnel> Ausweis:<cursor-optionnel> wiederholen:<ms-optionnel> Daten:<ligne-1> Daten:<ligne-2><ligne-vide>

Warum es in PHP gut funktioniert

  • Keine dedizierte Infrastruktur erforderlich: Es ist HTTP. * Einfache Bereitstellung hinter einem Reverse-Proxy. * Der Client übernimmt die erneute Verbindung („EventSource“).

Natürliche Einschränkung: kein Upstream (Client → Server). Zum Senden einer Nachricht verwenden wir eine klassische HTTP-Anfrage (AJAX/Fetch) und überlassen das Pushen der SSE.

ZeroMQ hinzufügen: Strukturierung der Flows

ZeroMQ (ØMQ) ist eine leistungsstarke Messaging-Bibliothek, die gebrauchsfertige Muster bietet:

  • REQ/REP – Anfrage/Antwort (einfaches RPC) * PUSH/PULL – Arbeitswarteschlange (Pipeline) * PUB/SUB – Broadcast (Broadcast an Abonnenten)

Kerngedanke des Vortrags:

  • Browser hören über SSE. * Der Anwendungsserver abonniert einen „PUB/SUB“-Broker (ZeroMQ). * Eingehende Nachrichten (Formulare, APIs) werden an den Broker weitergeleitet („PUSH“), der sie an alle SSE-Controller veröffentlicht („PUB“).

Diagramm (Text)

[HTTP-Client] --POST /message--> [Controller "message"] --PUSH--> [Broker ØMQ] --PUB--> [Controller "events"] --SSE--> [Browser]

Brokerseitige Skizze (PHP + ext-zmq)

$context = neuer ZMQContext();

// Empfangen von Anwendungsnachrichten $pull = new ZMQSocket($context, ZMQ::SOCKET_PULL); $pull->bind('tcp://*:5557');

// An SSE-Verbraucher senden $pub = new ZMQSocket($context, ZMQ::SOCKET_PUB); $pub->bind('tcp://*:5556');

while (true) { $msg = $pull->recv(); // auf eine Nachricht warten $pub->send($msg); // senden }

„Ereignis“-Controller (verbraucht PUB, gibt SSEs aus)

Header('Inhaltstyp: Text/Ereignisstrom'); Header('Cache-Steuerung: kein Cache');

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

while (true) { $msg = $sub->recv(); // JSON {Benutzer, Text} echo "Ereignis: Chat\n"; echo "Daten: $msg\n\n"; @ob_flush(); @flush(); }

„Message“-Controller (empfängt einen POST, pusht ihn an den Broker)

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

Praktische Hinweise & Fallstricke vermieden

  • Proxy-seitiges SSE: Lange Verbindungen und Leeren zulassen (Komprimierung auf diesem Pfad deaktivieren, X-Accel-Buffering: no unter Nginx beibehalten, falls erforderlich). * Gegendruck: Mit angemessener Rate ausgeben und leeren, um Ansammlung zu vermeiden (sonst Speicher). * Multiplexing: event: verwenden, um zwischen Streams zu unterscheiden (chat, metrics, alerts). * Wiederverbindung: EventSource versucht es automatisch; serverseitig, idempotent bleiben und falls erforderlich ein retry: zulassen. * Sicherheit: Alle Nachrichten validieren/bereinigen, niemals unverarbeitete Benutzereingaben senden.

TL;DR

  • SSE = Server-zu-Browser-Push, einfach und zuverlässig, perfekt für Live-Diffs. * ZeroMQ = Anwendungskleber für sauberes Routing/Broadcasting von Nachrichten. * Zusammen erhalten wir einen minimalistischen, sauberen und erweiterbaren Echtzeit-Chat – ohne einen vollständigen WebSocket-Stack zu erstellen.

2️⃣ Konfigurationsformate und Symfony – von Nicolas Grekas

Die zweite Präsentation wurde von Nicolas Grekas geleitet, einer Schlüsselfigur im Symfony-Framework.

Thema: Eine Übersicht über die in Symfony verfügbaren Konfigurationsformate – YAML, XML und PHP.

Wichtige Punkte:

YAML wurde lange Zeit wegen seiner Lesbarkeit bevorzugt, weist jedoch Einschränkungen hinsichtlich der Wartung auf.

XML ist ausführlicher und behält bestimmte Anwendungsfälle bei.

PHP erfreut sich zunehmender Beliebtheit, da es Sprachleistung, Vervollständigung und IDE-Integration bietet.

DX-Ansatz (Developer Experience): Die Diskussion zeigte, wie sich die Wahl des Formats direkt auf die Produktivität und Erfahrung des Teams auswirkt.

Die Beobachtung

  • Drei historische Formate existieren nebeneinander: YAML, XML, PHP (flüssige Konfiguration, generiert aus dem Konfigurationsbaum). * Diese Vielfalt erschwert die Suche (Dokument, mehrere Registerkarten), vervielfacht die Optionen und erhöht die kognitive Belastung für neue und alte Benutzer. * DX: Die Wahl des Formats wirkt sich auf Onboarding, IDE-Tools, Navigation/Refactoring, Flex-Patches und Zusammenarbeit (QA-Teams, Nicht-PHP usw.) aus.

Was jedes Format bringt (und kostet)

| Format | Stärken | Einschränkungen/Reibungen | | ----------------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | YAML | Einfach, prägnant, über PHP hinaus bekannt, leicht zu lesen/teilen | Implizite Typisierung, „hässliche“ Referenzen (const/enum), plugin-abhängige Tools, Einrückungsfehler | | XML | Sehr explizit, schematisierbar, wird von Ökosystemen verwendet (z. B. Sylius/Sulu) | Ausführlich, wird für die semantische App-Konfiguration nicht geschätzt | | PHP (flüssige Konfiguration) | Typisierte Referenzen, IDE-Vervollständigung, robustes Refactoring | Ausführlich, weniger „diffbar“, inkompatibel mit Flex-Rezepten (kompliziertes automatisches Patchen) |

Wichtiger Punkt: Flex kann YAML/XML deterministisch patchen, nicht beliebigen PHP-Code. Dies ist ein großes Hindernis für DX und das Ökosystem.

Vorgeschlagene Richtung (in Arbeit)

  1. XML für semantische Konfigurationen (z. B. „Framework“, „Messenger“ usw.) und anwendungsseitige Routen zugunsten von PHP (auf der Symfony-Seite bereits intern übernommen) verwerfen.

    • Behalten Sie XML bei, wo es strukturell und interoperabel bleibt (z. B. von Bundles bereitgestellte Servicedeklarationen, spezielle Fälle von Ökosystemen).

  2. Behalten Sie YAML als wichtigstes anwendungsseitiges Format bei: lesbar, stabil, allgemein verständlich (mehrsprachige Teams, Qualitätssicherung, CI/CD-Tools).

  3. PHP nicht „töten“: Das flüssige PHP-Format bleibt für diejenigen, die es wollen, die typisierteste und angenehmste Option in der IDE – aber ohne Flex zu beschädigen.

Neuigkeiten / ausführliche Projekte

A. Zusammenstellung „Ressourcen“ (über Dienstleistungen hinaus)

Führen Sie den Begriff der Ressource (Klassen mit nützlichen Metadaten) ein, die dem Container bei der Kompilierung bekannt ist:

  • Beispiel: Entitäten mit Validierungsbeschränkungen (Attribute), Serialisierungsmetadaten usw. * Ziel: Entdecken und Einfrieren dieser Informationen zur Kompilierzeit (anstelle einer Laufzeitreflexion), für schnellere Starts und eine robustere DX (weniger späte Magie).

B. Kompilierte Attribute (nicht nur Laufzeit)

  • Heute funktionieren Attribute zur Laufzeit über Reflexion. * In Arbeit: Sammeln Sie Attribute zur Kompilierzeit, generieren Sie Zuordnungen (Validierung, Serialisierung usw.) und reduzieren Sie die Laufzeitlast.

C. Metadaten ordnungsgemäß erweitern/überschreiben… ohne erzwungenes XML

  • Reale Fälle (z. B. Sylius/Sulu): Wir erweitern Validierungsbeschränkungen über YAML/XML. * Ziel: eine moderne Alternative (dedizierte „Support“-Klassen, kompilierte Attribute) zur Erweiterung von Modellen anzubieten, ohne Projekte an XML zu binden.

D. PHP-Arrays mit starker Autovervollständigung

  • Erkundung: Beschreiben Sie den Konfigurationsbaum, damit PHP-Tabellen von der umfassenden IDE-Autovervollständigung profitieren (tiefenabhängige gültige Schlüssel, Inline-Dokumentation). * Aktive Zusammenarbeit mit IDE-Teams (z. B. PhpStorm), um Kommentare/Dokumentation und verschachtelte Schlüssel besser zu unterstützen → Tabellen-DX stark verbessert.

Besprochene DX-Punkte (und Schiedsverfahren)

  • YAML vs. PHP-Leistung: vernachlässigbare Unterschiede in der Nutzung (Parsen beim Build/Cache). * Lesbarkeit: YAML bleibt kompakt für die App-Konfiguration; PHP gewinnt bei Refactoring und Typisierung. * Nicht-PHP-Teams: YAML bleibt universell (QA, Ops, Dokumentation). * Flex: entscheidendes Argument für die Beibehaltung von YAML/XML, wenn Rezepte Projekte automatisch patchen müssen.

Was sich „sichtbar“ ändern könnte

  • Weniger Tabs und Mehrdeutigkeiten in den Dokumenten (Reduzierung der empfohlenen Formate basierend auf dem Konfigurationstyp). * XML wird dort zurückgedrängt, wo es keinen direkten Nutzen bringt (semantische Konfiguration und App-Routing). * Kompilierte Attribute + Ressourcen: schnellere Builds, vorhersehbarere Bundles. * Intelligentere Autovervollständigung für PHP-Arrays (bessere Erkennung möglicher Schlüssel und Werte).

TL;DR

  • Kein „Religionskrieg“: YAML bleibt komfortabel und interoperabel; PHP ist in der IDE stark; XML zieht sich zurück, wo es nicht mehr nützlich ist. * Die Bemühungen konzentrieren sich auf globale DX: Flex, Dokumentation, Tools, Kompilierung von Attributen und sicherere Formate. * Kurs: Vereinfachen Sie Auswahlmöglichkeiten, reduzieren Sie die Streuung und beschleunigen Sie die Entwicklungsschleife dank kompilierter Metadaten und deutlich verbesserter Autovervollständigung.

3️⃣ Über die Gespräche hinaus: Der Wert des Treffens

Über technische Themen hinaus bestätigte die Veranstaltung die Bedeutung von Meetups für:

Treffen Sie die Pariser PHP-Community und diskutieren Sie Best Practices.

Entdecken Sie konkrete Ansätze durch Live-Code, ohne überflüssige Folien.

Schaffen Sie in freundlicher Atmosphäre Verbindungen zwischen Experten, Anfängern und Neugierigen.

📌 Fazit

Zwischen vereinfachter Echtzeit dank SSE/ZMQ und der Reflexion über DX in Symfony legte dieses erste Treffen der Saison eine solide Grundlage für zukünftige Treffen. Vielen Dank an SQLI für die Begrüßung und an die Referenten für ihre Energie und ihre konkreten Demonstrationen.

👉 Wir sehen uns nächsten Monat zur Fortsetzung der AFUP-Treffen in Paris!