[HN Gopher] Show HN: A framework for building Slack bots in Python
       ___________________________________________________________________
        
       Show HN: A framework for building Slack bots in Python
        
       I started building a couple of years ago because I found no easy
       existing solution to build Slack bots that can be composed
       from/organized into plugins. Existing libraries like Bolt make it
       pretty easy to develop Slack bots, but hard to organize and scale
       the code base of your bot. I was also missing some crucial features
       such as scheduling actions for your bot. So I wrote my own
       framework!  I recently rewrote the complete framework to make use
       of asyncio and the newest Slack SDK  Let me know what you think!
        
       Author : DandyDev
       Score  : 86 points
       Date   : 2022-09-16 14:17 UTC (8 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | tanepiper wrote:
       | This looks really nice, I've been looking for something to build
       | a bot.
        
       | Noumenon72 wrote:
       | Leading with "wonderful" confused me a little. I was expecting "X
       | is a wonderful project. Here is a new project built on X." When
       | introducing your own project, your subjective praise for it
       | doesn't add as much. I would drop the "wonderful".
        
         | DandyDev wrote:
         | I think you make a good point. I removed that word from the
         | description.
        
       | bkanuka wrote:
       | I really like the API and decorators! What I don't see in the
       | documentation is how to respond to events from _outside_ Slack
       | Machine. For example an external message queue.
       | 
       | I suppose I could look into writing a coroutine that listens for
       | messages on a queue and then runs the `emit()` from SM - just not
       | clear to me if that's the "right way".
        
         | DandyDev wrote:
         | That is an interesting use case! The solution you propose,
         | could work.
         | 
         | I've also been meaning to add support for webhooks as well, so
         | you could trigger plugin functions by calling an HTTP endpoint.
         | It's a small step from having messages on a queue and
         | triggering webhooks from them.
        
           | bkanuka wrote:
           | Yes a webhook could work!
        
       | shabbatt wrote:
       | How does one monetize and sell slack bots, is it even done?
        
         | dijit wrote:
         | If you're trying to get a `worse than zulip` experience but
         | really like threads then your only option is a paid bot called
         | Smithy: https://smithy.app
         | 
         | So at least someone is making money from bots.
        
         | turtlebits wrote:
         | Slack workflows are pretty powerful, and there is definitely a
         | gap in available actions (steps).
        
         | zoover2020 wrote:
         | I'd argue it's more about service or API integration.
         | 
         | People are willing to pay for solid solutions as long as you
         | can add value
         | 
         | For instance, let's say PagerDuty did not have Slack
         | integration. If you decide to build the glue that connects both
         | you already have a ton of potential clients as they don't want
         | to invest money themselves etc.
        
       | dijit wrote:
       | Interesting Project.
       | 
       | I'm sure you're aware of Errbot
       | (https://github.com/errbotio/errbot), though not specifically
       | designed with slack in mind: I have had excellent success with
       | this framework.
       | 
       | How does slack-machine compare?
       | 
       | PS: Please forgive the naive question, I'm about the board a
       | flight and don't see anything mentioned or anything radically
       | different about the stated goals.
        
         | DandyDev wrote:
         | It's not a naive question at all! The 2 biggest differences I
         | can see:
         | 
         | - Errbot being chat service agnostic, also makes it feel a bit
         | "non-native" for Slack. For example, you cannot say "@mybot
         | deploy webapp to production", but you have to say "!mybot
         | deploy webapp to production". slack-machine can work that way
         | as well (with command prefixes like ! or %), but it also
         | responds to actual mentions (@mybot). There are more
         | differences like that, where Errbot tries to be agnostic of the
         | chat service it's running against, but that also means it has
         | to cater to the lowest common denominator in terms of
         | integration with a chat service. slack-machine can for example
         | add "reactions" to messages, which Errbot cannot.
         | 
         | - slack-machine seems more feature-rich. Errbot seems to be
         | focused only on commands that are triggered by sending certain
         | chat messages. slack-machine lets you listen to any type of
         | event Slack emits. Examples could be: someone joins a channel,
         | a reaction is added to a message, a message is pinned. slack-
         | machine also has built-in scheduling to trigger plugin
         | functions on a cron-like schedule (Errbot has something similar
         | with pollers, but it's not as flexible as a cron schedule)
         | 
         | For me it was a clear design choice to focus only on Slack, so
         | the bots you build with it feel as "integrated" as possible
         | with Slack. You can really leverage all that the Slack API has
         | to offer.
        
       | rcarmo wrote:
       | I especially like that it uses sockets and not an open HTTP
       | endpoint. I've been messing about with Slack bots for a while and
       | will certainly give this a look.
        
       | jtwaleson wrote:
       | How do you deploy this? I want to run slack bots on 0 running
       | costs where possible.
        
         | DandyDev wrote:
         | Anywhere you can run Python code basically. Sadly, with the
         | decline of Heroku, I don't know of any places you can run
         | Python code 24/7 for free.
         | 
         | Myself, I run Slack bots on AWS inside a Docker container on
         | ECS (for $day_job) and inside a Docker container on my Synology
         | for personal use.
        
           | jtwaleson wrote:
           | I created a micro framework for slack bots that can be
           | deployed to Lambda here:
           | https://github.com/jtwaleson/minimalistic-serverless-
           | slack-a...
           | 
           | It's probably a lot less rich than your solution, but feel
           | free to look at it you want to run on serverless.
        
           | mritchie712 wrote:
           | You could probably use Cloud Run (it will run a python docker
           | container), it scales to 0
        
           | icey wrote:
           | Maybe fly.io? They have a pretty generous free tier.
        
           | seabrookmx wrote:
           | Google Compute Engine has a free tier. The developer
           | experience isn't nearly as smooth as Heroku though.
        
         | drhayes9 wrote:
         | I've been having fun using fly.io for a Telegram bot (listens
         | on an HTTPS endpoint like a Slack bot, if I remember right).
         | Has cost me $0 for my hobbyist bot that is only used by me.
        
         | aquajet wrote:
         | I'm sure you can set up a raspi to deploy this with minimal
         | running costs.
        
       | pbreit wrote:
       | Has anyone ever found a bot-generated message in Slack to be
       | useful?
        
         | Noumenon72 wrote:
         | Weekly reminder to fill out a report is nice. I would like
         | Jenkins to send me a Slack message when my build fails.
        
         | semitones wrote:
         | We have a slackbot that announces when a new customer signs up
         | for our service, with some info on them and links to view them
         | in our admin dashboard + third-party apps. Also, once our app
         | hears back from a third-party fraud-protection API, the
         | slackbot will reply to the message with info on the result, and
         | will also react to the announcement message with an appropriate
         | emoji :) Helps out our support staff a bunch, reduces the
         | surface area of the things they have to consistently look at.
         | 
         | It's very useful for us right now at our current scale. Should
         | we start getting an inordinate amount of new signups everyday,
         | we will have to start relying on other methods to understand
         | the signups.
        
         | paxys wrote:
         | Grafana alerts. GitHub PR requests. Jenkins builds. Surveys.
         | Google Drive shares/comments. Dozens of other internal tooling
         | integrations.
         | 
         | I can't imagine working without slack bots at this point.
        
         | LocalPCGuy wrote:
         | Absolutely - couple examples that I've used in the last day or
         | so: Github notifications (PR requests), Jira ticket updates
         | (less useful), Figma notifications. Basically, Slack is
         | aggregating the tool notifications into one place so I don't
         | have to check email or each individual website.
        
         | mod wrote:
         | Sure. We used to have one that reported any error on any web
         | app we had deployed.
         | 
         | You could use other types of reporting, of course, but that
         | worked for us.
         | 
         | Any important information could be reported by the bot instead
         | of wherever you normally find it.
         | 
         | It's a matter of what you build it to do.
        
         | zoover2020 wrote:
         | I'd say ChatOps is a very legitimate use case. But I see your
         | underlying point of bots frontloaded with a lot of logic.
        
         | lhoff wrote:
         | We built a relay bit couple years ago. You can invite the bot
         | into a private channel and then other users who are not part of
         | the channel can use a form to send messages to that channel.
         | The members of the Channel can then use the thread to answer.
         | 
         | Works really well and has the effect that inter-department
         | communication don't always need to go through the department
         | heads. This could, of course be abused for spam, but so far it
         | worked well.
        
         | agentdrtran wrote:
         | absolutely, we rely on them for a few things and it's very nice
        
       | leathersoft wrote:
       | Pretty interesting. I'll have a look.
        
       ___________________________________________________________________
       (page generated 2022-09-16 23:01 UTC)