Elige una arquitectura de app de Google Chat

En esta página, se describen los enfoques comunes de la arquitectura de servicios que se usan para crear apps de Google Chat. Si tienes una app existente que deseas integrar en Google Chat, puedes usar o adaptar tu implementación existente. Si estás creando una nueva app de Chat, en esta página se presenta información similar de diferentes maneras para ayudarte a elegir la arquitectura adecuada para tu caso de uso:

Descripción general por funciones y capacidades

En la siguiente tabla, se destacan las funciones y capacidades clave de las apps de chat, así como el estilo de arquitectura de servicio recomendado (). En algunos casos, es posible desarrollar otro estilo de arquitectura con estas características, pero no se adapta tan bien al caso de uso como otros estilos ().

Características y funciones

Servicio web o HTTP

Pub/Sub

Webhooks

Apps Script

AppSheet

Dialogflow

Secuencia de comandos

Público objetivo

Tu equipo

Tu organización

El público

Interactividad del usuario

Usa el procesamiento de lenguaje natural

Patrones de mensajería

Envía y recibe mensajes síncronos

Enviar y recibir mensajes síncronos, y enviar mensajes asíncronos

Solo enviar mensajes asíncronos

Envía mensajes desde un sistema externo a un solo espacio de Chat

Acceder a otros servicios y sistemas

Se integran con otros servicios de Google.

Cómo comunicarse detrás de un firewall

Consulta los eventos de Chat o suscríbete a ellos

Estilos de codificación e implementación

Desarrollo sin código

Desarrollo con poco código

Desarrollo en el lenguaje de programación que elijas

DevOps simplificado

Administración completa de DevOps y CI/CD

Estilos de arquitectura de servicios

En esta sección, se describen algunos de los enfoques de arquitectura más comunes que se usan para crear apps de Chat.

Servicio web o HTTP

Un servicio web o HTTP es la arquitectura que se implementa con mayor frecuencia porque proporciona la mayor flexibilidad para que los desarrolladores compilen apps de Chat públicas. Se recomienda esta arquitectura para los siguientes casos de uso:

  • La app de Chat se implementa para el público en Google Workspace Marketplace.
  • La app de Chat puede enviar y recibir todos los patrones de mensajería: enviar y recibir mensajes síncronos, enviar mensajes asíncronos y enviar mensajes desde un sistema externo.
  • La app de Chat se desarrolla en cualquier lenguaje de programación.
  • La app de Chat requiere una administración completa de DevOps y CI/CD.
  • El servicio de la app de Chat se implementa en servidores locales o en la nube.

En este diseño, configurarás Chat para que se integre con un servicio remoto a través de HTTP, como se muestra en el siguiente diagrama:

Arquitectura de una app de Chat que usa un servicio web en un servidor local.

En el diagrama anterior, un usuario que interactúa con una app de chat HTTP tiene el siguiente flujo de información:

  1. Un usuario envía un mensaje en un espacio de Chat a una app de Chat.
  2. Se envía una solicitud HTTP a un servidor web que es un sistema en la nube o local que contiene la lógica de la app de Chat.
  3. De manera opcional, la lógica de la app de Chat puede interactuar con servicios externos de terceros, como un sistema de administración de proyectos o una herramienta de tickets.
  4. El servidor web envía una respuesta HTTP al servicio de la app de Chat en Chat.
  5. La respuesta se entrega al usuario.
  6. De manera opcional, la app de Chat puede llamar a la API de Chat para publicar mensajes de forma asíncrona o realizar otras operaciones.

Esta arquitectura te brinda la flexibilidad de usar bibliotecas y componentes existentes que ya se encuentran en tu sistema, ya que estas apps de chat se pueden diseñar con diferentes lenguajes de programación. Existen diferentes formas de implementar esta arquitectura. En Google Cloud, puedes usar Cloud Functions, Cloud Run y App Engine. Para comenzar, consulta Cómo compilar una app de Google Chat.

Pub/Sub

