This chapter helps guide you on your choice of implementation architecture when you develop a Google Chat app.
Architecture styles
This section describes some of the most common architectural approaches used to create apps. See Choosing a service architecture for help deciding which approach is best for your apps.
Service architecture
Google Chat supports integration with app, but does not implement the app logic. This logic needs to be implemented in your code, using whatever libraries or services are appropriate to your app.
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.
Web service
One of the most common ways that apps 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.
Cloud Pub/Sub
If the app 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 app implementation subscribes to a topic that carries messages from Google Chat:
In this arrangement, the app implementation still must use HTTP for sending messages to Google Chat.
Apps Script
You can create your app logic entirely in Apps Script. This is especially useful for apps that also integrate with Google Workspace services. Apps 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 Google Workspace services would look like this:
It can be much simpler—especially in terms of auth—to implement such an app using Apps Script, with its built-in Google Workspace services and implicit auth model.
Incoming webhooks
You can create an app that just injects messages to a chat space, using calls to the Google Chat API. This approach is "hardcoded" to a specific chat space and does not allow user interaction, and this type of app cannot be shared or published.
Incoming webhooks are best suited for simple, one-off apps to report alerts or status, or for some kinds of app prototyping.
App logic implementation
Google Chat does not constrain the way in which you implement your app'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 parser
Command-driven apps examine the payload of Chat app interaction events, 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 app 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 app 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 app.
General considerations
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 app for?
- What resources will the app 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 app's audience
There are a number of potential audiences an app can have. Some examples include the following:
- Your own personal app
- Just a few people in your workgroup, nobody else
- Install it all around your organization
- Distribute it on the Marketplace
Access to resources
You should determine what resources your app will need to access; these resources may include:
- Google Workspace resources
- Other Google APIs and systems
- External (non-Google) resources
Conversational patterns
You also should consider how you want your app to interact with people. The following paragraphs describe some conversation patterns that your app might implement.
Call and response (synchronous)
In this pattern, the app responds to messages from users on a one-to-one basis. One user message to the app results in one response from the app.
Multiple responses (asynchronous)
This pattern is characterized by two-way communication between users and the app, with the app generating any number of additional messages. For example, a user might request something from a app—the app should send an initial reply to acknowledge the request—then the app later sends one or more messages back into the space where the request originated.
One-way from app
It's sometimes useful to create a Chat app that injects messages into a space but doesn't let users interact directly with the Chat app. This is not really conversational, but can be useful for things like alarm reporting.
One-way to app
While it is possible to create an app 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 app implementation? Of course if you have an existing app 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 app, the following diagram shows suggested architecture choices for various use cases.
