Best practices for deploying Slack Bolt to Google Cloud

Slack Bolt is a framework (available in JavaScript and Python) for building Slack App API servers. When deploying an API server to Google Cloud, Cloud Functions or Cloud Run are potential candidates, but you might run into trouble after deployment if you don't understand Slack's constraints. In this article, I will summarize what you should know before deploying Slack Bolt to Google Cloud.

Conclusion First

If you are deploying Slack Bolt to Google Cloud, I recommend configuring Cloud Run with Always-on CPU allocation!

Slack's Constraints

There are two constraints that you should know.

• If there is no response within 3 seconds, it will be retried.
• For actions and commands, an error will be displayed if there is no response within 3 seconds.

The So-called "3-Second Rule"

First, startup time becomes a bottleneck. Whether it's Cloud Functions or Cloud Run, it's tough to return a response within 3 seconds from a cold start. On the other hand, keeping instances on standby at all times costs money. (If you don't mind the cost, this conversation ends here.)

The problem is that by also processing the retried requests, duplicate processing occurs. For example, in the case of an App that responds to some message, if it also returns a response to the retried request, two responses will be sent for the same message.

The easiest workaround to avoid costs is to ignore retried requests (though reliability decreases slightly). In the case of a retry request, a key called x-slack-retry-num is added to the request header, so you can judge whether it is a retry by checking this.

This article was very clear and helpful. (Thanks, Moko-san)

https://dev.classmethod.jp/articles/slack-resend-matome/

Asynchronous Processing

Another bottleneck is that for actions and commands, an error will occur if a response is not returned within 3 seconds. In Slack Bolt, you return a response by executing ack() in the handler function. While you might want to continue time-consuming processing after returning the response, Cloud Functions and Cloud Run release the CPU once the response is returned, making it impossible to continue processing.

Slack Bolt (Python) has a feature called Lazy listeners for performing asynchronous processing, but please note that this is only supported on AWS Lambda. In other words, if you use Cloud Functions, you need to build your own mechanism to offload asynchronous processing elsewhere. (However, this increases the configuration on Google Cloud and makes local development difficult, so it's not ideal.)

With Cloud Run, if you allocate Always-on CPU, the instance can use the CPU even while it's not processing requests as long as it's running, so simply applying this setting is sufficient.

Conclusion

As I mentioned at the beginning, I recommend deploying to Cloud Run.

While I've focused a bit on the downsides, Slack Bolt itself is very well-made (compared to processing raw webhooks) and significantly reduces implementation effort. I also appreciate its developer-friendly features, such as support for Socket Mode.

Also, if you run into any trouble, I recommend the articles written by @seratch, who is also a developer of Slack Bolt; they are very clear and helpful. (Although the official documentation is very detailed, it can be a bit difficult to understand.)