[QUERY] What is the correct way to update/manage triggers?

There is a lot to like about this new sdk, but I'm finding triggers really difficult.

Question

Why do old triggers not get removed when running slack run? Ex. If I remove a trigger file and the app re-installs - what is the rational for the trigger still existing? I'm curious for both local and remote.
Why do triggers not automatically update when running slack run? Possible its a feature request to add a --sync-triggers flag, but I'm confused why the current flow is a desirable development exp. I find it confusing if the app hot reloads/reinstalls, but isn't using the new trigger logic. Needing to run slack trigger update removes the benefit of hot reloading.
What is the recommended way to create a trigger that listens for messages in the bot's channel? I currently have a shortcut trigger "configure" that you have to run in the bot's channel that then dynamically creates triggers. This is fine..., but how do I guarantee that it can only be run in the bot's channel?
The goal is to have this app be installed N times via oauth. How should triggers be managed at scale? Do I have to call update/delete after every deploy? Seems like a bit of a nightmare, but hopefully I'm missing something. Can I do this programmatically via the api?
Do you recommend bolt over this sdk? I noticed it had more events, but I'm hesitant to use something if its going to be deprecated. Also don't mind hosting if its more of the proven solution atm.

I realize this is a lot of questions, but I've been banging my head at the wall to only accomplish a simple reply in a thread in my bot's message channel.

Environment

"deno-slack-sdk/": "https://deno.land/x/deno_slack_sdk@2.2.0/",
"deno-slack-api/": "https://deno.land/x/deno_slack_api@2.1.1/"

deno 1.37.0 (release, x86_64-unknown-linux-gnu)
v8 11.8.172.3
typescript 5.2.2

Hi! Thanks for posting, asking questions, starting discussion. Lots to dive in to so I will do my best to answer each question.

Re: 1. and 2., these are great questions and we don't have 'best practices' or believe the current experience is great. We are still figuring all this out ourselves, too. In this initial release of the CLI and this SDK, we're still gathering data on usage and what's frustrating as well as delighting people. Thanks for the feedback around triggers; I agree with you that it feels like extra work to manage triggers mostly through the CLI. Specifically re: triggers for run, initially we would delete the entire app, along with its triggers and datastores and other constructs, when run would finish, but we got feedback that that was too heavy-handed, so we dialed it back. Maybe we dialed it back a bit too much? Worth exploring for sure.

Re: 3, this 'configurator' pattern you speak of is quite common. I'm not sure if that's a good thing or a bad thing - perhaps it is a pattern that arose because of a lack of other, possibly better avenues/options available to devs. Once more, worth exploring this more. Regarding gating access to triggers, there are a few options related to trigger management, such as specifying which channels or workspaces to 'lock' a trigger down to (see our docs on this here). Would that help in this situation?

Re: 4, great question. OAuth and installation into arbitrary workspaces is not supported at this time, though we will certainly get there at some point. In general, the 'distribution' story needs a lot of work: how to get into the App Directory, how manage OAuth, and even how to version custom functions that can be consumed from other apps - all of this plays a role. We will be starting work on this in the coming months. If you have ideas or suggestions or your own experience to share on this topic, we are all ears.

Re: 5, I do not recommend bolt over this SDK nor the opposite. Today, this SDK and use of the CLI is required in order to create Custom Functions that can be used in the new and improved Workflow Builder in Slack. We initially rolled out very alpha support in Bolt for this, but frankly it was sub-par and we pulled it. However, I'm happy to say that we will be working on much better support for custom functions across all Bolt projects starting very soon! This will include full support for self-hosted custom functions, too.

I'll also reiterate that there are no plans to deprecate the Bolt SDK nor the old app-centric model of developing on the Slack platform at this time. Last I checked, there are multiple tens-of-thousands of daily active applications on Slack powered by Bolt alone. In my opinion, it would be a stick-a-rod-into-your-own-bicycle-wheel-while-riding-it move of epic proportions to do so.