Si la app de Chat se implementa detrás de un firewall, Chat no puede realizar llamadas HTTP a ella. Un enfoque es usar Pub/Sub para permitir que la implementación de la app de Chat se suscriba a un tema que contenga mensajes de Chat. Pub/Sub es un servicio de mensajería asíncrona que separa los servicios que producen mensajes de los servicios que procesan esos mensajes. Se recomienda esta arquitectura para los siguientes casos de uso:

  • La app de Chat se compila detrás de un firewall.
  • La app de Chat recibe eventos sobre un espacio de Chat.
  • La app de Chat se implementó en tu organización.
  • La app de Chat puede enviar y recibir mensajes síncronos, y enviar mensajes asíncronos.
  • La app de Chat se desarrolla en cualquier lenguaje de programación.
  • La app de Chat requiere una administración completa de DevOps y CI/CD.

En el siguiente diagrama, se muestra la arquitectura de una app de chat creada con Pub/Sub:

Arquitectura de una app de Chat implementada con Pub/Sub.

En el diagrama anterior, un usuario que interactúa con una app de chat de Pub/Sub tiene el siguiente flujo de información:

  1. Un usuario envía un mensaje en Chat a una app de Chat, ya sea en un mensaje directo o en un espacio de Chat, o bien se produce un evento en un espacio de Chat para el que la app de Chat tiene una suscripción activa.

  2. Chat envía el mensaje a un tema de Pub/Sub.

  3. Un servidor de aplicaciones, es decir, un sistema en la nube o local que contiene la lógica de la app de Chat, se suscribe al tema de Pub/Sub para recibir el mensaje a través del firewall.

  4. De manera opcional, la app de Chat puede llamar a la API de Chat para publicar mensajes de forma asíncrona o realizar otras operaciones.

Para comenzar, consulta Usa Pub/Sub como extremo para tu app de Chat.

Webhooks

Puedes crear una app de Chat que solo pueda enviar mensajes a un espacio específico de Chat si realizas llamadas a una URL de webhook de Chat. Se recomienda esta arquitectura para los siguientes casos de uso:

  • La app de Chat se implementó para tu equipo.
  • La app de Chat envía mensajes desde un sistema externo a un solo espacio de Chat.

Con esta arquitectura, la app de Chat se limita a un espacio de Chat específico y no permite la interacción del usuario, como se muestra en el siguiente diagrama:

Arquitectura de los webhooks entrantes para enviar mensajes asíncronos a Chat.

En el diagrama anterior, una app de Chat tiene el siguiente flujo de información:

  1. La lógica de la app de Chat recibe información de servicios externos de terceros, como un sistema de administración de proyectos o una herramienta de tickets.
  2. La lógica de la app de Chat se aloja en un sistema local o en la nube que puede enviar mensajes a un espacio de Chat específico a través de una URL de webhook.
  3. Los usuarios pueden recibir mensajes de la app de Chat en ese espacio de Chat específico, pero no pueden interactuar con la app de Chat.

Este tipo de app de Chat no se puede compartir en otros espacios de Chat ni con otros equipos, y no se puede publicar en Google Workspace Marketplace. Se recomiendan los webhooks entrantes para que las apps de Chat informen alertas o estados, o para algunos tipos de prototipos de apps de Chat.

Para comenzar, consulta Envía mensajes a Chat con webhooks.

Apps Script

Puedes crear la lógica de tu app de Chat completamente en JavaScript. Google Apps Script es una plataforma de desarrollo con poco código para apps de Chat. Apps Script controla el flujo de autorización y los tokens de OAuth 2.0 para la autenticación de usuarios. Puedes usar Apps Script para compilar apps de Chat públicas, pero no se recomienda debido a las cuotas y los límites diarios.

Se recomienda esta arquitectura para los siguientes casos de uso:

  • La app de Chat se implementa en tu equipo o en tu organización.
  • La app de Chat puede enviar y recibir todos los patrones de mensajería: enviar y recibir mensajes síncronos, enviar mensajes asíncronos y enviar mensajes desde un sistema externo.
  • La app de Chat requiere una administración de DevOps simplificada.

Esta arquitectura es útil para las apps de Chat que también se integran con otros servicios de Google y Google Workspace, como Hojas de cálculo de Google, Presentaciones de Google, Calendario de Google, Google Drive, Google Maps y YouTube, como se muestra en el siguiente diagrama:

Arquitectura de una app de Chat implementada con Apps Script.

