Pusher: serviço hospedado para comunicação bidirecional em tempo real, fornecendo infraestrutura para canais, eventos e notificações webhook. Ele libera o desenvolvedor da necessidade de implantar seu próprio servidor WebSocket e garante a entrega de mensagens a milhões de dispositivos. De acordo com a documentação oficial do Pusher (2025), o serviço processa mais de 40 bilhões de mensagens mensalmente em todo o mundo.
Principais pontos
Pusher é um serviço em nuvem para comunicação bidirecional em tempo real, fundado em 2011. Ele fornece infraestrutura pronta para enviar e receber mensagens em tempo real sem precisar gerenciar seu próprio servidor WebSocket. Pusher é usado para construir chats, notificações ao vivo, edição colaborativa e placares de jogos.
Ao contrário de bibliotecas como Socket.IO, que exigem implantação e manutenção do próprio servidor, o Pusher opera em um modelo SaaS (Software como Serviço). O desenvolvedor se registra, obtém chaves (app_id, key, secret) e usa a API REST do Pusher para publicar eventos. A infraestrutura do servidor é totalmente gerenciada pela plataforma Pusher.
De acordo com o blog oficial do Pusher (2025), a plataforma atende mais de 250.000 projetos ativos em todo o mundo. Entre os clientes conhecidos estão GitHub (notificações em tempo real), Trello (sincronização de quadros) e Intercom (chat de suporte). O Pusher suporta data centers nos EUA, Europa e Ásia para minimizar a latência.
O Pusher foi lançado em 2011 como um dos primeiros serviços hospedados para WebSocket. Em 2014, a empresa apresentou o Pusher Channels — a arquitetura atual com suporte para canais private e presence. Em 2017, foi adicionado suporte a webhook para eventos do lado do servidor. Em 2022, o Pusher lançou o Pusher Beams, um serviço de notificações push para plataformas móveis.
A arquitetura do Pusher difere das soluções auto-hospedadas porque todo o gerenciamento de assinaturas, gerenciamento de conexões e roteamento de eventos acontece no lado do Pusher Cloud. O desenvolvedor gerencia apenas a autenticação dos canais private através de seu backend.
A arquitetura do Pusher é baseada no modelo Editor-Assinante. Aplicações de servidor publicam eventos através da API REST do Pusher, e aplicações cliente os recebem através de uma conexão WebSocket persistente. O Pusher atua como intermediário entre editores e assinantes.
Quando o servidor envia um evento através de uma requisição POST à API do Pusher, a plataforma determina o canal alvo e distribui a mensagem a todos os clientes inscritos naquele canal. Os clientes recebem o evento através de uma conexão WebSocket já aberta, proporcionando latência de 50–100 ms dependendo da localização geográfica.
Cada cliente estabelece uma conexão através do Pusher Client SDK, que seleciona automaticamente o transporte (WebSocket — prioridade, HTTP long-polling — fallback). O SDK gerencia reconexão, serialização de dados e tratamento de erros sem intervenção do desenvolvedor. De acordo com a documentação técnica do Pusher (2025), o tempo de reconexão após interrupção de rede é inferior a 1 segundo.
O sistema consiste em três componentes: Pusher Server API (endpoints REST para publicar eventos), Pusher Client SDK (bibliotecas para assinar eventos) e Pusher WebHook (notificações ao servidor sobre eventos de conexão/desconexão). Todos os componentes funcionam de forma assíncrona e independente.
Pusher Channels suporta três tipos de canais, cada um projetado para diferentes casos de uso. O tipo de canal determina o nível de acesso, o mecanismo de autenticação e as capacidades disponíveis.
| Tipo de canal | Prefixo | Autenticação | Uso |
|---|---|---|---|
| Public | channel- | Não requerida | Dados públicos: taxas de câmbio, clima, feed de notícias |
| Private | private- | Assinatura da requisição no servidor | Notificações pessoais, chats, dados do usuário |
| Presence | presence- | Assinatura + informações do usuário | Status online, salas de jogo, edição colaborativa |
Canais Public estão disponíveis para todos os clientes sem autenticação e são adequados para dados de transmissão. Canais Private exigem autenticação através do servidor do desenvolvedor: o cliente envia uma requisição ao seu backend com socket_id e channel_name, o servidor assina a requisição com a chave secreta do Pusher e retorna um token de autenticação. Canais Presence adicionalmente transmitem informações do usuário (user_id, user_info) e permitem rastrear quem está online atualmente.
De acordo com a documentação do Pusher (2025), o número máximo de clientes conectados simultaneamente por canal é de 10.000 para canais public e private. Para canais presence, o limite é de 10.000 usuários por canal com suporte de até 100.000 usuários por aplicação.
O modelo de eventos do Pusher é baseado em eventos nomeados que são publicados em um canal. Cada evento tem um nome (máximo 200 caracteres), dados em formato JSON e um socket_id opcional para evitar envio duplicado ao iniciador do evento.
Acionadores são requisições HTTP POST à API do Pusher que publicam um evento em um canal. Formato da requisição: POST /apps/{app_id}/events com um corpo contendo channel, name e data. A API de servidor do Pusher suporta acionadores de qualquer ambiente de servidor através de bibliotecas oficiais (PHP, Ruby, Python, Go, Java, Node.js).
O Pusher suporta acionadores em lote — publicar um evento em múltiplos canais com uma única requisição. Isso é mais eficiente que chamadas sequenciais e garante entrega atômica. De acordo com testes de desempenho do Pusher (2024), um acionador em lote para 100 canais leva 30–50 ms, enquanto chamadas sequenciais levam 2–5 segundos.
Pusher WebHook permite que seu servidor receba notificações sobre eventos de infraestrutura: conexão de cliente, desconexão, ocorrência de erro. Requisições Webhook são assinadas com HMAC-SHA256 para verificação. Isso é crítico para registro, análise e sincronização de estado.
A integração do Pusher consiste em duas partes: lado do servidor (publicação de eventos) e lado do cliente (assinatura de eventos). Vamos ver um exemplo usando Node.js para a parte do servidor e JavaScript para a parte do cliente. Primeiro, você precisa criar um aplicativo no painel do Pusher e obter credenciais.
De acordo com a documentação do Pusher (2025), o plano básico (Sandbox) inclui até 100 conexões simultâneas e 200.000 mensagens por dia — suficiente para desenvolvimento e teste. Planos de produção começam a partir de $49 por mês para 1000 conexões.
const Pusher = require('pusher');
const pusher = new Pusher({
appId: 'YOUR_APP_ID',
key: 'YOUR_KEY',
secret: 'YOUR_SECRET',
cluster: 'eu',
useTLS: true
});
pusher.trigger('my-channel', 'my-event', {
message: 'Hello from server',
timestamp: Date.now()
}).then(() => {
console.log('Evento publicado');
}).catch(console.error);
import Pusher from 'pusher-js';
const pusher = new Pusher('YOUR_KEY', {
cluster: 'eu',
forceTLS: true
});
const channel = pusher.subscribe('my-channel');
channel.bind('my-event', (data) => {
console.log('Evento recebido:', data);
displayNotification(data.message);
});
O Pusher fornece SDKs para iOS (Swift) e Android (Java/Kotlin) que replicam completamente a funcionalidade do cliente JavaScript. Os SDKs móveis suportam os mesmos tipos de canal, mecanismo de autenticação e modelo de eventos. Para React Native, o pacote pusher-js está disponível, funcionando através da ponte JavaScript.
Em dispositivos móveis, o SDK do Pusher lida automaticamente com a alternância entre Wi-Fi e redes móveis usando um mecanismo de reconexão com backoff exponencial. Isso é especialmente importante para aplicativos iOS, onde o iOS pode fechar forçadamente conexões WebSocket durante a operação em segundo plano.
De acordo com o blog técnico do Pusher (2024), o consumo médio de tráfego de uma conexão Pusher é de 1–2 KB por minuto quando não há eventos ativos. Isso é alcançado através de um protocolo de heartbeat otimizado com intervalo de 30 segundos. Um aplicativo de médio porte pode suportar até 1000 conexões Pusher simultâneas sem afetar significativamente a duração da bateria.
Pusher Beams é um serviço adicional para enviar notificações push para dispositivos móveis via APNs (iOS) e FCM (Android). O Beams se integra com o Pusher Channels: um evento de um canal pode acionar automaticamente uma notificação push se o cliente estiver offline. Isso resolve o problema de entrega de mensagens quando o aplicativo está fechado.
A segurança do Pusher é implementada em vários níveis. Cada requisição à API do Pusher é assinada com HMAC-SHA256 usando app_secret. Isso garante que apenas um servidor autorizado possa publicar eventos. Os SDKs de cliente usam app_key para identificação do aplicativo, mas acessar canais private e presence requer autenticação adicional.
A autenticação de canais private ocorre em três etapas: o cliente chama pusher.subscribe('private-channel'), o Pusher Client SDK envia uma requisição HTTP ao seu endpoint backend (/pusher/auth), o servidor verifica as permissões do usuário e retorna um token de autenticação assinado com a chave secreta. O Pusher verifica a assinatura e permite a assinatura.
Recomenda-se usar conexões TLS para todas as requisições (configuração useTLS: true no SDK). O Pusher também suporta restrições de acesso por endereço IP para requisições de servidor à API REST. Para planos empresariais, está disponível suporte para VPC (Virtual Private Cloud) e clusters dedicados com infraestrutura isolada.
Perguntas frequentes
Pusher é um serviço hospedado (SaaS) que não requer gerenciamento de servidor. Socket.IO é uma biblioteca que você precisa implantar por conta própria. Pusher é mais fácil de configurar, mas mais caro ao escalar; Socket.IO requer trabalho de DevOps, mas é mais barato em grande volume.
O plano gratuito Sandbox inclui 100 conexões e 200.000 mensagens por dia. Planos de produção começam em $49/mês (1000 conexões, mensagens ilimitadas) até enterprise com condições personalizadas.
O Pusher usa WebSocket com fallback automático para HTTP long-polling. Para mensagens críticas, uma fila no lado do Pusher está disponível com garantia de entrega pelo menos uma vez (at-least-once).
Sim, o Pusher está disponível na Rússia através do cluster europeu (eu). A latência é de 50–100 ms para data centers europeus. Para projetos com requisitos de localização de dados, recomenda-se considerar alternativas.
Os principais concorrentes são Ably (funcionalidade similar, preços mais flexíveis), PubNub (rede de entrega global), Socket.IO (auto-hospedado) e Firebase Realtime Database (ecossistema Google).
Resumo
Vamos desenvolver um aplicativo móvel chave na mão
A IT Sectr cria aplicativos para iOS e Android para startups e empresas desde 2017. Nós vamos aconselhá-lo e propor a melhor solução.
Leia também