Scegliere un'architettura per l'app Google Chat

Questa pagina descrive gli approcci comuni all'architettura dei servizi utilizzati per creare app di Google Chat. Se hai già un'app che vuoi integrare in Google Chat, puoi utilizzare o adattare la tua implementazione esistente. Se stai creando una nuova app di Chat, questa pagina presenta informazioni simili in diversi modi per aiutarti a scegliere l'architettura adatta al tuo caso d'uso:

Panoramica per caratteristiche e caratteristiche

La tabella seguente evidenzia le funzionalità principali delle app di Chat e lo stile di architettura del servizio consigliato (). In alcuni casi, potrebbe essere possibile sviluppare un altro stile di architettura con queste funzionalità, ma non è adatto al caso d'uso quanto altri stili ().

Caratteristiche e funzionalità

Servizio web o HTTP

Pub/Sub

Webhook

Apps Script

AppSheet

Dialogflow

Script

Pubblico di destinazione

Il tuo team

La tua organizzazione

Il pubblico

Interattività dell'utente

Utilizza l'elaborazione del linguaggio naturale

Pattern di messaggi

Inviare e ricevere messaggi sincroni

Invia e ricevi messaggi sincroni e invia messaggi asincroni

Invia solo messaggi asincroni

Inviare messaggi da un sistema esterno a un singolo spazio di Chat

Accedere ad altri servizi e sistemi

Integrazione con altri servizi Google

Comunicare dietro un firewall

Iscriviti agli eventi di Google Workspace

Stili di programmazione e deployment

Sviluppo senza codice

Sviluppo con poco codice

Sviluppo in un linguaggio di programmazione a tua scelta

DevOps semplificati

Gestione completa di DevOps e CI/CD

Stili di architettura dei servizi

Questa sezione descrive alcuni degli approcci all'architettura più comuni utilizzati per creare app di Chat.

Servizio web o HTTP

Un servizio web o HTTP è l'architettura di cui viene eseguito il deployment più comunemente, perché offre agli sviluppatori la massima flessibilità per creare app di Chat pubbliche. Questa architettura è consigliata per i seguenti casi d'uso:

  • Il deployment dell'app Chat è stato eseguito pubblicamente su Google Workspace Marketplace.
  • L'app Chat può inviare e ricevere tutti i pattern di messaggistica: inviare e ricevere messaggi sincroni, inviare messaggi asincroni e inviare messaggi da un sistema esterno.
  • L'app Chat è sviluppata in qualsiasi linguaggio di programmazione.
  • L'app Chat richiede una gestione DevOps e CI/CD completa.
  • Il servizio app Chat è implementato nel cloud o nei server on-premise.

In questa struttura, configurerai Chat in modo che si integri con un servizio remoto utilizzando HTTP, come illustrato nel diagramma seguente:

Architettura di un'app di Chat che utilizza un servizio web in un server on-premise.

Nel diagramma precedente, un utente che interagisce con un'app Chat HTTP ha il seguente flusso di informazioni:

  1. Un utente invia un messaggio in uno spazio di Chat a un'app Chat.
  2. Una richiesta HTTP viene inviata a un server web che è un sistema cloud o on-premise contenente la logica dell'app Chat.
  3. Facoltativamente, la logica dell'app di Chat può interagire con servizi di terze parti esterni, come un sistema di project management o uno strumento di gestione dei ticket.
  4. Il server web invia una risposta HTTP al servizio dell'app Chat in Chat.
  5. La risposta viene consegnata all'utente.
  6. Facoltativamente, l'app Chat può chiamare l'API Chat per pubblicare i messaggi in modo asincrono o eseguire altre operazioni.

Questa architettura ti offre la flessibilità di utilizzare le librerie e i componenti esistenti già presenti nel tuo sistema perché le app di Chat possono essere progettate utilizzando linguaggi di programmazione diversi. Esistono diversi modi per implementare questa architettura. In Google Cloud, puoi utilizzare Cloud Functions, Cloud Run e App Engine. Per iniziare, consulta Creare un'app Google Chat con Cloud Functions.

Pub/Sub

