This chapter helps guide you on your choice of implementation architecture when you develop a Google Chat bot.
This section describes some of the most common architectural approaches used to create bots. See Choosing a service architecture for help deciding which approach is best for your bot.
Google Chat supports integration with bots, but does not implement the bot logic. This logic needs to be implemented in your code, using whatever libraries or services are appropriate to your bot.
Where to instantiate your code, and how it interacts with Google Chat, together form a service architecture. The most commonly used of these are described below.
One of the most common ways that bots are implemented is using a web service or other HTTP implementation in on-premises servers. In this design, you configure Google Chat to integrate with a remote service via HTTP:
This allows the implementation to make use of existing libraries and components that already exist on your system.
If the bot implementations reside behind a firewall, Google Chat may be unable to make HTTP calls to it. One approach to resolving this is to use Google Cloud Pub/Sub—the bot implementation subscribes to a topic that carries messages from Google Chat:
In this arrangement, the bot implementation still must use HTTP for sending messages to Google Chat.
You can create your bot logic entirely in Apps Script. This is especially useful for bots that also integrate with G Suite services. Bots such as this may read and write data using Google Sheets, Slides, Calendar, Drive, and so on.
Consider how an implementation would look not implemented in Apps Script. The HTTP bot integrated with Google Chat and G Suite services would look like this:
It can be much simpler—especially in terms of auth—to implement such a bot using Apps Script, with its built-in G Suite services and implicit auth model.
You can create a bot that just injects messages to a chat room, using calls to the Google Chat REST API. This approach is "hardcoded" to a specific chat room and does not allow user interaction, and this type of bot cannot be shared or published.
Incoming webhooks are best suited for simple, one-off bots to report alerts or status, or for some kinds of bot prototyping.
Bot logic implementation
Google Chat does not constrain the way in which you implement your bot's logic. You can create a simple fixed-syntax command parser, use advanced AI and language processing libraries or services, or anything else appropriate for your particular goals.
Command-driven bots examine the message content of events coming from Google Chat, then extract commands and parameters from this content.
One straightforward approach is to tokenize the message, extract the command, and then reference a dictionary that maps commands to handler functions for each command.
Natural language processing
Many bot implementations use natural language processing (NLP) to determine what the user is asking for. There are many ways to implement NLP, and Google Chat doesn't care which you use.
One powerful and popular service that you can use in your bot implementation is Dialogflow, which lets you create intelligent agents using an intent/action model.
Choosing a service architecture
This section helps to guide you as you decide on a service architecture for your bot.
There are a number of factors that you should consider when deciding on a service architecture. These are each explained in following sections. The section Making the choice helps you choose an architecture based on these aspects.
- Who is the bot for?
- What resources will the bot access?
- What conversational patterns will you implement?
These are each explained in following sections. The section Making the choice helps you choose an architecture based on these aspects.
The bot's audience
There are a number of potential audiences a bot can have. Some examples include the following:
- Your own personal bot
- Just a few people in your workgroup, nobody else
- Install it all around your organization
- Distribute it on the G Suite Marketplace
Access to resources
You should determine what resources your bot will need to access; these resources may include:
- G Suite resources
- Other Google APIs and systems
- External (non-Google) resources
You also should consider how you want your bot to interact with people. The following paragraphs describe some conversation patterns that your bot might implement.
Call and response (synchronous)
In this pattern, the bot responds to messages from users on a one-to-one basis. One user message to the bot results in one response from the bot.
Multiple responses (asynchronous)
This pattern is characterized by two-way communication between users and the bot, with the bot generating any number of additional messages. For example, a user might request something from a bot—the bot should send an initial reply to acknowledge the request—then the bot later sends one or more messages back into the space where the request originated.
One-way from bot
It is sometimes useful to create a bot that injects messages into a space but never receives any events from users. This is not really conversational, but can be useful for things like alarm reporting.
One-way to bot
While it is possible to create a bot that only receives and processes messages without providing any response or message to the people using it, this results in a poor user experience and we strongly discourage this practice.
Making the choice
So which service architecture should you choose for your bot implementation? Of course if you have an existing bot that you want to integrate into Google Chat, you will most likely want to use or adapt your existing implementation.
If you're developing a new bot, the following diagram shows suggested architecture choices for various use cases.