As any Ruby on Rails enthusiast knows, Rails 6 is just around the corner, packed with a slew of highly anticipated features and enhancements. This article aims to bring you up to speed on the most significant features introduced in Rails 6 and demonstrate how they can streamline your development process, ultimately saving you precious time.

Before we dive in, it’s crucial to note that Rails 6 necessitates Ruby 2.5+ and updated databases. So, if you haven’t already, ensure you have a plan in place to upgrade your systems accordingly.

Ready to explore the new additions? Let’s take a quick tour of the key features in Rails 6 that you’ll likely be leveraging moving forward:

Testing in Rails 6

As professional Ruby on Rails developers, we strive for maximum code coverage. However, testing can become a bottleneck when our test cases grow in complexity, leading to long wait times for execution.

Parallel Testing

Rails 6 tackles this challenge head-on. The ActiveSupport::TestCase now includes a parallelize method, enabling you to run your test suite concurrently using forked processes.

To parallelize your tests, simply add the following to your test_helper.rb:

1

parallelize(workers: 2)

Alternatively, you can modify your existing test running commands. For instance, replace bin/rails test OR bin/rspec spec with PARALLEL_WORKERS=15 rails test OR PARALLEL_WORKERS=15 rspec spec.

This change can be replicated across different CI platforms like Travis, Gitlab, CircleCI, and others.

Hooks are also provided for process creation and destruction, which you can utilize like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

class ActiveSupport::TestCase
  parallelize_setup do |worker|
    # setup databases
  end
 
  parallelize_teardown do |worker|
    # cleanup databases
  end
 
  parallelize(workers: :number_of_processors)
end

Note: For a deeper dive, check out Rails Guides for additional information.

Action Cable Testing

Speaking of efficient testing, let’s shift our attention to Action Cable, a standout feature from Rails 5. Rails 6 elevates Action Cable testing by allowing you to test at various levels: connections, channels, and broadcasts.

Connection tests focus on verifying that connection identifiers are assigned correctly and that invalid connection attempts are rejected:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

class ApplicationCable::ConnectionTest < ActionCable::Connection::TestCase
  test "connects with params" do

    connect params: { user_id: 42 }
    OR
    cookies.signed[:user_id] = "42"
    connect

    assert_equal connection.user_id, "42"
  end
 
  test "rejects connection without params" do
    assert_reject_connection { connect }
  end
end

Channel tests can be written to confirm that users can subscribe to channels and that the channel has an active stream:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

class ChatChannelTest < ActionCable::Channel::TestCase
  test "subscribes and stream for room" do
    # Simulate a subscription creation by calling `subscribe`
    subscribe room: "15"
 
    # You can access the Channel object via `subscription` in tests
    assert subscription.confirmed?
    assert_has_stream "chat_15"
  end
end

Testing broadcasting to channels is now possible as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# app/jobs/chat_relay_job.rb
class ChatRelayJob < ApplicationJob
  def perform_later(room, message)
    ChatChannel.broadcast_to room, text: message
  end
end
 
# test/jobs/chat_relay_job_test.rb
require 'test_helper'
 
class ChatRelayJobTest < ActiveJob::TestCase
  include ActionCable::TestHelper
 
  test "broadcast message to room" do
    room = rooms(:all)
 
    assert_broadcast_on(ChatChannel.broadcasting_for(room), text: "Hi!") do
      ChatRelayJob.perform_now(room, "Hi!")
    end
  end
end

Note: Discover more testing tips here.

Bulk Insert and Upsert

We’ve all encountered scenarios where inserting multiple records simultaneously was necessary, often resorting to workarounds. Rails 6 introduces a new method, insert_all, mirroring the functionality of update_all.

This method bypasses callbacks and executes a single, efficient SQL query. Additionally, the upsert_all method leverages the upsert operation feature supported by modern databases like Postgres. This allows you to optimize your code by minimizing insert queries. Say goodbye to external gems like activerecord-import.

