Share via


Procedura: creare una lavagna collaborativa in tempo reale usando Azure Web PubSub e distribuirla in Servizio app di Azure

Una nuova classe di applicazioni sta riimaginando il lavoro moderno. Mentre Microsoft Word riunisce gli editor, Figma raccoglie designer sullo stesso sforzo creativo. Questa classe di applicazioni si basa su un'esperienza utente che ci rende connessi ai collaboratori remoti. Da un punto di vista tecnico, le attività dell'utente devono essere sincronizzate tra le schermate degli utenti a bassa latenza.

Panoramica

In questa guida viene usato un approccio nativo del cloud e si usano i servizi di Azure per creare una lavagna collaborativa in tempo reale e si distribuisce il progetto come app Web in Servizio app di Azure. L'app lavagna è accessibile nel browser e consente a chiunque di disegnare sulla stessa area di disegno.

Gif del progetto completato.

Architettura

Nome del servizio di Azure Scopo Vantaggi
Servizio app di Azure Fornisce l'ambiente di hosting per l'applicazione back-end, compilata con Express Ambiente completamente gestito per i back-end dell'applicazione, senza dover preoccuparsi dell'infrastruttura in cui viene eseguito il codice
Azure Web PubSub Fornisce una bassa latenza, canale di scambio di dati bidirezionale tra l'applicazione back-end e i client Riduce drasticamente il carico del server liberando il server dalla gestione di connessioni WebSocket persistenti e scalabilità a 100 K connessioni client simultanee con una sola risorsa

Diagramma dell'architettura dell'app di lavagna collaborativa.

Prerequisiti

È possibile trovare una spiegazione dettagliata del flusso di dati alla fine di questa guida come si sta andando a concentrarsi sulla compilazione e la distribuzione dell'app per la lavagna prima.

Per seguire la guida dettagliata, è necessario

Creare risorse di Azure usando l'interfaccia della riga di comando di Azure

1. Accesso

  1. Accedere all'interfaccia della riga di comando di Azure eseguendo il comando seguente.

    az login
    
  2. Creare un gruppo di risorse in Azure.

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

2. Creare una risorsa app Web

  1. Creare un piano di servizio app gratuito.

    az appservice plan create \ 
      --resource-group "whiteboard-group" \ 
      --name "demo" \ 
      --sku FREE
      --is-linux
    
  2. Creare una risorsa app Web

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

3. Creare una risorsa PubSub Web

  1. Creare una risorsa PubSub Web.

    az webpubsub create \
      --name "whiteboard-app" \
      --resource-group "whiteboard-group" \
      --location "westus" \
      --sku Free_F1
    
  2. Visualizzare e archiviare il valore di primaryConnectionString da qualche parte per un uso successivo.

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

Ottenere il codice dell'applicazione

Eseguire il comando seguente per ottenere una copia del codice dell'applicazione. È possibile trovare una spiegazione dettagliata del flusso di dati alla fine di questa guida.

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

Distribuire l'applicazione in servizio app

  1. servizio app supporta molti flussi di lavoro di distribuzione. Per questa guida, verrà distribuito un pacchetto ZIP. Eseguire i comandi seguenti per preparare il file ZIP.

    npm install
    npm run build
    zip -r app.zip *
    
  2. Usare il comando seguente per distribuirlo in Servizio app di Azure.

    az webapp deployment source config-zip \
    --resource-group "whiteboard-group" \
    --name "whiteboard-app" \
    --src app.zip
    
  3. Impostare la stringa di connessione PubSub di Azure nelle impostazioni dell'applicazione. Usare il valore primaryConnectionString archiviato da un passaggio precedente.

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

Configurare il server upstream per gestire gli eventi provenienti da Web PubSub

Ogni volta che un client invia un messaggio al servizio Web PubSub, il servizio invia una richiesta HTTP a un endpoint specificato. Questo meccanismo è ciò che il server back-end usa per elaborare ulteriormente i messaggi, ad esempio se è possibile rendere persistenti i messaggi in un database di scelta.

Come accade con le richieste HTTP, il servizio Web PubSub deve sapere dove individuare il server applicazioni. Poiché l'applicazione back-end viene ora distribuita in servizio app, viene visualizzato un nome di dominio accessibile pubblicamente.

  1. Visualizzare e archiviare il valore di name da qualche parte.

    az webapp config hostname list \
      --resource-group "whiteboard-group"
      --webapp-name "whiteboard-app" 
    
  2. L'endpoint che è stato deciso di esporre nel server back-end è /eventhandler e il nome per l'app per la hub lavagna "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 ha tre parti: protocollo + nome host + percorso, che in questo caso è https://<The hostname of your Web App resource>/eventhandler.

