This is great news. Back when we were building DotSpots (now defunct, sadly), our website was built entirely in GWT. We weren't just serving a static site - we had the full functionality being run in GWT-compiled code. This meant that the majority of the site itself could be hosted from a static domain, and only the APIs behind the scenes needed to be running on our EC2 fleet. At least that was the idea.
We managed to get the majority of the static images and JS running off CloudFront back then, but were always stuck serving html from our EC2 boxes (a combination of what was available from AWS at the time, and the previous one-day minimum timeout of CloudFront). We put a lot of work into optimizing them so that they'd be super lightweight and could be served quickly. It was pretty fast considering that we weren't able to put all of the static-like files into S3/CloudFront.
Now that you can host the whole static bits of your domain through S3/CloudFront, I'd love to give this another shot with a future project. With strongly-named resources (ie: resource name == MD5) being served with one-year expiration times from Amazon's infrastructure, you could build a blazing fast dynamic site without having to spin up a single EC2 box.
That's really awesome. Lately I've been a fan of a Static+API architecture where the site content is served static and dynamic content is loaded through an API call to api.mysite.com and bound using an MVVM. With caching set, static content is never re-requested and API calls are immediately made when a user loads a page. My server can be a simple event io platform like node, and can handle more requests because it's not building dynamic pages, just directly getting data from the db or memcache to serve back json. Unit testing is simplified because my tests are all integration tests against the same API my webpages use. I can write test scripts to create new users, login, run features and verify the JSON results. Basically use my site from the commandline if I want to, or provide 3rd party api support with no extra effort. I'm not a fan of rest urls mixing data with content requests so I use query params to specify the data to request in the api call. Like homework.com/assignment?id=324324 - when the page loads (immediately from cache) the javascript reads the id and makes the API call to get the content. Anyone else using this kind of design?
I'm doing pretty close to what you describe, with a few minor differences. I have a single-page playlist app for YouTube and SoundCloud called Muxamp [1] that runs on Node.js. The site is served as static HTML/JS/CSS right now, using JavaScript for all the heavy lifting. All requests go to a REST API--JSON in, JSON out. When a playlist is requested (static data), the server checks a cache, then checks the DB. Data is turned into JSON and sent over the wire.
I'm currently doing a rewrite in Backbone, which is extremely amenable to this kind of design. Unit testing so far has been pretty painless, too. Creating a new server instance is as easy as calling a function to get a server object with the endpoints specified. Start the server in setup, close it in teardown. Node.js makes this stuff super easy to automate, provided you can learn to live with callbacks and promises.
First used a similar design on an internal project a couple of years ago. I wrote a long comment on here a while ago that got a good response. This is what most people are referring to when they talk about 'single page webapp', which needs a better acronym, like Ajax
'Single page web app' makes me think of hash tag routing. I think Static+API or S+API (whatever) is like a typical web site with multiple pages. Whats unique is the layout and content are requested separately.
I do use a similar approach with html/css/javascript + json in a recent app, though the static content and the json data are served from the same server. With aggressive cache serving the static content is not a problem.
CORS is supported in most browsers today. Even IExplorer 8 has support for it. If you really want older browsers too, you can always fallback to flXHR.
This is excellent news. S3 turns out to be an extremely inexpensive static hosting service, yet very scalable. Now I don't have to run Apache on an EC2 instance to host static files.
This would be great for client side JS apps that don't need any write-back to the server. Local storage is pretty much supported in all modern browsers.
S3 is designed for 99.99% availability, and carries a service level agreement providing service credits if a customer’s availability falls below 99.9%. See (http://aws.amazon.com/s3-sla/) for more info.
We managed to get the majority of the static images and JS running off CloudFront back then, but were always stuck serving html from our EC2 boxes (a combination of what was available from AWS at the time, and the previous one-day minimum timeout of CloudFront). We put a lot of work into optimizing them so that they'd be super lightweight and could be served quickly. It was pretty fast considering that we weren't able to put all of the static-like files into S3/CloudFront.
Now that you can host the whole static bits of your domain through S3/CloudFront, I'd love to give this another shot with a future project. With strongly-named resources (ie: resource name == MD5) being served with one-year expiration times from Amazon's infrastructure, you could build a blazing fast dynamic site without having to spin up a single EC2 box.
Exciting!