Caching Principles

Caching Principles

From the very beginning Lovely.IO was designed for effective content delivery. It is backed up by the Amazon's CloudFront service for fastest and seemingness assets delivery across all the great wide web.

Use cdn.lovely.io!

If you want to have all the advantages of shared CDN hosting, use cdn.lovely.io! Don't spawn your own servers, don't drop lovely.io modules into static files and so on.

cdn.lovely.io is hooked directly to the Amazon's servers across all the world and will keep serving content from its own cache even if lovely.io itself goes down.

Production caching

By default, especially in production mode, you supposed to define all version numbers explicitly, for example

<script src="http://cdn.lovely.io/core-1.1.0.js"></script>
<script type="text/javascript">
  Lovely(['dom-1.2.0', 'ajax-1.1.1'], function($, Ajax) {
    // your application code
  });
</script>

In this case, lovely.io will set the expiration date in 1 year. The idea is that once you specified all the versions, your application structure will be solidified and none of the further changes in the modules will affect it.

Development mode

If you just want to write a quick example, or for some reason want to live on the edge, you can specify module names without version numbers

<script src="http://cdn.lovely.io/core.js"></script>
<script type="text/javascript">
  Lovely(['dom', 'ajax'], function($, Ajax) {
    // your application code
  });
</script>

In this case lovely.io will set the cache TTL for 1 day.

NOTE: in this case lovely.io will always send you the latest available version of the module. It is good for quick spikes but you shouldn't use it in production because module dependencies might get out of sync and your application will break.

Use the full definitions with version numbers whenever you can. That will keep you safe and cached.