Se l'app Chat viene implementata dietro un firewall, Chat non sarà in grado di effettuare chiamate HTTP all'app. Un approccio è utilizzare Pub/Sub per abilitare l'implementazione dell'app Chat per la sottoscrizione a un argomento che trasporta i messaggi da Chat. Pub/Sub è un servizio di messaggistica asincrono che disaccoppia i servizi che producono messaggi dai servizi che li elaborano. Questa architettura è consigliata per i seguenti casi d'uso:

  • L'app di chat è protetta da un firewall.
  • L'app Chat riceve gli eventi relativi a uno spazio di Chat.
  • È stato eseguito il deployment dell'app Chat nella tua organizzazione.
  • L'app Chat può inviare e ricevere messaggi sincroni e può inviare messaggi asincroni.
  • L'app Chat è sviluppata in qualsiasi linguaggio di programmazione.
  • L'app Chat richiede una gestione DevOps e CI/CD completa.

Il seguente diagramma mostra l'architettura di un'app Chat creata con Pub/Sub:

Architettura di un'app di chat implementata con Pub/Sub.

Nel diagramma precedente, un utente che interagisce con un'app di chat Pub/Sub ha il seguente flusso di informazioni:

  1. Un utente invia un messaggio in Chat a un'app Chat, in un messaggio diretto o in uno spazio di Chat, oppure si verifica un evento in uno spazio di Chat per il quale l'app Chat ha un abbonamento attivo.

  2. Chat invia il messaggio a un argomento Pub/Sub.

  3. Un server delle applicazioni, ovvero un sistema cloud o on-premise che contiene la logica dell'app di Chat, sottoscrive l'argomento Pub/Sub per ricevere il messaggio attraverso il firewall.

  4. Facoltativamente, l'app Chat può chiamare l'API Chat per pubblicare i messaggi in modo asincrono o eseguire altre operazioni.

Per iniziare, vedi Utilizzare Pub/Sub come endpoint per l'app di Chat.

Webhook

Puoi creare un'app di Chat che può inviare messaggi solo a uno spazio di Chat specifico utilizzando le chiamate a un URL webhook di Chat. Questa architettura è consigliata per i seguenti casi d'uso:

  • Il deployment dell'app Chat è stato eseguito nel tuo team.
  • L'app Chat invia messaggi da un sistema esterno a un singolo spazio di Chat.

Con questa architettura, l'app di chat è limitata a uno spazio di Chat specifico e non consente l'interazione degli utenti, come illustrato nel diagramma seguente:

Architettura per i webhook in arrivo per inviare messaggi asincroni a Chat.

Nel diagramma precedente, un'app di chat presenta il seguente flusso di informazioni:

  1. La logica dell'app di Chat riceve informazioni da servizi di terze parti esterni, come un sistema di project management o uno strumento di gestione dei ticket.
  2. La logica dell'app Chat è ospitata su un cloud o su un sistema on-premise che può inviare messaggi utilizzando un URL webhook a uno spazio di Chat specifico.
  3. Gli utenti possono ricevere messaggi dall'app Chat in quello specifico spazio di Chat, ma non possono interagire con l'app Chat.

Questo tipo di app di Chat non può essere condivisa in altri spazi di Chat o con altri team e non può essere pubblicata in Google Workspace Marketplace. I webhook in arrivo sono consigliati per consentire alle app Chat di segnalare avvisi o stato o per alcuni tipi di prototipazione delle app Chat.

Per iniziare, consulta Inviare messaggi a Chat con webhook.

Apps Script

Puoi creare la logica dell'app di chat interamente in JavaScript. Google Apps Script è una piattaforma di sviluppo low-code per le app di Chat. Apps Script gestisce il flusso di autorizzazione e i token OAuth 2.0 per l'autenticazione degli utenti. Puoi utilizzare Apps Script per creare app di chat pubbliche, ma è sconsigliato a causa di quote e limiti giornalieri.

Questa architettura è consigliata per i seguenti casi d'uso:

  • Il deployment dell'app Chat è stato eseguito per il tuo team o per la tua organizzazione.
  • L'app Chat può inviare e ricevere tutti i pattern di messaggistica: inviare e ricevere messaggi sincroni, inviare messaggi asincroni e inviare messaggi da un sistema esterno.
  • L'app Chat richiede la gestione DevOps semplificata.