En el diagrama anterior, un usuario que interactúa con una app de chat de Apps Script tiene el siguiente flujo de información:

  1. Un usuario envía un mensaje a una app de Chat, ya sea en un mensaje directo o en un espacio de Chat.
  2. La lógica de la app de Chat implementada en Apps Script, que reside en Google Cloud, recibe el mensaje.
  3. De manera opcional, la lógica de la app de Chat puede integrarse con servicios de Google Workspace, como Calendario o Hojas de cálculo, o con otros servicios de Google, como Google Maps o YouTube.
  4. La lógica de la app de Chat envía una respuesta al servicio de la app de Chat en Chat.
  5. La respuesta se entrega al usuario.

Para comenzar, consulta Compila una app de Chat con Apps Script.

AppSheet

Puedes crear una app de Chat compartida en el dominio sin código con AppSheet. Puedes simplificar el proceso de desarrollo usando el modo de configuración automática y siguiendo plantillas para compilar acciones comunes de la app de chat. Sin embargo, algunas funciones de las apps web de AppSheet no están disponibles en las apps de Chat.

Se recomienda esta arquitectura para los siguientes casos de uso:

  • La app de Chat se implementó para ti y tu equipo.
  • La app de Chat puede enviar y recibir mensajes síncronos, y enviar mensajes asíncronos.
  • La app de Chat requiere una administración de DevOps simplificada.

En el siguiente diagrama, se muestra la arquitectura de una app de chat creada con AppSheet:

Arquitectura de una app de Chat implementada con AppSheet.

En el diagrama anterior, un usuario que interactúa con una app de AppSheet Chat tiene el siguiente flujo de información:

  1. Un usuario envía un mensaje en Chat a una app de Chat, ya sea en un mensaje directo o en un espacio de Chat.
  2. La lógica de la app de Chat implementada en AppSheet, que reside en Google Cloud, recibe el mensaje.
  3. De manera opcional, la lógica de la app de Chat puede integrarse con los servicios de Google Workspace, como Apps Script o Hojas de cálculo de Google.
  4. La lógica de la app de Chat envía una respuesta al servicio de la app de Chat en Chat.
  5. La respuesta se entrega al usuario.

Para comenzar, consulta Compila una app de Chat con AppSheet.

Dialogflow

Puedes crear una app de Chat con Dialogflow, una plataforma de lenguaje natural para conversaciones automatizadas y respuestas dinámicas. Se recomienda esta arquitectura para los siguientes casos de uso:

  • La app de Chat puede enviar y recibir mensajes síncronos.
  • La app de Chat usa el procesamiento de lenguaje natural para responder y comunicarse con los usuarios.

En el siguiente diagrama, se muestra la arquitectura de una app de chat creada con Dialogflow:

Arquitectura de una app de chat implementada con Dialogflow.

En el diagrama anterior, un usuario que interactúa con una app de chat de Dialogflow tiene el siguiente flujo de información:

  1. Un usuario envía un mensaje en Chat a una app de Chat, ya sea en un mensaje directo o en un espacio de Chat.
  2. Un agente virtual de Dialogflow, que reside en Google Cloud, recibe y procesa el mensaje para producir una respuesta.
  3. De manera opcional, con un webhook de Dialogflow, el agente de Dialogflow puede interactuar con servicios externos de terceros, como un sistema de administración de proyectos o una herramienta de tickets.
  4. El agente de Dialogflow envía una respuesta al servicio de la app de Chat en Chat.
  5. La respuesta se entrega en el espacio de Chat.

Para comenzar, consulta Cómo compilar una app de Google Chat con Dialogflow.

Aplicación o secuencia de comandos de línea de comandos

Puedes crear una aplicación de línea de comandos o un script que envíe mensajes a Chat o realice otras operaciones, como crear un espacio o administrar a los miembros de un espacio, sin permitir que los usuarios invoquen directamente la app de Chat en Chat ni respondan a ella. Se recomienda esta arquitectura para los siguientes casos de uso:

  • La app de Chat se desarrolla en cualquier lenguaje de programación.
  • La app de Chat solo puede enviar mensajes asíncronos.

En el siguiente diagrama, se muestra la arquitectura:

Arquitectura de una app de Chat implementada con una aplicación de línea de comandos o una secuencia de comandos.

