rails 4 fragment caching for different views - ruby-on-rails

In my rails 4 app I'm trying to take off with caching, but I'm a bit confused thanks to the different versions of cache-key-settings, cache helpers and auto-expiration.
So let me ask this through few examples. I don't move the examples to different questions on purpose since I feel this way anybody can understand the subtle differences at one glance.
1: latest users in sidebar
I'd like to display the latest users. This of course is the same for all the users in the app and displayed on all the pages. In the railscasts I saw a similar example where it got expired by calling expire_fragment... in a controller. But according to other resources this should expire automatically when something changes (e.g. new user registration). So my question: Am I setting the key properly and will it auto-expire?
_sidebar.html.erb (displayed on all pages in sidebar)
<% cache 'latest-users' %>
<%= render 'users/user_sidebar' %>
<% end %>
_users_sidebar.html.erb
<% #profiles_sidebar.each do |profile| %>
<%= profile.full_name %>
........
<% end %>
2: product show page
I'd like to display a given product (only on show page). This is the same again for all the users, but there are more versions since there are more products. The question is the same again: Am I setting the key properly and will it auto-expire?
products/show.html.erb
<% cache #product %>
<%= #product.name.upcase %>
<%= #product.user.full_name %>
<% end %>
3: products/index (paginated with will-paginate gem)
Here I'd like to cache all the products on a given page of the pagination at once, so products get cached in blocks. This is also the same for all the users, and only gets displayed on the products index page. (Later on I'd like to implement the russian-doll-caching for the individual products on this page.) My question: Am I doing this right and will it auto-expire?
products index.html.erb
<% cache [#products, params[:page]] %>
<%= render #products %>
<% end %>
_product.html.erb
<%= product.name %>
<%= product.user.full_name %>
.....
Example code I tried to use (not sure if it's a good one):
First with index page and with no russian doll.
Second is with russian doll for the show page with comments.

There is a pretty big difference between caching a single record and a collection of records.
You can quite simply tell if a single record has been changed by looking at the timestamp. The default cache_key method works like this:
Product.new.cache_key # => "products/new" - never expires
Product.find(5).cache_key # => "products/5" (updated_at not available)
Person.find(5).cache_key # => "people/5-20071224150000" (updated_at available)
However telling when a collection is stale depends very much on how it is used.
In your first example you only really care about the created_at timestamp - in other situations you might want to look at when records are updated or even when associated records have been inserted / updated. There is no right answer here.
1.
First you would pull N number of users ordered by created_at:
#noobs = User.order(created_at: :desc).limit(10)
We can simply invalidate the cache here by looking at the first user in the collection.
<!-- _sidebar.html.erb -->
<% cache(#noobs.first) do %>
<%= render partial: 'users/profile', collection: #noobs %>
<% end %>
We can do this since we know that if a new user is registered (s)he will bump the previous number one down a slot.
We can then cache each individual user with russian doll caching. Notice that since the partial is called profile the partial gets passed the local variable profile:
<!-- users/_profile.html.erb -->
<% cache(profile) do %>
<%= profile.full_name %>
<% end %>
2.
Yes. It will expire. You might want to a partial with russian doll caching like the other examples.
3.
For a paginated collection you can use the ids of the records in the array to create a cache key.
Edited.
Since you don't want serve a stale representation of a product that may be updated you would also want to use updated_at as a cache key in the "outer layer" of the russian doll.
In this case it makes sense to load the records entirely. You can ignore my previous comment about .ids.
products/index.html.erb:
<% cache([#products.map(&:id), #products.map(&:updated_at).max]) do %>
<%= render #products %>
<% end %>
products/_product.html.erb:
<% cache(product) do %>
<%= product.name %>
<% end %>

IMHO, cache key is the spirit of the whole concept.
Now let's discuss these examples.
latest users in sidebar: fixed string as cache key
cache_key could be views/latest-users/7a1156131a6928cb0026877f8b749ac9 which the digest 7a11561.. is MD5 of cache block literal.
In this case, the cache only expires when you change the template or anything in this block.
<% cache 'latest-users' do %>
<%= render 'users/user_sidebar' %>
<% end %>
product show page: object as cache key
cache_key could be views/product/123-20160330214154/9be3eace37fa886b0816f107b581ed67, notice the cache is namespace with #{product.to_s}/#{product.id}-#{product.updated_at}.
In this case, the cache expires when (1) product.updated_at changed or (2) cache block literal changed.
And notice the cache differs from different product by id.
<% cache #product %>
<%= #product.name.upcase %>
<%= #product.user.full_name %>
<% end %>
products/index (paginated with will-paginate gem): array as cache key
cache_key could be views/product/123-20160330214154/product/456-20160330214154/d5f56b3fdb0dbaf184cc7ff72208195e not sure about this. but anyway, it should be expand something like this.
In this case, the cache expires when (1) either product-123 or product-456 changed(product.updated_at changed) or (2) cache block literal changed.
And the cache differs from different content of #products by their ids, so there's no need to append params[:page], it will cache each different page because of their different #products content.
<% cache [#products, params[:page]] %>
<%= render #products %>
<% end %>
You could read the article written by DHH, it described Russian Doll Caching very well. And the API doc

Related

Does the `cache do` block belong in the calling template or the called template?

What is the convention for where the cache do block goes?
Does it belong in "calling" template or the "inner" template that the "outer" template renders?
In some examples, I see the responsibility for caching a template B going in the "parent" or "calling" template, A—the template that renders template B. For example, https://blog.appsignal.com/2018/04/03/russian-doll-caching-in-rails.html says:
On the product index, we’ve wrapped each product partial in a cache block.
and shows this example:
# app/views/products/index.html.erb
<h1>Products</h1>
<% #products.each do |product| %>
<% cache product do %>
<%= render product %>
<% end %>
<% end %>
This identical example can also be found at https://edgeguides.rubyonrails.org/caching_with_rails.html#fragment-caching
But isn't that responsibility in the wrong place? That puts the burden on the user of the template rather than on the template itself (to cache itself). Which means that you have to remember, every time you render the product template, to wrap it in a cache block if you want it to be cached. This leads to duplicated code ("not DRY").
Wouldn't it be better, then, to put it in the template itself? Something like this, perhaps:
# app/views/products/_product.html.erb
<% cache product do %>
<article>
<h1><%= product.title %></h1>
…
</article>
<% end %>
There appears to be an examples of a template wrapping its own content in a cache block like this later on in the guide, at https://edgeguides.rubyonrails.org/caching_with_rails.html#russian-doll-caching:
For example, take the following view:
<% cache product do %>
<%= render product.games %>
<% end %>
Which in turn renders this view:
<% cache game do %>
<%= render game %>
<% end %>
but it's not 100% clear in precisely which files those templates actually belong. What file names would those views conventionally live in?
I can easily imagine/assume that the 1º template would live in either app/views/products/show.html.erb or app/views/products/_product.html.erb depending on whether it's an action view or a partial (it doesn't really matter which it is for the purposes of this discussion):
# app/views/products/show.html.erb ?
# app/views/products/_product.html.erb ?
<% cache product do %>
<%= render product.games %>
<% end %>
Where I am actually confused is the 2º template:
# app/views/games/_game.html.erb ?
<% cache game do %>
<%= render game %>
<% end %>
From context, I think we know this is a partial for a game (rendered once for each game in the collection passed in the _product template), so I guess it would live at app/views/games/_game.html.erb by convention.
But if that is the case, which is the 3º template that it is rendering here with render game?? It looks like it is rendering a partial for game — but aren't we already inside of the partial for game? Wouldn't this result in infinite recursion (games/_game.html.erb rendering itself recursively)?
Am I missing something obvious? Or is this just a poor example that needs to be updated in the guide? If so, what would an improved example look like?

rails4 caching naming conventions

I have a rails 4 app. I have to differentiate the different cache keys somehow but don't know the naming conventions.
FIRST EXAMPLE:
I have a task model with index, completed_tasks and incoming_tasks actions. A have the same instance name (#tasks) though because of the pagination.
At the moment the cache-keys are named like below. My questions: 1. Is the cache-key structure good enough? 2. Is it important in which order I put the parts of the key in the array? For example [#tasks.map(&:id), #tasks.map(&:updated_at).max, 'completed-tasks'] is better than ['completed-tasks', #tasks.map(&:id), #tasks.map(&:updated_at).max]?
completed_tasks.html.erb
<% cache([#tasks.map(&:id), #tasks.map(&:updated_at).max, 'completed-tasks']) do %>
<%= render #tasks %>
<% end %>
tasks.html.erb
<% cache([#tasks.map(&:id), #tasks.map(&:updated_at).max]) do %>
<%= render #tasks %>
<% end %>
incoming_tasks.html.erb
<% cache([#tasks.map(&:id), #tasks.map(&:updated_at).max, 'incoming-tasks']) do %>
<%= render #tasks %>
<% end %>
SECOND EXAMPLE:
I also have problem with the naming conventions of the russian-doll-caching:
products/index.html.erb
<% cache([#products.map(&:id), #products.map(&:updated_at).max]) do %>
<%= render #products %>
<% end %>
_product.html.erb
<% cache(product) do %>
<%= product.name %>
....
<% end %>
Is this version good enough or I always should put some string in both the outer and inner caching key array to avoid problems with similarly named cache-keys on other pages. For instance I plan to put <% cache(#product) do %> on the profile#show page which would be exactly the same like the inner caching in my example. If the key has to be different what the rails convention is to name the inner an outer cache keys?
First, according to Russian Doll Caching article, I think it's not necessary to set the cache_key on your own, you could just leave it to rails, it generates cache_key auto. For example, the cache_key of #tasks = Task.incoming should differ from #tasks = Task.completed with something like views/task/1-20160330214154/task/2-20160330214154/d5f56b3fdb0dbaf184cc7ff72208195e and views/task/3-20160330214154/task/4-20160330214154/84cc7ff72208195ed5f56b3fdb0dbaf1
cache [#tasks, 'incoming_tasks'] do
...
end
Second, As for the namespace, though the template digest will be the same but the #tasks digest will be different. So it seems to be okay without namespace in this case.
cache #tasks do
...
end
Third, when it comes to namespace, I prefer prefix rather than suffix. i.e.
cache ['incoming_tasks', #tasks] do
...
end
As the second example, I think this would do just fine.
<% cache #product do # first layer cache %>
<% cache #products do # second layer cache %>
<%= render #products %>
<% end %>
<% cache #product do # second layer cache %>
<%= product.name %>
....
<% end %>
<% end %>
The caching key for app/views/products/show.html.erb will be something like views/product/123-20160310191209/707c67b2d9fb66ab41d93cb120b61f46. That last bit is a MD5 of the template file itself and all of its dependencies. It'll change if you change either the template or any of the dependencies, and thus allow the cache to expire automatically.
For further reading: https://github.com/rails/cache_digests
It's best practice to always put a string at the end. It really just needs to be something that makes sense to you.

When doing fragment caching, should we cache active record queries as well?

If one is fragment caching a part of the page that has content loaded from models in the controller. Should these queries also be cached?
Does this mean there will be two types of caching: fragment and active support caching for two different types of data?
For example. In the view I could have:
<% cache 'videos_and_photos', :expires_in => 24.hours do %>
<div id="videos">
<% #videos.each do |video| %>
...
<% end %>
</div>
<div id="photos">
<% #photos.each do |photo| %>
...
<% end %>
</div>
<% end %>
and in the controller:
Rails.cache.fetch('videos', :expires_in => 24.hours) do
#videos = Video.where(...)
end
Rails.cache.fetch('photos', :expires_in => 24.hours) do
#photos = Photo.where(...)
end
My only grip with this is, if one cache expires first, then the data will display inconsistently. Is there a better way to go about this?
Normally one should not use business logic or queries in views, but in this case it is possible to make an exception. Just define a special method for your query, for instance Video.your_method, and use it in the view. This seems to be the cleanest way to do it:
<% cache 'videos_and_photos', :expires_in => 24.hours do %>
<div id="videos">
<% Video.your_method.each do |video| %>
...
<% end %>
</div>
Otherwise you are caching data which belongs together in two different places, which may lead to unpredictable results.
I have created a gem to avoid having to query the database if a cache exists.
https://github.com/rovermicrover/FlagpoleSitta
It stores all the database calls in Procs, and then only calls them if the cache doesn't exist. It then invalidates all related caches when an object gets updated. I got the idea from the following stackoverflow post.
Best way to combine fragment and object caching for memcached and Rails
While my gem might be over kill, and I still considered it in beta, the over all strat from the above stack overflow post should help.

Render rails partial multiple times on same page

I have a partial that I'm rendering twice on the same page, but in two different locations (one is shown during standard layout, one is shown during mobile/tablet layout).
The partial is rendered exactly the same in both places, so I'd like to speed it up by storing it as a variable if possible; the partial makes an API call each time, and the 2nd call is completely unnecessary since it's a duplicate of the first API call.
Is there any way to store the HTML from the returned partial as a variable and then use that for both renders?
Edit: I'm hoping to do this without caching, as it is a very simple need and I'm looking to keep the codebase lean and readable. Is it possible to store the partial as a string variable and then reference that twice?
<% content_for :example do %>
<%= render :your_partial %>
<%end%>
then call <%= yield :example %> or <%= content_for :example %> wherever you want your partial called.
One option would be to use fragment caching. After you wrap the partial with a cache block, the second call should show the cached version of the first. For example:
<% cache do %>
<%= render(:partial => 'my_partial') %>
<% end %>
... later in the same view ...
<% cache do %>
<%= render(:partial => 'my_partial') %>
<% end %>
To store the result of the render to a string, you could try the render_to_string method of AbstractController. The arguments are the same as for render.
partial_string = render_to_string(:partial => 'my_partial')
I'm adding an answer to this old question because it topped Google for a search I just made.
There's another way to do this now (for quite a while), the capture helper.
<% reuse_my_partial = capture do %>
<%= render partial: "your_partial" %>
<% end %>
<div class="visible-on-desktop"
<%= reuse_my_partial %>
</div>
<div class="visible-on-mobile"
<%= reuse_my_partial %>
</div>
This is simpler and slightly safer than using content_for because there is no global storage involved that something else might modify.
The rails docs linked to use instance #vars instead of local vars because they want it to be available to their layout template. That's a detail you do not need to worry about, because you're using it in the same template file.

will_paginate problem with action and fragment caching

i have added action caching to my index part and listing 9 records in a page
will_paginate dosent work, and renders same set of recors again and again.
and same issue with fragment caching
please suggest some solution for this..
thanks
try this: Rails action caching with querystring parameters
Unless you have a very basic Rails app, I would recommend using fragment caching as it's a much easier to use and maintain compared to action/page caching. If you decide to use fragment caching, you could add something like the following to your index template:
<% #models.each do |model| %>
<% cache ["v1", model] do %>
<%= render model %>
<% end %>
<% end %>
This will render the partial _model.html.erb and cache the result. For details about the cache mechanisms in Rails, I suggest reading Rails Guides.
A more aggressive caching strategy would be to cache all the models on a single page. That could be done by setting the current page to an instance variable in the controller:
def index
#page = params[:page]
#models = ...
end
Now in your template you can include the page in the composite cache key:
<% cache ["v1", cache_key_for(#models), #page] do %>
<% #models.each do |model| %>
<%= render model %>
<% end %>
<% end %>
<% end %>
cache_key_for is a helper that computes a cache key for a set of models. It could be defined as:
def cache_key_for(models)
"#{models.count}-{models.map(&:updated_at).max.utc.to_s(:number)}"
end

Resources