Preparing for Rails 8

Rails World starts tomorrow and that could mean an alpha of Rails 8.0. But you don’t need to wait, you can try it out today:

rails new rails8 --main
cd rails8
echo 'Rails.application.routes.draw { root "rails/welcome#index" }' >> config/routes.rb
fly launch

Two changes were made to enable this to work. A third set of changes are being investigated.

1. only create sidekiq or solid queue processes if jobs are defined

Previously if either of these gems were installed that was taken as a clear indication that jobs were going to be performed and a process was set up to handle this task. With Rails 8, solid queue is installed by default so that no longer is true. A change was made to actually look for jobs being defined in the app/jobs/*.rb directory before creating this process.

2. Enable DATABASE_URL to control the placement of all of the databases

Previously, a single Rails application would have only one database by default. With Rails 8, a default application will have four databases. Conceivably, they all could be placed in different places, but in practice you will want to place them all together. A small change to your config/database.yml file will be made at fly launch time to enable a single DATABASE_URL secret to control the placement of all four databases. Brainstorming is under way to explore ways that Rails 8 can handle this case better.

3. Adopt features from the default Dockerfile that Rails produces into dockerfile-rails.

As an example, dockerfile rails has always supported jemalloc as an option. Rails now includes this by default. dockerfile rails will be updated to also default this to true, even when launching applications based on prior versions of Rails.

Meanwhile, fly.io has been tested with both the Rails provided Dockerfiles and the docker files produced by the dockerfile generator.

3 Likes

Thanks for getting these changes out so early for Rails 8!

As a default, it might be a good idea to check more locations though? Or maybe even just do this check for solid queue and leave sidekiq as a gem only check?

For example, in my applications using sidekiq all jobs are placed in app/workers.

Running the default generator (rails generate sidekiq:job hard) for sidekiq places them in app/sidekiq.

Makes sense. Pull request here: treat inclusion of sidekiq as an indication of use by rubys · Pull Request #115 · fly-apps/dockerfile-rails · GitHub . Should go into the next release.

1 Like

Amazing, thank you!

Just wanted to chip in here! I came across this comment in a Solid Queue-related thread that enables the Solid Queue Puma plugin. I tried doing this on a hobby app that I run and this halved the memory usage since I’m not running multiple processes this way.

The Puma plugin for Solid Queue would help mitigate costs for devs. Perhaps worth considering as a default vs using Foreman?

1 Like

I’m convinced that’s the right approach for sqlite3, so I’ve made that change: Release v1.6.23 · fly-apps/dockerfile-rails · GitHub

If you think that’s the right approach for postgres, let’s talk some more.

Thanks for the prompt update! I have a minor suggestion. Rails 8’s config/puma.rb ships with the following line:

plugin :solid_queue if ENV["SOLID_QUEUE_IN_PUMA"]

Perhaps worth setting that env variable if that line is present, and otherwise adding plugin :solid_queue for folks who didn’t rails new with Rails 8 or added Solid Queue later.

I missed that! Done: Release v1.6.24 · fly-apps/dockerfile-rails · GitHub