What I thought I knew

OK so I’ll admit that there’s not much that I thought I knew. When you say Asset Pipeline my mind thinks of CSS, JavaScript, Images, Fonts getting moved around and served with a “fingerprint” to enable sensible caching.

I knew that there was a precompiling step when deploying to a production environment. The precompiling step would update references to files like application.css to use application-<fingerprint>.css

What I wanted to know

There are a few points that I was aware of but had never looked into finding out more about.

I know that the precompile step output some files to serve, but I wasn’t sure where these assets were stored. From the documentation assets are output into the public/assets path. There is also an option to allow your web server (NGINX/Apache) to serve these files which help with performance.

I knew that there was a rails precompile:assets step but I didn’t know how this realted back to the yarn:build step that css-bundling and js-bundling use. This became fairly straightforward in that css-bundling and js-bundling hook into the precompile command to call yarn:build before the files are transpiled.

There are a lot of files that can be magically included when working with assests. I didn’t know how Rails knew where to look for these files. This impacted me recently while trying to workout how to include images and fonts from a node_modules/package. Rails has a manifest.js which uses “directives” to include files and folders, link_tree and link_directory declarations. Rails also looks into any gems that declare themself as a Rails::Engine when including assets.

What I know now

I was surprised to find out that the asset pipeline (Sprockets), concatenates CSS files into one file. As mentioned it does this using the link_tree - for linking a given folder and it’s nested folders - and link_directory - for linking a specific folder - directives.

The asset pipeline treats index.css files as manifest files, meaning that you can not use index.css as a stylesheet filename.

CDNs seem to be very easy to set up. Rails needs to know the origin hostname - the url that the base CDN will request the files from - and that’s it. Caching works in the same way as serving locally.

As a performance boost you can set a x-sendfile header which will allow your web server (works on NGNIX and Apache) to serve the assets rather than having to run through the Rails app. This is a simple config to set in your production.rb