En el diagrama anterior, la app de Chat tiene el siguiente flujo de información:

  1. La app de Chat llama a la API de Chat para enviar un mensaje o realizar otra operación.
  2. Chat ejecuta la operación solicitada.
  3. De manera opcional, la app de Chat imprime una confirmación en la CLI.

Implementación de la lógica de la app de chat

Chat no limita la forma en que implementas la lógica de la app de Chat. Puedes crear un analizador de comandos de sintaxis fija, usar bibliotecas o servicios avanzados de IA y procesamiento del lenguaje, suscribirte a eventos y responder a ellos, o cualquier otra acción que sea adecuada para tus objetivos particulares.

Cómo controlar las interacciones del usuario

La app de chat puede interactuar con los usuarios de varias maneras. Una interacción del usuario es cualquier acción que realiza un usuario para invocar o interactuar con una app de Chat.

Analizador de comandos

Las apps de Chat basadas en comandos examinan la carga útil de los eventos de interacción de la app de Chat y, luego, extraen los comandos y los parámetros de este contenido. Por ejemplo, consulta Cómo responder a los comandos de la app de Google Chat.

Otro enfoque es tokenizar el mensaje, extraer el comando y, luego, hacer referencia a un diccionario que asigne comandos a funciones de controlador para cada comando.

Interfaz de usuario basada en diálogos

Las apps basadas en diálogos responden a los eventos de interacción de la app de Chat mostrando diálogos basados en tarjetas en los que el usuario puede interactuar con la app de Chat, por ejemplo, completar formularios o solicitar acciones.

Cada vez que el usuario ejecuta una acción en un diálogo, se envía un nuevo evento de interacción a la app de Chat, que puede responder actualizando el diálogo o enviando un mensaje.

Procesamiento de lenguaje natural

Muchas implementaciones de la app de Chat usan el procesamiento de lenguaje natural (PLN) para determinar lo que el usuario está preguntando. Hay muchas formas de implementar el PNL, y puedes elegir la que prefieras.

Puedes usar el PNL en la implementación de tu app de Chat con Dialogflow ES o la integración de Chat de Dialogflow CX, que te permite crear agentes virtuales para conversaciones automatizadas y respuestas dinámicas.

Emitir solicitudes de forma proactiva a Chat

Las apps de Chat también pueden enviar mensajes o solicitudes a Chat que no se activan por interacciones directas del usuario en Chat. En cambio, estas apps de Chat se pueden activar, por ejemplo, a través de aplicaciones de terceros o con una invocación de línea de comandos de un usuario, pero los usuarios no pueden interactuar con ellas directamente en Chat.

Las apps de Chat no interactivas usan la API de Chat para enviar mensajes o otros tipos de solicitudes a Chat.

Patrones de conversación

Debes tener en cuenta cómo quieres que tu app de Chat interactúe con los usuarios. En las siguientes secciones, se describen los patrones de conversación que podría implementar tu app de Chat.

Llamada y respuesta (síncrona)

En un patrón de llamada y respuesta síncronos, la app de Chat responde a los mensajes de los usuarios de forma individual. Un mensaje que un usuario envía a la app de Chat genera una respuesta de la app de Chat, como se muestra en el siguiente diagrama:

Arquitectura de un mensaje síncrono.

En el diagrama anterior, un usuario que interactúa con una app de chat tiene el siguiente flujo de información:

  1. Un usuario envía un mensaje síncrono a una app de Chat, por ejemplo, "¿Cuál es mi próxima reunión?".
  2. La app de Chat envía un mensaje síncrono al usuario, por ejemplo, "Dra. Silva a las 2:30".

Para este tipo de patrón conversacional, puedes implementar una arquitectura de app de chat con un servicio web, Pub/Sub, Apps Script, AppSheet o Dialogflow.

Varias respuestas (asíncronas)

El patrón de respuestas múltiples puede incluir mensajes síncronos y asíncronos. Este patrón se caracteriza por la comunicación bidireccional entre los usuarios y la app de Chat, en la que la app de Chat genera la cantidad de mensajes adicionales que sean necesarios, como se muestra en el siguiente diagrama:

Arquitectura de un mensaje asíncrono.

