Ticket to Ride

Ruby on Rails (RoR) version 5.1 [1] introduced Secrets, a mechanism designed to ensure that a programming team can store encrypted passwords or API keys in a public repository. However, the community's response to this feature proved to be mixed. Many found it useless right from the start, because the team members still had to exchange a secret encryption key. Others found it practical, but still a little too cumbersome to set up and use.

At least for the latter group, Rails 5.2 (Figure 1) is a good thing: The developers abolished Secrets and replaced it with simpler credentials. Thus RoR automatically generates a central master key and stores it in the config/master.key file. Of course, this file must never end up in a repository, which is why it is entered in the .gitignore file by default. The user edits the credentials on the command line with

EDITOR=vim rails credentials:edit

in YAML format (Listing 1). The credentials can then be retrieved, as in Listing 2, with the Rails application and console, where the name of the application in the example is Shop.

# aws:
# access_key_id: 123
# secret_access_key: 345
# Used as the base secret for all MessageVerifiers in Rails,
# including the one protecting cookies.
 **
secret_key_base: 9846dad34a3168?68d634f
foobar: test

$ rails console
Running via Spring preloader in process 19662
Loading production environment (Rails 5.2.0)
>> Shop::Application.credentials.foobar
=> "test"
>> exit

Surprise: Active Storage

Like most of the Rails features, the new Active Storage by Basecamp, led by Rails inventor David Heinemeier Hansson, sloshed over into the toolset. Active Storage is a framework for uploading files via the web browser and then managing them using Rails. This is possible for your own server as well as for cloud servers and services (e.g., Amazon S3, Google Cloud Storage, and Microsoft Azure Cloud File Storage). Active Storage also processes graphics autonomously. One good example is the ability to create a thumbnail automatically for an avatar image.

However, the introduction of Active Storage has surprised some Rails developers because at least two established solutions for the file upload problem, CarrierWave [2] and Paperclip [3], already exist. So why reinvent the wheel?

The answer lies in a central combination of functions and a new functionality: Active Storage users upload files directly from the browser to the cloud provider with the use of JavaScript. You no longer need to detour via the Rails server, which is blocked for an unnecessarily long time by these kinds of uploads. This blockade proved to be a problem with many Rails applications on cloud hosting services, such as Heroku, because they usually drop the connection to the client after 30 seconds.

There is some disagreement on whether the file upload functionality is intended to be a central part of RoR and whether Active Storage would not be better suited as a normal external gem. In any case, Active Storage makes uploading files easier for programmers and users.

Bootsnap

The Bootsnap [4] gem, created by major Rails user Shopify, now uses Rails 5.2 by default. This library reduces the start time of a Rails application on average by 50 percent. Shopify even reports a reduction of 75 percent, or more specifically, from 25 seconds down to an impressive 6.5 seconds, for its own core monolithic platform.

Content Security Policy

Rails has long offered built-in XSS and cross-site request forgery (CSRF) protection. Version 5.2 looks to extend this to include a new domain-specific language (DSL) that assigns access rights on the basis of resources. This undertaking is not trivial and can give newcomers headaches. For example, Action Cable does not work in development mode with a fresh Rails application, so the admin has to use

p.connect_src :self, :https, 'ws://localhost:3000'

to enable it manually in config/initializers/content_security_policy.rb.

HTTP/2 Early Hints

HTTP/2 is becoming increasingly widespread, as a consequence of which the demand for the push feature is also growing in the Rails community. Unlike HTTP/1.1, where a web client can only fetch files from the web server using HTTP GET, HTTP/2 also allows the web server to deliver unsolicited files actively to the web browser, which also increases the web performance of a web application.

Rails Core member Aaron Patterson has incorporated HTTP/2 into the new Rails version with the help of Eileen Uchitelle so that the web server above the Rails layer is tasked by the Rails framework with pushing stylesheets and JavaScript assets to the web browser.

This area is likely to see a lot of movement in future Rails versions. Thus far, Rails asset management is still building on the basic idea for HTTP/1.1 of sending one large file, rather than many small files that HTTP/2 can send.

Redis Cache Store

The new Redis Cache Store also comes from the Basecamp lab. With the new gem, Jeremy Daer has created a very stable and fast way to address Redis as a cache in distributed mode, which allows data to be stored on different Redis servers.

Those who rely on the Russian matryoshka doll strategy for fragment caching can look forward to an improved cache lifetime by default, and without additional work thanks to key recycling and compression.

Conclusions

Ruby on Rails 5.2 is a minor update and should integrate easily into existing Rails applications. The new version is not a revolution, but a handy set of solid improvements. Active Storage is likely to be the biggest change and optimization for most Rails users. Also on the horizon is Ruby 2.6, which is in a preview release (see the "Ruby 2.6" boxout).