Visualizzare l'app lavagna in un browser

Passare ora al browser e visitare l'app Web distribuita. È consigliabile aprire più schede del browser in modo che sia possibile sperimentare l'aspetto collaborativo in tempo reale dell'app. O meglio, condividere il collegamento con un collega o un amico.

Flusso di dati

Panoramica

La sezione Flusso di dati descrive in modo più approfondito il modo in cui viene compilata l'app per la lavagna. L'app lavagna include due metodi di trasporto.

  • Servizio HTTP scritto come app Express e ospitato in servizio app.
  • Connessioni WebSocket gestite da PubSub di Azure.

Usando Web PubSub di Azure per gestire le connessioni WebSocket, il carico nell'app Web è ridotto. Oltre a autenticare il client e la gestione delle immagini, l'app Web non implica la sincronizzazione delle attività di disegno. Le attività di disegno di un client vengono inviate direttamente a Web PubSub e trasmesse a tutti i client in un gruppo.

In qualsiasi momento, forse più di un disegno client. Se l'app Web doveva gestire le connessioni WebSocket autonomamente, è necessario trasmettere ogni attività di disegno a tutti gli altri client. L'enorme traffico e l'elaborazione sono un grande carico per il server.

Il client, compilato con Vue, effettua una richiesta HTTP per un token di accesso client a un endpoint /negotiate. L'applicazione back-end è un'app Express e ospitata come app Web usando Servizio app di Azure.

Screenshot del passaggio uno del flusso di dati dell'app.

Quando l'applicazione back-end restituisce correttamente il token di accesso client al client di connessione, il client lo usa per stabilire una connessione WebSocket con Azure Web PubSub.

Screenshot del passaggio due del flusso di dati dell'app.

Se l'handshake con Azure Web PubSub ha esito positivo, il client viene aggiunto a un gruppo denominato draw, sottoscrivendo in modo efficace i messaggi pubblicati in questo gruppo. Inoltre, il client ha l'autorizzazione per inviare messaggi al draw gruppo.

Screenshot del passaggio tre del flusso di dati dell'app.

Nota

Per mantenere attiva questa guida dettagliata, tutti i client di connessione vengono aggiunti allo stesso gruppo denominato draw e hanno l'autorizzazione per inviare messaggi a questo gruppo. Per gestire le connessioni client a livello granulare, vedere i riferimenti completi delle API fornite da Web PubSub di Azure.

Pub Web di Azure Invia una notifica all'applicazione back-end connessa da un client. L'applicazione back-end gestisce l'evento onConnected chiamando , sendToAll()con un payload del numero più recente di client connessi.

Screenshot del passaggio quattro del flusso di dati dell'app.

Nota

È importante notare che se nel gruppo sono presenti un numero elevato di utenti online, con una singola chiamata di rete dall'applicazione back-end, tutti gli utenti draw online riceveranno una notifica che un nuovo utente ha appena aggiunto. Ciò riduce drasticamente la complessità e il carico dell'applicazione back-end.

Non appena un client stabilisce una connessione persistente con Web PubSub, effettua una richiesta HTTP all'applicazione back-end per recuperare i dati di forma e sfondo più recenti in /diagram. Un servizio HTTP ospitato in servizio app può essere combinato con Web PubSub. servizio app si occupa della gestione degli endpoint HTTP, mentre Web PubSub si occupa della gestione delle connessioni WebSocket.

Screenshot del passaggio cinque del flusso di dati dell'app.

Ora che i client e l'applicazione back-end hanno due modi per scambiare dati. Uno è il ciclo di richiesta-risposta HTTP convenzionale e l'altro è il canale bidirezionale persistente tramite Web PubSub. Le azioni di disegno, che provengono da un utente e devono essere trasmesse a tutti gli utenti non appena avviene, vengono recapitate tramite Web PubSub. Non richiede il coinvolgimento dell'applicazione back-end.

Screenshot del passaggio sei del flusso di dati dell'app.

Pulire le risorse

Anche se l'applicazione usa solo i livelli gratuiti di entrambi i servizi, è consigliabile eliminare le risorse se non sono più necessarie. È possibile eliminare il gruppo di risorse insieme alle risorse in esso contenute usando il comando seguente:

az group delete 
  --name "whiteboard-group"

Passaggi successivi