Kompatibilität
Ein Pusher-kompatibles Realtime-Backend
PushCaster spricht auf der Leitung Version 7 des Pusher-Channels-Protokolls. Der Umzug ist Konfiguration, keine Neuschreibung — und diese Seite ist die genaue Liste dessen, was sich ändert.
Kein Umschreiben der Anwendung. Nur Änderungen an der Verbindungskonfiguration sind nötig. Drei bis sechs Zeilen pro Anwendung; bei Laravel eine Änderung in der .env und sonst nichts. Weder drop-in noch zero-config: der Host muss gesetzt werden, und die Zugangsdaten sind neu.
Was gleich bleibt
Die Leitung, die Bibliotheken und der Auth-Handshake
Kompatibilität heißt hier das Protokoll, nicht eine Ähnlichkeit — kompatible Anfrage-/Antwortformate, Ereignissemantik und Authentifizierungsschema.
| Bereich | Was unverändert bleibt |
|---|---|
| Protokoll | Version 7 des Pusher-Channels-Protokolls auf der Leitung. |
| Client-Bibliotheken | pusher-js, Laravel Echo und die offiziellen mobilen Bibliotheken, unverändert. |
| Server-Bibliotheken | pusher-php-server, pusher-http-node und die Bibliotheken für Python, Go, Ruby und Java. |
| Signaturen | Kompatibles Signatur- und Kanonisierungsschema. |
| Channel-Arten | public, private, presence und private-encrypted, mit denselben Präfixen. |
| Abonnement-Autorisierung | POST /pusher/auth behält Form von Anfrage und Antwort. |
| client events | Zwischen Abonnenten auf private- und presence-channels, wie bisher. |
| Webhooks | Dieselben Feldnamen und Header, darunter channel_occupied, member_added und cache_miss. |
Getestete SDK-Versionen
Kompatibel mit den aufgeführten Pusher-SDK-Versionen, ohne diese SDKs zu verändern.
| SDK | Getestete Version |
|---|---|
| pusher-js (browser) | 8.6.0 |
| pusher/pusher-php-server | 7.3.0 |
| pusher (Node.js) | 5.3.4 |
| pusher (Python) | 3.3.4 |
| pusher-http-go | v5.1.1 |
| pusher (Ruby) | 2.1.1 |
| laravel/framework (Echo) | ^13.0 |
Was sich ändert
Der host, und die Zugangsdaten
pusher-js hat ws-<cluster>.pusher.com fest verdrahtet, solange kein wsHost übergeben wird, und die Server-Bibliotheken gehen standardmäßig an api-<cluster>.pusher.com, solange kein Host übergeben wird. Diese beiden zu überschreiben ist die Migration.
const pusher = new Pusher(APP_KEY, {- cluster: 'eu',+ wsHost: 'ws-eu1.pushcaster.io',+ wsPort: 443,+ forceTLS: true, })Die vollständige Änderung, je Sprache
// before — talking to Pushernew Pusher(KEY, { cluster: 'eu' })// after — talking to PushCaster (the key & secret are new)new Pusher(KEY, { wsHost: 'ws-eu1.pushcaster.io', wsPort: 443, forceTLS: true,})Den host zu setzen wird leicht übersehen. Bleibt er auf dem Standardwert, spricht die Bibliothek mit den Servern von Pusher, und der Fehler nennt einen falschen key statt ein falsches Ziel.
App id, key und secret sind neu. Bestehende Zugangsdaten werden nicht übernommen. Wählen Sie gleichzeitig einen Cluster — er ist Teil des Hosts.
Bekannte Unterschiede
Drei Dinge, die nicht gleich sind
Ein Kompatibilitätsversprechen taugt nur mitsamt seinen Ausnahmen. Diese drei können eine Entwurfsentscheidung ändern.
Ein Cluster, keine Föderation
Ein Cluster ist eine Isolationsgrenze, kein geografischer Hinweis: eigene Knoten, eigenes NATS und Redis, und keine Zustellung zwischen Clustern. Eine Anwendung lebt in genau einem — zwei, die miteinander sprechen müssen, gehören in dasselbe.
Der Host ist nicht der Clustername
cluster: "eu" allein erreicht PushCaster nicht. Sie setzen wsHost im Client und host in der Server-Bibliothek. Das sind drei Optionen, und jede Migration nimmt sie vor.
Keine Statistik-API
Für Pushers Dashboard-Statistik-Endpunkt gibt es hier keine Entsprechung. Verbrauchsdaten kommen aus unserer eigenen API, Betriebsmetriken aus Prometheus. Kein offizielles Server-SDK ruft diesen Endpunkt auf — das betrifft also Ihr Tooling, nicht Ihre Anwendung.
Migration
Testen Sie zuerst private- und presence-channels
Public-channels laufen weiter durch, auch wenn etwas nicht stimmt — sie fragen Ihren Server nichts. Ein veralteter host oder ein nicht passendes secret zeigt sich nur bei private- und presence-Abonnements.
- 01Legen Sie die Anwendung anDer cluster, den Sie wählen, ist Teil jedes host, den Sie gleich konfigurieren.
- 02Setzen Sie den Host an beiden StellenDer Client braucht wsHost, der Server host. Übersehen Sie eines, redet die halbe Anwendung weiter mit Pusher.
- 03Tauschen Sie die ZugangsdatenAlle drei ändern sich zusammen. Ein neuer key mit einem alten secret scheitert nur an signierten Abonnements — und deshalb übersteht er einen schnellen Test.
- 04Abonnieren Sie einen private-channelDas übt POST /pusher/auth und belegt, dass das secret zur app id passt.
- 05Treten Sie einem Presence-channel beiDas bestätigt die Mitgliederliste und die Beitritts- und Austritts-events.
- 06Veröffentlichen Sie vom ServerDas bestätigt den Publish-host und die Signatur von Ende zu Ende.
Legen Sie eine Anwendung an und richten Sie einen Client darauf.
Pusher ist eine Marke des jeweiligen Inhabers. PushCaster ist ein unabhängiger Dienst, weder mit Pusher verbunden noch von Pusher unterstützt. Bibliotheksnamen werden beschreibend verwendet.