14 October 2012

I enjoy planning for success with web applications. Prepping scalability has the benefit of being objectively achievable, which is very nice when I'm just experimenting as a hobby. Even if the web application fails, at least it will be fast! I have some JavaScript code to make public, but making it available in an efficient method can be tricky.

Once the library has become stable and established, there are available systems like the Google CDN, the Microsoft CDN, and cdnjs.com (sponsored by CloudFlare). Given that my JS code is relatively new, it seems premature to bother trying to get into one of those systems. Working directly with CloudFlare seemed appropriate, but the terms of service do not allow JS-only hosting -- it specifies that the site should be primarily for HTML documents.

I've started using Github for managing the code, and some people treat Github as a CDN. Using GoogleCode.com is pretty standard, and linking directly to raw.github.com is becoming more common. However, I wanted to provide an alternate CDN that I can have more control over. After moving past the options above, Amazon's CloudFront was the clear winner among remaining options, especially since I already rely on other Amazon Web Services.

Key highlights in the setup

  1. Use a new domain (or subdomain) for the CDN that does not have any cookies from the site (or other sources). That is an important aspect of the CNAME setup, which is the alternative to using the cloudfront domain subdomain.
  2. Use CloudFront behaviors to limit paths that are forwarded, to filter cookies, and to filter query strings.
  3. Use Apache to confirm that the static files exist before serving (and/or disable dynamic languages for the virtual host):
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^.*$ - [L]
  4. Force cache headers for all requests (removing other headers was a good tip too, although less important).
    Header set Cache-Control "max-age=7200, must-revalidate"
  5. Point the default CloudFront behavior point at an empty S3 bucket (minimize the impact of 404 errors).

blog comments powered by Disqus