We take security very seriously, which is why we designed Relay to work so that we never have to see your encryption keys. If Let's Encrypt is working well enough for you, that's great, but we've also heard about rough edges that people struggle with so we are trying to help them out.
Unfortunately auto-scaling is incredibly application specific. It would be a great feature, but it seems likely to be quite difficult to make a particular solution that is useful to more than a small subset of users. You can get some sense of this from the other comments above (ie how analytics wouldn't be a good scaling metric for them).
Both the format and version are in the same header if that helps. So there are a couple values in there you might have to change, similar to the couple values you would have to change in the url to modify version/format. So in that regard I think the difficulty or complexity of one or the other is pretty similar. Hope that helps explain a bit, but let me know if I missed the point of your question.
We definitely used what you mentioned as a starting point. There are some changes, hopefully for the better, but it should in time provide all the same functionality in a more public and formal way. We definitely love that people were excited and motivated enough to reverse-engineer things as you did, so we hope this makes it easier on you and more accessible to others.
Thanks for sharing the link. There definitely can be a lot of gotchas and things that are easy to overlook until you see a good talk or are right in the middle of it.
I had not really explicitly considered that possibility in working on this. I suppose this is a step closer to that, but there are still some pieces that we would need to add. What kind of things did you have in mind?
What I'm imagining is click a button and have it create and deploy fully configured apps for me, similar to what I can do with all the add on services. They might be paid or free or tiered etc, it might be a once-off fee or a monthly/annual subscription or an on-going charge like some of Amazon's AMIs.
There's lots of commercially licensed, self-hosted software (blog, forum, ecommerce etc) and hosted-as-a-service (wordpress.com, discourse.org, duelapp.com etc) etc that would be applicable.
Enabling that by API or in general would be awesome.
I was pretty sure that was the kind of thing you meant, but just wanted to clarify. The API should certainly facilitate doing the kind of setup and management that this would require. But it doesn't currently provide a direct way to do the billing portion of things. So I think it could be a ready solution to open source self-hosted stuff, for instance, but you would have to provide your own billing stuff for commercially licensed things.
Billing is definitely on our todo list as we progress with the beta. Provisioning new accounts is a little trickier as it could potentially open the door to abuse. Which isn't to say we'll never do it or that it isn't possible, just that it is more complicated.
Thanks, glad you like it. A ton of thought went into a lot of the little choices like that. We plan to dig more into how and why those choices were made as we move forward.
This will be very interesting for those of us looking to learn more about building APIs. I for one am definitely looking forward to future posts on the subject!
Great, do let me know if there are particular questions you have and we can be sure to cover them. Otherwise I hope to start covering the key things that I think are interesting or important in the not too distant future.
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.
