Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Azure Web PubSub oferece múltiplas formas de adicionar comunicação em tempo real a uma aplicação. Você pode começar com primitivas de mensagens flexíveis, manter um protocolo e modelo de programação estabelecidos, ou usar APIs projetadas para um cenário de aplicação específico.
A escolha certa permite que você evite construir ou operar capacidades que não diferenciam sua aplicação. Este artigo explica o que cada opção oferece, o que permanece sob seu controle e onde cada opção oferece mais valor.
Escolha com base no que quer construir
| Se você precisar... | Comece com... | Por que |
|---|---|---|
| Projete comportamentos personalizados em tempo real para painéis, jogos, notificações, streaming de tokens de IA, sinalização ou outros cenários de aplicação | Web PubSub (serviço base) | Você controla o protocolo da aplicação e a lógica de negócios, enquanto o Azure gerencia as conexões e a entrega das mensagens. |
| Escale uma aplicação Socket.IO existente ou use as APIs e o ecossistema Socket.IO | Socket.IO Azure | Você mantém o modelo de programação Socket.IO sem operar Socket.IO infraestrutura de conexão ou um adaptador. |
| Conecte clientes MQTT via WebSocket ou troque mensagens entre clientes MQTT e Web PubSub | Suporte ao MQTT | Você pode usar bibliotecas clientes MQTT e permitir que o Web PubSub traduza entre conceitos MQTT suportados e nativos. |
| Adicione chat individual ou em grupo com salas, associação, pedidos de mensagens e histórico | Chat web PubSub | Você recebe APIs específicas para chat e capacidades gerenciadas de chat em vez de projetá-las a partir de primitivas de mensagens de baixo nível. |
Entenda como as capacidades diferem
Pense no Web PubSub base como uma base flexível em tempo real. Ela te dá blocos de construção como conexões, usuários, grupos e eventos. Você decide o que esses blocos de construção significam na sua candidatura.
As outras capacidades removem trabalho para uma necessidade mais específica:
- Socket.IO Azure preserva o modelo de programação que Socket.IO desenvolvedores já conhecem.
- O suporte ao MQTT adapta um subconjunto suportado do MQTT para o Web PubSub para que os clientes MQTT possam participar de mensagens em tempo real.
- O chat Web PubSub oferece um modelo de aplicação de nível mais alto para salas, membros, mensagens e histórico.
Eles não são nomes intercambiáveis para a mesma API. A melhor opção é aquela que corresponde às abstrações que sua aplicação já usa ou teria que construir.
| Area | Web PubSub (serviço base) | Socket.IO Azure | Suporte ao MQTT | Chat web PubSub |
|---|---|---|---|---|
| Valor primário | Blocos de construção flexíveis em tempo real | Desenvolvimento Socket.IO familiar sem escalonamento auto-hospedado | Compatibilidade com clientes MQTT e interoperabilidade de protocolos | Um modelo de chat pronto para uso |
| Superfície de programação | SDKs Web PubSub, subprotocolos WebSocket, gerenciadores de eventos e APIs REST | Socket.IO APIs de cliente e servidor | Pacotes e conceitos MQTT suportados via WebSocket | APIs de cliente e servidor de chat |
| Principais conceitos de aplicação | Conexões, usuários, grupos e eventos | Sockets, salas, namespaces e eventos | Clientes, temas, assinaturas e mensagens | Usuários, salas, membros, mensagens e histórico |
| Azure handles | Ciclo de vida da conexão, escalabilidade, roteamento e expansão da mensagem | Hospedagem de conexão, escalabilidade e coordenação entre servidores de aplicativos | Tradução entre os conceitos suportados de MQTT e Web PubSub | Entrega em tempo real, espalhamento de grupos, assinatura de quartos, pedido de mensagens e persistência |
| Você projeta | Modelo de eventos, cargas úteis, fluxo de autorização, lógica de negócios e qualquer persistência | Eventos de aplicação e lógica de negócios | Design de tópicos, lógica de negócios e capacidades fora do subconjunto MQTT suportado | Experiência em chat, identidades de aplicação, atribuições de autorização e lógica de negócios |
| Melhor ajuste | Cargas de trabalho personalizadas ou mistas em tempo real | Novas ou existentes aplicações Socket.IO | Clientes web que utilizam bibliotecas MQTT ou clientes mistos MQTT e Web PubSub | Aplicações onde o chat é um recurso do produto |
Web PubSub (serviço base)
Escolha o Web PubSub base quando a flexibilidade for mais valiosa do que um modelo de aplicação feito para esse fim. Ele oferece transporte e roteamento gerenciados em tempo real, deixando seu modelo de eventos e comportamento de negócios sob seu controle.
Por exemplo, sua aplicação pode:
- Envie uma atualização para todos os clientes conectados, um grupo, um usuário ou uma conexão.
- Receber eventos do cliente em um servidor de aplicações ou Azure Functions.
- Permitir que clientes autorizados publiquem mensagens diretamente para um grupo.
- Use payloads e eventos personalizados para fluxos de trabalho específicos da aplicação.
Essa flexibilidade é útil para dashboards ao vivo, coordenação multiplayer, notificações, experiências colaborativas, atualizações de dispositivos, sinalização e streaming de tokens por IA. Você evita operar servidores WebSocket, mas ainda assim projeta recursos de domínio como persistência de mensagens, histórico ou associação ao chat quando seu aplicativo precisa.
Socket.IO Azure
Escolha Socket.IO no Azure quando sua equipe já usa Socket.IO ou quer suas APIs e ecossistemas orientados a eventos.
Em uma aplicação Socket.IO auto-hospedada, sua equipe deve manter conexões de cliente com estado e coordenar múltiplos servidores Socket.IO usando um adaptador. Socket.IO Azure gerencia a infraestrutura de conexão e a coordenação do servidor. Essa gestão permite que seus servidores de aplicação se concentrem no gerenciamento de eventos e na lógica de negócios.
O valor chave é a continuidade: você pode manter o modelo de programação Socket.IO e migrar uma aplicação existente com apenas poucas alterações de código, em vez de redesenhá-la em torno de uma API em tempo real diferente.
Para saber mais, veja a Visão Geral Socket.IO sobre Azure.
Suporte ao MQTT
Escolha suporte a MQTT quando os clientes usam bibliotecas MQTT e se conectam via WebSocket, ou quando os clientes MQTT precisam trocar mensagens com clientes nativos Web PubSub.
O Web PubSub reconhece mensagens MQTT suportadas e mapeia conceitos MQTT, como tópicos e assinaturas, para os conceitos Web PubSub. Esse mapeamento poupa você de construir e operar uma camada separada de tradução de protocolos.
O suporte a MQTT no Web PubSub é uma adaptação leve, não um corretor completo de MQTT. Ele suporta apenas os recursos MQTT que mapeiam para o Web PubSub. Recursos como assinaturas curinga, mensagens retidas, assinaturas compartilhadas e apelidos de tópicos não são suportados.
Se sua solução requer um corretor MQTT abrangente, considere o suporte ao MQTT no Grade de Eventos do Azure. Para cenários Web PubSub suportados e detalhes do protocolo, veja MQTT no serviço Azure Web PubSub.
Chat web PubSub
Escolha o chat Web PubSub quando o chat for um recurso do produto e você quiser dedicar tempo de desenvolvimento à experiência do usuário, em vez de criar o modelo de chat subjacente.
Ao usar o Web PubSub base, você pode criar um chat personalizado, mas sua equipe define cargas úteis de mensagens e implementa preocupações como salas, associação, ordem de mensagens e histórico. O chat Web PubSub fornece esses conceitos por meio de APIs e SDKs feitos sob medida.
O chat Web PubSub é uma capacidade de nível mais alto construída sobre a infraestrutura em tempo real do Web PubSub. Ele fornece:
- Conversa individual e em grupo.
- Salas e gestão de membros.
- Ordenei mensagens em tempo real.
- Persistência da mensagem e histórico de salas.
- Papéis e permissões para operações de chat.
Você continua sendo responsável pela integração de identidade, experiência do usuário e regras de negócios da sua aplicação, enquanto o serviço gerencia a infraestrutura comum de chat.
Para saber mais, veja O que é o chat Web PubSub?
Faça a escolha
Use estas perguntas para restringir a decisão:
- Você precisa preservar Socket.IO APIs ou migrar uma aplicação Socket.IO? Escolha Socket.IO em Azure.
- Seus clientes precisam se comunicar usando o protocolo MQTT suportado via WebSocket? Escolha suporte ao MQTT.
- Você precisa de salas embutidas, membros, pedidos de mensagens e histórico de mensagens para uma experiência de chat? Escolha o chat Web PubSub.
- Você precisa de um modelo de evento personalizado ou de um cenário em tempo real que não se encaixe nas opções anteriores? Escolha Web PubSub (serviço base).
Escolher uma capacidade mais especializada pode reduzir o tempo de desenvolvimento porque o Azure fornece mais do modelo de aplicação. Escolher o serviço base te dá mais controle quando suas necessidades são únicas. Comece com a capacidade de mais alto nível que atenda às suas necessidades e use o serviço base quando essa flexibilidade criar valor para sua aplicação.