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 già un'app che vuoi integrare in Google Chat, puoi utilizzare o adattare l'implementazione esistente. Se stai creando una nuova app di Chat, questa pagina presenta informazioni simili in diversi modi per aiutarti a scegliere l'architettura più adatto al tuo caso d'uso:

Panoramica per funzioni e caratteristiche

La seguente tabella evidenzia le caratteristiche e le capacità principali App di chat e le app Stile dell'architettura del servizio (). In alcuni casi, potrebbe essere possibile sviluppare un altro stile di architettura queste funzionalità, ma non è adatta al caso d'uso di altre 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à utente

Utilizza l'elaborazione del linguaggio naturale

Pattern di messaggistica

Invia e ricevi messaggi sincronizzati

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

Accedi ad altri servizi e sistemi

Integra altri servizi Google

Comunica dietro un firewall

Eseguire query o iscriversi a eventi di Chat

Stili di programmazione e deployment

Sviluppo senza codice

Sviluppo con poco codice

Sviluppo in un linguaggio di programmazione a tua scelta

DevOps semplificate

Gestione completa DevOps e CI/CD

Stili dell'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 di cui viene eseguito il deployment più comune perché Offre la massima flessibilità agli sviluppatori per creare App di chat. Questa architettura è consigliata per: casi d'uso:

  • Il deployment dell'app Chat viene eseguito per il pubblico Google Workspace Marketplace.
  • L'app Chat può inviare e ricevere tutti i messaggi pattern: invio e ricezione di messaggi sincroni, invio asincrono e inviare messaggi da un sistema esterno.
  • L'app Chat è sviluppata in qualsiasi programmazione lingua.
  • L'app Chat richiede DevOps e CI/CD completi gestione dei dispositivi.
  • Il servizio dell'app Chat è implementato nel cloud tra i server on-premise.

In questa progettazione, configuri Chat in modo che si integri con remoto mediante 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 indirizzo HTTP L'app Chat prevede 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 è cloud o sistema on-premise che contiene l'app di Chat logica.
  3. Facoltativamente, la logica dell'app di Chat può interagire con servizi di terze parti esterni, come un sistema di project management o un per la vendita di biglietti.
  4. Il server web invia una risposta HTTP all'URL Servizio app di Chat in Chat.
  5. La risposta viene consegnata all'utente.
  6. Facoltativamente, l'app Chat può chiamare l'API Chat per pubblicare messaggi in modo asincrono o eseguire operazioni.

Questa architettura offre la flessibilità di utilizzare le librerie esistenti componenti già esistenti nel sistema, in quanto Le app di chat possono essere progettate utilizzando linguaggi di programmazione diversi. Esistono diversi modi per implementare questa architettura. Su Google Cloud, possono usare Cloud Functions, Cloud Run e App Engine. Per iniziare, consulta Crea un'app Google Chat.

Pub/Sub

Se l'app Chat è implementata dietro un firewall, Chat non è in grado di effettuare chiamate HTTP. Un approccio è utilizzare Da Pub/Sub a abilitare l'implementazione dell'app Chat per sottoscrivere un abbonamento che trasporta messaggi da Chat. Pub/Sub è un servizio servizio di messaggistica che disaccoppia i servizi che producono messaggi dai servizi nell'elaborazione di questi messaggi. Questa architettura è consigliata per: casi d'uso:

  • L'app Chat è protetta da un firewall.
  • App Chat riceve 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 sincrona e possono inviare messaggi asincroni.
  • L'app Chat è sviluppata in qualsiasi programmazione lingua.
  • L'app Chat richiede DevOps e CI/CD completi gestione dei dispositivi.

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 Pub/Sub L'app Chat prevede il seguente flusso di informazioni:

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

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

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

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

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

Webhook

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

  • È stato eseguito il deployment dell'app Chat per il tuo team.
  • L'app Chat invia messaggi da un indirizzo in un singolo spazio di Chat.

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

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

Nel diagramma precedente, un'app di Chat include quanto segue flusso di informazioni:

  1. La logica dell'app Chat riceve informazioni servizi di terze parti esterni, come un sistema di project management o un per la vendita di biglietti.
  2. La logica dell'app di Chat è ospitata in un cloud sistema on-premise in grado di inviare messaggi utilizzando un URL webhook a un uno spazio di Chat specifico.
  3. Gli utenti possono ricevere messaggi dall'app Chat in spazio di Chat specifico, ma non riesci a interagire con 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 Google Workspace Marketplace. I webhook in arrivo sono consigliati per App di chat per segnalare avvisi o stato o per alcuni tipi di Prototipazione di app di chat.

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

