fsck.sh - Deutsch

Symfony Messenger Worker hängt? 3 stille Production-Bugs

2026-02-27T00:00:00Z

Sechzehn Minuten. Drei Bugs. Null Fehlermeldungen.

Oder: Wie Symfony Messenger uns versicherte, dass alles läuft — während absolut nichts passierte

Wir haben einen Symfony-Messenger-Worker auf Production deployed, den Start beobachtet, das vertraute [OK] Consuming messages from transport "bulk_operations" in den Logs gesehen — und weitergemacht. Messages stauten sich. Der Worker tat nichts. Keine Exceptions, keine Warnings, keine fehlgeschlagenen Jobs. Nur Stille.

Was folgte, war eine 16-minütige Debugging-Session, die drei voneinander unabhängige Bugs aufdeckte — jeder auf seine Art unsichtbar. Hier ist der Ablauf.

TL;DR: Drei Bugs, drei Silent Failures. (1) auto_setup=0 in der DSN sorgte dafür, dass die messenger_messages-Tabelle nie erstellt wurde — der Worker loggt trotzdem OK. (2) use_notify: true funktioniert nur mit PostgreSQL; MySQL ignoriert es und fällt nicht auf Polling zurück. (3) PHP-FPM schrieb Europe/Berlin-Timestamps, während PHP CLI sie als UTC las — jeder Background-Job verzögerte sich um exakt eine Stunde.

Das Setup

Die Umgebung: Symfony 6.2, PHP 8.1, MySQL 8.0 auf einem Bare-Metal-Ubuntu-Server. Alle Erkenntnisse beziehen sich auf diesen Stack — das Verhalten kann sich mit anderen Symfony-Versionen oder Redis/AMQP-Transports unterscheiden. Der Background-Worker läuft als systemd-Service (der Standard-Mechanismus unter Linux für langlaufende Hintergrundprozesse):

# /etc/systemd/system/messenger.service ExecStart=/usr/bin/php /var/www/app/bin/console messenger:consume bulk_operations --time-limit=3600 --memory-limit=128M User=www-data

Der Transport nutzt Doctrine:

# config/packages/messenger.yaml framework:  messenger:  transports:  bulk_operations:  dsn: "%env(MESSENGER_TRANSPORT_DSN)%"  options:  use_notify: true  check_delayed_interval: 60000

Und die DSN in .env:

MESSENGER_TRANSPORT_DSN=doctrine://default?auto_setup=0

Drei Config-Entscheidungen. Drei Bugs. Schauen wir sie uns in der Reihenfolge an, in der wir sie gefunden haben.

Warum schlägt Messenger ohne die ‘messenger_messages’-Tabelle still fehl?

Die messenger_messages-Tabelle existierte nicht.

Die DSN hatte auto_setup=0, was Symfonys Doctrine-Transport anweist, die Queue-Tabelle nicht automatisch anzulegen. Das ist ein vernünftiges Production-Setting — du willst nicht, dass deine App Datenbanktabellen on the fly erstellt. Aber es setzt voraus, dass du die Tabelle selbst angelegt hast. Hatten wir nicht.

Das Problem: messenger_messages ist keine Doctrine-Entity. Es gibt keine Migration dafür, keine Entity-Klasse, nichts in src/Entity/. Es ist eine interne Transport-Tabelle, die Symfony außerhalb deines ORM-Layers verwaltet. Wenn du den Transport sie nicht erstellen lässt und es auch nicht manuell machst, existiert sie schlicht nicht.

Die Reaktion des Workers auf eine fehlende Tabelle? [OK] Consuming messages from transport "bulk_operations". Kein Error. Kein Warning. Nur ein grünes Häkchen und unendliche…

Weiterlesen auf fsck.sh →

Jagd auf einen 0,18%-Bug: Redis Lock Expiration in Crunz

2026-02-10T00:00:00Z

Wenn „sporadisch" eigentlich „mathematisch unvermeidlich" heißt

In RedisStore.php line 185: [Symfony\Component\Lock\Exception\LockConflictedException]

