errbotio / errbot

Errbot is a chatbot, a daemon that connects to your favorite chat service and bring your tools and some fun into the conversation.
http://errbot.io
GNU General Public License v3.0
3.12k stars 614 forks source link

Support for Serverless based deployment (AWS: Lambda + APIGateway) #1547

Closed rams3sh closed 2 years ago

rams3sh commented 2 years ago

I am...

I am running...

Issue description

I have been searching for a bot framework to be used for our internal chatops operations and hit upon errbot. We were planning to host the bot framework as part of AWS lambda and API Gateway since serverless deployment would be cheaper for us , scalable and would have less management overhead.

I just wanted to know if this can be supported by errbot or are there any plans in the roadmap. We are in AWS and we thought of APIGateway for listening to external events and the lambda as a processing entity.

Additional info

I checked on this ticket https://github.com/errbotio/errbot/issues/833 and found that a similar conversation has taken place earlier. However, I wanted to bring this to attention and hence raised a new issue.

sijis commented 2 years ago

I think some of the questions raised are still valid in that prior discussion.

Errbot isn't designed with a serverless architecture. Errbot is actively getting and parsing through all the messages for the configured backend. I'm not sure how running errbot via lambda would work.

An approach I could think of is configuring your chat system to publish all messages to SQS and then have lambda process those messages.

The other approach that comes to mind is to configure a "slash command" (Slack for example) and have that go to an API gateway. That in turn could run errbot within lambda and process that message.

Both of these approaches are untested and theoretical.

rams3sh commented 2 years ago

Hey @sijis

I understand. I was thinking on if there could be a custom mode supported (in case there exists any plan for a serverless roadmap) where errbot need not continously run for listening onto incoming events / messages and instead outsource this part alone to external serverless listeners supported through some sort of pluggable listeners module (api gateway being one example in case of AWS cloud).

With the above idea , Errbot would get invoked and do computation / processing only when an external listener invokes it based on an event received by it, which would probably suit for lambda based deployment. I understand this would probably require good amount of core changes as you had mentioned that errbot wasnt designed with serverless architecture mindset.

Sure, in that case I will close this issue.

Thanks for providing detailed response. Really appreciate it !!