Compatibilité
Un backend realtime compatible Pusher
PushCaster parle la version 7 du protocole Pusher Channels sur le fil. Déménager relève de la configuration, pas de la réécriture — et cette page est la liste exacte de ce qui change.
Aucune réécriture de l'application. Seuls des changements de configuration de connexion sont nécessaires. Trois à six lignes par application ; pour Laravel, une modification du .env et rien d'autre. Ce n'est ni drop-in ni zero-config : il faut définir le host, et les identifiants sont nouveaux.
Ce qui ne change pas
Le fil, les bibliothèques et le handshake d'authentification
Ici, compatibilité désigne le protocole, pas une ressemblance — formats de requête/réponse, sémantique des événements et schéma d'authentification compatibles.
| Domaine | Ce qui reste inchangé |
|---|---|
| Protocole | La version 7 du protocole Pusher Channels sur le fil. |
| Bibliothèques client | pusher-js, Laravel Echo et les bibliothèques mobiles officielles, non modifiées. |
| Bibliothèques serveur | pusher-php-server, pusher-http-node, et les bibliothèques Python, Go, Ruby et Java. |
| Signatures | Schéma de signature et de canonicalisation compatible. |
| Types de channel | public, private, presence et private-encrypted, avec les mêmes préfixes. |
| Autorisation d'abonnement | POST /pusher/auth conserve la forme de sa requête et de sa réponse. |
| client events | Entre abonnés sur les channels private et presence, comme avant. |
| Webhooks | Les mêmes noms de champs et les mêmes en-têtes, dont channel_occupied, member_added et cache_miss. |
Versions de SDK testées
Compatible avec les versions de SDK Pusher listées, sans modifier ces SDK.
| SDK | Version testée |
|---|---|
| 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 |
Ce qui change
Le host, et les identifiants
pusher-js code en dur ws-<cluster>.pusher.com sauf si wsHost est fourni, et les bibliothèques serveur pointent par défaut vers api-<cluster>.pusher.com sauf si host est fourni. Écraser ces valeurs, c'est toute la migration.
const pusher = new Pusher(APP_KEY, {- cluster: 'eu',+ wsHost: 'ws-eu1.pushcaster.io',+ wsPort: 443,+ forceTLS: true, })Le changement complet, par langage
// 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,})Définir le host s'oublie facilement. Laissée à sa valeur par défaut, la bibliothèque parle aux serveurs de Pusher, et l'erreur désigne une key incorrecte plutôt qu'une mauvaise destination.
L'app id, la key et le secret sont nouveaux. Les identifiants existants ne sont pas transférés. Choisissez un cluster en même temps — il fait partie du host.
Différences connues
Trois choses qui ne sont pas identiques
Une promesse de compatibilité ne sert qu'avec ses exceptions. Ces trois-là peuvent changer une décision de conception.
Un cluster, sans fédération
Un cluster est une frontière d'isolation, pas une indication géographique : ses propres nœuds, NATS et Redis, et aucune livraison entre clusters. Une application vit dans exactement un, donc deux qui doivent communiquer appartiennent au même.
L'hôte n'est pas le nom du cluster
cluster: "eu" seul n'atteint pas PushCaster. Vous définissez wsHost côté client et host dans la bibliothèque serveur. C'est une modification de trois options, et toute migration la fait.
Pas d'API de statistiques
Le point de terminaison de statistiques du tableau de bord Pusher n'a pas d'équivalent ici. L'usage vient de notre propre API et les métriques opérationnelles de Prometheus. Aucun SDK serveur officiel n'appelle ce point de terminaison : cela concerne votre outillage, pas votre application.
Migration
Testez d'abord les channels private et presence
Les channels public continuent de passer quand quelque chose ne va pas — ils ne demandent rien à votre serveur. Un host périmé ou un secret qui ne correspond pas n'apparaît que sur les abonnements private et presence.
- 01Créez l'applicationLe cluster que vous choisissez fait partie de chaque host que vous êtes sur le point de configurer.
- 02Définissez le host aux deux endroitsLe client a besoin de wsHost, le serveur de host. Oubliez l'un des deux et la moitié de votre application parle encore à Pusher.
- 03Changez les identifiantsLes trois changent ensemble. Une key neuve avec un secret ancien n'échoue que sur les abonnements signés — et c'est pour cela qu'elle survit à un test rapide.
- 04Abonnez-vous à un channel privateCela exerce POST /pusher/auth et prouve que le secret va avec l'app id.
- 05Rejoignez un channel presenceCela confirme la liste des membres et les events d'arrivée et de départ.
- 06Publiez depuis le serveurCela confirme le host de publication et la signature de bout en bout.
Créez une application et pointez un client vers elle.
Pusher est une marque déposée de son titulaire. PushCaster est un service indépendant, sans affiliation ni approbation de Pusher. Les noms des bibliothèques sont employés à titre descriptif.