What do you use as a origin server for your static media? And how does cloudfront work.. when its cached on the CDN, how long does it stay there? Don't you have to pay for files stored on the CDN? Oh, and where's your drydrop fork? :)
I use my www as the origin for the static media. I assume that cloudfront files stay in the CDN until they are invalidated. I haven't tested how long they stay. I imagine that if there are no requests, they go away after awhile.
You do have to pay for cloudfront usage. I am not sure the breakdown of custom origin vs s3 is - but i imagine it is similar.
GitHub pages[1] is other great option for static site hosting. You are pushing to github repo and your site is regenerating. Jekyll [2] is used as static site generator. I'm using GH Pages for HNresources.com hosting. If I need quickly update site I could change source page on project page on github.com site without even using git.
One question according to GAE hosting: If your application wasn't requested for some time it is unloaded from memory and first request after that require more time. Is it still apply to static sites?
Application will be unloaded from memory for sure but to serve static file you don't need to initialize app (i.e. load jar file into memory and start it or parse python source), you just need to serve static file. So start-up time could be much better. It is interesting to know about actual experience on GAE for static files hosting.
I'm the author of DryDrop. I've created it before GitHub pages were announced. Then I switched to GitHub Pages+Jekyll and quite ironically, DryDrop site itself is hosted from GH pages :-)
But still I think DryDrop may be useful for some folks who want to use GAE for hosting. See the FAQ on http://drydrop.binaryage.com/#faq
> you have a public repo, you don't want to pay for CNAME support on GitHub and you are obsessed with the idea of running your site on GAE :-)
You don't need to pay anything for CNAME support now. It was not true previously but now only "obsessed with the idea of running your site on GAE" reason remains.
(I am not on the App Engine team, but researched it recently to give a talk about it)
If the request is going through a static handler (as declared in app.yaml), then the request won't go to the Apps frontend servers at all, it will go to the static file servers. So, no, the app unloading shouldn't be relevant for static files.
I like the idea of having a git backend for site data, but in the case of the author: why not just use a regular host?
There are some pay-for-what-you-use hosts (e.g. https://www.nearlyfreespeech.net/).
Well, https://www.nearlyfreespeech.net/ supports git, bash, sh etc, if you follow the instructions from the comments further down you can use git as a backend ^^
I think the point of this setup was to get a free solution for those sites that get infrequent hits - that still fit into a git developer's workflow. We all have those sites. I noes! :)
Not to mention, while some have mentioned that you could create a github page, does that mean you'd have to create a separate repo for every page? (Not sure how github pages work at that level). This solution would allow for a single repo that holds all the sites - whereas not polluting your repo space.
I think this solution is for a particular niche of devs who control N number of domains - who want minimal maintenance and most importantly - no cost. ;)
I use GAE + Github for several of my tiny websites. I don't use DryDrop as I hadn't heard of it, and I like being able to control the app.yaml myself (particularly useful for when I have a sudden urge to port static sites over to Django, which happens surprisingly often). Also, it looks like DryDrop may actually use script handlers instead of static file handlers, which wouldn't be as performant for my simple stuff.
The trickiest part of using GAE for static files is setting up the app.yaml, since it's different from just FTPing files and having them show up on your server. Here's an example app.yaml for a completely static site, where the root redirects to index.html, and the rest is mapped to a static directory (with nested directories in it):
https://gist.github.com/774838
I posted the same thing yesterday, but it went nowhere. I guess I should have included the word "FREE!" in the title.
Anyway, here it is. As the blog post explains [1], I created a small Flask app that will let you host multiple static sites/domains on one GAE instance without having to learn Git or push to Github or anything. Just download the app [2], put the static files and media in the appropriate directories, configure the URLs and deploy.
Don't think that your post was wasted. Maybe this guy saw it and decided to submit this one, or maybe the author saw it and decided to write his version.
Also, I like your version of the static hoster way more. Really simple, no git/github. I think friends that use Dreamweaver could use this.
Thanks, that's the exact expected use case. You don't need to host your static sites on servers that you might want to move/decommission in the future, you can just host them all on one GAE instance for free.
24 comments
[ 4.1 ms ] story [ 70.0 ms ] threadThanks for the post, really nice
You do have to pay for cloudfront usage. I am not sure the breakdown of custom origin vs s3 is - but i imagine it is similar.
Here yea go: https://github.com/harperreed/drydrop
One question according to GAE hosting: If your application wasn't requested for some time it is unloaded from memory and first request after that require more time. Is it still apply to static sites?
* [1] http://pages.github.com/
* [2] https://github.com/mojombo/jekyll
According to GH pages performance is great.
But still I think DryDrop may be useful for some folks who want to use GAE for hosting. See the FAQ on http://drydrop.binaryage.com/#faq
You don't need to pay anything for CNAME support now. It was not true previously but now only "obsessed with the idea of running your site on GAE" reason remains.
If the request is going through a static handler (as declared in app.yaml), then the request won't go to the Apps frontend servers at all, it will go to the static file servers. So, no, the app unloading shouldn't be relevant for static files.
I made this diagram for a recent talk that somewhat shows that: http://www.slideshare.net/wuzziwug/writing-apps-the-googley-...
EDIT: It looks like DryDrop may actually use script handlers, not static handlers, in the app.yaml, so app unloading would apply.
Yes, I should write more.
Not to mention, while some have mentioned that you could create a github page, does that mean you'd have to create a separate repo for every page? (Not sure how github pages work at that level). This solution would allow for a single repo that holds all the sites - whereas not polluting your repo space.
I think this solution is for a particular niche of devs who control N number of domains - who want minimal maintenance and most importantly - no cost. ;)
See Option B here:
http://www.labnol.org/software/dropbox-with-custom-domain/18...
The trickiest part of using GAE for static files is setting up the app.yaml, since it's different from just FTPing files and having them show up on your server. Here's an example app.yaml for a completely static site, where the root redirects to index.html, and the rest is mapped to a static directory (with nested directories in it): https://gist.github.com/774838
Anyway, here it is. As the blog post explains [1], I created a small Flask app that will let you host multiple static sites/domains on one GAE instance without having to learn Git or push to Github or anything. Just download the app [2], put the static files and media in the appropriate directories, configure the URLs and deploy.
[1] http://blog.stochastictechnologies.com/easily-host-multiple-...
[2] https://github.com/stochastic-technologies/static-appengine-...
Also, I like your version of the static hoster way more. Really simple, no git/github. I think friends that use Dreamweaver could use this.
If i didn't already use git in my workflow, i would prefer this approach.