There are a number of different approaches to creating an app for Google Chat. Which is the most appropriate for your app depends on what your app will do, along with some technical constraints that might apply to your situation.
Interaction pattern
Start by identifying a suitable interaction pattern for your app. Here's a set of interaction patterns, in increasing order of complexity:
| Pattern | Description |
|---|---|
| Notifications only | Apps in this category are not conversational; they simply inject messages (alarms, state change notifications, etc.) into a space. |
| Fetching data with simple commands | These apps typically have a one-in, one-out message pattern. A message to the app triggers some kind of lookup and a response to send the resulting data into the space. |
| Starting external processes with simple commands | The conversational complexity of these apps depend on the nature of the process they initiate. Typically these respond synchronously to a command, but also inject asynchronous updates as a result of process execution. |
| Smart agents that combine internal systems together | These are the most complex of apps, often involving NLP and integration with multiple external systems. |
Endpoint type
Depending on the usage pattern and your deployment needs, you also need to decide on an endpoint type. Here's a summary of endpoint types and their suggested uses:
| Endpoint type | Pub? | Application | Authentication |
|---|---|---|---|
| Incoming webhook | — | Not a true endpoint, but a simple way to build one-off notifiers that are "hardwired" to a specific chat room. | None |
| Apps Script | — | Straightforward way to build a simple app for yourself, team, or domain. | None |
| Synchronous HTTP | ✔ | Easy way to build an app that you want the world to use, if the app never needs to respond asynchronously. | None |
| Asynchronous HTTP | ✔ | Standard way to build an app that you want the world to use. | Service account |
| Cloud Pub/sub | ✔ | Best for connecting to an internal system that is behind a firewall. | Service account |
Additional considerations
This section lists the main things you should consider when defining how your app will work with Google Chat. These are described in detail in following sections.
Security
There may be security mechanisms you need to accommodate when connecting your app implementation to Google Chat:
- Is your app's implementation behind a firewall? Use a Cloud Pub/Sub endpoint.
- Does your app's HTTP endpoint use OAuth?
- Does your app's implementation need to access protected resources? You'll need to set up third-party authentication.
- Will your app send unsolicited messages? Your app will need a service account.
Publishability
If you want to publish your app in the Google Workspace Google Workspace Marketplace, you will need to use an HTTP or Cloud Pub/Sub endpoint.
If you just want a quick app for you or your workgroup to use, and you're not using an existing remote implementation, you can write the app directly in Apps Script. This doesn't require any authentication (since Apps Scripts always run in the context of an authorized user).
Service accounts
Apps that asynchronously inject messages do so using the Google Chat REST API. To make calls the this API, apps must authenticate using a service account.
Some apps don't fall into this category:
- Apps Script apps
- Incoming webhooks notifiers
- Simple, synchronous HTTP apps that only send information back in the HTTP POST response.
Simple synchronous HTTP apps
Other types of apps
All other apps, unless they are implemented in Apps Script, need to use service accounts so that they can authenticate their inbound messages.
System architectures
This section describes several of the key architectures used to implement Chat apps for Google Chat, using the endpoint types described above.
Simple notifier
The simple notifier is not a conversational Chat app, and doesn't support messages from users to the app. It simply allows an application to inject messages into a chat room.
This pattern uses an incoming webhook to inject messages into the space. It does not use a developer console project or a service account, so it cannot be published and added to various spaces. However, for one-off notifiers built for a single Chat space, it is quick to implement.
Basic synchronous HTTP
This is the standard architecture for a one-in, one-out conversational app. It doesn't use a service account; this is because its responses are always carried by the HTTP response to the originating HTTP POST message.
Many simple apps can be implemented using this architecture, and they can be registered so that they can be discovered and added to other chat rooms.
Asynchronous HTTP
This pattern allows HTTP-based apps to respond asynchronously to user messages or other triggers.
This pattern is slightly more complex to set up than the synchronous version, but is adaptable to a large range of app requirements.
Cloud Pub/Sub
This pattern is well suited to systems where the app implementation is behind a firewall. Instead of Google Chat attempting to traverse the firewall, part of the implementation is an event subscriber and "pulls" the messages from the Pub/Sub topic.
Note that there is no mechanism for responding through the Pub/Sub mechanism. The app must respond asynchronously in the same way as the async HTTP pattern.