New version

A new version of Fresc is available. The current window will be refresh in seconds...

Technical blog summary

All the technical stuff around how we build and run Fresc.

Check out the product blog for general news about Fresc.

About Fresc

Fresc is an image sharing and review platform for professionnals. Share any kind of images, like logos, website mockups or even PDF exports and get them reviewed by your team or your clients.

Fresc is free for newcomers, no registration needed and it is damn fast.

Lastest articles

Subscribe to the feed to stay informed.

 

A new approach of caching in web applications

 

Update : We are aware that in most case you should use the browser built-in mechanisms, but in realtime applications like Fresc you may want to be able to read, update, or delete your cached data when some events occurs.

Each time we talk about caching, we usually think about client side ressources, SQL requests and fragment caching. But, does it cover everything ?

On Fresc most of the navigation is done via AJAX. For example images switching is a JSON containing url, name and many others metadatas. We noticed that each time a client was requesting again the same image, it was the same response over and over.

Why keep requesting for something already known ? That's why we developed a mechanism to cache responses from Ajax Request, allowing you to avoid making unnecessary requests in order to save time and bandwidth. We bundled this in a jQuery plugin named jquery-ajax-jstorage-cache

How to cache AJAX requests with jQuery

The plugin is a jQuery.ajax prefilter. Since HTML5 allow us to use LocalStorage, we use this space as the cache storage. To manipulate it we use a library called jStorage, which allow us to support a large panel of browsers.

Before each requests, the plugin checks if the requests are already cached, and if so, returns the cached version directly and ends up the request.

Caching AJAX requests can be used in many ways like instant pagination, preload data or even fragment page caching.

Here is a snippet of a Rails application to show you how the stuff works. In this case news are displayed via AJAX and cached for later viewing. Note that this sample is a bit too simple to justify using this method instead of classic HTTP caching.

The index action renders the layout and provide the last news id. An AJAX request is then made to last_news action get the last 5 news. The id is used as a key to validate the cache.

On first visit, response will be cached. Then each time index is visited and cached id matches index's one, no Ajax Request will be triggered.

Use it, Improve it and Fork it

The plugin is available on our Github repository, feel free to fork it and improve it !

Paul Irish already did it and made a version with no dependency on jStorage using directly LocalStorage : jQuery-ajax-localstorage-cache .


 
Fresc branches

Fresc source code is hosted at Github and we use the classical Git branching model: we create branches for almost every features, everything is then merged on our development branch - called pending - and when we are ready to deploy, we merge everything to the master branch using Pull Requests.

Following defunkt's blog post on improving Capistrano deploy task when working with Git, we were deploying in 7 seconds - excluding Resque workers and scheduler restart time -.

This was true before Rails 3.1.

Rails 3.1 brought us the assets pipeline, which is awesome. But there was one major counterpart, when deploying Capistrano was now always running the rake assets:precompile task which made our deployment time increasing from 7 seconds to almost 8 minutes.

Compile only what needs to be compiled.

In order to reduce the amount of time spent precompiling assets, we used a snippet from @iwinux to customize the way the precompiler should behave in order to ignore any file starting with a _. We adopted this naming convention for both JS and CSS files and now any included only files are starting with _.

This made us reducing deployment time from 8 to 4 minutes. Still, that was far from our previous 7 seconds to deploy.

rails-precompile2git : assets precompilation daemon

We explored another possibility, why not removing the precompilation task from capistrano deployment task and alias git to run the precompilation task when pushing. We were back to our 7 seconds deployment time but we quickly figured out that this was counter productive. Git is about being fast and we just had made it really SLOW.

Then, we finally though about another approach. Why not making a daemon that would do the job for us, automatically? We developed the idea and published rails-precompile2git.

On each new commit on a given branch, rails-precompile2git will:

  • break any currently running rake assets:precompile task, hard reset branches
  • fetch changes, merge them to destination branch
  • run rake assets:precompile
  • git add/commit everything
  • push to remote destination branch

We now make our Pull Requests from the development branch to a branch called premaster, which is the branch being watched by our rails-precompile2git instance, which runs the precompilation task and push back to the master branch. With rails-precompile2git we are now back to our 7 seconds deployment time.


 

Welcome to the Tech blog !

 

Hi everyone and welcome to our tech blog. Here at Nectify, we spent lot of time hacking around. Althought we are quite a small team, we hate being driven by deadlines and when we have an idea about how something should be made, we are always eager to try it out.

It is also in our philosophy to share, that is why we already open sourced some of our stuff on Github. We also want to talk about that. Add this blog to your favorites or save its feed, this will be the place where we will keep posting about how we build and run Fresc!

Private project

Choose the organization the project belongs to...

Signup