Pular para o conteúdo

Compatibilidade

Um backend realtime compatível com o Pusher

O PushCaster fala a versão 7 do protocolo Pusher Channels no fio. Mudar é configuração, não reescrita — e esta página é a lista exata do que muda.

Sem reescrever a aplicação. Apenas mudanças na configuração de conexão são necessárias. De três a seis linhas por aplicação; no Laravel, uma mudança no .env e mais nada. Não é drop-in nem zero-config: o host precisa ser definido, e as credenciais são novas.

O que continua igual

O fio, as bibliotecas e o handshake de autenticação

Compatibilidade aqui significa o protocolo, não uma semelhança — formatos de requisição/resposta, semântica de eventos e esquema de autenticação compatíveis.

O que não muda ao sair do Pusher Channels para o PushCaster
ÁreaO que não muda
ProtocoloA versão 7 do protocolo Pusher Channels no fio.
Bibliotecas de clientepusher-js, Laravel Echo e as bibliotecas móveis oficiais, sem modificação.
Bibliotecas de servidorpusher-php-server, pusher-http-node e as bibliotecas de Python, Go, Ruby e Java.
AssinaturasEsquema de assinatura e canonicalização compatível.
Tipos de channelpublic, private, presence e private-encrypted, com os mesmos prefixos.
Autorização de inscriçãoPOST /pusher/auth mantém o formato da requisição e da resposta.
client eventsEntre inscritos em channels private e presence, como antes.
WebhooksOs mesmos nomes de campo e os mesmos cabeçalhos, incluindo channel_occupied, member_added e cache_miss.

Versões de SDK testadas

Compatível com as versões dos SDKs da Pusher listadas, sem modificar esses SDKs.

Versões dos SDKs da Pusher contra as quais a suíte de compatibilidade roda
SDKVersão testada
pusher-js (browser)8.6.0
pusher/pusher-php-server7.3.0
pusher (Node.js)5.3.4
pusher (Python)3.3.4
pusher-http-gov5.1.1
pusher (Ruby)2.1.1
laravel/framework (Echo)^13.0

O que muda

O host, e as credenciais

O pusher-js tem ws-<cluster>.pusher.com fixo a menos que wsHost seja informado, e as bibliotecas de servidor vão por padrão para api-<cluster>.pusher.com a menos que host seja informado. Sobrescrever isso é a migração.

src/realtime.tsunified diff
  const pusher = new Pusher(APP_KEY, {
-   cluster: 'eu',
+   wsHost: 'ws-eu1.pushcaster.io',
+   wsPort: 443,
+   forceTLS: true,
  })

A mudança completa, por linguagem

client.js
js
// 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,})

Definir o host passa batido com facilidade. Deixado no padrão, a biblioteca fala com os servidores do Pusher, e o erro aponta uma key errada em vez de um destino errado.

O app id, a key e o secret são novos. As credenciais existentes não são transferidas. Escolha um cluster na mesma hora — ele faz parte do host.

Diferenças conhecidas

Três coisas que não são iguais

Uma promessa de compatibilidade só serve com as exceções dela. Estas três podem mudar uma decisão de projeto.

  • Um cluster, sem federação

    Um cluster é um limite de isolamento, não uma dica geográfica: tem seus próprios nós, NATS e Redis, e não há entrega entre clusters. Uma aplicação vive em exatamente um, então duas que precisam conversar pertencem ao mesmo.

  • O host não é o nome do cluster

    cluster: "eu" sozinho não chega ao PushCaster. Você define wsHost no cliente e host na biblioteca de servidor. É uma edição de três opções, e toda migração a faz.

  • Sem API de estatísticas

    O endpoint de estatísticas do painel da Pusher não tem equivalente aqui. O uso vem da nossa própria API e as métricas operacionais do Prometheus. Nenhum SDK de servidor oficial chama esse endpoint, então isso afeta suas ferramentas, não sua aplicação.

Migração

Teste primeiro os channels private e presence

Os channels public continuam passando quando alguma coisa está errada — eles não perguntam nada ao seu servidor. Um host velho ou um secret que não bate só aparece nos channels private e presence.

  1. 01Crie a aplicaçãoO cluster que você escolher faz parte de cada host que você está prestes a configurar.
  2. 02Defina o host nos dois lugaresO cliente precisa de wsHost, o servidor precisa de host. Esqueça um e metade da sua aplicação continua falando com o Pusher.
  3. 03Troque as credenciaisAs três mudam juntas. Uma key nova com um secret velho só falha nas inscrições assinadas — e é por isso que ela sobrevive a um teste rápido.
  4. 04Inscreva-se num channel privateExercita POST /pusher/auth e prova que o secret combina com o app id.
  5. 05Entre num channel presenceConfirma a lista de membros e os events de entrada e saída.
  6. 06Publique do servidorConfirma o host de publicação e a assinatura de ponta a ponta.

Crie uma aplicação e aponte um cliente para ela.

Começar a construirLer a documentação

Pusher é marca registrada de seu respectivo titular. O PushCaster é um serviço independente, sem afiliação ao Pusher e sem endosso dele. Os nomes das bibliotecas são usados de forma descritiva.

Support