Scegliere un'architettura per l'app Google Chat

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

Panoramica per funzionalità e caratteristiche

La tabella seguente evidenzia le funzionalità chiave delle app di chat e lo stile di architettura del servizio consigliato (). In alcuni casi, è possibile sviluppare un altro stile di architettura con queste funzionalità, ma non è adatto al caso d'uso come 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

Utilizzare l'elaborazione del linguaggio naturale

Pattern di messaggistica

Inviare e ricevere messaggi sincroni

Inviare e ricevere messaggi sincroni e inviare messaggi asincroni

Inviare solo messaggi asincroni

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

Accedere ad altri servizi e sistemi

Integra altri servizi Google

Comunicare dietro un firewall

Eseguire query o iscriversi agli eventi di Chat

Stili di codifica e deployment

Sviluppo senza codice

Sviluppo con low code

Sviluppo in un linguaggio di programmazione a tua scelta

DevOps semplificate

Gestione completa di DevOps e CI/CD

Stili di architettura dei servizi

Questa sezione descrive alcuni degli approcci architetturali più comuni utilizzati per creare app di chat.

Servizio web o HTTP

Un servizio web o HTTP è l'architettura più comunemente implementata perché offre agli sviluppatori la massima flessibilità per creare app di chat pubbliche. Questa architettura è consigliata per i seguenti casi d'uso:

  • L'app di chat viene implementata pubblicamente su Google Workspace Marketplace.
  • L'app Chat può inviare e ricevere tutti i modelli 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 la gestione completa di DevOps e CI/CD.
  • Il servizio dell'app di chat è implementato in server cloud o on-premise.

In questa progettazione, configuri Chat in modo che si integri con un servizio remoto utilizzando HTTP, come mostrato nel seguente diagramma:

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 di chat HTTP ha il seguente flusso di informazioni:

  1. Un utente invia un messaggio in uno spazio di Chat a un'app di chat.
  2. Una richiesta HTTP viene inviata a un server web che è un sistema cloud o on-premise che contiene la logica dell'app di chat.
  3. Se vuoi, la logica dell'app Chat può interagire con servizi esterni di terze parti, ad esempio un sistema di gestione dei progetti 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 inviata all'utente.
  6. Se vuoi, l'app Chat può chiamare l'API Chat per pubblicare messaggi in modo asincrono o eseguire altre operazioni.

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

Pub/Sub

Se l'app Chat è implementata dietro un firewall, Chat non è in grado di effettuare chiamate HTTP. Un approccio consiste nell'utilizzare Pub/Sub per consentire all'implementazione dell'app Chat di sottoscrivere un argomento che trasporta i messaggi di 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 Chat è protetta da un firewall.
  • L'app di Chat riceve eventi relativi a uno spazio di Chat.
  • L'app Chat viene implementata 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 la gestione completa di DevOps e CI/CD.

Il seguente diagramma mostra l'architettura di un'app di 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 di 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 di 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 Chat, si iscrive all'argomento Pub/Sub per ricevere il messaggio tramite il firewall.

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

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

Webhook

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

  • L'app di chat viene implementata nel tuo team.
  • L'app Chat invia messaggi da un sistema esterno a un singolo spazio di Chat.

Con questa architettura, l'app Chat è limitata a uno spazio Chat specifico e non consente l'interazione con l'utente, come mostrato nel seguente diagramma:

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

Nel diagramma precedente, un'app Chat ha il seguente flusso di informazioni:

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

Questo tipo di app di chat non può essere condiviso in altri spazi di chat o con altri team e non può essere pubblicato su Google Workspace Marketplace. I webhook in entrata sono consigliati per le app di chat per segnalare avvisi o stati oppure per alcuni tipi di prototipazione di app di chat.

Per iniziare, vedi Inviare messaggi a Chat con i webhook.

Apps Script

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

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

  • L'app Chat viene implementata nel tuo team o nella tua organizzazione.
  • L'app Chat può inviare e ricevere tutti i modelli di messaggistica: inviare e ricevere messaggi sincroni, inviare messaggi asincroni e inviare messaggi da un sistema esterno.
  • L'app Chat richiede una gestione DevOps semplificata.

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

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

Nel diagramma precedente, un utente che interagisce con un'app Chat Apps Script ha 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 Chat implementata in Apps Script, che si trova in Google Cloud, riceve il messaggio.
  3. Se vuoi, la logica dell'app Chat può integrarsi con i servizi Google Workspace, come Calendar o Fogli, o 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 inviata all'utente.

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

AppSheet

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

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

  • L'app Chat viene implementata per te e il tuo team.
  • L'app Chat può inviare e ricevere messaggi sincroni e può inviare messaggi asincroni.
  • L'app Chat richiede una gestione DevOps semplificata.

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

Architettura di un'app di Chat implementata con AppSheet.

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

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

Per iniziare, consulta Creare un'app Chat con AppSheet.

Dialogflow

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

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

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

Architettura di un'app di chat implementata con Dialogflow.

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

  1. Un utente invia un messaggio in Chat a un'app di 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. Se vuoi, utilizzando un webhook Dialogflow, l'agente Dialogflow può interagire con servizi esterni di terze parti, ad esempio un sistema di gestione dei progetti o uno strumento di gestione dei ticket.
  4. L'agente Dialogflow invia una risposta al servizio dell'app Chat in Chat.
  5. La risposta viene inviata allo spazio di Chat.

Per iniziare, vedi Creare un'app Google Chat Dialogflow.

Applicazione o script a riga di comando

