slackapi / bolt-python

A framework to build Slack apps using Python
https://slack.dev/bolt-python/
MIT License
1.02k stars 236 forks source link

Are there any practices to make the slack app code scalable? #1095

Closed dvrshi closed 3 weeks ago

dvrshi commented 3 weeks ago

Hey guys, I have developed a slack app that handles that handles functionalities like answering NLP queries, and fetching certain data from my MongoDB and processing that data in textual format and showing to users. My question is, the code I have written is by following the documentation and tutorials I have found for slack bolt framework online. Which includes an Installation Store for handling app installations, events that handle messages, commands etc. Now during development and testing phase, I am using two accounts at max to test the applications. But how do I figure out the scalable part? Like we need to handle the app being used by 100s of users, do I need to implement a queue system or something else that ensure when my LLM query endpoint doesn't get bombarded with message events? If any one can explain how to handle this, considering my app will make multiple external API calls for the features I am implementing. This question may not even be slack-bolt related, but I want to understand how it works.

filmaj commented 3 weeks ago

This question is certainly not SDK or Slack specific. It all Depends ™️ on what your app is doing, what external services it relies on, the performance profiles of all the system components, and the constraints that you have to operate within Slack. If your event handler is lean and fast, then maybe a single instance of the application with no queue is sufficient. If each event handler is doing heavy operations, perhaps not. A Slack app is like any other app in terms of scalability: you could run multiple instances of it behind a load balancer, you could throw more hardware at it, and so on.

Queues are a good idea if you expect a lot of events coming your way. If your handler is doing a lot of I/O or relies on different external services, then that drags down how performant your handler can be. Recall that typically Slack requires apps to answer to events within 3 seconds - that is a key constraint that your app has to operate within. One resilient pattern could be to respond to events right away (e.g. the ack method you see across the Bolt framework), and then place the payload, or a parsed version of the payload, into a queue for your system to process at a later date.

Hope that's helpful, but I will close this issue down as there is no Bolt Python specific issue here.