Elige una arquitectura de app de Google Chat

En esta página, se describen los enfoques comunes de la arquitectura de servicio que se usan para crear apps de Google Chat. Si tienes una app existente que quieres integrar en Google Chat, puedes usar o adaptar la implementación existente. Si estás compilando 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 y el estilo de arquitectura de servicio recomendado (). En algunos casos, es posible desarrollar otro estilo de arquitectura con estas funciones, pero no es una opción tan adecuada para el caso de uso como otros diseños ().

Características y funciones

Servicio web o HTTP

Pub/Sub

Webhooks

Apps Script

AppSheet

Dialogflow

Script

Público objetivo

Tu equipo

Tu organización

El público

Interactividad del usuario

Usa procesamiento de lenguaje natural

Patrones de mensajes

Envía y recibe mensajes síncronos

Envía y recibe mensajes síncronos, así como mensajes asíncronos

Envía solo mensajes asíncronos

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

Acceder a otros servicios y sistemas

Permiten la integración con otros servicios de Google

Cómo comunicarse detrás de un firewall

Suscríbete a eventos de Google Workspace

Estilos de implementación y programación

Desarrollo sin código

Desarrollo con poco código

Desarrollo en un lenguaje de programación de tu elección

DevOps simplificados

Administración completa de DevOps y CI/CD

Estilos de arquitectura de servicio

En esta sección, se describen algunos de los enfoques arquitectónicos 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 más frecuencia porque proporciona la mayor flexibilidad a los desarrolladores para compilar apps de Chat públicas. Esta arquitectura se recomienda para los siguientes casos prácticos:

  • La app de Chat se implementa de forma pública 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, configuras Chat para integrarlo en un servicio remoto mediante HTTP, como se muestra en el siguiente diagrama:

Arquitectura de una app de Chat mediante 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 local o en la nube 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 proporciona la flexibilidad para usar las bibliotecas y los componentes existentes 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 Compila una app de Google Chat con Cloud Functions.

Pub/Sub

Si la app de Chat se implementa detrás de un firewall, Chat no podrá realizarle llamadas HTTP. 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 aquellos que los procesan. Esta arquitectura se recomienda para los siguientes casos prácticos:

  • La app de Chat se compila detrás de un firewall.
  • La app de Chat recibe eventos sobre un espacio de Chat.
  • Se implementó la app de Chat en tu organización.
  • La app de Chat puede enviar y recibir mensajes síncronos, así como 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 compilada 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 un evento en un espacio de Chat en 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, que es un sistema local o en la nube 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 de Chat específico mediante llamadas a una URL de webhook de Chat. Esta arquitectura se recomienda para los siguientes casos de uso:

  • Se implementó la app de Chat en 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 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 generación 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 mediante una URL de webhook a un espacio de Chat específico.
  3. Los usuarios pueden recibir mensajes de la app de Chat en ese espacio específico de Chat, pero no pueden interactuar con ella.

Este tipo de app de Chat no se puede compartir en otros espacios de Chat ni con otros equipos, ni se puede publicar en Google Workspace Marketplace. Se recomiendan los webhooks entrantes para que las apps de Chat generen informes sobre alertas o estados, o para algunos tipos de prototipado 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 por completo 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 del usuario. Puedes usar Apps Script a fin de compilar apps de Chat públicas, pero no se recomienda debido a las cuotas y límites diarios.

Esta arquitectura se recomienda 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 en otros servicios de Google Workspace y Google, 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 que se implementa en Apps Script, que reside en Google Cloud, recibe el mensaje.
  3. De manera opcional, la lógica de la app de Chat se puede integrar en los servicios de Google Workspace, como Hojas de cálculo o Calendario, o bien 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 de dominio sin código con AppSheet. Puedes simplificar el proceso de desarrollo con el modo de configuración automática y las plantillas que se indican a continuación para compilar acciones comunes de la app de Chat. Sin embargo, algunas funciones de la aplicación web de AppSheet no están disponibles en las apps de Chat.

Esta arquitectura se recomienda para los siguientes casos de uso:

  • La app de Chat se implementa para ti y tu equipo.
  • La app de Chat puede enviar y recibir mensajes síncronos, así como 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 compilada con AppSheet:

Arquitectura de una app de Chat implementada con AppSheet

En el diagrama anterior, un usuario que interactúa con una app de Chat de AppSheet presenta 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 que se implementa en AppSheet, que reside en Google Cloud, recibe el mensaje.
  3. De manera opcional, la lógica de la app de Chat se puede integrar en 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. Esta arquitectura se recomienda para los siguientes casos de uso:

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