Questa architettura è utile per le app di Chat che si integrano anche con altri servizi Google e Google Workspace, come Fogli Google, Presentazioni Google, Google Calendar, Google Drive, Google Maps e YouTube, come mostrato nel diagramma seguente:

Architettura di un'app di chat implementata con Apps Script.

Nel diagramma precedente, un utente che interagisce con un'app di chat di Apps Script presenta il seguente flusso di informazioni:

  1. Un utente invia un messaggio a un'app di Chat in un messaggio diretto o in uno spazio di Chat.
  2. La logica dell'app di Chat implementata in Apps Script, che risiede in Google Cloud, riceve il messaggio.
  3. Facoltativamente, la logica dell'app Chat può integrarsi con i servizi Google Workspace, come Calendar o Fogli, oppure con altri servizi Google, come Google Maps o YouTube.
  4. La logica dell'app Chat invia una risposta al servizio dell'app Chat in Chat.
  5. La risposta viene consegnata all'utente.

Per iniziare, consulta Creare un'app di chat con Apps Script.

AppSheet

Puoi creare un'app di chat condivisa nel dominio senza codice utilizzando AppSheet. Puoi semplificare il processo di sviluppo utilizzando la modalità di configurazione automatica e i seguenti modelli per creare azioni comuni dell'app Chat. Tuttavia, alcune funzionalità dell'app web di AppSheet non sono disponibili nelle app di Chat.

Questa architettura è consigliata per i seguenti casi d'uso:

  • Il deployment dell'app Chat è stato eseguito per te e per il tuo team.
  • L'app Chat può inviare e ricevere messaggi sincroni e può inviare messaggi asincroni.
  • L'app Chat richiede la gestione DevOps semplificata.

Il seguente diagramma mostra l'architettura di un'app Chat creata con AppSheet:

Architettura di un'app di chat implementata con AppSheet.

Nel diagramma precedente, un utente che interagisce con un'app di chat di AppSheet ha il seguente flusso di informazioni:

  1. Un utente invia un messaggio in Chat a un'app Chat, in un messaggio diretto o in uno spazio di Chat.
  2. La logica dell'app di Chat implementata in AppSheet, che si trova in Google Cloud, riceve il messaggio.
  3. Facoltativamente, la logica dell'app Chat può integrarsi con i servizi Google Workspace, come Apps Script o Fogli Google.
  4. La logica dell'app Chat invia una risposta al servizio dell'app Chat in Chat.
  5. La risposta viene consegnata all'utente.

Per iniziare, vedi Creare un'app di chat con AppSheet.

Dialogflow

Puoi creare un'app di chat con Dialogflow, una piattaforma basata sul linguaggio naturale per le conversazioni automatiche e le risposte dinamiche. Questa architettura è consigliata per i seguenti casi d'uso:

  • L'app Chat può inviare e ricevere messaggi sincroni.
  • L'app di chat utilizza l'elaborazione del linguaggio naturale per rispondere e interagire con gli utenti.

Il seguente diagramma mostra l'architettura di un'app Chat creata con Dialogflow:

Architettura di un'app di chat implementata con Dialogflow.

Nel diagramma precedente, un utente che interagisce con un'app Dialogflow Chat ha il seguente flusso di informazioni:

  1. Un utente invia un messaggio in Chat a un'app Chat, in un messaggio diretto o in uno spazio di Chat.
  2. Un agente virtuale Dialogflow, che si trova in Google Cloud, riceve ed elabora il messaggio per produrre una risposta.
  3. Facoltativamente, la logica dell'app di Chat può interagire con servizi di terze parti esterni, come un sistema di project management o uno strumento di gestione dei ticket.
  4. L'agente Dialogflow invia una risposta al servizio app Chat in Chat.
  5. La risposta viene consegnata all'utente.

Per iniziare, consulta Integrazione di Dialogflow ES Chat o Integrazione di Dialogflow CX Chat.

Applicazione o script a riga di comando

Puoi creare un'applicazione a riga di comando o uno script che invia messaggi a Chat o esegue altre operazioni, come la creazione di uno spazio o la gestione dei membri di uno spazio, senza consentire agli utenti di richiamare o rispondere direttamente all'app Chat in Chat. Questa architettura è consigliata per i seguenti casi d'uso:

  • L'app Chat è sviluppata in qualsiasi linguaggio di programmazione.
  • L'app Chat può inviare solo messaggi asincroni.

