WebSockets sind leistungsstark, weil sie die bidirektionale Kommunikation unterstützen. Das ist auch der Grund, warum sie oft überdimensioniert sind. Viele Produkte benötigen keinen Voll-Duplex-Kanal. Sie benötigen einen Browser, der verbunden bleibt und Aktualisierungen empfängt.
Für Benachrichtigungen, Dashboards, Fortschrittsanzeigen und Aktivitätsfeeds sind Server-Sent Events oft die sauberere Wahl.
Warum SSE Gut Altert
SSE bleibt einfach, da es das Transportmodell eng hält:
- standardmäßige HTTP-Anfrage
- natives Browser
EventSource
- nur Server-zu-Client-Streaming
- einfache Integration mit Proxys und vorhandenen Authentifizierungsmustern
Ein minimales Server-Endpunkt sieht so aus:
app.get("/events", (req, res) => {
res.writeHead(200, {
"Content-Type": "text/event-stream",
"Cache-Control": "no-cache",
Connection: "keep-alive",
});
res.write(`event: ready\n`);
res.write(`data: ${JSON.stringify({ status: "ok" })}\n\n`);
});
Und die Client-Seite ist ebenso klein:
const source = new EventSource("/events");
source.addEventListener("ready", (event) => {
console.log(JSON.parse(event.data));
});
Wenn WebSockets Immer Noch Gewinnen
WebSockets sind immer noch das bessere Werkzeug, wenn der Browser und der Server beide häufig sprechen müssen:
- Multiplayer-Interaktionen
- Kollaboratives Bearbeiten
- Bidirektionale Befehlskanäle
- Hochfrequente Client-Events
Der Fehler besteht darin, WebSockets zu wählen, weil „Echtzeit“ so klingt, als ob sie erforderlich wären.
Besseres Prinzip
Wenn der Browser hauptsächlich zuhört, beginnen Sie mit SSE. Wechseln Sie zu WebSockets, wenn die bidirektionale Kommunikation eine echte Produktanforderung ist, nicht nur ein architektonischer Reflex.
Weitere Lektüre