Eine Zeile. Kein Stack Trace. Kein Kontext. Nur eine LockConflictedException in den Logs unseres crunz-Schedulers — jeden einzelnen Tag. Mal einmal, mal ein Dutzend Mal. Kein erkennbares Muster, kein offensichtlicher Auslöser. Ein nicht-deterministischer Bug wie aus dem Lehrbuch.

Ich hab’s eine Weile ignoriert. Dann hab ich gerechnet.

Es war gar nicht zufällig. Es war eine probabilistische Gewissheit, eingebaut in den Lock-Refresh-Mechanismus von Crunz — ein Bug, der ungefähr 1 von 550 Lock-Operationen trifft. Bei 42 Redis-gesicherten Cronjobs über den Tag verteilt war die Frage nie ob es passiert, sondern wie oft.

Was ist ein Lock, und warum läuft er ab?

Wer sich mit Distributed Locking und Mutual Exclusion bereits auskennt: einfach weiterspringen. Für alle anderen — ein kurzes Gedankenmodell.

Stell dir einen Lock vor wie eine Parkuhr. Du wirfst Münzen rein (eine TTL — Time to Live), und solange die Uhr läuft, gehört der Parkplatz dir. Niemand sonst kann ihn nehmen. Aber sobald die Zeit abläuft, ist der Platz wieder frei — auch wenn du noch im Laden einkaufst.