Lastly, if you don't mind describing your specific use case more ("I've been banging my head at the wall to only accomplish a simple reply in a thread in my bot's message channel"), happy to discuss options and brainstorm in this issue about it.

@filmaj Thank you for the quick, detailed, and helpful response! I'd already switched and started building a bolt app. It took me too long to realize that this is sdk is tailored more towards single workspaces, but I'm glad to hear that bolt still has a future which was my main concern.

initially we would delete the entire app, along with its triggers and datastores and other constructs, when run would finish, but we got feedback that that was too heavy-handed, so we dialed it back. Maybe we dialed it back a bit too much? Worth exploring for sure.

I could see how deleting datastores every run would be annoying. Triggers when stateless would be safe to reset, but because you can dynamically create triggers from triggers it throws a wrench in things.

Re: 3, this 'configurator' pattern you speak of is quite common. I'm not sure if that's a good thing or a bad thing - perhaps it is a pattern that arose because of a lack of other, possibly better avenues/options available to devs. Once more, worth exploring this more. Regarding gating access to triggers, there are a few options related to trigger management, such as specifying which channels or workspaces to 'lock' a trigger down to (see our docs on this here). Would that help in this situation?

Not a big fan of the configurator pattern, but it was the only option. Could you add events for app install/update to register/update triggers? My preferred flow would be someone runs slack run or deploy and everything just works. They don't have to know what shortcuts to run or where. Someone has already made the decision to install your app and having them run a shortcut after installation doesn't seem to offer any security advantage (I'm sure there are subtleties to the security advantage that I'm missing). Since shortcuts can generate triggers which can generate triggers and so on - I doubt an admin will be able to rationalize the impact of running a shortcut link.

I guess my preference would be to not have to manage triggers at all. Triggers get initialized at startup of the app and are stateless. They could still dynamically create triggers, but you'd never have to worry about updating or deleting old triggers since they live and die with the app.

Re: 4, great question. OAuth and installation into arbitrary workspaces is not supported at this time, though we will certainly get there at some point. In general, the 'distribution' story needs a lot of work: how to get into the App Directory, how manage OAuth, and even how to version custom functions that can be consumed from other apps - all of this plays a role. We will be starting work on this in the coming months. If you have ideas or suggestions or your own experience to share on this topic, we are all ears.

Thanks for answering again. I saw this thread https://github.com/slackapi/deno-slack-sdk/issues/202 after posting this one. This is definitely going to be a difficult problem, and may be the reason bolt can never be replaced. Having the apps/datastores/logs/triggers scoped to each workspace is amazing from a security posture. However, that will be a full-time job to manage at scale past a certain number of installs. I'd imagine debugging, trigger migrations, etc would be really painful without a heavy abstraction layer. Even then having the number of running apps scale with the number of installs probably wouldn't work.

I'll also reiterate that there are no plans to deprecate the Bolt SDK nor the old app-centric model of developing on the Slack platform at this time. Last I checked, there are multiple tens-of-thousands of daily active applications on Slack powered by Bolt alone. In my opinion, it would be a stick-a-rod-into-your-own-bicycle-wheel-while-riding-it move of epic proportions to do so.

🎊 - this gives me plenty of confidence moving forward with Bolt without fears of having to re-write in a year. Also loving bolt so far - so nice job! Already have it running and supporting multiple installs right in my nest api. At some point I might split out into its own service, but its nice for rapid development for it to have direct access to the api/db.

Lastly, if you don't mind describing your specific use case more ("I've been banging my head at the wall to only accomplish a simple reply in a thread in my bot's message channel"), happy to discuss options and brainstorm in this issue about it.

Sorry the "banging my head" wasn't exactly constructive. Most of my issues were with trying to figure out how to build a generic slack app without hardcoding channel ids. Having to create a configure trigger that upserted dynamic triggers felt super heavy as a first step to not hardcode channel ids. I still think there should be hooks to configure triggers at startup/update as I mentioned above for all types of apps. Happy to discuss/brainstorm more, but I'm also not using this sdk anymore.

