Clarify that this app runs on a worker and why about greetingslack

[orliesaurus]

Hey, @patcon

I don't understand the problem because (luckily) I don't use Heroku. I added Heroku because it makes it so much simpler for people to use this slackbot.

Wouldn't the best advice just create a new Heroku account that has no other apps running alongside it?
Alternatively, moving this to a web-process would force the bot to sleep - so that would break it?

[gundmc]

I think this is a result of choosing to use the Slack RTM api instead of the Events and Web API.

I found this repo from a Medium article while looking for this type of functionality for a hobby-related Slack. Really cool stuff and a great idea!

To get around the worker always running issue, I ended up converting to the web api and running as a Cloud Function on GCP. That way, you subscribe to certain events in slack and the function only executes when the event is triggered - no servers/workers. Has worked really well so far!

Happy to discuss implementation with you guys if desired. Thanks for the inspiration!

[patcon]

You're right, that would totally be a partial work-around for some of my very specific woes :)

but I feel there's perhaps another rationale for having this app work a bit more intuitively within heroku users' assumptions: if someone isn't paying, then they should expect sleep happen, right? If they don't want it to sleep, then they should knowingly start paying, instead of having this app take them into a countdown of "heroku dyno debt" through a bit of a work-around. Even with a separate account, the approach here invites users to run a 24 hour worker dyno (that can't intelligently sleep) without paying, and so 3 weeks into using the bot (at perhaps about the time that people start trusting and depending on it), heroku shuts down the app due to overage, and the bot (perhaps unknowingly) goes down, and breaks their onboarding. This seems like a bad thing to set people up for, no? :)

At least with a web dyno, people can think on using something like https://github.com/hubot-scripts/hubot-heroku-keepalive, and keep itself awake during certain hours (when people most often use slack).

tl;dr - current setup just defers dealing with the dyno restrictions in an overly clever way that sets people up for later difficulty :)

[orliesaurus]

@patcon Ok - I never had a complaint from any of the people that run the bot.
I have a friend who runs a community for podcasters whose bot has been running for 3 months without shutting down.
I understand the issue better now at least.
Maybe if I fork the project and make it behave as a web-dyno version then this would overcome the issue you mentioned.
The other solution is to pay Heroku fees...
#foodforthought
Not sure what's the path to take here...

[patcon]

Totally. I'm willing to work on a solution too, so not all on you. i expect to be back into onboarding process mode at some point, and would be happy to loop back to convo then!

(fwiw, due to how heroku tallies dyno hours in aggregate, someone with a bunch of heroku apps might see the "debt" of this app masked by surplus hours on other quiet apps. at least that's my analysis of the situation :)

[orliesaurus]

@gundmc great to hear: this bot was written many years ago, there was no event api back then, it would be cool to see others update the code or create their own now that it is possible and just like you did use serverless platforms with hooks

[patcon]

I'd love to check out that code @gundmc! Are you planning to release in another project? :)