Redis Locks funktionieren genauso. Crunz — ein PHP-Cronjob-Scheduler — nutzt die Symfony Lock-Komponente mit einem RedisStore, um überlappende Task-Ausführung zu verhindern. Wenn ein Task startet, holt er sich einen Lock mit Zeitlimit via ZADD (Redis’ „Sorted Set Add"-Befehl — speichert einen einzigartigen Token mit einem Score, der den Expiry-Timestamp darstellt). Solange der Task den Lock vor Ablauf erneuert, ist alles sicher. Aber kommt die Erneuerung zu spät — auch nur um den Bruchteil einer Sekunde — betrachtet Redis den Lock als weg. Der nächste Refresh-Versuch findet einen leeren Platz und wirft LockConflictedException.

Der Clou: Crunz erneuert den Lock nicht zuverlässig. Es nutzt einen probabilistischen Ansatz. Dazu gleich mehr.

Redis Distributed Locks in PHP

Ein Distributed Lock mit Redis stellt sicher, dass nur ein Prozess gleichzeitig einen kritischen Abschnitt ausführt — selbst über mehrere Server hinweg. In PHP macht die Symfony Lock-Komponente das unkompliziert. Ein einfaches Redis-Lock-Beispiel:

use Symfony\Component\Lock\LockFactory; use Symfony\Component\Lock\Store\RedisStore;  $redis = new \Predis\Client(['host' => 'localhost', 'port' => 6379]); $store = new RedisStore($redis…

Weiterlesen auf fsck.sh →

PHP: Die Kakerlake unter den Programmiersprachen (Und warum das ein Kompliment ist)

2026-01-29T00:00:00Z

Unsterblich, unmodern, unbestreitbar beschäftigt

2011 machte ein Artikel mit dem Titel „PHP is Dying“ die Runde. Der Autor prophezeite, dass PHP innerhalb von fünf Jahren nur noch für Legacy-Wartung taugen würde. Das war vor 15 Jahren. PHP betreibt immer noch 73,3% aller Websites mit erkennbarer Server-Technologie (W3Techs, Januar 2026).

Ich schreibe PHP seit 2002. In 15 dieser Jahre war es mein Haupteinkommen als Freiberufler. Mit Symfony arbeite ich seit Version 2. Und alle paar Jahre erzählt mir jemand selbstsicher, dass meine Berufswahl am Sterben ist.

Sie liegen immer noch falsch. Aber ganz ohne Punkte sind sie nicht.

Die Kritiker haben teilweise recht

Seien wir ehrlich: PHP hat echte Probleme. Sie anzuerkennen macht uns zu besseren Entwicklern, nicht zu illoyalen.

Die Standardbibliothek ist Chaos. Die Parameterreihenfolge ist inkonsistent (strpos($haystack, $needle) vs array_search($needle, $haystack)). Namenskonventionen sind überall anders (str_replace vs substr vs string_starts_with). Das ist nicht zu verteidigen. Es ist historischer Ballast aus dem rasanten, Community-getriebenen Wachstum der frühen Jahre.

Unicode-Handling ist angeflanscht. Du brauchst mb_*-Funktionen für ordentliche Multibyte-Unterstützung, und wenn du sie vergisst, entstehen subtile Bugs. 2026 ist das immer noch nicht erstklassig gelöst.

Legacy-Code gibt PHP einen schlechten Ruf. Viel PHP da draußen ist wirklich furchtbar. Ungepflegte WordPress-Plugins, Spaghetti-Code von 2008, überall rohes SQL. Wenn Kritiker sagen „PHP-Code ist schlecht“, schauen sie oft auf Code, der in jeder Sprache schlecht wäre. Aber PHPs niedrige Einstiegshürde bedeutet, dass mehr davon sichtbar ist.

Das sind legitime Kritikpunkte. Wer sich darauf konzentriert, ist fair.

Warum der Mythos sich hält

Wenn PHP also echte Probleme hat, warum nenne ich „PHP stirbt“ einen Mythos? Weil die Vorhersagen nicht zur Realität passen. Die „PHP stirbt“-Erzählung läuft durchgehend seit mindestens 2004 (Slashdot-Diskussionen) über 2007 (frühe Blogposts) bis 2011 (Mainstream-Tech-Presse) bis heute.

Survivorship-Bias funktioniert in beide Richtungen. Kritiker erinnern sich an den furchtbaren PHP-4-Code, den sie gesehen haben. Sie sehen nicht die modernen Symfony-Anwendungen mit strikter Typisierung, 100% Testabdeckung und sauberer Architektur. Diese Anwendungen laufen einfach still in Produktion.

Der Hype-Zyklus bevorzugt Neues. Node.js sollte PHP 2012 „killen“. Go 2015. Rust 2018. Jede neue Sprache bekommt atemlose Berichterstattung. PHP liefert weiter Features und baut sein Ökosystem aus. Ohne den gleichen Rummel.

Engagement-Farming. „PHP ist tot“ generiert Klicks und hitzige Diskussionen. „PHP 8.4 bringt Property Hooks“ trendet nicht auf X (das Twitter ersetzt hat).

Die Mythen, die nicht…

Weiterlesen auf fsck.sh →

Doppar: Laravels schlanker, schneller Cousin

2026-01-28T00:00:00Z

Oder: Was passiert, wenn “schnell genug” nicht reicht

318 Requests pro Sekunde. 1.000 gleichzeitige Nutzer. Null verlorene Verbindungen.

Das sind Stresstestergebnisse von Doppar, einem PHP-Framework, von dem du wahrscheinlich noch nie gehört hast. Laravel optimiert für Developer Experience. Symfony optimiert für Enterprise-Stabilität. Doppar optimiert für pure Geschwindigkeit — und überlässt dir den Rest.

Für wen das hier ist: Du hast deine PHP-Anwendung profiliert, Queries optimiert, Caching eingebaut, und brauchst trotzdem mehr Durchsatz. Du hast kein Problem damit, Integrationen selbst zu schreiben, die woanders ein composer require wären. Du willst Laravel-Syntax ohne Laravel-Overhead.

Was ist Doppar?

Doppar ist ein performantes, minimalistisches PHP-Framework, das Ende 2025 Version 3.x veröffentlicht hat. Es basiert auf drei Prinzipien:

Null externe Abhängigkeiten für Kernfunktionen
Intelligentes Memoization wiederholter Ausführungen
Attribute-First-Konfiguration

composer create-project doppar/doppar my-app cd my-app php pool server:start

Deine erste Route:

// app/Http/Controllers/HelloController.php #[Mapper(prefix: 'api')] class HelloController extends Controller {  #[Route(uri: 'hello/{name}', methods: ['GET'])]  public function greet(string $name): Response  {  return response()->json(['message' => "Hallo, {$name}!"]);  } }

Voraussetzungen: PHP 8.3+ und Composer.

Geschichte & Philosophie

Doppar wurde von techmahedy entwickelt — ein Entwickler, der Laravels elegante Syntax ohne den Overhead wollte. Das 3.x-Release Ende 2025 markierte den Übergang vom Experiment zum nutzbaren Framework. Die Parallele zu Laravels eigener Entstehungsgeschichte ist kein Zufall — Symfony existierte und war robust, aber Laravel fand seine Stimme, indem es etwas anderes anbot.

Die Philosophie ist simpel:

“Brauchst du ein Feature? Installier es und nutz es. Brauchst du es nicht? Halt deine Anwendung so einfach und sauber wie möglich.”

Doppar will Laravel oder Symfony nicht ersetzen. Es ist eine Alternative für Entwickler, die alles aus ihrem aktuellen Stack rausgeholt haben und trotzdem mehr brauchen.

Warum ist es schnell?

Drei Techniken machen Doppar schneller als typische PHP-Frameworks:

1. Intelligentes Memoization

Wiederholte Ausführungen werden automatisch gecacht. Config-Parsing, Service-Auflösung, Route-Matching — alles, was mehr als einmal läuft, wird ohne manuelles Eingreifen memoized.

2. Abhängigkeitsfreier Core

ORM, Validation, WebSocket-Server und Scheduler sind direkt im Core eingebaut. Kein Doctrine. Keine externen Queue-Packages. Keine Third-Party-HTTP-Clients für…

Weiterlesen auf fsck.sh →

Spukhafte Fernwirkung: Wenn dein Proxy-Fix die Anwendung zerstört

2026-01-21T00:00:00Z

Oder: Wie ich lernte, dass „funktioniert" und „korrekt" nicht dasselbe sind

„Spukhafte Fernwirkung" (Spooky action at a distance) — so nannte Einstein 1947 die Quantenverschränkung, das Phänomen, bei dem die Messung eines Teilchens sofort ein anderes beeinflusst, egal wie weit sie voneinander entfernt sind. Er meinte es abwertend; die Idee schien absurd.

Den Begriff in Bezug auf Software hörte ich zum ersten Mal vor fast zehn Jahren, in Marco Pivettas (@ocramius) Vortrag Extremely Defensive PHP. Das Konzept blieb im Kopf: Code an einer Stelle beeinflusst Code woanders, ohne sichtbare Verbindung.

„Die Ranking-Berechnungen laufen nicht."

Das System: Eine Callback-basierte Pipeline

Unser Ranking-Tool fragt eine Externe-API nach Suchmaschinendaten ab. Die Pipeline ist simpel:

flowchart LR A[Task senden
Command] --> B[Externe
API] B --> C[Verarbeiten
Command] C --> D[Ergebnisse
berechnen]

Jeder Task durchläuft eine State Machine, die durch drei Flags getrackt wird:

class AnalysisTask {  private bool $submitted = false; // An externe API gesendet?  private bool $completed = false; // API hat Verarbeitung abgeschlossen?  private bool $processed = false; // Wir haben Ergebnisse abgeholt? }

Die Übergabe passiert über einen Webhook-Callback: Wenn die externe API uns die Daten gesendet hat, wird danach einen HTTP-Request an unseren Callback-Endpoint geschickt, der completed = true setzt.

Einfach, oder?

Der Bug: Tasks für immer blockiert

Tasks wurden erfolgreich erstellt und übermittelt. Die externe API verarbeitete sie (im Anbieter Dashboard verifiziert). Aber unser Process-Command fand nichts zu tun. Mitte November 2025 hörte die Verarbeitung auf.

Ich schaute mir die Pipeline an:

protected function execute(InputInterface $input, OutputInterface $output): int {  $tasksToProcess = $this->repository->findBy([  'submitted' => true,  'completed' => false, // <-- Hmm...  'processed' => false,  ]);   foreach ($tasksToProcess as $task) {  $this->processTask($task);  }   return Command::SUCCESS; }

Moment mal. Wir suchen nach Tasks, bei denen completed = false ist?

Wenn der Callback completed = true setzt, wenn die API fertig ist… warum suchen wir dann nach Tasks, die nicht abgeschlossen sind?

Die Annahmen-Falle

Ich schaute mir den Callback-Controller an:

#[Route('/api/callback', methods: ['POST'])]…

Weiterlesen auf fsck.sh →

HP iLO Hardware-Monitoring mit OMD Labs einrichten

2026-01-13T00:00:00Z

Sieben Probleme. So viele Stolpersteine habe ich gezählt, bis das Hardware-Monitoring für drei HP ProLiant Server endlich lief. Dabei klang es in der Dokumentation so einfach: SNMP aktivieren, check_hpasm ausführen, fertig.

Oder: Wie ich lernte, dass “Community-Projekt” manchmal “bring dein eigenes Pflaster mit” bedeutet

Falls du gerade vor einem ähnlichen Setup stehst – HP ProLiant Server via iLO überwachen, OMD Labs als Monitoring-System – dann wird dir dieser Bericht einiges an Frust ersparen.

Die Ausgangssituation

Drei HP ProLiant DL360p Gen8 Server mit VMware ESXi 7.0.3. Jeder Server hat einen iLO4 Management-Controller mit eigenem Netzwerkinterface:

Server	ESXi IP	iLO IP
esxi-01	192.168.20.x	192.168.21.101
esxi-02	192.168.20.x	192.168.21.102
esxi-03	192.168.20.x	192.168.21.103

Ziel: Umfassendes Hardware-Monitoring – Lüfter, Temperaturen, Netzteile, RAM, RAID – über die iLO-Schnittstelle.

Monitoring-System: OMD Labs 5.60 (ConSol Edition) mit Naemon als Core und PNP4Nagios für Graphing.

Klingt straightforward? War es nicht.

Problem 1: “Failed to create new file: invalid path”

Beim allerersten Versuch, einen Host über das Thruk Web-Interface anzulegen, begrüßte mich sofort eine Fehlermeldung:

Failed to create new file: invalid path

Was ist passiert? Das Verzeichnis für Konfigurationsdateien existierte schlicht nicht. OMD Labs ist ein Community-Projekt – manche Grundfunktionen sind nicht perfekt out-of-the-box konfiguriert.

Die Lösung:

su - monitoring # Als OMD-Site-User mkdir -p ~/etc/naemon/conf.d/hosts mkdir -p ~/etc/naemon/conf.d/services mkdir -p ~/etc/naemon/conf.d/commands

Lesson Learned: Für produktive Setups empfiehlt es sich, Konfigurationen direkt per CLI zu erstellen. Das Web-Interface ist nett für Quick Wins, aber nicht immer zuverlässig.

Der Umweg über ESXi SNMP

Bevor wir uns dem iLO widmeten, haben wir zunächst ESXi selbst via SNMP überwacht.

SNMP auf ESXi aktivieren

Per SSH auf den ESXi-Host:

esxcli system snmp set --communities public esxcli system snmp set --enable true esxcli network firewall ruleset set --ruleset-id snmp --enabled true

Problem 2: SNMP MIBs nicht geladen

Beim ersten Test:

snmpwalk -v2c -c public esxi-01.example.com sysDescr

Kam die Meldung:

sysDescr: Unknown Object Identifier (Sub-id not found: (top) -> sysDescr)

Die SNMP MIBs waren auf dem OMD-Server nicht geladen. Kein Drama – numerische OIDs sind ohnehin universeller:

snmpwalk -v2c -c public esxi-01.example.com .1.3.6.1.2.1.1.1.0

Ergebnis:

iso.3.6.1.2.1.1.1.0 = STRING: "VMware ESXi 7.0.3 build-24411414 VMware, Inc. x86_64"

Lesson Learned: Für Nagios/Naemon Checks immer numerische OIDs verwenden – sie sind…

Weiterlesen auf fsck.sh →

PHPStan Level 9: Der Weg zu fehlerfreiem PHP

2025-12-26T00:00:00Z

Drei Tage. So lange habe ich gebraucht, um einen Payment-Reconciliation-Bug zu fixen, den PHPStan in drei Sekunden gefunden hätte.

Oder: Wie ich lernte, das Type System zu lieben

Der Bug war subtil. Unser API-Wrapper hat null zurückgegeben, wenn die API in Wartung war – aber nur für bestimmte Transaction-Types. Unsere Tests haben mit Mocks gearbeitet, die nie null zurückgeben. Das Code-Review hat sich auf die Berechnungs-Logik konzentriert, nicht auf Null-Safety. Production? Production ist um 3 Uhr morgens an einem Sonntag abgestürzt.

PHPStan Level 9 hätte uns angeschrien: “Parameter #2 $bankData of function reconcileTransaction() expects BankData, BankData|null given.”

Dieser 3-Uhr-morgens-Incident hat verändert, wie ich über Type Safety denke. Heute zeige ich dir, wie wir 90% unserer typ-bezogenen Bugs eliminiert haben, ohne einen einzigen zusätzlichen Test zu schreiben. Das Geheimnis? Dein Compiler ist schlauer als deine Tests.

Warum Static Analysis alles verändert

Kennste das noch aus Production?

Fatal error: Uncaught Error: Call to a member function format() on null in /var/www/app/PaymentProcessor.php:142

Das passiert, weil PHP dynamisch typisiert ist. Variablen können zur Runtime alles sein. Deine IDE warnt dich vielleicht, deine Tests fangen 80% der Fälle ab, aber die 20% finden ihren Weg in Production – zum ungünstigsten Zeitpunkt.

Static Analysis Tools wie PHPStan analysieren deinen Code ohne ihn auszuführen. Sie bauen einen kompletten Type-Graph deiner Anwendung auf und sagen dir genau, wo Dinge kaputtgehen werden, bevor du deployst.

Traditionelles Testing:

Code schreiben
Tests schreiben
Tests laufen lassen
Deployen
Production-Bugs fixen, die du nicht getestet hast

Static Analysis:

Code schreiben
PHPStan laufen lassen
Type-Errors fixen
Mit Confidence deployen
Die ganze Nacht durchschlafen

Die PHPStan Level Journey (0-9)

PHPStan bietet 10 Strictness-Level, von “kaum irgendwas checken” bis “dein Code ist mathematisch bewiesen fehlerfrei”. Jedes Level catcht progressiv subtilere Bugs.

Level 0: Basis Existenz-Checks

Der sanfteste Einstieg. PHPStan verifiziert, dass Klassen, Funktionen und Methoden, die du aufrufst, tatsächlich existieren.

// Level 0 catcht das hier $user = new UserrModel(); // Typo im Klassennamen $user->getName(); // Klasse existiert nicht, Methode existiert nicht  // Level 0 erlaubt das hier (sollte es aber nicht) function process($data) {  return $data->value; // Was wenn $data null ist? }

Was es catcht:…

Weiterlesen auf fsck.sh →

Async PHP in Production: Fibers, ReactPHP und Swoole entmystifiziert

2025-12-19T00:00:00Z

Async PHP in Production: Fibers, ReactPHP und Swoole entmystifiziert

PHP kann 10.000 gleichzeitige Verbindungen handhaben. So geht’s.

PHPs am wenigsten verstandene Superkraft

Drei Tage. So lange hab ich damit verbracht, einen API-Aggregation-Service zu optimieren, der 15 externe APIs sequenziell aufgerufen hat. Die Response-Zeit? Schmerzhafte 2,1 Sekunden im Durchschnitt. Dann hab ich Async PHP entdeckt, und derselbe Service antwortet jetzt in 520 Millisekunden. Das ist eine Verbesserung von 304% – ohne die Business-Logik anzufassen.

Falls du immer noch denkst, PHP ist diese langsame, blockierende, synchrone Sprache aus der LAMP-Stack-Ära, dann hast du was verpasst. In 2025 ist Async PHP keine Ausnahme mehr. Mit Fibers im Core seit PHP 8.1, plus ausgereiften Ecosystemen wie ReactPHP, Swoole und Amp, kann PHP Low-Latency-APIs, WebSockets und Streaming-Pipelines fahren – ohne deine Codebase in Callback-Hell zu verwandeln.

Ich zeig dir, wie Async PHP in Production funktioniert, wann du welchen Ansatz nutzt und wie du die Fallstricke vermeidest, die dich um 3 Uhr morgens beißen werden.

Die PHP-Performance-Revolution, über die niemand spricht

Kennste das noch? Concurrent Operations in PHP bedeuteten entweder mehrere Prozesse hochzufahren (Memory-Alptraum) oder Threads zu nutzen (Complexity-Alptraum)? Diese Zeiten sind vorbei.

Was Async PHP heute kann:

200 RSS-Feeds verarbeiten in 2,3 Sekunden statt 111 Sekunden (463% Verbesserung)
500+ Webseiten scrapen in der Zeit, die früher für 100 gebraucht wurde
10x mehr gleichzeitige User bei konsistenten Response-Zeiten handhaben
WebSocket-Server betreiben, die tausende Verbindungen gleichzeitig offen halten

Das Geheimnis? Cooperative Multitasking durch Fibers und Event-Loops. Lass uns aufdröseln, was das eigentlich bedeutet.

PHP Fibers verstehen: Das Fundament

PHP 8.1 hat Fibers eingeführt – Full-Stack, unterbrechbare Funktionen. Stell sie dir vor wie leichtgewichtige Threads, die du nach Belieben pausieren und wieder aufnehmen kannst, aber ohne die Komplexität von echtem Parallelismus.

Der entscheidende Unterschied: Fibers sind für Concurrency, nicht Parallelismus. Du führst nicht mehrere CPU-intensive Tasks gleichzeitig aus. Du jonglierst effizient mehrere I/O-gebundene Operationen – während eine wartet, läuft eine andere.

Dein erster Fiber: Der “Aha”-Moment

<?php  $fiber = new Fiber(function (): string {  echo "Fiber gestartet\n";   // Ausführung unterbrechen und Kontrolle zurückgeben  $value = Fiber::suspend('pausiert');   echo "…

Weiterlesen auf fsck.sh →

Laravel vs Symfony 2025: Wann du was nutzen solltest

2025-12-12T00:00:00Z

Laravel vs Symfony 2025: Wann du was nutzen solltest

Ein pragmatischer Leitfaden für die Wahl des richtigen Tools - denn Glaubenskriege liefern keine Produkte aus

Der Framework-Krieg ist vorbei. Laravel hat den Popularitätswettbewerb gewonnen. Symfony hat die Enterprise-Schlacht gewonnen. Und hier kommt die Wendung: Es spielt keine Rolle.

Was zählt, ist die Wahl des richtigen Tools für dein spezifisches Projekt. Ich habe die letzten sechs Monate damit verbracht, einen Laravel-Monolithen auf Symfony-Komponenten zu migrieren, und weitere drei Monate damit, ein Greenfield-SaaS in Laravel zu bauen. Beide Entscheidungen waren richtig. Beide wären Katastrophen gewesen, wenn vertauscht.

Lass mich dir das Entscheidungsframework zeigen, das ich mir vor zwei Jahren gewünscht hätte.

Der Status von PHP-Frameworks 2025

Bevor wir in Philosophie und Code eintauchen, schauen wir uns die harten Daten aus JetBrains’ State of PHP 2025-Umfrage an:

Laravel: 64% Marktanteil (1.720 befragte PHP-Entwickler)
Symfony: 23% Marktanteil
WordPress: 25% (ja, höher als Symfony, aber es ist ein CMS, kein Framework)
Andere: CodeIgniter, Yii, CakePHP zusammen unter 10%

Hier ist, was dir niemand erzählt: Laravel läuft auf Symfony-Komponenten. Check mal dein vendor-Verzeichnis in jedem Laravel-Projekt - du findest symfony/http-foundation, symfony/routing, symfony/console und etwa ein Dutzend mehr.

Laravel ist Symfony mit einem wunderschönen Developer-Experience-Layer obendrauf. Symfony ist eine Sammlung entkoppelter Komponenten, die alles von einem CLI-Tool bis zu Laravel selbst antreiben können.

Der Philosophie-Graben

Laravel: Developer Happiness zuerst

Laravels Philosophie ist radikale Einfachheit kombiniert mit ästhetischem Vergnügen. Taylor Otwell hat Laravel für Entwickler entworfen, die schnell shippen wollen und den Prozess genießen möchten.

// Laravel Eloquent - das fühlt sich einfach gut an zu schreiben $activeUsers = User::where('status', 'active')  ->with('posts')  ->latest()  ->paginate(15);  return view('users.index', compact('activeUsers'));

Alles an Laravel schreit “aus dem Weg gehen”. Convention over Configuration. Vollausgestattet. Meinungsstarke Defaults, die für 80% der Use Cases funktionieren.

Symfony: Flexibilität und Kontrolle

Symfonys Philosophie ist professionelle Flexibilität. Fabien Potencier hat Symfony für Teams gebaut, die präzise Kontrolle über jede Architektur-Entscheidung brauchen.

// Symfony Doctrine - ausführlicher,…

Weiterlesen auf fsck.sh →

Symfony AssetMapper: Tschüss Webpack, Hallo Einfachheit

2025-12-05T00:00:00Z

Was wäre, wenn dein Frontend-Build-Prozess einfach… nichts wäre?

Die Rückkehr zur Einfachheit in der Frontend-Entwicklung

Ich habe die letzten fünf Jahre damit verbracht, Webpack-Konfigurationen zu pflegen. Fünf Jahre, in denen npm install drei Minuten gedauert hat. Fünf Jahre Debugging, warum mein Build plötzlich nicht mehr funktioniert, nachdem ich ein einziges Package aktualisiert habe. Fünf Jahre, in denen ich Junior-Entwicklern erklären musste, warum sie ein komplett separates Ökosystem lernen müssen, nur um eine JavaScript-Datei zu einem Symfony-Projekt hinzuzufügen.

Dann kam Symfony 6.3 mit AssetMapper, und mir wurde klar: Wir hatten die ganze Zeit das falsche Problem gelöst.

Das Versprechen klingt fast zu gut, um wahr zu sein: Schreib modernes JavaScript und CSS ohne jegliches Build-System. Kein Node.js, kein npm, kein Webpack, keine Konfigurationsdateien, keine Transpilierungs-Pipeline. Nur PHP und die nativen Features, die Browser seit Jahren unterstützen.

Ich war skeptisch. Solltest du auch sein. Aber nachdem ich drei Produktionsanwendungen migriert habe, bin ich überzeugt: Das ist die Zukunft der Symfony-Frontend-Entwicklung.

Das Problem, das wir uns selbst geschaffen haben

Kennste das? Du startest ein neues Symfony-Projekt:

symfony new mein-projekt --webapp

In den “alten Zeiten” (also… 2023) hast du sofort als nächstes ausgeführt:

composer require symfony/webpack-encore-bundle npm install

Und dann musstest du:

Node.js installieren (natürlich eine spezifische Version)
Die webpack.config.js konfigurieren
Deine package.json einrichten
Mit node_modules kämpfen (hallo, 400MB)
Babel für die Transpilierung konfigurieren
Watching im Development einrichten
Build für Production konfigurieren
Deinem Ops-Team erklären, warum dein Docker-Image jetzt 2GB groß ist

Wofür? Um import-Statements in JavaScript zu nutzen. Features, die Browser nativ seit 2017 unterstützen.

Der Webpack-Kaninchenbau

So sah ein typisches Encore-Setup aus:

// webpack.config.js const Encore = require("@symfony/webpack-encore");  Encore.setOutputPath("public/build/")  .setPublicPath("/build")  .addEntry("app", "./assets/app.js")  .splitEntryChunks()  .enableSingleRuntimeChunk()  .cleanupOutputBeforeBuild()  .enableBuildNotifications()  .enableSourceMaps(!Encore.isProduction())  .enableVersioning(Encore.isProduction())  .configureBabel((config) => {  config.plugins.push("@babel/plugin-proposal-class-properties");  })  .configureBabelPresetEnv((config) => {  config.useBuiltIns = "usage";  config.corejs = 3;  })  .enableSassLoader()  .enablePostCssLoader()  .autoProvidejQuery();  module.exports = Encore.getWebpackConfig();

Das…

Weiterlesen auf fsck.sh →