Seeing the wood for the trees with Rails asset serving

Every web developer has run into this at some point.

You’re working on a site or an app, and you need to watch the logs, but all you can see are the requests for the static assets — images, stylesheets, fonts, and so on — making it impossible to see the log entries you care about.

We ran into this too, back in 2012. We were building apps on Rails, using the Asset Pipeline, and whenever we wanted to look at the logs generated by our controllers, they’d be swamped with requests for the assets on each of the pages.

Although it does now, Rails’ Asset Pipeline at that time didn’t provide a standard way to do this. Our Head of Frontend, Dmitry Karpunin, started looking for a solution to the problem, and found the core of a solution on StackOverflow: a monkey-patch that could be added to a project to filter the log output.

The patch worked by hooking Rails::Rack::Logger and inspecting the PATH_INFO in the request environment passed to the logging method: if it matches the static assets regular expression, temporarily bump the log level to ERROR, before allowing the call the real Rails::Rack::Logger to continue as normal, before restoring the previous log level.

It’s important to note that this worked only by adjusting the logging priority threshold, not by preventing the logging altogether — this means that it would be as robust as possible in the face of unexpected changes to Rails in the future (including from other potential monkey-patches).

Monkey-patches are never ideal, and monkey-patches that you apply to every project you work on are a recipe for disaster. So, whilst this did seem to be the only feasible cure for the asset-logging plague under Rails 4, it needed a better delivery system. At least if this solution was packaged up, then it could be maintained once and used by any developer who needed it.

So, Dmitry, along with a group of other developers, assembled the quiet_assets gem.

Word quickly spread, and before long, thousands of developers were using it every day to keep their logs free of noise.

In fact, quiet_assets was so popular, and solved a problem that was so common for developers, that like all the best software, it served its purpose admirably for several years until it was rendered entirely obsolete.

By 2016, Rails had evolved. On the 9th of June that year, Rafael França opened this Pull Request on Sprockets, a gem in Rails that provides the framework for compiling and serving static frontend, which added quiet_assets’ functionality to Sprockets itself, in his words “Basically a deprecation of the quiet_assets gem”.

And now, another five years after quiet_assets was deprecated, we have ended support for the gem altogether. Its git repository will remain available on Github, but there will be no more commits, issues, nor pull requests, and it will exist only in read-only archived mode.

Of course, there are some legacy Rails 4 projects out there still, but they are just that: legacy. And, realistically, us no longer committing to quiet_assets is almost certainly the least of their problems! 

The quiet_assets gem was essential for the developers’ community & improving the development experience. We always care about how friendly the infrastructure, the ecosystem of the project is, how convenient, fast it is for the developers. The work on quiet_assets proves our initiative & understanding of what developers love and need. Reach out to us via the form below if you need to update your project to the latest versions of the technology stack!