Seite 4 - PHP

Ein externer Feature-Flag-Dienst bringt eine komfortable Oberfläche mit, aber auch eine zusätzliche Abhängigkeit, laufende Kosten und in vielen Fällen Nutzerdaten, die einen dritten Server erreichen, obwohl das gar nicht nötig wäre. Für einen großen Teil der üblichen Anwendungsfälle, von einfachen Ein-Aus-Schaltern bis zu prozentualem Rollout mit Segment-Targeting, reicht ein kompaktes, selbst gebautes Feature-Flag-System in PHP vollkommen aus.

RFC 7807 definiert ein einziges, vorhersagbares JSON-Format für Fehlerantworten: type, title, status, detail und instance. Dieser Artikel zeigt, wie eine PHP-API dieses Format konsequent umsetzt, von der Problem-Details-Klasse über den globalen Exception-Handler bis zu fachlichen Validierungsfehlern mit eigenen Erweiterungsfeldern.

Ein Fluent Interface soll Code lesbarer machen, endet in der Praxis aber oft in schwer debugbaren Ketten ohne klare Fehlerpfade. Mit return $this, sauberer Typsicherheit zwischen self und static sowie Immutability lässt sich ein Fluent Interface bauen, das Method Chaining wirklich sicher macht statt nur elegant aussehen zu lassen.

Verstreute mysql_-Aufrufe und String-verkettete SQL-Abfragen sind eines der häufigsten und gefährlichsten Erbstücke alter PHP-Projekte. Dieser Artikel zeigt, wie man solche Legacy-Datenbankzugriffe systematisch durch eine einheitliche PDO-Schicht mit Prepared Statements ersetzt, ohne den Betrieb zu unterbrechen.

Jeder session_start()-Aufruf, jede TLS-Verbindung und jede Erzeugung eines CSRF-Tokens in PHP benoetigt zufaellige Bytes vom Betriebssystem. Reicht die gesammelte Entropie des Kernels nicht aus, blockieren betroffene Aufrufe, bis genuegend Zufallsdaten vorliegen, ein Effekt, der auf virtuellen Maschinen und in Containern besonders haeufig auftritt und sich als schwer erklaerbare, sporadische Latenzspitzen zeigt.

Ein einziges Modell, das sowohl komplexe Geschäftsregeln beim Schreiben durchsetzt als auch performante, denormalisierte Sichten für die Oberfläche liefert, zwingt fast immer zu faulen Kompromissen auf beiden Seiten. CQRS löst diesen Zielkonflikt auf, indem es Befehle, die Zustand ändern, konsequent von Abfragen trennt, die nur lesen, jeweils mit einem eigenen, auf seinen Zweck zugeschnittenen Modell.

Ein klassischer PHP-FPM-Request gibt seinen kompletten Speicher am Ende automatisch frei, ein Swoole- oder RoadRunner-Worker dagegen lebt über tausende Requests hinweg im selben Prozess. Genau dieser Unterschied macht statischen Zustand, vergessene Closures und wachsende Caches zu einem echten Speicherleck, das über Stunden hinweg langsam den verfügbaren Arbeitsspeicher aufbraucht.

strict_types schaltet die automatische, stille Typkonvertierung von PHP für die aktuelle Datei ab: Ein String an einen int-Parameter, ein Float an einen int-Parameter oder ein falscher Rückgabetyp lösen sofort einen TypeError aus, statt unbemerkt in einen anderen Typ konvertiert zu werden, was Bugs Jahre früher sichtbar macht, direkt am Aufruf statt irgendwo tiefer im Code.

Ein gewöhnliches Array als Cache mit Objekten als Schlüsseln oder Werten verhindert, dass diese Objekte jemals vom Garbage Collector eingesammelt werden, solange der Cache selbst existiert, und genau das führt in lang laufenden Prozessen zu schleichenden Memory Leaks. WeakMap löst dieses Problem strukturell, indem der Cache selbst keinen Einfluss mehr auf die Lebensdauer der referenzierten Objekte nimmt.

Ein eigenes Observer-Pattern hat fast jeder PHP-Entwickler schon einmal gebaut, meist mit einer Subject-Klasse und einer Liste von Callbacks. PSR-14 formalisiert dieses Muster in zwei klar getrennte Verträge. Wir implementieren beide selbst, inklusive Stoppable Events, und bauen daraus einen praktischen Domain-Event-Mechanismus ohne Framework.