Puoi creare un'applicazione da 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 Chat implementata con un'applicazione a riga di comando o uno script.

Nel diagramma precedente, l'app Chat ha il seguente flusso di informazioni:

  1. L'app Chat chiama l'API Chat per inviare un messaggio o eseguire un'altra operazione.
  2. La 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 di chat. Puoi creare un parser di comandi a sintassi fissa, utilizzare servizi o librerie di elaborazione del linguaggio e di AI avanzata, iscriverti e rispondere agli eventi o qualsiasi altra cosa appropriata per i tuoi obiettivi specifici.

Gestire le interazioni utente

L'app di chat può interagire con gli utenti in diversi modi. Un'interazione utente è qualsiasi azione intrapresa da un utente per richiamare o interagire con un'app di chat.

Analizzatore sintattico dei comandi

Le app di chat basate su comandi esaminano il payload degli eventi di interazione con le app di chat, quindi estraggono comandi e parametri da questi contenuti. Ad esempio, vedi Rispondere ai comandi dell'app Google 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 gestione per ogni comando.

Interfaccia utente basata su finestre di dialogo

Le app basate su finestre di dialogo rispondono agli eventi di interazione dell'app Chat visualizzando finestre di dialogo basate su schede in cui l'utente può interagire con l'app Chat, ad esempio compilare moduli o richiedere 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 Chat utilizzano l'elaborazione del linguaggio naturale (NLP) per determinare cosa sta chiedendo l'utente. Esistono molti modi per implementare l'elaborazione del linguaggio naturale e puoi scegliere di implementarla come preferisci.

Puoi utilizzare l'elaborazione del linguaggio naturale nell'implementazione dell'app di chat con Dialogflow ES o con l'integrazione della chat di Dialogflow CX, che ti consente di creare agenti virtuali per conversazioni automatizzate e risposte dinamiche.

Emettere richieste in modo proattivo a Chat

Le app di chat possono anche inviare messaggi o altre richieste a Chat, che non vengono attivate da interazioni dirette degli utenti in Chat. Queste app di chat possono 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 direttamente con queste app di chat in Chat.

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

Pattern conversazionali

Devi valutare in che modo vuoi che la tua app Chat interagisca con gli utenti. Le seguenti sezioni descrivono i pattern di conversazione che la tua app Chat potrebbe implementare.

Botta e risposta (sincrono)

In un pattern di chiamata e risposta sincrono, l'app Chat risponde ai messaggi degli utenti in modo individuale. Un messaggio all'app Chat da parte di un utente genera una risposta dall'app Chat, come mostrato nel seguente diagramma:

Architettura di un messaggio sincrono.

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

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

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

Più risposte (asincrone)

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

Architettura di un messaggio asincrono.

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

  1. Un utente invia un messaggio sincrono a un'app di chat, ad esempio "Monitora il traffico".
  2. L'app Chat invia un messaggio sincrono all'utente per confermare la richiesta, ad esempio "Monitoraggio attivo".
  3. In un secondo momento, 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 il traffico".
  5. L'app Chat invia un messaggio sincrono all'utente per confermare la richiesta, ad esempio "Monitoraggio disattivato".

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

Eseguire query o abbonarsi agli eventi (asincrono)

In un pattern asincrono basato sugli eventi, l'app Chat riceve gli eventi eseguendo query sull'API Chat o creando un abbonamento a uno spazio o a un utente di Chat utilizzando l' API Google Workspace Events. Gli eventi rappresentano modifiche alle risorse di Chat, ad esempio quando viene pubblicato un nuovo messaggio o quando un utente entra in uno spazio. Le app di chat basate sugli eventi esaminano il payload dell'evento per ottenere dati sulla risorsa Chat modificata, quindi rispondono di conseguenza.

Le app di chat possono ricevere molti tipi di eventi, inclusi eventi relativi a spazi, abbonamenti, messaggi e reazioni. Quando un'app Chat riceve un evento eseguendo una query sull'API Chat o tramite un abbonamento attivo, l'app Chat può generare facoltativamente un numero qualsiasi di risposte asincrone, che invia di nuovo 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 un esempio di pattern conversazionale basato sugli eventi:

Architettura di una sottoscrizione agli eventi di Chat

Nel diagramma precedente, l'interazione tra Chat e l'app Chat segue 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 Chat invia un evento a un argomento in Pub/Sub, che funge da endpoint di notifica per l'abbonamento. L'evento contiene dati sulle modifiche apportate alla risorsa.
  4. L'app Chat elabora il messaggio Pub/Sub che contiene l'evento e, se necessario, interviene.

Per questo tipo di pattern conversazionale, puoi implementare un'architettura di app di chat utilizzando Pub/Sub, un servizio web o Apps Script.

Per saperne di più su come ricevere e rispondere agli eventi, vedi Utilizzare gli eventi di Google Chat.

Messaggio unidirezionale da un'app di chat

Un messaggio unidirezionale da un pattern di app di chat consente a un'app di chat di inviare messaggi asincroni a uno spazio di chat, ma non consente agli utenti di interagire direttamente con l'app di chat. Questo pattern non è conversazionale o interattivo, ma può essere utile per attività come la segnalazione di 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 messaggio su un webhook URL, ad esempio "Avviso di overflow della coda".
  • Se vuoi, l'app Chat invia messaggi asincroni aggiuntivi.

Per questo tipo di pattern conversazionale, puoi implementare un'architettura di app di chat utilizzando un servizio web, un webhook, Apps Script, AppSheet, un'applicazione da riga di comando o uno script.

Messaggio unidirezionale a un'app di chat

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