Could you add events for app install/update to register/update triggers?

I think this is a good idea and provides an avenue for CLI-managed workflows/apps vs. OAuth-managed ones to react to app management events in a consistent way. I think this would help us down the road once distribution is supported in workflow apps.

I guess my preference would be to not have to manage triggers at all. Triggers get initialized at startup of the app and are stateless. They could still dynamically create triggers, but you'd never have to worry about updating or deleting old triggers since they live and die with the app.

I hear you and feel much the same way. One wrinkle here is that triggers are not entirely workspace-agnostic today: many of them can define channel or workspace IDs that limit the scope of the trigger. If those features are used in a particular trigger, it makes them suddenly much less portable across workspaces. However, perhaps there are some things we can polish in the CLI to allow it to inspect if a trigger is workspace agnostic or not, and if it is, transparently update any defined triggers in the app. I'm glad you brought it up, I think it's a nice idea worth exploring! 💡

Not a big fan of the configurator pattern, but it was the only option.

Me neither! I've been spending time thinking about what could be done to remove this pattern altogether. It feels more like a bug than a feature, to be honest.

However, that will be a full-time job to manage at scale past a certain number of installs. I'd imagine debugging, trigger migrations, etc would be really painful without a heavy abstraction layer. Even then having the number of running apps scale with the number of installs probably wouldn't work.

100% agree; we've got our work cut out for us in the coming months 😅

Also loving bolt so far - so nice job!

❤️ thanks so much for the kind words; it means a lot to our entire team. 😊

Sorry the "banging my head" wasn't exactly constructive. Most of my issues were with trying to figure out how to build a generic slack app without hardcoding channel ids. Having to create a configure trigger that upserted dynamic triggers felt super heavy as a first step to not hardcode channel ids. I still think there should be hooks to configure triggers at startup/update as I mentioned above for all types of apps. Happy to discuss/brainstorm more, but I'm also not using this sdk anymore.

Your frustration is totally understandable and not to worry about your message 😃 . We appreciate you taking the time to report, respond and discuss with us. In my opinion, while we work on improving the sophistication for workflow apps from a developer perspective, it reinforces to me our need to maintain and offer all of these improvements on the Bolt side, which we will be investing in more in the coming weeks and months.

I seem to be running into a lot of the same types of issues others are here. Primarily, "configurator" pattern and trigger deployment concerns.

I would like to provide some feedback regarding these things:

... Regarding gating access to triggers, there are a few options related to trigger management, such as specifying which channels or workspaces to 'lock' a trigger down to (see our docs on this here). Would that help in this situation?

I feel like requiring deployment to manage this seems potentially a bit inefficient for managing access control. It seems like such things should allow runtime management. The flags take specific IDs which require information from a specific deployment. If we want such a configuration, this should be controllable at runtime. For example, if there were a place to control these options on a per trigger basis after install. I do, however, feel like these should be exposed at an app's discretion. Allowing, for example, controlling bulk control of access to a group of triggers rather than requiring individual control of access.

I think channels are arguably not appropriate for this as it simply represents a many users within a scope. I think a more appropriate thing to use for this (within a workspace) would be User Groups, which I don't see an option for that.

As a note, I think much of this can be resolved, to some extent, by having branching logic in workflow steps. If, for example, there as an "authorization" step and then conditional steps after then actually authorization is relatively easy to control at runtime. It can also be abstracted as a "workflow" step to control who can use a given trigger. This, unfortunately, does not help with controlling "exposure" or who can see a given shortcut. I think exposure of access to a trigger can be done in essentially the same way (without requiring deployment) but I don't really know the underlying mechanism used for exposing vs not exposing a given trigger and why this is unable to be controlled at runtime.

I would note, I know you can "create" link triggers at runtime but I don't really see any information in documentation regarding access control setting at runtime. I could be missing this but it seems really difficult to find.

slackapi / deno-slack-sdk

[QUERY] What is the correct way to update/manage triggers? #220