Asset statico Caching su Heroku con Jammit cambiando ActionController :: Base # Pagina_Cache_Directory

Question

Sto tentando di utilizzare Jammit per il confezionamento di CSS e JS per un'app Rails implementata su Heroku, che non funziona fuori dalla scatola a causa del file system di sola lettura di Heroku. Ogni esempio che ho visto su come fare ciò consiglia di costruire in anticipo tutti i file di risorse confezionati. A causa della distribuzione basata su Git di Heroku, ciò significa che è necessario effettuare un impegno separato per il tuo repository ogni volta che questi file cambiano, che non è una soluzione accettabile per me. Invece, voglio cambiare il percorso che Jammit utilizza per scrivere i pacchetti memorizzati nella cache a #{Rails.root}/tmp/assets (cambiando ActionController::Base#page_cache_directory), che è scrivibile su Heroku.

Quello che non capisco è il modo in cui i file memorizzati nella cache saranno utilizzati senza colpire la pila dei binari ogni volta, anche usando il percorso predefinito per i pacchetti memorizzati nella cache. Lasciami spiegare cosa intendo:

Quando includi un pacchetto usando l'helper di Jammit, sembra qualcosa del genere:

<%= include_javascripts :application %>

.

che genera questo tag script:

<script src="/assets/application.js" type="text/javascript"></script>

.

Quando il browser richiede questo URL, ciò che accade in realtà è che viene indirizzato a Jammit::Controller#package, che rende il contenuto del pacchetto al browser e quindi scrive una copia memorizzata nella cache su #{page_cache_directory}/assets/application.js. L'idea è che questo file memorizzato nella cache è stato costruito sulla prima richiesta e le richieste successive dovrebbero servire direttamente il file memorizzato nella cache senza colpire la pila dei binari. Guardai attraverso il codice jammit e non vedo come dovrebbe accadere questo. Ciò che impedisce le richieste successive a /assets/application.js dal semplice routing a Jammit::Controller di nuovo e mai utilizzare il file memorizzato nella cache?

La mia ipotesi è che ci sia un middleware del rack da qualche parte non vedo che serve il file se esiste e inoltra la richiesta al controller se non lo fa. Se è così, dov'è quel codice? E come funzionerebbe quando si cambia ActionController::Base#page_cache_directory (cambiando efficacemente in cui Jammit scrive i pacchetti memorizzati nella cache)? Poiché #{Rails.root}/tmp è sopra la radice del documento pubblico, non c'è URL che mappa in quel percorso.

Answer 1

Grande domanda!Non ho impostato questo stesso, ma è qualcosa che ho intenzione di esaminare, quindi mi hai spinto a farlo.Ecco cosa ci proverei (Darò un tiro a presto, ma probabilmente ti batterò ad esso).

config.action_controller.page_cache_directory = "#{Rails.root}/tmp/page_cache"

.

Ora cambia la tua configurazione in:

require ::File.expand_path('../config/environment',  __FILE__)
run Rack::URLMap.new(
   "/"       => Your::App.new,
   "/assets" => Rack::Directory.new("tmp/page_cache/assets"))

.

Assicurati di non avere nulla in public/assets, dal momento che non sarà mai stato prelevato.

Note:

.
• Questo è per le rotaie 3. Non sono sicuro della soluzione sotto i binari 2.
• Sembra che Rack::Directory Set Imposta le intestazioni di controllo della cache a 12 ore in modo che Heroku cacherà le tue risorse alla vernice.Non sono sicuro se Jammit lo inserisce nel suo controller, ma anche se non lo è, sarà memorizzato nella cache abbastanza rapidamente.
• Heroku imposta anche anche ENV['TMPDIR'], quindi puoi usarlo invece di Rails.root + '/tmp' se lo desideri.

Answer 2

Questo potrebbe essere utile, è per un gemma diverso ma l'idea è simile e sto cercando di farcela con gli helpers di Asset Plain Asset.

http://devcenter.heroku.com/articles/using-compass .

Purtroppo sembra essere abbastanza difficile da ottenere rotaie per farlo senza patching / riscrivere il modulo Asset Helphers (che assomiglia agli spaghetti accoppiati).