Il seguente diagramma mostra l'architettura:

Architettura di un'app di chat implementata con un'applicazione a riga di comando o uno script.

Nel diagramma precedente, l'app di chat presenta il seguente flusso di informazioni:

  1. L'app Chat chiama l'API Chat per inviare un messaggio o eseguire un'altra operazione.
  2. Chat esegue l'operazione richiesta.
  3. Facoltativamente, l'app Chat stampa una conferma nell'interfaccia a riga di comando.

Implementazione della logica dell'app di chat

Chat non limita il modo in cui implementi la logica dell'app Chat. Puoi creare un analizzatore sintattico di comandi a sintassi fissa, utilizzare librerie o servizi di elaborazione del linguaggio e di AI avanzati, sottoscrivere e rispondere a eventi o qualsiasi altra opzione appropriata per i tuoi obiettivi specifici.

Gestire le interazioni degli utenti

L'app di chat può ricevere e rispondere alle interazioni degli utenti in vari modi. Un'interazione utente è qualsiasi azione eseguita da un utente per richiamare o interagire con un'app di chat.

Analizzatore sintattico di comandi

Le app di Chat basate sui comandi esaminano il payload degli eventi di interazione dell'app Chat, quindi estraggono comandi e parametri da questi contenuti. Ad esempio, vedi Configurare i comandi slash per interagire con gli utenti di Chat.

Un altro approccio consiste nel tokenizzare il messaggio, estrarre il comando e quindi fare riferimento a un dizionario che mappa i comandi alle funzioni di gestore di ciascun comando.

Interfaccia utente basata su dialogo

Le app basate su dialoghi rispondono agli eventi di interazione dell'app Chat mostrando finestre basate su schede in cui l'utente può interagire con l'app Chat, ad esempio compilando moduli o richiedendo azioni.

Ogni volta che l'utente esegue un'azione in una finestra di dialogo, viene inviato un nuovo evento di interazione all'app Chat, che può rispondere aggiornando la finestra di dialogo o inviando un messaggio.

Elaborazione del linguaggio naturale

Molte implementazioni dell'app di Chat utilizzano l'elaborazione del linguaggio naturale (NLP) per determinare ciò che l'utente sta chiedendo. Esistono molti modi per implementare l'NLP e puoi scegliere di farlo come preferisci.

Puoi utilizzare NLP nell'implementazione dell'app Chat con Dialogflow ES o l'integrazione di Dialogflow CX Chat, che ti consente di creare agenti virtuali per conversazioni automatizzate e risposte dinamiche.

Invia richieste a Chat in modo proattivo

Le app di chat possono anche inviare a Chat messaggi o altre richieste, che non vengono attivate dalle interazioni dirette degli utenti in Chat. Queste app di chat possono invece essere attivate, ad esempio da applicazioni di terze parti o utilizzando una chiamata da riga di comando da parte di un utente, ma gli utenti non possono interagire con queste app di Chat direttamente in Chat.

Le app di Chat non interattive utilizzano l'API Chat per inviare messaggi o altri tipi di richieste a Chat.

Modelli di conversazione

Dovresti prendere in considerazione il modo in cui vuoi che la tua app di chat interagisca con gli utenti. Le seguenti sezioni descrivono i modelli di conversazione che l'app di chat potrebbe implementare.

Chiamata e risposta (sincrona)

In un pattern di chiamata e risposta sincrono, l'app Chat risponde ai messaggi degli utenti su base one-to-one. Un messaggio di un utente all'app di chat genera una risposta dall'app Chat, come mostrato nel diagramma seguente:

Architettura di un messaggio sincrono.

Nel diagramma precedente, un utente che interagisce con un'app Chat ha il seguente flusso di informazioni:

  1. Un utente invia un messaggio sincrono a un'app Chat, ad esempio "Qual è la mia prossima riunione?".
  2. L'app Chat invia un messaggio sincrono all'utente, ad esempio "Dott. ssa Silva alle 2:30".

Per questo tipo di pattern di conversazione, puoi implementare un'architettura dell'app Chat utilizzando un servizio web, Pub/Sub, Apps Script, AppSheet o Dialogflow.

Risposte multiple (asincrone)