En el siguiente diagrama, se muestra la arquitectura de una app de Chat compilada 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, 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 agente de Dialogflow envía una respuesta al servicio de la app de Chat en Chat.
  5. La respuesta se entrega al usuario.

Para comenzar, consulta Integración de chat de Dialogflow ES o Integración de chat de Dialogflow CX.

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

Puedes crear una aplicación de línea de comandos o una secuencia de comandos que envíe mensajes a Chat o realice otras operaciones, como crear un espacio o administrar sus miembros, sin permitir que los usuarios invoquen o respondan directamente a la app de Chat en Chat. Esta arquitectura se recomienda para los siguientes casos prácticos:

  • 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 lógica de la app de chat

Chat no restringe 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 de lenguaje, suscribirte y responder eventos o cualquier otra opción adecuada para tus objetivos particulares.

Cómo controlar las interacciones del usuario

La app de Chat puede recibir y responder a las interacciones del usuario de varias maneras. Una interacción del usuario es cualquier acción que un usuario realiza para invocar una app de Chat o interactuar con ella.

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 comandos y parámetros de este contenido. Por ejemplo, consulta Configura comandos de barra para interactuar con usuarios de Chat.

Otro enfoque es asignar tokens al mensaje, extraer el comando y, luego, hacer referencia a un diccionario que asigne comandos a las funciones del 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 con 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 apps de chat usan procesamiento de lenguaje natural (PLN) para determinar qué solicita el usuario. Existen muchas formas de implementar el PLN, y puedes elegir hacerlo como prefieras.

Puedes usar PLN 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.

Enviar solicitudes de forma proactiva a Chat

Las apps de Chat también pueden enviar mensajes y otras solicitudes a Chat, que no se activan mediante interacciones directas del usuario en Chat. En su lugar, estas apps de Chat se pueden activar, por ejemplo, a través de aplicaciones de terceros o mediante 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 y otros tipos de solicitudes a Chat.

Patrones de conversación

Debes considerar 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 puede implementar tu app de Chat.

Llamada y respuesta (síncrono)

En un patrón de llamada y respuesta síncrona, 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 desde 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, "Dr. Silva a las 2:30".

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

Respuestas múltiples (asíncronas)

El patrón de respuestas múltiples puede incluir mensajes síncronos y asíncronos. Este patrón se caracteriza por una comunicación bidireccional entre los usuarios y la app de Chat, en la que esta genera cualquier cantidad de mensajes adicionales, 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, “Supervisión activada”.
  3. Luego, la app de Chat envía uno o más mensajes asíncronos al usuario mediante una llamada 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, “Ignorar tráfico”.
  5. La app de Chat envía un mensaje síncrono al usuario para confirmar la solicitud, por ejemplo, “Monitoring desactivado”.

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

Suscribirse a eventos (asíncrono)

En un patrón asíncrono controlado por eventos, la app de Chat se suscribe a los eventos con la API de eventos de Google Workspace. Las apps de Chat controladas por eventos examinan la carga útil de los eventos de suscripción de Chat y, luego, responden según el tipo de evento. Cuando se produce un evento en un espacio de Chat, en el que la app de Chat tiene una suscripción activa, Chat envía el evento a la app de Chat. De manera opcional, esta app puede generar cualquier cantidad de respuestas asíncronas, que las envía de vuelta a Chat mediante 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, con un mensaje de bienvenida cuando un usuario nuevo se une a un espacio de Chat.

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

Arquitectura de un mensaje controlado por eventos.

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 sirve 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 de conversación, puedes implementar una arquitectura de app de Chat mediante Pub/Sub.

Mensaje unidireccional desde la app de Chat

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

Arquitectura de un mensaje unidireccional.

En el diagrama anterior, un usuario 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 mediante una llamada a la API de Chat o una publicación en una URL de webhook, por ejemplo, “Alerta de desbordamiento de cola”.
  • De manera opcional, la app de Chat envía mensajes asíncronos adicionales.

Para este tipo de patrón de conversación, puedes implementar una arquitectura de app de Chat mediante 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 mensaje unidireccional para un patrón de app de Chat permite que un usuario envíe un mensaje a una app de Chat sin que esta responda mientras se procesa la solicitud. Si bien esta arquitectura es técnicamente posible, esto da como resultado una experiencia del usuario deficiente y no recomendamos este patrón.