Bolt-js: Why not use official node Slack client?

Created on 2 Sep 2017  路  3Comments  路  Source: slackapi/bolt-js

Currently the Slack client in use is smallwins slack one. Just wondering why not switch to the more official slackapi node sdk.

Most helpful comment

I do agree that the smallwins client is lighter but since this is all used on the server side, size shouldn't be too big of an issue. But, in my own projects, I don't rely on the smallwins client exposed through slapp - I instead pull in the slack one and just query through that. This is especially because the slack one is more up to date in slack features exposed (chat.postEphemeral for example) - with the last update being 5 days ago vs 2 months ago for smallwins. There's clearly a more vested interest now in the slack node sdk being up to date and maintained as opposed to where it was when this project decided on smallwins.

I do agree that it would be a breaking change in switching over - it would be entirely new syntax and everything but I would be willing to take a stab at it if this is something that's in the direction that slapp decides to go.

All 3 comments

We like how thin the smallwins client is. At the time at least (and I think is still the case), the official node client was pretty heavy including a bunch of built in caching options and things we think are better left outside of the core library.

It could be worth another look soon, but would be a pretty big breaking change for anyone who relies on slapp.client.

I do agree that the smallwins client is lighter but since this is all used on the server side, size shouldn't be too big of an issue. But, in my own projects, I don't rely on the smallwins client exposed through slapp - I instead pull in the slack one and just query through that. This is especially because the slack one is more up to date in slack features exposed (chat.postEphemeral for example) - with the last update being 5 days ago vs 2 months ago for smallwins. There's clearly a more vested interest now in the slack node sdk being up to date and maintained as opposed to where it was when this project decided on smallwins.

I do agree that it would be a breaking change in switching over - it would be entirely new syntax and everything but I would be willing to take a stab at it if this is something that's in the direction that slapp decides to go.

馃憢 I think there are a few benefits to using the slackapi/node-slack-sdk package in the context of slapp that haven't been mentioned yet:

However, it should be acknowledged that it's still the case that the official client is larger than the smallwins/slack client and it includes additional RTM and Incoming Webhook clients that most developers won't have a reason to use.

I don't anticipate the migration cost being too high for developers since the method calling conventions are the same in the smallwins/slack and slackapi/node-slack-sdk clients, but curious to hear other's thoughts.

Was this page helpful?
0 / 5 - 0 ratings