En el diagrama anterior, un usuario que interactúa con una app de chat tiene el siguiente flujo de información:

  1. Un usuario envía un mensaje síncrono a una app de chat, por ejemplo, "Supervisa el tráfico".
  2. La app de Chat envía un mensaje síncrono al usuario para confirmar la solicitud, por ejemplo, "Monitoreo activado".
  3. Más adelante, la app de Chat envía uno o más mensajes asíncronos al usuario llamando a la API de REST, por ejemplo, "Tráfico nuevo".
  4. El usuario envía un mensaje síncrono adicional a la app de Chat, por ejemplo, "Ignora el tráfico".
  5. La app de Chat envía un mensaje síncrono al usuario para confirmar la solicitud, por ejemplo, "Se desactivó el monitoreo".

Para este tipo de patrón conversacional, puedes implementar una arquitectura de app de chat con un servicio web, Pub/Sub, Apps Script o AppSheet.

Consultar o suscribirse a eventos (asíncrono)

En un patrón asíncrono basado en eventos, la app de Chat recibe eventos consultando la API de Chat o creando una suscripción a un espacio o usuario de Chat con la API de Google Workspace Events. Los eventos representan cambios en los recursos de Chat, como cuando se publica un mensaje nuevo o cuando un usuario se une a un espacio. Las apps de Chat controladas por eventos examinan la carga útil del evento para obtener datos sobre el recurso de Chat modificado y, luego, responden según corresponda.

Las apps de Chat pueden recibir muchos tipos de eventos, incluidos eventos sobre espacios, membresías, mensajes y reacciones. Cuando una app de Chat recibe un evento a través de una consulta a la API de Chat o mediante una suscripción activa, puede generar de forma opcional cualquier cantidad de respuestas asíncronas, que luego envía a Chat a través de la API de Chat.

Puedes usar este tipo de lógica para actualizar sistemas externos, como un sistema de administración de tickets, o enviar mensajes a un espacio de Chat de forma asíncrona, por ejemplo, enviando un mensaje de bienvenida cuando un usuario nuevo se une a un espacio de Chat.

En el siguiente diagrama, se muestra un ejemplo de un patrón de conversación basado en eventos:

Arquitectura de una suscripción a eventos de Chat

En el diagrama anterior, la interacción entre Chat y la app de Chat tiene el siguiente flujo de información:

  1. La app de Chat se suscribe a un espacio de Google Chat.
  2. Cambia el espacio al que está suscrita la app de Chat.
  3. La app de Chat entrega un evento a un tema en Pub/Sub, que funciona como el extremo de notificación para la suscripción. El evento contiene datos sobre lo que cambió en el recurso.
  4. La app de Chat procesa el mensaje de Pub/Sub que contiene el evento y, si es necesario, toma medidas.

Para este tipo de patrón conversacional, puedes implementar una arquitectura de app de chat con Pub/Sub, un servicio web o Apps Script.

Para obtener más información sobre cómo recibir eventos y responder a ellos, consulta Trabaja con eventos de la API de Google Chat.

Mensaje unidireccional de una app de Chat

Un patrón de app de Chat de mensajes unidireccionales permite que una app de Chat envíe mensajes asíncronos a un espacio de Chat, pero no permite que los usuarios interactúen directamente con la app de Chat. Este patrón no es conversacional ni interactivo, pero puede ser útil para tareas como la notificación de alarmas, como se muestra en el siguiente diagrama:

Arquitectura de un mensaje unidireccional.

En el diagrama anterior, un usuario que se encuentra en el mismo espacio que la app de Chat tiene el siguiente flujo de información:

  • La app de Chat envía un mensaje asíncrono al usuario llamando a la API de Chat o publicando en una URL de webhook, por ejemplo, "Alerta de desbordamiento de la cola".
  • De manera opcional, la app de Chat envía mensajes asíncronos adicionales.

Para este tipo de patrón conversacional, puedes implementar una arquitectura de app de chat con un servicio web, un webhook, Apps Script, AppSheet, una aplicación de línea de comandos o una secuencia de comandos.

Mensaje unidireccional a una app de Chat

Un patrón de mensaje unidireccional a una app de Chat permite que un usuario le envíe un mensaje a una app de Chat sin que esta responda mientras procesa la solicitud. Si bien esta arquitectura es técnicamente posible, genera una mala experiencia del usuario, por lo que desaconsejamos este patrón.