Apps Script

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

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

  • È stato eseguito il deployment dell'app Chat per il tuo team, o all'organizzazione.
  • L'app Chat può inviare e ricevere tutti i messaggi pattern: invio e ricezione di messaggi sincroni, invio asincrono e inviare messaggi da un sistema esterno.
  • L'app Chat richiede DevOps semplificate gestione dei dispositivi.

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

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

Nel diagramma precedente, un utente interagisce con uno script di Google Apps L'app Chat prevede il seguente flusso di informazioni:

  1. Un utente invia un messaggio a un'app di Chat in un un messaggio diretto o in uno spazio di Chat.
  2. La logica dell'app di Chat implementata Apps Script, che risiede in Google Cloud, riceve il messaggio.
  3. Facoltativamente, la logica dell'app di Chat può integrarsi con ai servizi Google Workspace, ad esempio Calendar o Fogli o altri servizi Google, ad esempio Google Maps o su YouTube.
  4. La logica dell'app Chat invia una risposta all' Servizio app di 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 app di Chat. Tuttavia, alcune Le funzionalità dell'app web 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 il tuo team.
  • L'app Chat può inviare e ricevere messaggi sincrona e possono inviare messaggi asincroni.
  • L'app Chat richiede DevOps semplificate gestione dei dispositivi.

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 AppSheet L'app Chat prevede il seguente flusso di informazioni:

  1. Un utente invia un messaggio in Chat a un App di Chat, in un messaggio diretto o in Spazio di Chat.
  2. La logica dell'app di Chat implementata AppSheet, che risiede in Google Cloud, riceve per creare un nuovo messaggio email.
  3. Facoltativamente, la logica dell'app di Chat può integrarsi con ai servizi Google Workspace, ad esempio Apps Script o in Fogli Google.
  4. La logica dell'app Chat invia una risposta all' Servizio app di Chat in Chat.
  5. La risposta viene consegnata all'utente.

Per iniziare, consulta Crea un'app di Chat con AppSheet.

Dialogflow

Puoi creare un'app di chat con Dialogflow, una 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 sincrona messaggi.
  • 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 Dialogflow L'app Chat prevede il seguente flusso di informazioni:

  1. Un utente invia un messaggio in Chat a un App di Chat, in un messaggio diretto o in Spazio di Chat.
  2. Un agente virtuale Dialogflow, che risiede in Google Cloud, riceve ed elabora il messaggio per produrre una risposta.
  3. Facoltativamente, l'utilizzo di Webhook Dialogflow, l'agente Dialogflow può interagire con servizi di terze parti esterni, come sistema di gestione dei progetti o strumento di gestione dei ticket.
  4. L'agente Dialogflow invia una risposta all'agente Servizio app di Chat in Chat.
  5. La risposta viene consegnata allo spazio di Chat.

Per iniziare, consulta Creare un'app Dialogflow di Google Chat.

Applicazione o script a riga di comando

Puoi creare un'applicazione a riga di comando o uno script che invia di messaggi a Chat o eseguire altre operazioni come la creazione uno spazio o la gestione dei relativi membri, senza che gli utenti possano accedere direttamente per richiamare o rispondere all'app Chat Chatta. Questa architettura è consigliata per i seguenti usi casi:

  • L'app Chat è sviluppata in qualsiasi programmazione lingua.
  • 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 Chat include il seguente flusso di informazioni:

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

Implementazione della logica dell'app di Chat

La chat non limita il modo in cui implementi Logica dell'app di chat. Puoi creare un comando di sintassi fissa parser, utilizzare librerie o servizi avanzati di IA ed elaborazione del linguaggio, sottoscrivere un abbonamento e rispondere agli eventi o a qualsiasi altra cosa appropriata per i tuoi obiettivi specifici.

Gestire le interazioni degli utenti

L'app di chat può ricevono e rispondono alle interazioni degli utenti in vari modi. Con "interazione utente" si intende qualsiasi azione intrapresa da un utente per chiamare o interagire con un'app di Chat.

Parser dei comandi

Le app di Chat basate su comandi esaminano il payload Eventi di interazione con l'app di Chat, ed estrarre comandi e parametri da questi contenuti. Ad esempio, vedi Configurare i comandi con barra per interagire con gli utenti di Chat.

Un altro approccio è tokenizzare il messaggio, estrarre il comando fare riferimento a un dizionario che mappa i comandi a funzioni di gestore per ciascun comando.

Interfaccia utente basata su finestre di dialogo

Le app basate su finestre di dialogo rispondono Eventi di interazione con l'app di Chat mostrando i dati delle schede di dialogo in cui l'utente può interagire con l'app di chat, ad esempio compilazione di moduli o richiedere azioni.

Ogni volta che l'utente esegue un'azione in una finestra di dialogo, viene generato un nuovo evento di interazione. inviati all'app Chat, che può rispondere aggiornando le finestra di dialogo o per inviare un messaggio.

