Can't wait for someone to build a "Deploy to Heroku" button that I can stick on a GitHub README. It will spin up the app, do all the setup and then pass it off to the end-user; the instructions for most Heroku deployable apps always follow the same repeatable actions so it would be awesome to automate this.
That's actually been one of my backburner projects for some time. But I haven't had much time recently…
My approach though was having a Chrome extension to add that button on any GitHub repo. Clicking it would create the app, clone it and push it out to your own instance.
Some things slowed me down though. For example the Heroku API doesn't play well with requests made with XMLHttpRequest inside the browser, so I wrote a simple proxy for that purpose. I started working on a Heroku app that would do the git cloning but haven't had much time on it.
The problem I had with XMLHttpRequest was that the API would use the current Heroku cookie rather than the API token passed in with the request.
With curl, the doc says to use a blank username and the token as password in Basic Auth. When I do that with XMLHttpRequest, the token is completely ignored and the main site's cookie is used. There is no way not to pass the cookie with XMLHttpRequest unfortunately, so I would have to rely on if the user is logged in or not. That would bring other problems: I could only use the API for one account at a time for example, and I would have to add checks to see if the user is logged in, etc.
So my work-around was to write a proxy that would just pass around the requests to Heroku and the response back to the XMLHttpRequest client. (https://github.com/Timothee/Passeplat) With it, I can make the same requests I would make to https://api.heroku.com but instead make them to mypasseplatinstance.heroku.com.
Making this a Heroku-ready app is of course not a coincidence: my plan is to use my Heroku instances (the proxy and the yet-to-be-written git clone) to bootstrap a couple of Heroku instances with the user's own Heroku account. Then the extension would use these to start up other apps. I like the bootstrap idea: it's like compiling a compiler. :)
I'm now realizing that it might even be done with a buildpack… I'd have to look into that. (that would remove the need for that second "git clone" app) Hum, I'll really have to look into that! That could make things much easier and cleaner. (and also cooler)
There would still be the issue of specific configurations and add-ons to deal with, but that shouldn't be too hard if the rest is done.
edit: I haven't checked if this is still a problem with today's announcement. Also, I contacted Heroku support about it, but they only suggested I use a proxy.
Interesting. I fear I'm mostly a back-end type of guy (ie not much experience with XMLHttpRequest). Sounds like the browser may be at issue to some extent. I certainly find the behavior you describe to be surprising. Is there something we can change to better facilitate this?
It seems to me that the problem is that the backend is treating the XHR like if you were hitting the main site. So sometimes (but not for all endpoints I think), if I were logged out, the XHR would be redirected to the login page.
To me, the API endpoints should behave the same way in a browser as with curl without ever redirecting to the login page.
But, once again, it might have been fixed in the meantime… I haven't tried recently.
What if you got around it by instead just registering a domain and pointing it to the heroku api's IP? I'm not sure if heroku's api would be ok with the mismatched Host header, but it would be less moving parts.
Those repetitive setup tasks are definitely one of the things we wanted to provide an easier solution for. I definitely look forward to simple scripts instead of multi-step manual processes.
heroku config:set SECRET_TOKEN=`openssl rand -hex 20`
heroku run rake db:migrate
heroku addons:add scheduler
Open the scheduler webpage and add an hourly task
heroku restart
Exactly. For simple cases just shelling out to the API is good enough, but many of these deployable apps are a bit more complicated. Especially those that need databases or other add-ons to work.
Comments
Can't wait for someone to build a "Deploy to Heroku" button that I can stick on a GitHub README. It will spin up the app, do all the setup and then pass it off to the end-user; the instructions for most Heroku deployable apps always follow the same repeatable actions so it would be awesome to automate this.
I tried out this project with similar aims in the past: https://github.com/rainforestapp/heroku.json but it wasn't quite enough to get an app up and running.
That's actually been one of my backburner projects for some time. But I haven't had much time recently…
My approach though was having a Chrome extension to add that button on any GitHub repo. Clicking it would create the app, clone it and push it out to your own instance.
Some things slowed me down though. For example the Heroku API doesn't play well with requests made with XMLHttpRequest inside the browser, so I wrote a simple proxy for that purpose. I started working on a Heroku app that would do the git cloning but haven't had much time on it.
Sounds like a great approach. What can we do to better support XMLHttpRequest?
The problem I had with XMLHttpRequest was that the API would use the current Heroku cookie rather than the API token passed in with the request.
With curl, the doc says to use a blank username and the token as password in Basic Auth. When I do that with XMLHttpRequest, the token is completely ignored and the main site's cookie is used. There is no way not to pass the cookie with XMLHttpRequest unfortunately, so I would have to rely on if the user is logged in or not. That would bring other problems: I could only use the API for one account at a time for example, and I would have to add checks to see if the user is logged in, etc.
So my work-around was to write a proxy that would just pass around the requests to Heroku and the response back to the XMLHttpRequest client. (https://github.com/Timothee/Passeplat) With it, I can make the same requests I would make to https://api.heroku.com but instead make them to mypasseplatinstance.heroku.com.
Making this a Heroku-ready app is of course not a coincidence: my plan is to use my Heroku instances (the proxy and the yet-to-be-written git clone) to bootstrap a couple of Heroku instances with the user's own Heroku account. Then the extension would use these to start up other apps. I like the bootstrap idea: it's like compiling a compiler. :)
I'm now realizing that it might even be done with a buildpack… I'd have to look into that. (that would remove the need for that second "git clone" app) Hum, I'll really have to look into that! That could make things much easier and cleaner. (and also cooler)
There would still be the issue of specific configurations and add-ons to deal with, but that shouldn't be too hard if the rest is done.
edit: I haven't checked if this is still a problem with today's announcement. Also, I contacted Heroku support about it, but they only suggested I use a proxy.
Interesting. I fear I'm mostly a back-end type of guy (ie not much experience with XMLHttpRequest). Sounds like the browser may be at issue to some extent. I certainly find the behavior you describe to be surprising. Is there something we can change to better facilitate this?
It seems to me that the problem is that the backend is treating the XHR like if you were hitting the main site. So sometimes (but not for all endpoints I think), if I were logged out, the XHR would be redirected to the login page.
To me, the API endpoints should behave the same way in a browser as with curl without ever redirecting to the login page.
But, once again, it might have been fixed in the meantime… I haven't tried recently.
Sure. I haven't tried either. Its on my list of stuff to dig into and sort out, so hopefully we have a better answer soon.
What if you got around it by instead just registering a domain and pointing it to the heroku api's IP? I'm not sure if heroku's api would be ok with the mismatched Host header, but it would be less moving parts.
Interesting idea. I'll have to give it a try. Thanks!
Those repetitive setup tasks are definitely one of the things we wanted to provide an easier solution for. I definitely look forward to simple scripts instead of multi-step manual processes.
That sounds like a fun weekend project! Instead of "try a live demo" you get "create a live demo of your own".
Totally. I definitely hope that this will lead to many, many fun weekend projects. Definitely really excited to see what people dream up.
How's this?
Well most apps needs some others like:
Exactly. For simple cases just shelling out to the API is good enough, but many of these deployable apps are a bit more complicated. Especially those that need databases or other add-ons to work.