Warum wir WebSocket-first bauen

Wir haben WebSockets nicht gewählt, weil sie schick sind. Wir haben sie gewählt, weil sie für Live-Daten messbar besser sind als eine Kette höflicher HTTP-Requests: geringere Latenz, eine Verbindung für den gesamten Traffic (hundert Nachrichten stapeln nicht hundert Handshakes an Round-Trip-Time aufeinander), Kanal-Subscriptions für Clients, die nur einen Teil des Zustands brauchen, Presence ohne Aufwand, Peer-Nachrichten ("Whispers"), wenn zwei Nutzer:innen direkt miteinander sprechen wollen statt über den Server. Der Standard-Web-Stack von 2022 beantwortete die Frage "Hat sich etwas geändert?" immer noch mit einem HTTP-Request alle fünf Sekunden, also antwortete der Server achttausendmal pro Stunde mit "Nein, nichts neu", die Nutzerin sah einen veralteten Bildschirm, und die Rechnung war das Schlechteste aus beiden Welten. WebSockets haben den Trade entfernt. Wir sind nicht zurückgegangen.

Im Laravel-Ökosystem gab es genau ein ausgereiftes, selbst hostbares WebSocket-Runtime: beyondcode/laravel-websockets. Hervorragend, kostenlos, und als Laravel Reverb angekündigt wurde, verstummte der Upstream. Wir hatten Produktiv-Traffic darauf. Also haben wir master geforkt und weitergemacht. Aus "Licht anlassen" wurde ein eigenes kleines Projekt: async-Funktionalität, damit ein langsamer Handler die Event-Loop nicht blockiert, Hot Code Reload, damit ein Channel-Handler ohne Server-Restart geändert werden kann, Controller-Resolving, damit Channel-Logik aussieht wie der Rest einer Laravel-App, und zuletzt WebSocket-Attribute für gewöhnliche HTTP-Controller, damit derselbe Controller einen HTTP-Request und eine WebSocket-Nachricht beantwortet, ohne sich zu duplizieren.

Die Featureliste klingt nach Infrastruktur, ist sie auch, aber auf der Empfänger-Seite ist sie Produkt. Live-Dashboards, die sofort lesen, weil der Server pusht. Mehrbenutzer-Bearbeitung ohne Merge-Konflikte, weil alle denselben Zustand zur selben Zeit sehen. Mikrocontroller-Telemetrie, die im Browser ankommt, sobald der Sensor liest. Formularfelder, die beim Tippen validieren, ohne pro Tastendruck einen Request zu verbrennen. Hintergrundjobs, die ihren Fortschritt an einen echten Balken melden statt an einen Spinner. Nichts davon ist exotisch. Es ist, was Ihre Kunden von Slack, Linear und Figma längst gewohnt sind; wir haben es nur günstig genug gemacht, dass es Standard für ein KMU oder ein Frühphasen-Produkt sein kann.

Reverb ist ein gutes Runtime und wir freuen uns, dass es existiert. Wir sind nicht migriert, weil unser Fork ein etwas anderes Problem löst: Er bleibt bis ganz unten eine normale Laravel-App, Controller inklusive, und liefert die DX-Bausteine (Hot Reload, die Attribut-Syntax, die async-Event-Loop-Haltung), die zählen, wenn WebSockets der Standard ist, nicht die Ausnahme. Reverb macht Realtime einfach hinzufügbar. Unser Fork macht Realtime-first-Bauen einfach. Verschiedene Aufgaben, beide nützlich.

Sie werden "wir haben WebSockets ergänzt" nicht als Positionen auf einem Blax-Angebot sehen. Live-Daten sind einfach unser Standardweg, so wie eine Web-App 2026 standardmäßig TLS nutzt. Wenn Ihr Produkt Dashboards, Kollaboration, Live-Status, Queues oder irgendetwas hat, wo ein Mensch wartet, ob sich etwas ändert, gehen Sie davon aus, dass dieser Teil out of the box dabei ist. Wenn wir für Ihren Fall falsch liegen (eine statische Visitenkarten-Seite, ein stündlicher Batch-Job), sagen wir es und lassen das Runtime weg. Wir wählen das richtige Werkzeug, wir weigern uns nur, weiter den Polling-Aufschlag zu zahlen, wenn es nicht sein muss.