These methods generate a single INSERT SQL query, resulting in a single database call. They operate without instantiating models, triggering callbacks, or performing validations. You can even specify criteria to handle primary key, unique index, or unique constraint violations, with options to skip or execute upsert queries.

Here are a few examples:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

result = Article.insert_all(
  [
    { id: 1,
      title: 'Handling 1M Requests Per Second',
      author: 'John',
      slug: '1m-req-per-second' },
    #...snip...
  ],
  returning: %w[ id title ],
  unique_by: :index_articles_on_title_and_author
)


result = Article.upsert_all(
  [
    { id: 1, title: 'Handling 1M Requests Per Second', author: 'John', slug: '1m-req-per-second' },
    { id: 1, .... }, # duplicate 'id' here
    { id: 2, .... },
    { id: 3, .... }, # duplicate 'title' and 'author' here
    { id: 4, .... },
    { id: 5, .... }, # duplicate 'slug' here
    { id: 6, .... }
  ]
)

It’s worth noting that the methods insert, insert!, and upsert are essentially wrappers around insert_all, insert_all!, and upsert_all, respectively.

Note: For a comprehensive discussion on bulk queries across different databases, check it out.

Switching Between Multiple Databases

Large-scale applications will greatly benefit from this feature: Rails 6 finally introduces built-in support for multiple databases!

This empowers you to design your application architecture as per your needs, whether it’s splitting it into microservices with dedicated databases, maintaining a monolithic structure, or implementing read replicas.

Having this capability readily available has the potential to significantly expedite your development cycles.

Here’s a glimpse of the updated database.yml file structure:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

development:
  primary:
    database: my_primary_db
    user: root
  primary_replica:
    database: my_primary_db
    user: ro_user
    replica: true
  animals:
    database: my_animals_db
    user: root
  animals_replica
    database: my_animals_db
    user: ro_user
    replica: true

Switching between databases is made easy with these methods:

1
2
3
4
5
6
7
8
9

class AnimalsModel < ApplicationRecord
  self.abstract_class = true

  connects_to database: { writing: :animals_primary, reading: :animals_replica }
end

class Dog < AnimalsModel
  # connected to both the animals_primary db for writing and the animals_replica for reading
end

For a deeper dive into this functionality, refer to the comprehensive official GitHub page. Looking ahead, it would be exciting to see database sharding capabilities, similar to this, in future Rails releases.

Action Mailbox

Another exciting addition in Rails 6 is Action Mailbox, which enables you to route incoming emails to controllers within your Rails application, much like mailboxes.

Action Mailbox comes equipped with ingresses for Mailgun, Mandrill, Postmark, and SendGrid. You can also directly handle inbound emails using the built-in Exim, Postfix, and Qmail ingresses. The possibilities are vast, from streamlining help desk processes by automatically creating support tickets to enabling customers to respond directly via email. This feature opens up a world of opportunities for you to explore and tailor to your specific needs.

Let’s illustrate the usage of Action Mailbox with a simple example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

COMMENTS_REGEX = /^comment\+(.+)@example\.com/i

# app/mailboxes/application_mailbox.rb
class ApplicationMailbox < ActionMailbox::Base
  routing COMMENTS_REGEX => :comments
end

# app/mailboxes/comments_mailbox.rb
class CommentsMailbox < ApplicationMailbox
  def process
    user = User.find_by(email: mail.from)
    post_uuid = COMMENTS_REGEX.match(mail.to)[1]
    
    post = Post.find_by(uuid: post_uuid)
    post.comments.create(user: user, content: mail.body)
  end
end

Configuring emails is also streamlined (using Sendgrid as an example):

1
2

# config/environments/production.rb
config.action_mailbox.ingress = :sendgrid

Securely store your password in your application’s encrypted credentials under action_mailbox.ingress_password using rails credentials:edit. Action Mailbox will automatically retrieve it from there:

1
2

action_mailbox:
  ingress_password: …

Within your SendGrid Inbound Parse, configure it to forward inbound emails to /rails/action_mailbox/sendgrid/inbound_emails with the username actionmailbox and the password you generated earlier. Assuming your application is hosted at https://example.com, your SendGrid configuration would include the following URL:

