Seite 4 - Symfony

Ein Symfony Docker Image, das lokal läuft, ist noch lange nicht produktionsreif. Multi-Stage-Builds trennen Build- und Laufzeitumgebung, Composer-Caching verkürzt jeden Build, ein Non-Root-User und ein Healthcheck machen den Container betriebssicher. Dieser Artikel zeigt Schritt für Schritt, wie ein schlankes, gehärtetes Symfony Docker Image entsteht.

Ein Webhook-Endpunkt ist per Definition öffentlich erreichbar und nimmt Daten von einem externen Dienst entgegen, ohne dass sich der klassische Login-Mechanismus der eigenen Anwendung anwenden ließe. Ohne eine kryptografische Signaturprüfung kann grundsätzlich jeder, der die URL kennt, beliebige Payloads einschleusen und dadurch fachliche Aktionen wie eine Zahlungsbestätigung oder eine Bestellstatus-Änderung auslösen. Dieser Artikel zeigt, wie man in Symfony einen dedizierten Webhook-Controller baut, eine HMAC-Signatur mit hash_hmac und hash_equals sicher gegen Timing-Angriffe prüft, wann sich die eingebaute Symfony-Webhook-Komponente eignet und wie man wiederholte Zustellungen desselben Events idempotent verarbeitet.

Attribute-Routing deckt den weitaus größten Teil aller Anwendungen ab, stößt aber an seine Grenzen, sobald Routen zur Laufzeit aus einer Datenbank stammen, etwa für CMS-Seiten oder Redirects. Dieser Artikel zeigt, wie ein eigener Loader solche Fälle abdeckt, wie Custom-Requirements mit Regex Parameter direkt im Routing validieren und wie sich die Reihenfolge bei überlappenden Routen zuverlässig steuern lässt.

Symfony UX Autocomplete verbindet Doctrine-Entities, eigene Suchlogik und externe APIs mit einem einzigen Formularfeld-Typ und liefert dabei serverseitiges Rendering, Stimulus-Steuerung und Tom Select als Frontend, ohne dass ein einziges eigenes JavaScript-Modul geschrieben werden muss.

Symfony mit Inertia.js zu kombinieren bedeutet, Controller weiterhin klassisch Twig-artig zu schreiben, nur dass am Ende statt HTML ein React-Komponentenname mit Props zurückgegeben wird, wodurch das gesamte Frontend wie eine Single-Page-Application wirkt, ohne dass irgendwo eine separate REST- oder GraphQL-API entsteht.

Naive Entity-Iteration über Millionen Datensätze führt zuverlässig in ein Memory-Limit, weil der UnitOfWork jede geladene Entity im Speicher hält. EntityManager::clear(), toIterable() und Bulk-DQL-Updates lösen dieses Problem, jeweils mit eigenen Kompromissen.

Wer glaubt, API Platform funktioniere nur mit Doctrine Entities, kennt den State Provider und den State Processor noch nicht. Diese beiden Interfaces entkoppeln Lesen und Schreiben komplett von der Persistenzschicht und erlauben es, REST Endpunkte, Legacy Systeme oder reine Rechenwerte als vollwertige API Ressourcen bereitzustellen.

Feature Flags ermöglichen Continuous Deployment ohne Feature Branching: Code wird gemergt, aber Features bleiben deaktiviert, bis sie bereit sind. Eine eigene, auf Symfony-Bordmitteln aufgebaute Lösung ist schlanker, schneller und vollständig kontrollierbar — ohne externe Abhängigkeiten und ohne Vendor-Lock-in.

Veraltete Symfony Bundles sind eines der groessten stillen Risiken in produktiven Anwendungen: unsupportete Sicherheits-Fixes, inkompatible Abhaengigkeiten und stillstehende Weiterentwicklung. Ein klarer Entscheidungsrahmen zeigt, wann ein Bundle ersetzt werden muss und welche native Symfony-Komponente die richtige Alternative ist.

PHPStan ist der mächtigste statische Analyzer für PHP — aber in Symfony-Projekten stoßen Teams schnell auf Grenzen: magische Methoden in Repositories, Doctrine-Spaltentypen die sich von PHP-Typen unterscheiden, Container-Parameter ohne Typen und komplexe Generic-Annotierungen. Dieser Beitrag zeigt, wie man PHPStan in Symfony systematisch auf Level 9 bringt.