Rails published an 8.0 milestone on Github that lays out the goals for the next Rails release, and it’s sprawling. It ships with a new background worker, cache backend, asset pipeline, framework for pushing notifications to mobile devices, and a load of development tools.
One of Rails’ mantras is “compress the complexity of modern web apps”, which is a technical way of saying “make it easier to build web applications”. Rails 8 continues this tradition by reducing infrastructure and “moving parts” required to run Rails in production. It’s also taking on the App Store Industrial Complex by making it easier for Rails developers to ship progressive web applications with features that rival native mobile apps.
Less moving parts in production
Redis is a fast, reliable piece of software that has been a staple of the Rails stack for years. Despite its stability, Redis remains a dependency that requires monitoring and can fail. Have you heard of key eviction? You won’t have to find out what that means if you ship a default Rails 8 app.
Rails 8 reduces its dependencies on Redis by shifting more workload from Redis into the database on the premise that they’re getting much faster, thanks to NVMe solid state drives.
Solid Cache & Queue
Solid Cache and Solid Queue are two new software libraries that ship with Rails 8. They’re both built on top of the database and are designed to replace libraries that use Redis for caching and background jobs.
Are they as fast as a Redis backed worker queue and cache? Nope, generally they’re slower because the database needs to commit data to disk whereas Redis stores it in memory, but they are “fast enough” to handle caching and worker queue workloads for most Rails apps because database disks are much faster thanks to NVMe solid state drives.
There’s still a need for Redis in some cases, like rate limiting HTTP requests, but for the most part, you can get away with not using Redis at all in a production Rails deployment.
Database backed ActionCable WebSocket broadcasting
Postgres and MySQL ship with features that make it possible to broadcast messages to web browsers over WebSockets. Rails 8 will ship with a new ActionCable adapter that uses the database to broadcast messages to all connected clients which eliminates another Redis dependency.
Since databases weren’t designed with pub/sub as their primary use case, there can be limitations. For example, Postgres has a default maximum payload size of 8000 bytes, which could be a problem for an application trying to push a large HTML payload over the wire.
Fortunately Rails 8 also ships with Turbo 8 page morphs, which is unlikely to reach the default payload size limits since it only publishes the fact that a model has been changed and the server should reload the HTML over HTTP.
Propshaft replaces Sprockets
Web applications need to quickly & efficiently serve up CSS, JavaScript, and image assets. One of the most effective methods of doing this is to “fingerprint” an asset and serving it up by its fingerprint with a cache header that never expires.
That’s exactly what Propshaft does: it digests the image at /images/foo.png and generates a URL like /images/foo-586e0b396456675e08bba21db5941a3099b07766084e51400576f7622c5217cc.png with a cache header that effectively never expires.
Sprockets was the original Rails asset pipeline included into Rails in 2009 that predates JS-based asset pipelines like web pack. Consequently Sprockets had to do all the heavy lifting that asset pipelines like esbuild do today like compiling SCSS into CSS, minifying JavaScript, etc.
It’s 2024 and we now live in a world where most browsers can efficiently download JavaScript and stylesheet assets without an asset pipeline or a more capable pipeline can be used like esbuild. The only thing Rails needs to do is generate fingerprinted URLs for images, videos, and other media files. That’s why Propshaft was introduced—it gets out of the business of CSS and JavaScript compilation and leaves that up to either modern browsers or more capable asset compilers like esbuild.
Ship progressive web apps instead of native apps
macOS Sonoma, iOS 17, and iPadOS 17 shipped with “progressive web application” features that make it possible for web applications to integrate better with operating system without the need for a native app.
Push notifications
One big reason to ship native applications was for notifications. For example, a Rails chat app might need to notify a user if they’re mentioned with @user so they can respond to a message.
The most recent version of Safari finally introduced the web notifications feature making it feasible for Rails to bake it into the framework. That means mobile web notifications are possible without installing a native iOS application.
It’s not clear yet if web notifications will use an existing gem or if the Rails team will roll their own.
Add a web page to the Home Screen or dock
Improvements have been made to adding a webpage to the Home Screen on iPhones and iPads and now it’s possible to add a webpage to the dock so that it appears as an app.
This has been on Windows and Android for a while, but it’s nice to see Apple finally offer decent support for it making it a viable channel for distributing apps.
Lots and lots of development tools
Rails 8 ships with a lot of additional default tools that make it easier to develop and deploy Rails applications.
Deployments with Kamal
Kamal gets anointed as a default when running rails new. Kamal is a deployment tool that makes deploying Rails applications to metal servers possible if you’re comfortable managing a load balancer, HTTPS certificates, Docker, and more.
You don’t need Kamal to deploy to Fly.io since we provide you with the load balancer and tooling needs to handle HTTP certificates.
HTTP Basic Authentication generator
Rails 8 will ship with a code generator that will add HTTP Basic authentication to Rails applications. This has been possible already with third-party gems or a few lines of Ruby code, so this will be a nice addition for those who are new to the framework and need more implementation guidance.
Benchmarking tool
A common benchmarking tool will make limited apples-to-apples comparison possible between hosts. The purpose of these benchmarks isn’t to understand how a specific application will behave in production—rather its a suite that tests disk speed, networking, and other aspects of server performance that can help developers make a more informed decision about where to deploy their Rails apps.
Rails 8 language server
Language servers instruct IDEs, like Zed Editor and VS Code, what to display in the autocomplete pop-over while coding. Rails 8 will ship with a language server that will offer autocomplete for Rails constructs like ActiveRecord validations, etc.
RuboCop
For those of you who like linters, Rails 8 is going to ship with RuboCop Omakase. You’ll be able to customize it to whatever flavor of Ruby you or your team prefers.
Github integration
Rails 8 projects now have a .github folder with everything configured for running CI, pull request templates, and other common workflows on Github.
Devcontainers
Devcontainers are a set of scripts that setup a development environment on your local workstations via Dockerfiles and a configuration file.
Be aware on macOS you may run into issues in larger Rails projects with lots of files where Docker Desktop’s hypervisor performance slows down your development environment by an order of magnitude.
Better HTTP/2 support
Rails continues its slow march towards better HTTP/2 support with a few upgrades.
Rack 3
Rack is a low level HTTP API that sits between Ruby web frameworks, like Rails, and web application servers, like Puma and Falcon. Rack 3 ships with better APIs for HTTP/2 that cleans up some of the hacks that were required to make it work in previous versions of Rack.
HTTP/2 in Thruster
Thruster is a Dockerfile for Rails apps that includes an HTTP/2 proxy for web hosts that don’t support it out of the box. If you deploy your app to Fly.io, you won’t need this since Fly’s applicaton proxy supports HTTP/2 with no additional configuration.
Documentation for ActiveModel
ActiveModel is an API that’s been extracted from ActiveRecord that makes it possible to make plain ‘ol Ruby objects behave more like ActiveRecord models. It’s been around forever, but now it finally gets the documentation it deserves in Rails 8.
Wrap-up
Rails 8 is shaping up to be a big release that will significantly expand the default tooling included with a Rails app and introduce new frameworks that eliminate the need for production service dependencies like Redis. As always, you’ll still be able to remove whatever pieces you don’t like when creating a new Rails app or pulling the gems out later.
Overall most of the features delivered in Rails 8 will delay the need to think about production infrastructure early on in your app. This makes Rails more approachable for people new to web development since they have fewer decisions to make.