1

https://actionmailbox:PASSWORD@example.com/rails/action_mailbox/sendgrid/i

To delve deeper into Action Mailbox, refer to the official Rails guide here.

Zeitwerk

Zeitwerk steps in as the new code loader for Ruby. With a conventional file structure, it dynamically loads your project’s classes and modules, eliminating the need for manual require calls. To enable it in Rails 6, add this to your configuration:

1

config.autoloader = :zeitwerk

Explore more about Zeitwerk here for a deeper understanding.

Optimizer Hints

Are slow-running queries causing you concern? You can now set timeouts for your queries.

The following statement will trigger a StatementTimeout exception if the query execution time exceeds the specified limit:

1

User.optimizer_hints("MAX_EXECUTION_TIME(5000)").all

While supported by MySQL, you’ll need to verify if your database supports this feature.

Truncate Database

Seeding data just got easier. The following statement will efficiently truncate all tables in your database, preparing it for fresh data:

1

rails db:truncate_all  

This elegant solution eliminates the need for manual database deletions prior to seeding.

Action Text

Applications leveraging WYSIWYG editors will appreciate the native support for Trix editor in Rails 6.

Trix, the underlying engine for Action Text, offers a robust and consistent editing experience across different browsers, abstracting away the complexities and inconsistencies of contenteditable.

Installation is straightforward:

1
2
3
4
5
6

rails action_text:install

# app/models/message.rb
class Message < ApplicationRecord
  has_rich_text :content
end

You can find comprehensive details about Action Text in the official documentation, here.

Security

No update is complete without security enhancements, and Rails 6 delivers. The first notable addition is support for Host Authorization.

This middleware acts as a safeguard against DNS rebinding attacks by explicitly whitelisting the hosts to which requests can be sent, enhancing your application’s security posture.

Another security improvement aims to prevent attacks that exploit signed/encrypted cookies by embedding the cookie name in the purpose field. This ensures that only cookies with matching names are processed on the server-side, mitigating potential vulnerabilities. Enable action_dispatch.use_cookies_with_metadata to activate this feature.

Webpack as the Default Bundler

Aligning with modern JavaScript development practices, Rails 6 adopts Webpack as the default JavaScript bundler through the webpacker gem, replacing the Rails Asset pipeline. This transition is designed to be straightforward and offers a more streamlined front-end development experience.

Preventing Race Conditions

To address SELECT/INSERT race conditions, a common challenge in scaling applications, Rails 6 introduces a new method. You can find more information in the GitHub thread.

This method requires unique constraints on relevant columns in the underlying table. While it effectively mitigates race conditions between SELECT and INSERT operations, it’s important to note that a race condition between INSERT and SELECT is still possible if another client performs a DELETE operation between those two statements. However, in most applications, this scenario is less likely to occur.

Credentials in Rails 6

Introduced in Rails 5.2, credentials provided a secure mechanism for managing sensitive information, aiming to replace the use of .env files. They allowed encrypted keys for third-party services to be stored directly in version control.

However, Rails previously used a single encrypted file for all environments, posing challenges when managing different keys across development and production, especially in larger projects.

Rails 6 addresses this limitation by introducing support for per-environment credentials, simplifying key management across different environments. For a more in-depth understanding, refer to the official GitHub thread.

Is Rails 6 a Good Update?

In short, yes. Rails 6 is a substantial update, even if not a complete overhaul. With its long history, Ruby on Rails isn’t expected to undergo drastic transformations. However, this sixth iteration brings a wealth of valuable additions.

While some features might appear incremental, others hold the potential to significantly reduce development time, bolster security, and improve overall robustness. The bottom line is that Rails remains a mature and well-supported framework, and Rails 6 makes it even better.

This list only scratches the surface of what’s new in Rails 6. For a comprehensive overview of changes, consult the official changelog. Additionally, there are several deprecations to be aware of. If you want a deep dive into every single update, refer to the detailed full release notes.