Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion] Pros and Cons compared to howdyai/botkit #27

Closed
malonehedges opened this issue Aug 3, 2016 · 5 comments
Closed

[Discussion] Pros and Cons compared to howdyai/botkit #27

malonehedges opened this issue Aug 3, 2016 · 5 comments

Comments

@malonehedges
Copy link

I'd love to hear your thoughts (contributors) on how BeepBoopHQ/slapp compares to howdyai/botkit. 😁

@selfcontained
Copy link
Contributor

You bet. We've been using and contributing to botkit for quite awhile, so definitely are appreciative of it as a library, and there are some obvious places slapp is influenced by botkit. It would probably help to explain some of our motivations for writing this library.

One of our main motivations and needs (for writing our own Slack Apps) was a library that let us do so in a stateless way. The new Slack Events API is really compelling, in that it lets you write an HTTP based app, which is much easier to scale and maintain for many teams than a stateful websocket connection based one (using the RTM api). We didn't see an easy way to accomplish this with the way you write bots in botkit, using scoped callbacks to maintain your state during a conversation (that could change?). We also wanted our apps to handle restarts and rolling updates, which are solved problems when it's HTTP based, but more difficult when using websockets.

Another driver was to have a very thoroughly tested library that we could feel confident in as we used it, and as it evolves alongside Slack's feature-set. So far we've accomplished that with 100% code coverage in our tests, and that will remain a standard we keep for the library.

We also feel there's an advantage to having a library specifically tailored to Slack instead of multi-platform. Platforms all evolve differently, and it can become difficult to maintain a consistent API across all of them. While there are definitely use-cases for multi-channel bots, we think there are also strong and common use-cases for Slack-only Apps, so having a library w/ an API tailored specifically for them is advantageous.

If you stacked them side-by side, there are definitely things one does that the other doesn't. Namely botkit supports the Slack RTM API, which slapp doesn't support currently. That's by design on our part. Botkit also supports multiple platforms, while slapp is Slack only. We think these decisions allow slapp to have a more intuitive API when it comes to writing Slack only Apps. That's not an exhaustive list, but those are the more prominent differences that stand out to me.

@malonehedges
Copy link
Author

@selfcontained Thanks so much for the thoughtful response.
Always happy to see more options in the space as a bot developer.

@malonehedges
Copy link
Author

I'm going to leave this open so other newcomers can see your thoughts. Feel free to close whenever though.

@2color
Copy link

2color commented Apr 4, 2018

@malonehedges I wonder if you have any thoughts given some experience with this?

@malonehedges
Copy link
Author

@2color I actually haven't done much work with bots for a while so I'm not up to speed on the different frameworks available. I'd start by checking out this and botkit. There might be some other frameworks listed in the READMEs too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants