zfbot - powered by expressive

[geerteltink]

I'm using hubot myself for github notifications and a deployment system connected to slack. I'm not so happy with hubot. Some stuff doesn't work right and JavaScript is sometimes painful to work with. Let alone, you need to learn coffee script to be able to submit a patch.

I've been thinking... the only real need for hubot is to hook into a slack channel and listen for commands. Everything else is just done sending data to api's. That api is started by hubot, but in theory it could be run by anything.

So what if hubot is replaced by slack slash commands? This way you don't need to run hubot as slack adds a listener for /zfbot. It then sends the commands to a self hosted api endpoint.

What I'm saying is, get rid of hubot, swap to slash commands and use php and expressive (or the next apigility) to build the api. This way the zfbot api can serve as an example and basically every one can contribute. No need to learn coffee script if you want to submit a patch.

[weierophinney]

I see a few potential issues with this approach.

First, apps implemented via slash commands can only post to a channel in response to a command. This means that things like the github and discourse webhooks could not post to the channels, and would need to be implemented as an app anyways.

Second, some of the integrations do not use polling. In particular, the Twitter integration uses the Twitter streaming API, which means it has a long-running TCP connection running to the Twitter API, allowing it to get real-time updates. Re-implementing this in PHP would require setting up polling instead, which is a new moving part.

The only "slash" commands that are really viable currently would be those used to setup github webhooks, tweet/retweet, follow/track twitter users and search terms, and setup ACLs. These actions are the smallest portion of what zfbot is currently doing; the bulk is acting as a system of webhooks in order to send messages to Slack. Hubot provides this functionality out-of-the-box.

We could use the Slack Web RPC API to handle the webhook aspect; a quick search on packagist reveals a ton of packages for interacting with the Slack API. The trickier integration would be Twitter. There are tools like php-api-clients/twitter, but there are a few issues I foresee:

• Keeping it running. Daemonized PHP can be tricky to keep running: they can run out of memory, uncaught errors can bring them down, etc.
• How do we notify the daemon of new terms or users to track/follow?

My point is that while we would gain from the fact that contributions would be in the same language in which our consumers are fluent, we also end up with a more convoluted infrastructure. I'd rather not have to run multiple services to make things work, particularly when we already have solutions such as hubot that are well-tested across many ecosystems and for which there's a fair number of developers already familiar with the technology.

[geerteltink]

First, apps implemented via slash commands can only post to a channel in response to a command. This means that things like the github and discourse webhooks could not post to the channels, and would need to be implemented as an app anyways.

As you are saying yourself, you use the Web RPC API for this. This is what hubot is doing as well. It just runs an instance of express to receive GitHub data and makes posts to Slack via Web RPC.

The trickier integration would be Twitter.

That I don't know. I haven't looked into that part.

Keeping it running. Daemonized PHP can be tricky to keep running: they can run out of memory, uncaught errors can bring them down, etc.
How do we notify the daemon of new terms or users to track/follow?

I didn't know new users were tracked. However there is the Events API. Instead of listening to all messages and respond to new users etc, you can subscribe to the team_join event. Slack sends your endpoint a json payload and you respond to it. Reading that event API it feels like Slack actually wants you to use the Event API instead of a bot listening.