Share via

Procedimentos: criar um quadro colaborativo em tempo real com o Azure Web PubSub e implementá-lo no Serviço de Aplicações do Azure

  • Artigo

Uma nova classe de aplicações está a reimaginar o que pode ser o trabalho moderno. Enquanto o Microsoft Word reúne editores, a Figma reúne designers no mesmo esforço criativo. Esta classe de aplicações baseia-se numa experiência de utilizador que nos faz sentir ligados aos nossos colaboradores remotos. Do ponto de vista técnico, as atividades do utilizador têm de ser sincronizadas entre os ecrãs dos utilizadores com baixa latência.

Descrição geral

Neste guia de procedimentos, tomamos uma abordagem nativa da cloud e utilizamos os serviços do Azure para criar um quadro colaborativo em tempo real e implementamos o projeto como uma Aplicação Web para Serviço de Aplicações do Azure. A aplicação do quadro é acessível no browser e permite que qualquer pessoa possa desenhar na mesma tela.

Gif do projeto concluído.

Dar saída da demonstração em direto do quadro

Arquitetura

Nome do serviço do Azure Objetivo Benefícios
Serviço de Aplicações do Azure Fornece o ambiente de alojamento para a aplicação de back-end, que é criada com o Express Ambiente totalmente gerido para back-ends de aplicações, sem necessidade de se preocupar com a infraestrutura onde o código é executado
Azure Web PubSub Fornece um canal de troca de dados bidirecional de baixa latência entre a aplicação de back-end e os clientes Reduz drasticamente a carga do servidor ao libertar o servidor da gestão de ligações e dimensionamentos persistentes do WebSocket para ligações de cliente simultâneas de 100 K com apenas um recurso

Diagrama de arquitetura da aplicação de quadro colaborativo.

Pré-requisitos

Pode encontrar uma explicação detalhada do fluxo de dados no final deste guia de procedimentos, uma vez que vamos concentrar-nos primeiro na criação e implementação da aplicação do quadro.

Para seguir o guia passo a passo, precisa de

Criar recursos do Azure com a CLI do Azure

1. Iniciar sessão

  1. Inicie sessão na CLI do Azure ao executar o seguinte comando.

    az login

  2. Criar um grupo de recursos no Azure.

    az group create \
  --location "westus" \  
  --name "whiteboard-group"

2. Criar um recurso de Aplicação Web

  1. Crie um plano de Serviço de Aplicações gratuito.

    az appservice plan create \ 
  --resource-group "whiteboard-group" \ 
  --name "demo" \ 
  --sku FREE
  --is-linux

  2. Criar um recurso de Aplicação Web

    az webapp create \
  --resource-group "whiteboard-group" \
  --name "whiteboard-app" \ 
  --plan "demo" \
  --runtime "NODE:18-lts"

3. Criar um recurso Web PubSub

  1. Crie um recurso Web PubSub.

    az webpubsub create \
  --name "whiteboard-app" \
  --resource-group "whiteboard-group" \
  --location "westus" \
  --sku Free_F1

  2. Mostrar e armazenar o valor de primaryConnectionString algures para utilização posterior.

    az webpubsub key show \
  --name "whiteboard-app" \
  --resource-group "whiteboard-group"

Obter o código da aplicação

Execute o seguinte comando para obter uma cópia do código da aplicação. Pode encontrar uma explicação detalhada do fluxo de dados no final deste guia de procedimentos.

git clone https://github.com/Azure/awps-webapp-sample.git

Implementar a aplicação no Serviço de Aplicações

  1. Serviço de Aplicações suporta muitos fluxos de trabalho de implementação. Para este guia, vamos implementar um pacote ZIP. Execute os seguintes comandos para preparar o ZIP.

    npm install
npm run build
zip -r app.zip *

  2. Utilize o seguinte comando para implementá-lo no Serviço de Aplicações do Azure.

    az webapp deployment source config-zip \
--resource-group "whiteboard-group" \
--name "whiteboard-app" \
--src app.zip

  3. Defina a cadeia de ligação Azure Web PubSub nas definições da aplicação. Utilize o valor armazenado primaryConnectionString de um passo anterior.

    az webapp config appsettings set \
--resource-group "whiteboard-group" \
--name "whiteboard-app" \
--setting Web_PubSub_ConnectionString="<primaryConnectionString>"

Configurar o servidor a montante para processar eventos provenientes do Web PubSub

Sempre que um cliente envia uma mensagem para o serviço Web PubSub, o serviço envia um pedido HTTP para um ponto final que especificar. Este mecanismo é o que o servidor de back-end utiliza para processar mensagens adicionais, por exemplo, se conseguir manter mensagens numa base de dados de eleição.