Il pattern con più risposte può includere messaggi sincroni e asincroni. Questo pattern è caratterizzato da una comunicazione bidirezionale tra gli utenti e l'app Chat, in cui l'app Chat genera un numero qualsiasi di messaggi aggiuntivi, come illustrato nel seguente diagramma:

Architettura di un messaggio asincrono.

Nel diagramma precedente, un utente che interagisce con un'app Chat ha il seguente flusso di informazioni:

  1. Un utente invia un messaggio sincrono a un'app Chat, ad esempio "Monitora il traffico".
  2. L'app di chat invia all'utente un messaggio sincrono per confermare la richiesta, ad esempio "Monitoraggio attivo".
  3. Successivamente, l'app Chat invia uno o più messaggi asincroni all'utente chiamando l'API REST, ad esempio "Nuovo traffico".
  4. L'utente invia un messaggio sincrono aggiuntivo all'app Chat, ad esempio "Ignora traffico".
  5. L'app di chat invia all'utente un messaggio sincrono per confermare la richiesta, ad esempio "Monitoraggio disattivato".

Per questo tipo di pattern di conversazione, puoi implementare un'architettura dell'app Chat utilizzando un servizio web, Pub/Sub, Apps Script o AppSheet.

Iscrizione agli eventi (asincrona)

In un pattern asincrono basato su eventi, l'app Chat si iscrive agli eventi utilizzando l'API Google Workspace Events. Le app di Chat basate su eventi esaminano il payload degli eventi di abbonamento a Chat, quindi rispondono in base al tipo di evento. Quando un evento si verifica in uno spazio di Chat per il quale l'app Chat ha un abbonamento attivo, quest'ultimo lo invia all'app Chat, che può generare facoltativamente un numero qualsiasi di risposte asincrone, che invia a Chat utilizzando l'API Chat.

Puoi utilizzare questo tipo di logica per aggiornare sistemi esterni, ad esempio un sistema di gestione dei ticket, o inviare messaggi a uno spazio di Chat in modo asincrono, ad esempio inviando un messaggio di benvenuto quando un nuovo utente entra in uno spazio di Chat.

Il seguente diagramma mostra il modello di conversazione basata sugli eventi:

Architettura di un messaggio basato su eventi.

Nel diagramma precedente, l'interazione tra Chat e l'app Chat prevede il seguente flusso di informazioni:

  1. L'app Chat si iscrive a uno spazio di Google Chat.
  2. Lo spazio a cui è iscritta l'app Chat cambia.
  3. L'app di chat consegna un evento a un argomento in Pub/Sub, che funge da endpoint di notifica per la sottoscrizione. L'evento contiene dati su ciò che è cambiato nella risorsa.
  4. L'app di chat elabora il messaggio Pub/Sub che contiene l'evento e, se necessario, interviene.

Per questo tipo di pattern di conversazione, puoi implementare un'architettura dell'app Chat utilizzando Pub/Sub.

Messaggio unidirezionale da un'app di Chat

Un messaggio unidirezionale di un pattern dell'app Chat consente a un'app Chat di inviare messaggi asincroni a uno spazio Chat, ma non consente agli utenti di interagire direttamente con l'app Chat. Questo pattern non è conversazionale o interattivo, ma può essere utile per attività come la generazione di report degli allarmi, come mostrato nel diagramma seguente:

Architettura di un messaggio unidirezionale.

Nel diagramma precedente, un utente nello stesso spazio dell'app Chat ha il seguente flusso di informazioni:

  • L'app Chat invia un messaggio asincrono all'utente chiamando l'API Chat o pubblicando un URL webhook, ad esempio "Avviso di overflow della coda".
  • Facoltativamente, l'app di chat invia messaggi asincroni aggiuntivi.

Per questo tipo di pattern di conversazione, puoi implementare un'architettura dell'app Chat utilizzando un servizio web, un webhook, Apps Script, AppSheet, un'applicazione a riga di comando o uno script.

Messaggio unidirezionale a un'app di Chat

Un messaggio unidirezionale a un pattern dell'app di chat consente a un utente di inviare un messaggio a un'app di chat senza che quest'ultima risponda durante l'elaborazione della richiesta. Sebbene questa architettura sia tecnicamente possibile, ciò comporta un'esperienza utente scadente e sconsigliamo vivamente di utilizzare questo pattern.