Elaborazione del linguaggio naturale

Molte implementazioni di app di Chat utilizzano il linguaggio naturale dell'elaborazione (NLP) per determinare cosa chiede l'utente. Ci sono molti modi per implementare l'NLP e puoi scegliere di implementarla come preferisci.

Puoi usare l'NLP nei Implementazione dell'app di chat con Dialogflow ES o integrazione di Dialogflow CX Chat, che consente di creare agenti virtuali per conversazioni automatizzate e dinamiche diverse.

Inviare richieste a Chat in modo proattivo

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

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

Modelli conversazionali

Devi considerare come vuoi che l'app Chat interagire con gli utenti. Le seguenti sezioni descrivono i pattern di conversazione che 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 una uno a uno. Un messaggio all'app Chat da parte di un utente genera un'unica risposta dall'app Chat, come mostrato in il seguente diagramma:

Architettura di un messaggio sincrono.

Nel diagramma precedente, un utente interagisce con un L'app Chat prevede 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 al utente, ad esempio "Dott. Silva a 14:30".

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

Risposte multiple (asincrone)

Il pattern di risposte multiple può includere sincrono e asincrono messaggi. Questo modello è caratterizzato da una comunicazione bidirezionale tra gli utenti e l'app Chat, con un'app di chat che genera un numero qualsiasi di messaggi aggiuntivi come illustrato nel seguente diagramma:

Architettura di un messaggio asincrono.

Nel diagramma precedente, un utente interagisce con un L'app Chat prevede 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 al all'utente per accettare la richiesta, ad esempio "Monitoraggio attivo".
  3. In seguito, l'app Chat invia uno o più all'utente chiamando l'API REST, ad esempio "Nuovo traffico".
  4. L'utente invia un ulteriore messaggio sincrono al App di chat, ad esempio "Ignora il traffico".
  5. L'app Chat invia un messaggio sincrono al all'utente per accettare la richiesta, ad esempio "Monitoraggio disattivato".

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

Query o sottoscrizione di eventi (asincrona)

In un pattern asincrono basato su eventi, l'app Chat riceve gli eventi inviando una query all'API Chat o creando un a uno spazio di Chat o a un utente utilizzando API Google Workspace Events. Gli eventi rappresentano modifiche a Chat ad esempio quando viene pubblicato un nuovo messaggio o un utente partecipa a uno spazio. App di chat basate su eventi esamina il payload dell'evento per ottenere dati sulla modifica della chat delle risorse, quindi reagisci di conseguenza.

Le app di chat possono ricevere molti tipi di eventi, inclusi eventi su spazi, iscrizioni, messaggi e reazioni. Quando L'app di chat riceve un evento eseguendo una query sul API Chat o tramite un abbonamento attivo, Chat può quindi generare facoltativamente un numero qualsiasi di asincrone, che invia a Chat utilizzando API Chat.

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

Il seguente diagramma mostra un esempio di conversazione basata su eventi motivo:

Architettura di una sottoscrizione agli eventi di Chat

Nel diagramma precedente, l'interazione tra Chat e il 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 modifiche.
  3. L'app Chat invia un evento a un argomento in Pub/Sub, che funge da endpoint di notifica per la sottoscrizione. La contiene i dati su cosa è cambiato nella risorsa.
  4. L'app Chat elabora Messaggio Pub/Sub che contiene l'evento e, se necessario, esegue un'azione.

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

Per ulteriori informazioni su come ricevere e rispondere agli eventi, vedi Utilizzare gli eventi degli eventi di Google Chat.

Messaggio unidirezionale da un'app di Chat

Un messaggio unidirezionale da un pattern dell'app di Chat consente a un Le app di chat inviano messaggi asincroni a un spazio di Chat, ma non consente agli utenti di interagire direttamente App Chat. Questo pattern non è colloquiale interattivi, ma possono essere utili per cose come la segnalazione di allarmi, come mostrato in diagramma seguente:

Architettura di un messaggio unidirezionale.

Nel diagramma precedente, un utente che si trova nello stesso spazio L'app Chat prevede il seguente flusso di informazioni:

  • L'app Chat invia un messaggio asincrono all'utente chiamando l'API Chat o pubblicando post su un webhook URL, ad esempio "Avviso overflow coda".
  • Facoltativamente, l'app Chat invia altre e asincroni.

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

Messaggio unidirezionale per un'app di Chat

Un messaggio unidirezionale per un pattern dell'app di chat consente a un utente inviare messaggi a un'app di Chat senza L'app Chat risponde ma la richiesta è ancora in fase di elaborazione. Sebbene questa architettura sia tecnicamente possibile, ciò si traduce in un peggioramento delle prestazioni un'esperienza ottimale e scoraggiamo vivamente questo modello.