How can my add on send data back to the Heroku apps

[Julien Genestoux]

Hello,

We at Superfeedr are a RSS/Atom feed service on demand : our customers
send us a feed url and a callback url (or many). We then poll the feed
and when there is new content in that feed, we send the new content to
the callback url.

We are in the process of creating an addon for Heroku. I think we
understand mostly how it's done. However, we wonder how we could
handle the callback url complexity to the user. Is there any callback
mechanism built in add ons?

We could very well ask the user who uses the add on to provide one
inside his app, but the callback also needs to implement a few steps
to perform verification and we would rather hide that to the addon
user.

Thanks a lot!

[Morten Bagai]

Hi Julien,

Sounds like functionality one would normally bake in to language or even framework specific library. So, for example, for Ruby on Rails you could have a gem that adds the callback route along with any standard logic for authenticating etc. Perhaps it could even be Rack middleware to work across Ruby frameworks. A good example to look at might be something like Omniauth (https://github.com/intridea/omniauth) which will provide default paths for callbacks in Oauth2 flows etc. Of course, there are similar paths for other languages. 

Best,

-Morten

[Julien Genestoux]

Morten,

How do the cron add on work? I believe I could use a similar
technique, as our notifications are events... We do have a gem that
can be used inside heroku apps, and we also do have a nodejs module,
but I think we can do better by providing an addon and make the
developer lives easier by not creating a superfeedr account etc and
just use the Heroku platform.

Generally, for add on, is there a way for the add on to send data to
the application or is it just possible to return elements upon
requests?

Thanks,

[Morten Bagai]

Yeah, sounds like the add-on is the right way to go, but understand what the add-on does is allow you to automate provisioning of an account with an external service (suprfeedr), and to have configuration information (API key etc) automatically added to the Heroku app's environment. From there, you would have to add a gem that would then automatically pick up the config information from the environment. That's how most add-ons work.

As for the cron add-on, it doesn't rely on HTTP callbacks. It's also being replaced by https://addons.heroku.com/scheduler.

Best,

Morten

[Julien Genestoux]

Morten
Thanks. How does scheduler work then?
I'll see if we can deal with gem and node module... but that's a bit
sad that we couldn't integrate directly with some kind of web hook
merchanism. That would really be very powerful for a addon to be given
a url and let the user handle it the way they want :)

Ju

On Dec 29, 1:05 am, Morten Bagai <mor...@heroku.com> wrote:
> Yeah, sounds like the add-on is the right way to go, but understand what the add-on does is allow you to automate provisioning of an account with an external service (suprfeedr), and to have configuration information (API key etc) automatically added to the Heroku app's environment. From there, you would have to add a gem that would then automatically pick up the config information from the environment. That's how most add-ons work.
>

> As for the cron add-on, it doesn't rely on HTTP callbacks. It's also being replaced byhttps://addons.heroku.com/scheduler.

[Morten Bagai]

Hi Julien,

I believe the scheduler works by using the Heroku API to run processes on behalf of the user. It uses an special permission that will most likely be made available to addon providers soon. It's a little bit of a tricky issue, because running processes can incur charges beyond the cost of the addon itself, so we have to come up with a reasonable review structure for addons that want to use this feature.

As for what you're asking for, I understand the concept, but I doesn't seem to me that the net benefit to the user would be very high. Let's say that on provisioning, Heroku issued you - the provider - a callback URL in the form of appname.herokuapp.com/something that you could hit at any time. Well, wouldn't the user then still have to implement authentication, handling logic and also make sure that it didn't clash with a particular URL scheme implemented in the app itself? It seems to me that as user I actually get more benefit from using a gem that will include the default controller, know how to use the config vars, parse the data etc.

Perhaps I'm misunderstanding what it is that you want. If so, feel free to outline the flow you have in mind in detail. We're all for considering features that will add value to developers and add-on providers overall.

Best,

-Morten