filmaj
commented
1 year ago Hey @geekflyer ! Sorry for the late response. I will do my best to answer your questions/observations.
bolt@4/future on node - proven runtime but the bolt@4/nextgen/future lib seems not well maintained - last update was 8 months. Ts-template isn't working. Deployment outside slack platform.
This is, unfortunately, true at this time. We are not investing in this area at this time though we see why this would be a tantalizing option for many Slack developers. While we initially invested very baseline support for, as we call it, "remote function" support in the new Workflow Builder refresh (let's refer to this as WFB2.0), maintaining just the deno-slack-sdk to work for run-on-Slack functions ended up taking a majority of our focus. Better support for remote functions is still something we want to tackle - but we haven't prioritized nor invested in this area just yet.
Is there an option 4 - using deno-slack-sdk / next gen SDK/API and Deno but deploy this on my own infrastructure (probably GCP Cloud Run)?
It should technically be possible today but there are many details to work through that probably make this option prohibitive right now. In particular, there is no way - yet - for remotely-deployed apps to subscribe to the new WFB2.0-specific step or function execution events over HTTP (the existing workflow.steps-execute events are for the legacy Steps for Apps implementation, or Workflow 1.0) - these are only broadcast over Socket Mode for remote apps. While maybe not a showstopper, maintaining a long-lived socket connection is probably not ideal for a production app.
Going back to your numbered list of approaches 1 through 4, 1 and 3 are the officially supported avenues right now.
So, I'm wondering - any recommendations on what I should do?
I would recommend employing either avenue 1 or 3. It sounds like your app requirements preclude avenue 3, so 1 is probably what I would lean towards. The only limitation with avenue 1 is that you won't be able to expose the richer and more configurable WFB2.0 steps ("custom functions" as we call them) for Slack users that have your app installed in their workspaces. Everything else - all events and functionality - is available to these apps.
Is an option 4 already there or on the roadmap (i.e. deno app using new SDK/API but deployed outside slack platform)?
I would bundle this option together with us investing more into option 2 - the underlying approach is the same for both (deploying your app on your own infrastructure - regardless of the language or runtime it is written in - and being able to register your app to the WFB2.0 function execution events). Investing more into option 2/4 is definitely on our roadmap.
I don't mind bleeding edge, using Deno etc, but locking myself into deploying the app within slack and then operating within its constraints is something I'd ideally like to avoid.
Totally understandable, and we want to enable as many Slack app developers as possible. No matter what we roll out in terms of infrastructure and services on our side, there will always be cases where Slack developers will want to use a particular service or stack or have specific constraints that preclude them from deploying to Slack. I am keen to see us support this slice of developers as well.
Also more generally wondering - is the "new platform" meant to eventually supersede bolt or are they meant to coexist forever?
My understanding is that the two are meant to co-exist, but prioritization leads us to (naturally, I think) ensure that any deployed-on-Slack offerings are at the top of the list. Once WFB2.0 becomes fully available in a couple of months, I could see us renaming this SDK to use the Bolt name as well.
Hope that's helpful! Happy to answer any other questions you may have. Otherwise, feel free to close the issue. Cheers and appreciate your feedback.
Hi team.
I'm in the starting phase of building out a slack bot that interacts with github. The main/initial use case is to identity stale branches via some heuristics and prompt slack users repeatetly if they want to delete them - and deleting them automatically after a few days of non-response from the slack users. I'm planning to use firebase for storage (instead of slack's built-in datastore) since I need to build also some custom admin UI stuff etc. on top of the data that doesn't fit cleanly into slack datastore API (I for example want to keep a history of when / how often a user has been bugged about a particular branch and automatically expire entries via TTL to make sure the db doesn't grow infinitely in size).
As I was reading docs and trying out things I'm slightly confused by the different options and constraints the slack dev SDKs provide. This is my impression so far:
Is there an option 4 - using deno-slack-sdk / next gen SDK/API and Deno but deploy this on my own infrastructure (probably GCP Cloud Run)?
While option 3 sounds pretty convenient the fact that my app interacts with a lot of outside systems makes me a bit wary of deploying this via option 3. In particular stuff like creating an external admin UI (but still be able to call slack) and modern observability (the current logging functionality of slack platform seems pretty basic compared to the observability stack we use for other apps in GCP and co and I worry how I can monitor and troubleshoot the app if it crashes etc.).
So, I'm wondering - any recommendations on what I should do? Is an option 4 already there or on the roadmap (i.e. deno app using new SDK/API but deployed outside slack platform)? I don't mind bleeding edge, using Deno etc, but locking myself into deploying the app within slack and then operating within its constraints is something I'd ideally like to avoid.
Also more generally wondering - is the "new platform" meant to eventually supersede bolt or are they meant to coexist forever?
Appreciate your insights.
Best, Christian