Архитектуры реализации чат-приложений

Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

Эта глава поможет вам выбрать архитектуру реализации при разработке приложения Google Chat.

Стили архитектуры

В этом разделе описываются некоторые из наиболее распространенных архитектурных подходов, используемых для создания приложений. См. Выбор архитектуры службы, чтобы решить, какой подход лучше всего подходит для ваших приложений.

Сервисная архитектура

Google Chat поддерживает интеграцию с приложением, но не реализует логику приложения. Эта логика должна быть реализована в вашем коде с использованием любых библиотек или служб, подходящих для вашего приложения.

Где создавать экземпляр вашего кода и как он взаимодействует с Google Chat, вместе формируют архитектуру службы. Наиболее часто используемые из них описаны ниже.

веб-сервис

Одним из наиболее распространенных способов реализации приложений является использование веб-службы или другой реализации HTTP на локальных серверах. В этом дизайне вы настраиваете Google Chat для интеграции с удаленным сервисом через HTTP:

Это позволяет реализации использовать существующие библиотеки и компоненты, которые уже существуют в вашей системе.

Облачный паб/саб

Если реализация приложения находится за брандмауэром, Google Chat не сможет выполнять HTTP-запросы к нему. Одним из подходов к решению этой проблемы является использование Google Cloud Pub/Sub — реализация приложения подписывается на тему, в которой передаются сообщения из Google Chat:

При таком расположении реализация приложения по-прежнему должна использовать HTTP для отправки сообщений в Google Chat.

Скрипт приложений

Вы можете полностью создать логику приложения в Apps Script. Это особенно полезно для приложений, которые также интегрируются со службами Google Workspace. Такие приложения могут считывать и записывать данные с помощью Google Sheets, Slides, Calendar, Drive и т. д.

Подумайте, как будет выглядеть реализация, не реализованная в Apps Script. HTTP-бот, интегрированный с сервисами Google Chat и Google Workspace , будет выглядеть так:

Может быть намного проще — особенно с точки зрения аутентификации — реализовать такое приложение с помощью Apps Script со встроенными службамиGoogle Workspace и неявной моделью аутентификации.

Входящие вебхуки

Вы можете создать приложение, которое просто вводит сообщения в пространство чата, используя вызовы REST API Google Chat. Этот подход «жестко запрограммирован» для определенного пространства чата и не допускает взаимодействия с пользователем, а приложением этого типа нельзя делиться или публиковать.

Входящие веб-перехватчики лучше всего подходят для простых одноразовых приложений, чтобы сообщать о предупреждениях или статусе, или для некоторых видов прототипирования приложений.

Реализация логики приложения

Google Chat не ограничивает способ реализации логики вашего приложения. Вы можете создать простой синтаксический анализатор команд с фиксированным синтаксисом, использовать расширенные библиотеки или сервисы для обработки ИИ и языка или что-либо еще, подходящее для ваших конкретных целей.

Парсер команд

Приложения, управляемые командами, проверяют содержимое сообщений о событиях, поступающих из Google Chat, а затем извлекают из этого содержимого команды и параметры.

Один из простых подходов состоит в том, чтобы разметить сообщение, извлечь команду, а затем сослаться на словарь, который сопоставляет команды с функциями обработчика для каждой команды.

Обработка естественного языка

Многие реализации приложений используют обработку естественного языка (NLP), чтобы определить, что запрашивает пользователь. Существует множество способов реализации НЛП, и Google Chat не имеет значения, какой из них вы используете.

Одним из мощных и популярных сервисов, которые вы можете использовать в реализации своего приложения, является Dialogflow , который позволяет создавать интеллектуальных агентов с использованием модели намерения/действия.

Выбор сервисной архитектуры

Этот раздел поможет вам определиться с архитектурой сервиса для вашего приложения.

Общие Соображения

Существует ряд факторов, которые следует учитывать при выборе архитектуры службы. Каждый из них объясняется в следующих разделах. Раздел «Выбор» поможет вам выбрать архитектуру на основе этих аспектов.

  • Для кого предназначено приложение?
  • К каким ресурсам будет обращаться приложение?
  • Какие разговорные модели вы будете использовать?

Каждый из них объясняется в следующих разделах. Раздел «Выбор» поможет вам выбрать архитектуру на основе этих аспектов.

Аудитория приложения

У приложения может быть несколько потенциальных аудиторий. Некоторые примеры включают следующее:

  • Ваше личное приложение
  • Всего несколько человек в вашей рабочей группе, больше никто
  • Установите его по всей организации
  • Распространите его на Google Workspace .

Доступ к ресурсам

Вы должны определить, к каким ресурсам потребуется доступ вашему приложению; эти ресурсы могут включать:

  • Google Workspace ресурсов
  • Другие API и системы Google
  • Внешние (не Google) ресурсы

Разговорные модели

Вы также должны подумать о том, как вы хотите, чтобы ваше приложение взаимодействовало с людьми. В следующих абзацах описываются некоторые шаблоны диалога, которые может реализовать ваше приложение.

Звонок и ответ (синхронно)

В этом шаблоне приложение отвечает на сообщения от пользователей индивидуально. Одно сообщение пользователя приложению приводит к одному ответу от приложения.

Множественные ответы (асинхронные)

Этот шаблон характеризуется двусторонней связью между пользователями и приложением, при этом приложение генерирует любое количество дополнительных сообщений. Например, пользователь может запросить что-то у приложения — приложение должно отправить первоначальный ответ, чтобы подтвердить запрос — затем приложение позже отправляет одно или несколько сообщений обратно в пространство, откуда был отправлен запрос.

В одну сторону из приложения

Иногда полезно создать приложение, которое вводит сообщения в пространство, но никогда не получает никаких событий от пользователей. На самом деле это не диалог, но может быть полезно для таких вещей, как оповещение о тревоге.

Односторонний доступ к приложению

Хотя можно создать приложение, которое только получает и обрабатывает сообщения, не предоставляя какой-либо ответ или сообщение людям, использующим его, это приводит к плохому взаимодействию с пользователем, и мы настоятельно не рекомендуем такую ​​практику.

Делая выбор

Итак, какую сервисную архитектуру следует выбрать для реализации вашего приложения? Конечно, если у вас есть существующее приложение, которое вы хотите интегрировать в Google Chat, вы, скорее всего, захотите использовать или адаптировать существующую реализацию.

Если вы разрабатываете новое приложение, на следующей диаграмме показаны рекомендуемые варианты архитектуры для различных вариантов использования.