Tal como acontece com os pedidos HTTP, o serviço Web PubSub precisa de saber onde localizar o servidor de aplicações. Uma vez que a aplicação de back-end está agora implementada no Serviço de Aplicações, obtemos um nome de domínio acessível publicamente para a mesma.

  1. Mostrar e armazenar o valor de name algures.

    az webapp config hostname list \
  --resource-group "whiteboard-group"
  --webapp-name "whiteboard-app"

  2. O ponto final que decidimos expor no servidor de back-end é /eventhandler e o nome da aplicação hub de quadro "sample_draw"

    az webpubsub hub create \ 
  --resource-group "whiteboard-group" \
  --name "whiteboard-app" \
  --hub-name "sample_draw" \
  --event-handler url-template="https://<Replace with the hostname of your Web App resource>/eventhandler" user-event-pattern="*" system-event="connected" system-event="disconnected"

Importante

url-template tem três partes: protocolo + nome do anfitrião + caminho, que no nosso caso é https://<The hostname of your Web App resource>/eventhandler.

Ver a aplicação do quadro num browser

Agora, aceda ao seu browser e visite a sua Aplicação Web implementada. É recomendado ter vários separadores do browser abertos para que possa experimentar o aspeto colaborativo em tempo real da aplicação. Ou melhor, partilhe a ligação com um colega ou amigo.

Fluxo de dados

Descrição geral

A secção de fluxo de dados analisa mais aprofundadamente a forma como a aplicação do quadro é criada. A aplicação do quadro tem dois métodos de transporte.

  • Serviço HTTP escrito como uma aplicação Express e alojado no Serviço de Aplicações.
  • Ligações WebSocket geridas pelo Azure Web PubSub.

Ao utilizar o Azure Web PubSub para gerir ligações WebSocket, a carga na Aplicação Web é reduzida. Além de autenticar o cliente e de servir imagens, a Aplicação Web não está envolvida na sincronização de atividades de desenho. As atividades de desenho de um cliente são enviadas diretamente para o Web PubSub e transmitidas a todos os clientes num grupo.

A qualquer momento, talvez haja mais do que um desenho de cliente. Se a Aplicação Web gerisse as ligações WebSocket por si só, precisava de difundir todas as atividades de desenho para todos os outros clientes. O tráfego e o processamento enormes são um grande fardo para o servidor.

O cliente, criado com o Vue, faz um pedido HTTP para um Token de Acesso de Cliente para um ponto /negotiatefinal . A aplicação de back-end é uma aplicação Express e alojada como uma Aplicação Web com Serviço de Aplicações do Azure.

Captura de ecrã do passo um do fluxo de dados da aplicação.

Quando a aplicação de back-end devolve com êxito o Token de Acesso de Cliente ao cliente de ligação, o cliente utiliza-o para estabelecer uma ligação WebSocket com o Azure Web PubSub.

Captura de ecrã do passo dois do fluxo de dados da aplicação.

Se o handshake com o Azure Web PubSub for bem-sucedido, o cliente será adicionado a um grupo com o nome draw, subscrevendo efetivamente as mensagens publicadas neste grupo. Além disso, é dada ao cliente a permissão para enviar mensagens para o draw grupo.

Captura de ecrã do passo três do fluxo de dados da aplicação.

Nota

Para manter este guia de procedimentos focado, todos os clientes de ligação são adicionados ao mesmo grupo com draw o nome e é-lhe dada a permissão para enviar mensagens para este grupo. Para gerir ligações de cliente a um nível granular, veja as referências completas das APIs fornecidas pelo Azure Web PubSub.

O Azure Web PubSub notifica a aplicação de back-end que um cliente ligou. A aplicação de back-end processa o onConnected evento ao chamar o sendToAll(), com um payload do número mais recente de clientes ligados.

Captura de ecrã do passo quatro do fluxo de dados da aplicação.

Nota

É importante ter em atenção que, se existir um grande número de utilizadores online no draw grupo, com uma única chamada de rede da aplicação de back-end, todos os utilizadores online serão notificados de que um novo utilizador acabou de aderir. Isto reduz drasticamente a complexidade e a carga da aplicação de back-end.

Assim que um cliente estabelece uma ligação persistente com o Web PubSub, faz um pedido HTTP à aplicação de back-end para obter os dados de forma e fundo mais recentes em /diagram. Um serviço HTTP alojado no Serviço de Aplicações pode ser combinado com o Web PubSub. Serviço de Aplicações tem o cuidado de servir pontos finais HTTP, enquanto o Web PubSub trata da gestão de ligações WebSocket.

Captura de ecrã do passo cinco do fluxo de dados da aplicação.

Agora que os clientes e a aplicação de back-end têm duas formas de trocar dados. Um é o ciclo de pedido-resposta http convencional e o outro é o canal persistente bidirecional através do Web PubSub. As ações de desenho, que têm origem num utilizador e precisam de ser transmitidas a todos os utilizadores assim que ocorrer, são entregues através do Web PubSub. Não requer o envolvimento da aplicação de back-end.

Captura de ecrã do passo seis do fluxo de dados da aplicação.

Limpar os recursos

Embora a aplicação utilize apenas os escalões gratuitos de ambos os serviços, é melhor prática eliminar recursos se já não precisar deles. Pode eliminar o grupo de recursos juntamente com os recursos nele contidos com o seguinte comando,

az group delete 
  --name "whiteboard-group"

Passos seguintes

Veja mais demonstrações criadas com o Web PubSub