Rewrite For New API

[pmcintyresfdc]

Your Question

Any thoughts about creating a new framework based on the new slack API style using inbound HTTPS calls from slack?

We're needing to move in that direction to support some of the newer features like modals. We already have a hack to get around that and some firewall issues but I'm wondering if you'd be interested in help with any clean-slate work here.

[alexandre-normand]

Are you referring to the Events API? I hadn't really thought about this before but given how it wraps and reuses the same event structure than the realtime API, I think it would be reasonable. This would involve slackscot starting an http server with handler but then it could probably reuse most of the existing logic.

Is that what you had in mind? Also, I'm curious about your firewall issues but I assume it's related to how you need to open up http access to your slack app for the http handlers?

Also, thanks for being an active supporter of the project!

[pmcintyresfdc]

Events API

Yup

http server

Exactly

Firewall

This issue is related to security in different parts of our infra. Nothing I can go into here.

[alexandre-normand]

I haven't looked at the details yet but looking at the Events API at a high-level, I could almost just imagine adding new Options where one would drive slackscot running in traditional RTM mode and another one to run with the Events API.

I can't commit to a timeline for the addition but this is definitely interesting and I'd be up for exploring that addition. A few random thoughts:

• It would be nice if we could support slackscot starting a server but also maybe just having a receiving http handler that would drive the message/event handling flow so we could deploy this serverless (like with gcloud functions).
• Testing might be the harder part but I think that having support for a serverless mode might help since that usually involves having a publicly accessible https url.

Any more thoughts to share about this? The way I'm thinking about this right now is that this would be just about adding that compatibility with the Events API via server or serverless modes while preserving the existing functionality.

[alexandre-normand]

I just realized I had completely forgotten about this issue. The main reason I haven't taken this on myself is that my main deployments have the opposite problem: it's easier to use the RTM api because it's an outgoing web socket connection rather than having a publicly accessible http endpoint. I might still be able to work on this and test this out at some point but if you'd like to try and add the feature using your setup for testing and iterating, I'd be happy to look over those changes and iterate on the implementation with you.