current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
up vote 12 down vote favorite

Given that

  • CDNs are a Good Thing because they can serve resources closer to the client, the client can cache them, and you can reduce load on your own server.
  • In recent browsers, loading resources from third-party servers does not decrease security thanks to Subresource Integrity (SRI).
  • CDNs may be down or blocked in some countries, and are not available when developing offline1.

I think it is compelling to use CDNs, but also to be prepared for them to be unavailable. This blog post gives a nice introduction to different approaches for providing fallbacks. If you look at the Basic example, you can see that it already contains quite a bit of boilerplate code to provide fallbacks for just jQuery and Bootstrap, while the favored solution suggests using Fallback.js, which seems to be largely unmaintained for the past year. Similarly, the most relevant SO question for the topic is only about providing a fallback for jQuery.

However, in most real-world projects, I would expect to have 5 or more js/css resources, so I feel like you shouldn't have to repeat some messy boilerplate to provide fallbacks for all of them. Furthermore, every time you add or update a resource, you now have to

  • Update the CDN link
  • Update the local fallback copy by manual download or changing version in npm/bower config
  • Update the link to the fallback
  • Update the SRI hash

Whereas in the Ideal World, I would expect to add/update the resource in one configuration file, and have all the other steps execute automatically (and then run tests to see if the update broke anything).

Is there already an established workflow to achieve this?

Or are CDNs, and especially SRI, still too recent?

Or do most people simply not care to provide fallbacks for CDN resources?

1. Although you could have a dev build that doesn't rely on CDNs, but I also consider that a form of fallback, since it also needs to be maintained.

share|improve this question

This question has an open bounty worth +50 reputation from ValarDohaeris ending in 4 hours.

This question has not received enough attention.
    
I haven't fiddled with CDNs myself, but it does seem like it ought to be possible to automate all but one of those steps as part of one's standard deployment process. – Ixrec Mar 30 at 13:11
    
is Fallback.js unmaintained because it already works perfectly? Software doesn't have to be changed every 5 minutes if it already works. – Robert Harvey Mar 30 at 15:05
    
No, I would argue it doesn't work perfectly, otherwise I don't see why the author would have started to work on a new version 2. I would also claim that a library that is so essential for a website to work correctly has to be continuously tested and improved. From what I understand, adding more tests and CI on different browsers is actually one of the main goals of version 2. It also currently lacks support for SRI. – ValarDohaeris Mar 30 at 15:16
up vote 1 down vote

I think you perhaps misunderstand how larger sites which might need this kind of resilience use CDNs.

it's not just a matter of hosting jQuery or some images. The majority of the site will be hosted on the CDN, with only dynamically generated things like payment pages or shopping baskets being hosted on the 'primary webfarms'

Even these are moving more and more to being processed locally with JS and cookies to display user specific stuff without hitting server side processing.

If a CDN fails and you start getting all the traffic passed to your webserver, it is likely to fall over, otherwise you didn't really need the CDN.

share|improve this answer
    
You can have a CDN backup that automatically scales up. And with CDN its not about the traffic but also about being more comfortable and cost reduction. I think CDN also makes sense on low traffic website, why shouldn't it? – Sjoerd222888 yesterday
up vote 1 down vote

The site I work on our CDN has become more and more important to the site. In the beginning we simply used it to cache Images/CSS/JS. At this stage we had a config property that rewrote the host name of these resources from www.mysite.com/ to www.cdn.com/ so if the CDN went down we could simply change this host value or turn it off completely and leave the urls pointing to our webserver.

However we have now moved on to caching basically entire pages with personalised content being loaded in via AJAX. Our CDN has become essential to our site and we could as much run without it as we could our own HTTP servers. We pay our CDN good money in part because of there resilience and SLA promises of uptime therefore putting time and effort into fallbacks seems a waste of time. We do have a DR plan in place just incase there is a major issue with our provider but it is not a simple automated process and would see a period of outage as we migrate to our fallback CDN.

So in answer to your question it depends on how integral to your site the CDN is. If it is just your assets you are putting into the CDN and assuming your http servers could handle the load of serving this content out then you can use a config switch to essentially turn on or off the CDN. Coupled with a monitoring tool you can automate that switch being on or off.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.