Databases
StackOverflow2013
Postsdbo
POStatic asset caching on Heroku with Jammit by changing ActionController::Base#page_cache_directory
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POStatic asset caching on Heroku with Jammit by changing ActionController::Base#page_cache_directory
    primarykey
    data
    text
    <p>I'm attempting to use Jammit for packaging CSS and JS for a Rails app deployed on Heroku, which doesn't work out of the box due to Heroku's read only file system. Every example I've seen of how to do this recommends building all the packaged asset files in advance. Because of Heroku's Git-based deployment, this means you need to make a separate commit to your repository every time these files change, which is not an acceptable solution to me. Instead, I want to change the path that Jammit uses to write the cached packages to <code>#{Rails.root}/tmp/assets</code> (by changing <code>ActionController::Base#page_cache_directory</code>), which is writable on Heroku.</p> <p>What I don't understand is how the cached files will be used without hitting the Rails stack every time, even using the default path for cached packages. Let me explain what I mean:</p> <p>When you include a package using Jammit's helper, it looks something like this:</p> <pre><code>&lt;%= include_javascripts :application %&gt; </code></pre> <p>which generates this script tag:</p> <pre><code>&lt;script src="/assets/application.js" type="text/javascript"&gt;&lt;/script&gt; </code></pre> <p>When the browser requests this URL, what actually happens is that it gets routed to <code>Jammit::Controller#package</code>, which renders the contents of the package to the browser and then writes a cached copy to <code>#{page_cache_directory}/assets/application.js</code>. The idea is that this cached file is built on the first request, and subsequent requests should serve the cached file directly without hitting the Rails stack. I looked through the Jammit code and I don't see how this is supposed to happen. What prevents subsequent requests to <code>/assets/application.js</code> from simply routing to <code>Jammit::Controller</code> again and never using the cached file?</p> <p>My guess is that there's a Rack middleware somewhere I'm not seeing that serves the file if it exists and forwards the request on to the controller if it doesn't. If that's the case, where is that code? And how would it work when changing <code>ActionController::Base#page_cache_directory</code> (effectively changing where Jammit writes cached packages)? Since <code>#{Rails.root}/tmp</code> is above the public document root, there's no URL that maps to that path.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USJimmy Cuadra
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POStatic asset caching on Heroku with Jammit by changing ActionController::Base#page_cache_directory
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POStatic asset caching on Heroku with Jammit by changing ActionController::Base#page_cache_directory
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POStatic asset caching on Heroku with Jammit by changing ActionController::Base#page_cache_directory
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload