I'm currently wrestling with a lot of all.js / all.css missing hits on a rails 2 upgraded to 3 app on Heroku. I'd prefer not to have a dozen or so stylesheet links per request, and also don't want to statically bundle -> s3 the files as part of the deploy.
This seems like a familiar problem, preparing some content specific to a url and sending it back to the browser.
Rather than using an external bundling app as part of a deploy script etc, has anyone considered having rails generate these files on-the-fly and use varnish to cache them (since it's cleared on redeploy, which is when the css/js files would change)?
My question is whether this has been done already & I just failed to google it, or if it sounds like a dumb idea, why?
Even better: Rails 3.1 asset pipeline does exactly this, and Heroku handles precompilation and caching for you.
Related
I love to develop without the internet. But the problem is we cannot get image/css/javascript assets files by CDN.
I think the best way is
On development env, try to get such asset files from CDN first, and
If possible, use it and cache it
If impossible, use cache
Alternative is
Keep all such asset files in the repo too
Use them on development env, use CDN on production env
But implementing these takes a bit time and I believe many developers face this problem.
So I want to know your way to solve this problem. If any good gem, it's fantastic.
My env is Rails4 without assets pipeline nor turbolinks.
Before deploying a new version of my app on Heroku, I need to do this in my console (for css and js to work on Heroku): RAILS_ENV=production bundle exec rake assets:precompile.
I just picket this code line from a forum, and I my questions is:
1) Why do I need to do this?
2) Is it possible to implement something more permanent in my Rails code so it does this precompiling automatically (so I don't need to write it manually every time I do some changes in my css or js files)?
1) Why do I need to do this?
There are lot of js files and css file in rails app generally. The above command compress and minified all those files which will reduce the number of requests that browser makes to render a web page. Web browsers are limited in the number of requests that they can make in parallel, so fewer requests can mean faster loading for your application.
More
2) Is it possible to implement something more permanent in my Rails code so it does this precompiling automatically (so I don't need to write it manually every time I do some changes in my css or js files)?
Yes. Heroku automatically compiles your assets if you dont include public/assets/manifest.yml for rails 3 and in rails 4 it is public/assets/manifest-<md5 hash>.json
More
Related Answer : Automatically precompile assets before pushing to Heroku
In your production.rb
config.assets.compile = true
I am trying to deploy my Rails 3.2 app to a subdirectory, /support, on an Apache server. Consulting the various posts, the only solutions that seem to have helped involve setting up a symbolic link on the server and changing css image references slightly (two dots '..' required before /assets in the css url references--I can't seem to find the post on that one now). I am getting success in deployment to production with Capistrano, but then strangely after awhile something changes, the /support reference breaks and the stylesheets don't load. Any suggestions?
oh no, please don't deploy rails as sub-uri in that way, you are making yourself in trouble.
So far as I see, ( according to this post: http://kb.site5.com/ruby-on-rails/how-to-deploy-a-rails-3-application-to-a-sub-directory/ ) you created soft links, modified your routes.rb, and changed RAILS.root in environment.rb, and also changed your assets files... all of these make your rails app messed up.
I suggest you use 'passenger' as rails server and checkout this post: http://www.modrails.com/documentation/Users%20guide%20Nginx.html#deploying_rack_to_sub_uri, it's quite easier and simplier
I am moving a rails app to Heroku.
Heroku doesn't seem to support page caching.
So I generated cached pages on my development machine and checked them in to Heroku.
For example, /about_us generates public/about_us.html.
But when I call /about_us, public/about_us.html doesn't seem to be called.
Should my trick work?
Thanks.
Sam
In Rails 3, you'll be using the assets pipeline, so your assets--about_us.html--will be precompiled and put into a folder, WITHIN your public folder. Usually, this file will not be located at 'public/about_us.html'.
With your assets now precompiled, they'll be statically available and appended with an id, that will uniquely identify this asset until it is changed. With the unique signature, caching will occur on both Heroku's (last I checked) as well as within browsers.
Basically, the asset pipeline is doing this already for you.
I'm using rails page caching (with memcache) on one page of my website. The cache has an expiration time of 24 hours. But the cache value contains some assets named asset-FINGERPRINT.css
If I run a deploy during the 24 hours of cache existence, the fingerprint changes but I still have the old version in my cache value. So I get 404s when I try to fetch the assets.
I have multiple versions of the page so I can't manually expire the page after each deploy. My question is, has anyone encountered the same problem and what was the solution?
If I were you I wouldn't be deleting the old versions of assets. In addition to the problem you are facing, you probably don't want the old version of the HTML being used alongside new CSS or Javascript - that could easily break things if you aren't careful.
Because each version of the assets has a fingerprint you can have the current and several previous versions available concurrently. One way of doing this is by symlinking public/assets to a folder that doesn't change between releases (If you deploy using capistrano this happens for you if you use the default asset pipeline integration).
All that said, being in a situation where you feel you can't ever clear the cache feels precarious to me.