Paagman.dev

How fast can you actually patch Ruby?

2026-10-27T00:00:00+01:00

When I tried to update an app to Ruby 4.0.9 last Friday, the official Docker community image wasn’t available yet. The release fixed vulnerabilities GitLab had found, but I had to wait before I could deploy.

A few months ago, a government Rails site was hit by an ActiveStorage vulnerability eight hours after the patch went out. Last week, PHP2Shell was being exploited before it was announced.¹ Waiting for a Docker image can eat up the time you have to respond.

When Ruby 4.0.9 became available

I took every installer and version manager listed on the official installation page on ruby-lang.org, then added container images, CI providers and hosting platforms I could think of. For each, I checked when 4.0.9 became available.²

All times start when the Ruby 4.0.9 source tarball became available, on Friday 23 October 2026, 04:04 UTC.³

Installers and version managers

Resource	Available after
ruby-build (rbenv, and mise when compiling)	43 m
ruby/ruby-builder binaries	48 m
Homebrew ruby-build	1 h 10 m
asdf	2 h 43 m
jdx/ruby binaries (mise’s precompiled Rubies)	8 h 15 m
RubyInstaller (Windows, also RVM 4 Windows)	⚠️ 16 h 35 m
RVM	⚠️ 18 h 34 m
rv	⚠️ 21 h 40 m
ruby-install	⚠️ 5 d 10 h 46 m⁴
chruby	Depends on the installer used⁵
rbenv for Windows	❌ last updated to 4.0.1 in March

Container images

Resource	Available after
rubylang/ruby (by the Ruby core team)	8 m
bitnami/ruby	1 h 59 m
sorah/ruby (by Ruby committer @sorah, uses sorah-rbpkg)	2 h 29 m
rails/devcontainer (Rails dev container images)	9 h 34 m
ruby (by the Docker community)	⚠️ 15 h 57 m

CI

Resource	Available after
GitHub Actions setup-ruby (Linux/macOS)	1 h 12 m
CircleCI cimg/ruby	1 h 36 m
GitHub Actions setup-ruby (Windows)	⚠️ 28 h 34 m

Hosting platforms

Resource	Available after
Heroku	2 h 28 m
DigitalOcean App Platform (uses Heroku’s buildpack)	2 h 28 m⁶
Railway (uses mise)	8 h 15 m
Fly.io, Kamal and anything else using the official Docker community image	⚠️ 15 h 57 m
Google Cloud (Cloud Run, App Engine)	⚠️ ≈ 3 d 14 h, default still 4.0.7
AWS Elastic Beanstalk	⚠️ 4 d 4 h 07 m
AWS Lambda	⚠️ 4 d 16 h 29 m

System packages

Resource	Available after
Snap	7 m
sorah-rbpkg (APT packages for Ubuntu and Debian)	2 h 26 m
Homebrew	2 h 41 m
nixpkgs	3 h 47 m
Fedora (Rawhide; 44/45 still in testing)	⚠️ 11 h 03 m
winget	⚠️ 20 h 54 m
Debian, Ubuntu, Alpine, Arch	❌ no Ruby 4 at all

What stands out

The fastest ones are really fast, and mostly come from Ruby itself. The Snap package and the rubylang/ruby image are both published by the Ruby core team, and were available after 7 and 8 minutes. A bot committed the ruby-build definition 28 seconds after the tarball was uploaded, and the ruby-build release followed at 43 minutes.
The official Docker community image took almost 16 hours.⁷ The Dockerfile Rails generates uses this image, so it’s also what you get with Kamal and Fly.io by default.⁸ The Dockerfile itself was updated about seven hours after the tarball appeared. Most of the wait came after that, in the official-images review and build pipeline. That review serves a purpose, but it also adds hours to the wait for a security patch.
Some platforms are even slower. AWS Lambda and Elastic Beanstalk are still on 4.0.7, ~~DigitalOcean’s docs list 4.0.1–4.0.2,~~ and Google Cloud took about three and a half days to publish a 4.0.9 image, while its default for Ruby 4.0 is still 4.0.7. If you rely on a provider’s Ruby runtime, you depend on its update schedule. Edit: Elastic Beanstalk and Lambda got 4.0.9 after 4 days. Rectification: DigitalOcean actually supports 4.0.9, as it uses Heroku buildpacks.

How to patch faster

Your version manager, CI and production environment all need to support the new version before you can roll it out. The slowest one decides how fast you can patch.

Some things you can do before the next Ruby security release:

Check the whole path to production. Find out how your local version manager, CI and production environment pick up new Ruby releases. Look for a manual approval, a scheduled build or another step that could hold up an update.
Automate the boring part. Let a bot pick up new versions of your dependencies (Ruby, your gems and your base image), run CI and deploy when everything is green. The fewer manual steps, the faster you’re patched.
Choose a hosting setup that lets you patch promptly. I’d avoid relying on a provider’s Ruby runtime if it’s still two patch versions behind. Use a custom container where supported, so you can update Ruby on your own schedule.

Most of this is volunteer work

All of this puts extra pressure on the maintainers of these tools, and most of them are volunteers. Every patch release means a chain of PRs, reviews, builds and releases across dozens of projects. The expectations keep going up.

The fastest ones show how much of that work bots can take over, so maintainers don’t have to drop everything for every release.

So a big thank you to everyone who makes this happen, often within minutes. 🙏

Updates

28 October 2026: Added rails/devcontainer to the container images (about 9.5 hours).
28 October 2026: AWS Lambda’s ruby:4.0 image was updated to 4.0.9, about 4.5 days after the release.
28 October 2026: AWS Elastic Beanstalk updated its Ruby 4.0 platform to 4.0.9 on 27 October, about 4 days after the release.
28 October 2026: ruby-install’s version metadata was updated to 4.0.9, about 5.5 days after the release.
28 October 2026 (rectification): DigitalOcean App Platform uses Heroku’s Ruby buildpack and binaries, so it got 4.0.9 at the same time as Heroku, even though its docs only list 4.0.1–4.0.2. Thanks to @dblockdotorg for confirming.
29 October 2026: Added sorah-rbpkg’s APT packages for Ubuntu and Debian and its sorah/ruby container image (both about 2.5 hours).

Amazon’s honeypots saw the first attempts four days before disclosure. ↩
Availability was checked through October 29. Most timestamps are Git commit dates or GitHub release dates. For Docker images I used Docker Hub’s last pushed date, or the GitHub Container Registry’s creation date for rails/devcontainer; for Heroku, the S3 Last-Modified header. For Homebrew it’s the bottle commit. For sorah-rbpkg I used the GitHub release date of the Debian packages, and for its sorah/ruby image the completion of the image manifest job, as the tags on ECR have since been re-pushed. For Google Cloud I used the upload time of the ruby:4.0.9 runtime image in Artifact Registry. For AWS Lambda I used the creation date of the public.ecr.aws/lambda/ruby:4.0.2026.10.27.20 image, the first one where ruby -v reports 4.0.9. For AWS Elastic Beanstalk I used the DateCreated of the Ruby 4.0 platform version 4.15.0. ↩
The v4.0.9 tag was pushed at 02:36 UTC, 1 h 28 m before the tarball appeared on cache.ruby-lang.org. The announcement post followed 34 minutes after the tarball. The fixes themselves were public even earlier as regular commits in the Ruby repository, and some were already part of 4.0.8. I use the tarball upload to measure how quickly downstream tools packaged the release. ↩
ruby-install gets its version list and checksums from postmodern/ruby-versions. This row tracks that metadata. ruby-install also supports explicit versions, custom source URLs and checksums, so you can supply the release tarball URL and its official checksum before the metadata is updated. ↩
chruby switches between installed Rubies and doesn’t require an update for each release. Its documentation covers manual installation and using either ruby-install or ruby-build. With ruby-build, the release was available after 43 minutes; you could also compile the tarball yourself. ↩
DigitalOcean’s docs and release notes still only list Ruby 4.0.1–4.0.2. Its pinned Heroku buildpack downloads Ruby binaries from Heroku’s S3 bucket, where 4.0.9 appeared after 2 h 28 m, and @dblockdotorg confirmed that 4.0.9 deploys. ↩
What counts as ‘official’ is a bit confusing here. ruby is a Docker Official Image maintained by the Docker community, while rubylang/ruby is published by the Ruby core team itself. ↩
Docker Hub shows ~1.59 billion pulls for ruby and ~3.5 million for rubylang/ruby. The image that took 15 h 57 m has about 450 times as many pulls as the one available after 8 minutes. ↩

Introducing Rebundler: make your Gemfile look great with a single command

2026-08-04T00:00:00+02:00

Today I’m introducing Rebundler. It’s a little tool to automatically re-organize and annotate your Gemfile. I wrote it because I like my Gemfiles to be structured neatly, but in reality I always just put gems near vaguely adjacent gems or end up chucking them at the end of the file. Eventually my Gemfiles turn out to be an incoherent mess.

Rebundler groups and sorts your gems and adds a description to each, which gives you more context on what a gem does. Especially with some of the funky names in the Ruby ecosystem, it’s not always clear from the name alone.

Here’s a small example (full example below):

Before

source "https://rubygems.org"

gem "rails"
gem "puma"
gem "avo"

group :development do
  gem "herb"
end

After

source "https://rubygems.org"

gem "avo" # Admin panel framework and Content Management System for Ruby on Rails.
gem "puma" # A Ruby/Rack web server built for parallelism.
gem "rails" # Full-stack web application framework.

group :development do
  gem "herb" # The modern HTML+ERB Toolchain
end

Installation

You can either add it to your Gemfile or run it standalone.

bundle add rebundler or gem install rebundler.

❯ bundle exec rebundle
Reordering and annotating Gemfile...
✓ Gemfile has been reordered and annotated

There’s a ‘CI mode’, where it checks if the formatting is still correct, without writing to the file. Useful if you want to add it as a step in your linting pipeline.

❯ bundle exec rebundle --ci
Checking if Gemfile is properly formatted...
✓ Gemfile is properly formatted

Try it online

You can also play around with it on the online Rebundler Playground. Just paste your Gemfile and hit Rebundle. It encodes the file in a hash in the URL, so you can easily share the URL around.

How it works

Since Gemfiles are just regular Ruby files, they can be parsed with Prism. Rebundler uses Prism’s visitor pattern to group gems that it thinks belong together. It also looks out for generic Gemfile setup methods, like ruby and source and puts them at the top.

Gems defined at the ‘top level’ are grouped together. Gems inside blocks (like group :development do .. end) stay together, and duplicate groups are automatically merged.

Prism is only a parser: it can’t format the parsed code back into Ruby¹. To work around this, Rebundler does some classic string manipulation. Prism saves the exact line and column coordinates of each parsed piece of code, so it uses those to extract the original code as a string. This has the added benefit that it keeps your code style intact, as the code is just copied.

When reconstructing the Gemfile, it sorts each group’s gems alphabetically. It then loads each gem’s description from the local bundle (fetching it from RubyGems if it’s missing) and appends it to the line as a comment. To do this it needs to take some additional steps to find the trailing comment of the original line².

By default it keeps existing trailing comments intact. Other comments are currently discarded.

The current version should work with most Gemfiles, but there are probably esoteric ones out there which it doesn’t support (they are Ruby files, after all, so you can do anything you want). If you have a straightforward Gemfile with only ‘Gemfile syntax’ it should work.

Full example

Here’s a full example using RubyEvents’ Gemfile (view in playground). It’s a good example of a ‘messy’ Gemfile, with occasional comments, commented-out gems, and no real grouping or structure — exactly the kind Rebundler benefits the most.

Before

source "https://rubygems.org"
git_source(:github) { |repo| "https://github.com/#{repo}.git" }

ruby file: ".ruby-version"

# Use Rails edge
gem "rails", github: "rails/rails"

# The modern asset pipeline for Rails [https://github.com/rails/propshaft]
gem "propshaft"

# Use sqlite3 as the database for Active Record
gem "sqlite3", ">= 2.1.0"

# Use the Puma web server [https://github.com/puma/puma]
gem "puma"

# use jbuilder for the api
gem "jbuilder"

# Bundle and transpile JavaScript [https://github.com/rails/jsbundling-rails]
# gem "jsbundling-rails"

# Hotwire's SPA-like page accelerator [https://turbo.hotwired.dev]
gem "turbo-rails"

# Hotwire's modest JavaScript framework [https://stimulus.hotwired.dev]
# gem "stimulus-rails"

# Bundle and process CSS [https://github.com/rails/cssbundling-rails]
# gem "cssbundling-rails"

# Use Redis adapter to run Action Cable in production
# gem "redis", ">= 4.0.1"

# Use Kredis to get higher-level data types in Redis [https://github.com/rails/kredis]
# gem "kredis"

# Use Active Model has_secure_password [https://guides.rubyonrails.org/active_model_basics.html#securepassword]
gem "bcrypt", "~> 3.1.7"

# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
gem "tzinfo-data", platforms: %i[windows jruby]

# Reduces boot times through caching; required in config/boot.rb
gem "bootsnap", require: false

# Deploy this application anywhere as a Docker container [https://kamal-deploy.org]
gem "kamal", "2.7.0", require: false

# Add HTTP asset caching/compression and X-Sendfile acceleration to Puma [https://github.com/basecamp/thruster/]
gem "thruster", require: false

# Use Active Storage variants [https://guides.rubyonrails.org/active_storage_overview.html#transforming-images]
gem "image_processing", "~> 1.2"

# Image processing for event asset generation
gem "mini_magick"

# All sorts of useful information about every country packaged as convenient little country objects
gem "countries"

# ISO 639-1 and ISO 639-2 language code entries and convenience methods
gem "iso-639"

# A minimal client of Bluesky/ATProto API
gem "minisky", "~> 0.4.0"

# Extract Collaborator Objects from your Active Records, a new concept called Associated Objects
gem "active_record-associated_object"

# Headless Chrome driver for Capybara
gem "cuprite"

# A single delightful Ruby way to work with AI.
gem "ruby_llm", "~> 1.15.0"

# A simple and clean Ruby DSL for creating JSON schemas.
gem "ruby_llm-schema", github: "marcoroth/ruby_llm-schema", branch: "conditionals"

# JSON Schema validator
gem "json_schemer"

# YouTube V3 API client.
gem "yt"

# Family of libraries that support various formats of XML "feeds".
gem "rss", "~> 0.3.1"

# YAML Editing and Refactoring with Better Accuracy
gem "yerba", "~> 0.5.1"

# Powerful and seamless HTML-aware ERB parsing and tooling.
gem "herb", "~> 0.9"

# An ActionView-compatible ERB engine with modern DX - re-imagined with Herb.
gem "reactionview", "~> 0.3"

# Agnostic pagination in plain ruby.
gem "pagy"

# gem "activerecord-enhancedsqlite3-adapter"
gem "solid_cache"

# Database-backed Active Job backend.
gem "solid_queue", github: "joshleblanc/solid_queue", branch: "async-mode"

# Operational controls for Active Job
gem "mission_control-jobs"

# Simple, powerful, first-party analytics for Rails
gem "ahoy_matey"

# The simplest way to group temporal data
gem "groupdate"

# Create beautiful JavaScript charts with one line of Ruby
gem "chartkick", "~> 5.0"

# Use Vite in Rails and bring joy to your JavaScript experience
gem "vite_rails"

# Collection of SEO helpers for Ruby on Rails.
gem "meta-tags"

# Logs performance and exception data from your app to appsignal.com
gem "appsignal"

# Autoload dotenv in Rails.
gem "dotenv-rails"

# Automatic generation of html links in texts
gem "rails_autolink", "~> 1.1"

# Easily generate XML Sitemaps
gem "sitemap_generator", "~> 6.3"

# A framework for building reusable, testable & encapsulated view components
gem "view_component"

# Adds ActiveRecord-specific methods to Dry::Initializer
gem "dry-initializer-rails"

# Type system for Ruby supporting coercions, constraints and complex types
gem "dry-types", "~> 1.7"

# Protocol Buffers are Google's data interchange format.
gem "google-protobuf", require: false

# ActiveJob::Performs adds the `performs` macro to set up jobs by convention.
gem "active_job-performs"

# Use the OpenAI API with Ruby!
gem "ruby-openai"

# Repairs broken JSON strings.
gem "json-repair", "~> 0.2.0"

# Markdown that smells nice
gem "redcarpet", "~> 3.6"

# Syntax highlighting
gem "rouge", "~> 4.4"

# Country Select Plugin
gem "country_select"

# Admin panel framework and Content Management System for Ruby on Rails.
gem "avo"

group :avo, optional: true do
  gem "avo-pro", source: "https://packager.dev/avo-hq/"
end

# Marksmith is a GitHub-style markdown editor for Ruby on Rails applications.
gem "marksmith"

# A fast, safe, extensible parser for CommonMark. This wraps the comrak Rust crate.
gem "commonmarker", ">= 2.6.1"

# ActiveRecord like interface to read only access and query static YAML files
gem "frozen_record", "~> 0.27.2"

# A convenient way to diff string in ruby
gem "diffy"

# ActiveRecord soft-deletes done right
gem "discard"

# Makes consuming restful web services dead easy.
gem "httparty"

# Use OmniAuth to support multi-provider authentication [https://github.com/omniauth/omniauth]
gem "omniauth"

# Official OmniAuth strategy for GitHub.
gem "omniauth-github"

# Provides a mitigation against CVE-2015-9284 [https://github.com/cookpad/omniauth-rails_csrf_protection]
gem "omniauth-rails_csrf_protection"

# An accessible autocomplete for Ruby on Rails apps using Hotwire.
gem "hotwire_combobox", "~> 0.4.0"

# Common locale data and translations for Rails i18n.
gem "rails-i18n", "~> 8.0"

# Ruby standards gems
gem "openssl" # https://github.com/ruby/openssl/issues/949

# Class to build custom data structures, similar to a Hash.
gem "ostruct"

# Complete geocoding solution for Ruby.
gem "geocoder", github: "alexreisner/geocoder" # Use latest geocoder with Nominatim improvements until next release

# RubyGems.org API wrapper for gem information
gem "gems"

# A glamorous CLI toolkit for Ruby
gem "gum", "~> 0.3.1"

# Regex pattern searching in files
gem "grepfruit"

# Create beautiful JavaScript maps with one line of Ruby
gem "mapkick-rb", "~> 0.2.0"

# Typesense Ruby client
gem "typesense", "~> 4.1"

# Typesense integration to your favorite ORM
gem "typesense-rails", "~> 1.0.0.rc4"

group :development, :test do
  # See https://guides.rubyonrails.org/debugging_rails_applications.html#debugging-with-the-debug-gem
  gem "bundler-audit", require: false
  gem "debug", platforms: %i[mri windows]
  gem "byebug"
  gem "minitest-difftastic", "~> 0.2"
end

group :development do
  # A gem for generating annotations for Rails projects.
  gem "annotaterb"

  # Use console on exceptions pages [https://github.com/rails/web-console]
  gem "web-console"

  # Add speed badges [https://github.com/MiniProfiler/rack-mini-profiler]
  gem "rack-mini-profiler"

  # For call-stack profiling flamegraphs
  gem "stackprof"

  # Speed up commands on slow machines / big apps [https://github.com/rails/spring]
  # gem "spring"

  # Use listen to watch files for changes [https://github.com/guard/listen]
  gem "listen", "~> 3.5"

  # Guard for watching file changes and auto-importing [https://github.com/guard/guard]
  gem "guard"

  # Benchmark is no longer included in the standard lib - used for benchmarking
  gem "benchmark"

  gem "ruby-lsp-rails", require: false
  gem "standardrb", "~> 1.0", require: false
  gem "erb_lint", require: false
  gem "authentication-zero", require: false
end

group :test do
  # Use system testing [https://guides.rubyonrails.org/testing.html#system-testing]
  gem "capybara"
  gem "rails-controller-testing"
  gem "selenium-webdriver"
  gem "vcr", "~> 6.1"
  gem "webmock"
end

gem "icalendar", "~> 2.12"

After

source "https://rubygems.org"

git_source(:github) { |repo| "https://github.com/#{repo}.git" }

ruby file: ".ruby-version"

gem "active_job-performs" # ActiveJob::Performs adds the `performs` macro to set up jobs by convention.
gem "active_record-associated_object" # Associate a Ruby PORO with an Active Record class and have it quack like one.
gem "ahoy_matey" # Simple, powerful, first-party analytics for Rails
gem "appsignal" # Logs performance and exception data from your app to appsignal.com
gem "avo" # Admin panel framework and Content Management System for Ruby on Rails.
gem "bcrypt", "~> 3.1.7" # OpenBSD's bcrypt() password hashing algorithm.
gem "bootsnap", require: false # Boot large ruby/rails apps faster
gem "chartkick", "~> 5.0" # Create beautiful JavaScript charts with one line of Ruby
gem "commonmarker", ">= 2.6.1" # CommonMark parser and renderer. Written in Rust, wrapped in Ruby.
gem "countries" # Gives you a country object full of all sorts of useful information.
gem "country_select" # Country Select Plugin
gem "cuprite" # Headless Chrome driver for Capybara
gem "diffy" # A convenient way to diff string in ruby
gem "discard" # ActiveRecord soft-deletes done right
gem "dotenv-rails" # Autoload dotenv in Rails.
gem "dry-initializer-rails" # Adds ActiveRecord-specific methods to Dry::Initializer
gem "dry-types", "~> 1.7" # Type system for Ruby supporting coercions, constraints and complex types like structs, value objects, enums etc
gem "frozen_record", "~> 0.27.2" # ActiveRecord like interface to read only access and query static YAML files
gem "gems" # Ruby wrapper for the RubyGems.org API
gem "geocoder", github: "alexreisner/geocoder" # Complete geocoding solution for Ruby.
gem "google-protobuf", require: false # Protocol Buffers
gem "grepfruit" # Tool for searching regex patterns in files
gem "groupdate" # The simplest way to group temporal data
gem "gum", "~> 0.3.1" # Ruby wrapper for Charm's gum CLI tool.
gem "herb", "~> 0.9" # The modern HTML+ERB Toolchain
gem "hotwire_combobox", "~> 0.4.0" # Accessible Autocomplete for Rails apps
gem "httparty" # Makes http fun! Also, makes consuming restful web services dead easy.
gem "icalendar", "~> 2.12" # A ruby implementation of the iCalendar specification (RFC-5545).
gem "image_processing", "~> 1.2" # High-level wrapper for processing images for the web with ImageMagick or libvips.
gem "iso-639" # ISO 639-1 and ISO 639-2 language code entries and convenience methods.
gem "jbuilder" # Create JSON structures via a Builder-style DSL
gem "json-repair", "~> 0.2.0" # Repairs broken JSON strings.
gem "json_schemer" # JSON Schema validator. Supports drafts 4, 6, 7, 2019-09, 2020-12, OpenAPI 3.0, and OpenAPI 3.1.
gem "kamal", "2.7.0", require: false # Deploy web apps in containers to servers running Docker with zero downtime.
gem "mapkick-rb", "~> 0.2.0" # Create beautiful JavaScript maps with one line of Ruby
gem "marksmith" # Marksmith is a GitHub-style markdown editor for Ruby on Rails applications.
gem "meta-tags" # Collection of metadata helpers for Ruby on Rails.
gem "mini_magick" # Manipulate images with minimal use of memory via ImageMagick
gem "minisky", "~> 0.4.0" # A minimal client of Bluesky/ATProto API
gem "mission_control-jobs" # Operational controls for Active Job
gem "omniauth" # A generalized Rack framework for multiple-provider authentication.
gem "omniauth-github" # Official OmniAuth strategy for GitHub.
gem "omniauth-rails_csrf_protection" # Provides CSRF protection on OmniAuth request endpoint on Rails application.
gem "openssl" # SSL/TLS and general-purpose cryptography for Ruby
gem "ostruct" # Class to build custom data structures, similar to a Hash.
gem "pagy" # Pagy 🐸 The Leaping Gem!
gem "propshaft" # Deliver assets for Rails.
gem "puma" # A Ruby/Rack web server built for parallelism.
gem "rails", github: "rails/rails" # Full-stack web application framework.
gem "rails_autolink", "~> 1.1" # Automatic generation of html links in texts
gem "rails-i18n", "~> 8.0" # Common locale data and translations for Rails i18n.
gem "reactionview", "~> 0.3" # An ActionView-compatible ERB engine with modern DX - re-imagined with Herb.
gem "redcarpet", "~> 3.6" # Markdown that smells nice
gem "rouge", "~> 4.4" # A pure-ruby colorizer based on pygments
gem "rss", "~> 0.3.1" # Family of libraries that support various formats of XML "feeds".
gem "ruby_llm", "~> 1.15.0" # One beautiful Ruby API for GPT, Claude, Gemini, and more.
gem "ruby_llm-schema", github: "marcoroth/ruby_llm-schema", branch: "conditionals" # A simple Ruby DSL for creating JSON schemas.
gem "ruby-openai" # OpenAI API + Ruby! 🤖❤️
gem "sitemap_generator", "~> 6.3" # Easily generate XML Sitemaps
gem "solid_cache" # A database backed ActiveSupport::Cache::Store
gem "solid_queue", github: "joshleblanc/solid_queue", branch: "async-mode" # Database-backed Active Job backend.
gem "sqlite3", ">= 2.1.0" # Ruby library to interface with the SQLite3 database engine (http://www.sqlite.org).
gem "thruster", require: false # Zero-config HTTP/2 proxy
gem "turbo-rails" # The speed of a single-page web application without having to write any JavaScript.
gem "typesense", "~> 4.1" # Ruby Library for Typesense
gem "typesense-rails", "~> 1.0.0.rc4"
gem "tzinfo-data", platforms: %i[windows jruby] # Timezone Data for TZInfo
gem "view_component" # A framework for building reusable, testable & encapsulated view components in Ruby on Rails.
gem "vite_rails" # Use Vite in Rails and bring joy to your JavaScript experience
gem "yerba", "~> 0.5.1" # YAML Editing and Refactoring with Better Accuracy
gem "yt" # Yt makes it easy to interact with Youtube V3 API by providing a modular, intuitive and tested Ruby-style API.

group :avo, optional: true do
  gem "avo-pro", source: "https://packager.dev/avo-hq/" # Visit https://avohq.io/ to get more information about this gem.
end

group :development do
  gem "annotaterb" # A gem for generating annotations for Rails projects.
  gem "authentication-zero", require: false # An authentication system generator for Rails applications
  gem "benchmark" # a performance benchmarking library
  gem "erb_lint", require: false # ERB lint tool
  gem "guard" # Guard keeps an eye on your file modifications
  gem "listen", "~> 3.5" # Listen to file modifications
  gem "rack-mini-profiler" # Profiles loading speed for rack applications.
  gem "ruby-lsp-rails", require: false # A Ruby LSP addon for Rails
  gem "stackprof" # sampling callstack-profiler for ruby 2.2+
  gem "standardrb", "~> 1.0", require: false # Alias for the standard gem, which has a standardrb binary
  gem "web-console" # A debugging tool for your Ruby on Rails applications.
end

group :development, :test do
  gem "bundler-audit", require: false # Patch-level verification for Bundler
  gem "byebug" # Ruby fast debugger - base + CLI
  gem "debug", platforms: %i[mri windows] # Debugging functionality for Ruby
  gem "minitest-difftastic", "~> 0.2" # Minitest Plugin to use difftastic for failed assertions
end

group :test do
  gem "capybara" # Capybara aims to simplify the process of integration testing Rack applications, such as Rails, Sinatra or Merb
  gem "rails-controller-testing" # Extracting `assigns` and `assert_template` from ActionDispatch.
  gem "selenium-webdriver" # Selenium is a browser automation tool for automated testing of webapps and more
  gem "vcr", "~> 6.1" # Record your test suite's HTTP interactions and replay them during future test runs for fast, deterministic, accurate tests.
  gem "webmock" # Library for stubbing HTTP requests in Ruby.
end

Give it a spin on your own Gemfile in the Rebundler Playground, or bundle add rebundler and run it locally. I’d love to hear what you think!

It seems that might be coming via syntax_tree soon, though. ↩
The next version of Prism will make that a lot easier. ↩

Making sure local CI is green before deploying to Heroku

2025-11-18T00:00:00+01:00

Note: this article assumes you’re using GitHub, something similar can probably also be cooked up for other hosting providers.

Rails 8.1 was released recently with a new ‘Local CI’ feature. This allows you to easily define and run the steps you traditionally run on an external system (like GitHub Actions) on your own machine. Modern hardware is fast enough to even run large test suites nowadays.

One benefit of using an external system is that they can run your CI steps structurally and independently and you can prevent PRs from being merged if the linters and test suites are failing, adding famous green checks to your pull requests.

Local CI also does this by including a “signoff” step which basically signals to GitHub that your commit has successfully run the CI suite locally (Works On My Machine™). This is great and allows you to keep some certainty of the state of your code and your pull requests.

With local CI there is a missing piece though: once a PR gets merged there is no final check for the merge commit on your main branch. All external tools I know run another build for the merge commit and I usually wait for those before deploying (or automated deploy processes usually do).

Since I deploy directly to Heroku through the command line (git push heroku main 🤘) there is no such check anymore and I have to remember to run and check the command myself.

To prevent myself from forgetting I’ve written a small git pre push hook that runs the local CI suite if necessary and holds the push if it fails. This serves as a nice backstop while keeping all the benefits from running everything locally.

What it basically does:

Check if the current commit has already been signed off.
If not: run the CI suite (which then marks the commit as signed off).
Blocks the push if it fails, else continue and deploy.

This gives me peace of mind that no bugs will make it to production (right 🥹).

Setup

Install the gh cli tool and authenticate with GitHub (gh auth login).
Create a new file in your app’s folder: .git/hooks/pre-push:

#!/usr/bin/env bash

set -euo pipefail

# Pre-push hook that only runs on main branch when pushing to Heroku

remote="$1"

while IFS=' ' read -r local_ref local_sha remote_ref remote_sha; do
  # Only check main branch pushes to Heroku
  if [[ "$remote_ref" != "refs/heads/main" ]] || [[ "$remote" != "heroku" ]]; then
    continue
  fi

  echo "Pushing to main branch on Heroku..."
  echo "Checking if commit $local_sha has passed status checks on GitHub..."

  # Get commit status from GitHub
  status_response=$(gh api "repos/:owner/:repo/commits/$local_sha/status")
  status=$(echo "$status_response" | jq -r '.state // "unknown"')

  case "$status" in
  success)
    echo "✅ Commit has passed GitHub status checks, skipping bin/ci"
    ;;
  pending)
    echo "⏳ GitHub checks are still pending. Running local CI..."
    bin/ci || {
      echo "❌ bin/ci failed! Push aborted."
      exit 1
    }
    echo "✅ bin/ci passed!"
    ;;
  failure | error)
    echo "❌ GitHub checks failed with status: $status"
    echo "Running local CI to verify..."
    bin/ci || {
      echo "❌ bin/ci failed! Push aborted."
      exit 1
    }
    echo "✅ bin/ci passed!"
    ;;
  *)
    echo "⚠️ Unknown GitHub status: '$status'. Running local CI..."
    bin/ci || {
      echo "❌ bin/ci failed! Push aborted."
      exit 1
    }
    echo "✅ bin/ci passed!"
    ;;
  esac
done

exit 0

And you’re done ✅! Only green commits will be deployed to Heroku.

Hotwire Native is extremely future proof

2025-09-16T00:00:00+02:00

Yesterday, iOS 26 was released with a whole new look-and-feel called ‘liquid glass’.

You might think that getting that to work with your Hotwire Native app requires at least writing some code. But because of the tight integration with iOS (using first party, native UI components) it actually does not need any code changes at all.

Upgrading your app to the new look requires exactly 0 lines of code! Just a few clicks and some patience:

Update Xcode.
Rebuild your app against iOS 26.
✨ literally nothing else ✨.
Push to the App Store.

And you’re ready to go. Your users will like that your app matches the new shiny looks of their OS, including all new animations and effects.

iOS 18

iOS 26 (w/ liquid glass)

Joe Masilotti also touched on this in his Rails World 2025 keynote (check out it if you haven’t, it’s awesome).

My main take away is something else though: things like this makes Hotwire Native extremely future proof. Any changes to the underlying platforms will almost automatically just work in your app. You just need to rebuild and push a new version every now and then.

This makes building on top of Hotwire and Hotwire Native the best way to accompany your Rails app with native apps. You can have the best of both worlds and focus on building your web app the way you’re used to, adding some sprinkles for native behavior when needed.

Changes in your web app will automatically be available to your app users when you deploy and platform changes will automatically trickle down to your apps as well. It only require a new build every now and then.

This made my believe in the future of Hotwire Native and Rails even more solid. Exciting times are ahead!

Handling chrome.devtools.json requests in Rails apps

2025-08-28T00:00:00+02:00

Chrome recently added a new feature called “Automatic Workspace Folders” to Chrome DevTools. It can help with automatically mapping the correct folder of a project to the Workspace feature of the web inspector. In the workspace you can, for example, directly edit and save files in your project.

I don’t use the feature, but errors from requests to a specific file for this feature in my logs were cluttering my log output. Basically Chrome is constantly trying to fetch a JSON file:

Started GET “/.well-known/appspecific/com.chrome.devtools.json” for ::1 at ….

ActionController::RoutingError (No route matches [GET] “/.well-known/appspecific/com.chrome.devtools.json”):

To resolve this I wrote a small Rack middleware class that handles these requests and responds in the way Chrome wants. That solves the problem of the cluttered log entries and you can automatically set up the Workspace feature if you want. It needs a small JSON response with the path to the project and a unique UUID.

There are some other solutions out there, like a Vite plugin or a small Ruby gem (chrome_devtools_rails), but the nice thing about this small middleware is that you can simply add it to your codebase without adding an extra dependency.

Simply create the following file as lib/middleware/chrome_devtools.rb:

# frozen_string_literal: true

require "digest"
require "json"

module Middleware
  # Chrome DevTools middleware that intercepts requests to the Chrome DevTools
  # `com.chrome.devtools.json` endpoint and returns a workspace configuration.
  #
  # This allows Chrome DevTools to automatically detect and connect to the project
  # workspace in their developer tools.
  #
  # For more info: See https://chromium.googlesource.com/devtools/devtools-frontend/+/main/docs/ecosystem/automatic_workspace_folders.md
  class ChromeDevtools
    NAMESPACE = "822f7bc5-aa31-4b9f-9c14-df23d95578a1" # randomly generated when writing this code, you can change it to any UUID you want.
    PATH = "/.well-known/appspecific/com.chrome.devtools.json"

    def initialize(app)
      @app = app
    end

    def call(env)
      return @app.call(env) unless env["PATH_INFO"] == PATH

      body = {
        workspace: {
          uuid: generate_uuid,
          root: Rails.root.to_s
        }
      }

      headers = {
        "Content-Type" => "application/json",
        "Cache-Control" => "public, max-age=31536000, immutable",
        "Expires" => (Time.now + 1.year).httpdate
      }

      [200, headers, [body.to_json]]
    end

    private

    def generate_uuid
      Digest::UUID.uuid_v5(NAMESPACE, Rails.root.to_s)
    end
  end
end

And enable the middleware in your config/environments/development.rb:

require "./lib/middleware/chrome_devtools"

Rails.application.configure do
  # ...
  config.middleware.use Middleware::ChromeDevtools
end

That’s it!

Deep link into apps with Hotwire Native and universal links (iOS)

2025-02-27T00:00:00+01:00

This post was updated in October 2025 to work with the latest version of Hotwire Native (1.2 and up).

By default all external links in your Hotwire Native app will open in a Safari modal. This is great for most cases, but it’s also very nice to directly open links in a specific app, for example, when linking to a location on Google Maps, or an Instagram post.

This is where universal links come in. They are just standard https links that you can also open in the browser, but if the user has the app installed, the system will open the link directly in the app.

When users tap or click a universal link, the system redirects the link directly to your app without routing through Safari or your website. In addition, because universal links are standard HTTP or HTTPS links, one URL works for both your website and your app. If the user has not installed your app, the system opens the URL in Safari, allowing your website to handle it.

Hotwire Native

Fortunately, Hotwire Native offers some flexibility on how to deal with links through ‘route decision handlers’ (introduced in 1.2.0), and with a little bit of code we can open links that have a the corresponding app installed in their app, and open the rest in a Safari modal.

There are two built-in handlers:

Open links through the system (SystemNavigationRouteDecisionHandler).
Open links in a Safari modal (SafariViewControllerRouteDecisionHandler), the default.

The first option works well with universal links, they open in their app as expected. But if you don’t have the app installed (or there is no app at all), those links will now be opened in the Safari app, no longer in a modal, and the user will have left your app.

Instead of using one of the options above, we can also write our own custom handler and have the best of both worlds. We’ll call it the UniversalRouteDecisionHandler. Put the following in a file named UniversalRouteDecisionHandler.swift.

It’s based on the SafariViewControllerRouteDecisionHandler, especially the code for matches is copied as it is. The ‘magic’ happens in the handle method.

Unfortunately, as of today there is no other way to detect if an app answers to an universal links then trying to open it and see what happens. We tell the system to open the link (but as an universal link only), and if it fails, we fall back by calling Hotwire Native’s built in SafariViewControllerRouteDecisionHandler to handle the link.

import Foundation
import HotwireNative
import UIKit

public final class UniversalRouteDecisionHandler: RouteDecisionHandler {
    public let name: String = "universal-route-decision-handler"

    public init() {}

    public func matches(location: URL,
                        configuration: Navigator.Configuration) -> Bool
    {
        /// SFSafariViewController will crash if we pass along a URL that's not valid.
        guard location.scheme == "http" || location.scheme == "https" else {
            return false
        }

        if #available(iOS 16, *) {
            return configuration.startLocation.host() != location.host()
        }

        return configuration.startLocation.host != location.host
    }

    public func handle(location: URL,
                       configuration: Navigator.Configuration,
                       navigator: Navigator) -> Router.Decision
    {
        UIApplication.shared.open(location, options: [.universalLinksOnly: true]) { success in
            if !success {
                // no app to handle the link, open in a modal through the built-in SafariViewControllerRouteDecisionHandler
                let handler = SafariViewControllerRouteDecisionHandler()

                _ = handler.handle(location: location,
                                   configuration: configuration,
                                   navigator: navigator)
            }
        }

        return .cancel
    }
}

The only thing left is to register our new handler in your AppDelegate. We keep some of the existing stack of handlers as well, as they handle internal links (AppNavigationRouteDecisionHandler) and other links, like email:... or tel:... or other custom URL schemes (SystemNavigationRouteDecisionHandler).

Hotwire.registerRouteDecisionHandlers([
    AppNavigationRouteDecisionHandler(),
    UniversalRouteDecisionHandler(), // this replaces `SafariViewControllerRouteDecisionHandler()`
    SystemNavigationRouteDecisionHandler()
])

This way your users will have the best user experience for all links in your app. If a link has a corresponding app installed, that will be used. If not, the link will open in a modal Safari screen in your app.

Make delete actions stand out in Hotwire Native menus

2025-01-06T00:00:00+01:00

The Hotwire Native menu bridge is one of the most common ways to interact with native functionality from your Hotwire Native app. It is part of the demo application and probably one of the first components you will implement when you start building your own Hotwire Native app. It instantly makes your app feel more native.

A common design pattern is to show ‘destructive’ actions (deleting a record, for example) in a different color (usually red) to indicate that the action is potentially dangerous and make them stand out from the other actions.

The example menu component has no way to do this out of the box, so in this article I will show you how to add different styling for such actions with just a few lines of code!

The current situation

What we'll end up with

The Bridge component (iOS)

All code is based on the example app’s MenuComponent and the corresponding Stimulus controller from the Hotwire Native demo app.

The menu is constructed from UIAlertAction classes in the iOS app’s MenuComponent. They allow for little configuration, but do have a style property that can be set to .destructive to indicate a destructive action, which makes the text of the item red. We’ll use this property to style our menu item differently.

The current implementation always uses the .default style, so we’re going to keep that as, well, the default.

To distinguish between regular and destructive menu items, we add a destructive boolean property to the Item struct (which is part of the data structure received from the bridge component), and set the style property of the UIAlertAction based on it’s value.

That leads to the following changes:

// MenuComponent.swift
// source: https://github.com/hotwired/hotwire-native-ios/blob/1.1.0/Demo/Bridge/MenuComponent.swift

// lines 39-43
for item in items {
-   let action = UIAlertAction(title: item.title, style: .default) { [unowned self] _ in
-       onItemSelected(item: item)
-   }
+   let action = UIAlertAction(title: item.title,
+                              style: item.destructive ? .destructive : .default)
+   { [unowned self] _ in
+       onItemSelected(item: item)
+   }
    alertController.addAction(action)
}

// ...

# line 89
struct Item: Decodable {
    let title: String
    let index: Int
+   let destructive: Bool
}

The formatting is a bit different, but the main functional change is the addition of the ternary operator that sets style based on the new property.

The Bridge component (Android)

Thanks to Leon Vogt for providing tips for the Android implementation!

The Android implementation is a bit different, but the concept is the same. We need to add a destructive property to the Item data class and use it to set the text color of the menu item. Android itself has no notion of ‘destructive’ actions, so we set to set the color of the text ourselves.

// MenuComponent.kt
// source: https://github.com/hotwired/hotwire-native-android/blob/1.1.1/demo/src/main/kotlin/dev/hotwire/demo/bridge/MenuComponent.kt

// line 72
@Serializable
data class Item(
    @SerialName("title") val title: String,
    @SerialName("index") val index: Int
+   @SerialName("destructive") val destructive: Boolean
)

// MenuComponentAdapter.kt
// source: https://github.com/hotwired/hotwire-native-android/blob/1.1..1/demo/src/main/kotlin/dev/hotwire/demo/bridge/MenuComponentAdapter.kt

// line 50
fun bind(item: MenuComponent.Item) {
    textView.text = item.title

+   if (item.destructive) {
+       textView.setTextColor(Color.RED)
+   } else {
+       textView.setTextColor(Color.BLACK)
+   }
+
    itemView.setOnClickListener {
        action?.invoke(item)
    }
}

The Stimulus bridge controller

We now need to change the payload that is sent from the stimulus controller. The menuItem function inside the controller constructs the data for each menu item, so that’s where we need to add our new destructive property.

We could use a custom Stimulus value or data attribute and set it explicitly for the items we want to use it for. But since we already use Turbo there’s a good chance there’s already a data-turbo-method attribute set on link that do deletes, as Turbo uses that to send requests with the right HTTP request method.

We can leverage that attribute to set the destructive property directly. This means that all menu items that link to a DELETE action will automatically be marked as destructive, without changing any of the underlying HTML.

// app/javascript/controllers/bridge/menu_controller.js
// source: https://github.com/hotwired/hotwire-native-demo/blob/f5d60c343a1cf741f50aaec930e2ff17c267df26/public/javascript/controllers/bridge/menu_controller.js

// line 34
menuItem(element, index) {
  const bridgeElement = new BridgeElement(element)

  if (bridgeElement.disabled) return null

  return {
    title: bridgeElement.title,
    index: index,
+   destructive: element.dataset.turboMethod === "delete",
  }
}

That’s it! All menu items that link to a DELETE action will now be marked as destructive and shown in red in the native menu.

Building a Native sharing component with Hotwire Native (iOS)

2024-12-11T00:00:00+01:00

One of the great things about building with Hotwire Native is being able to easily tap into native functionality. A common use case in mobile apps is the ability to share content using the native share functionality. It’s the most center button in Safari, after all. Let’s look at how we can implement this using Hotwire Native’s bridge components! The implementation consists of three parts:

A Stimulus bridge component that handles the web interface.
A Swift bridge component that opens the native sharing modal.
HTML markup to wire everything up.

Let’s break down each piece:

The Stimulus bridge controller

// app/javascript/controllers/bridge/share_controller.js
import { BridgeComponent } from "@hotwired/hotwire-native-bridge";

export default class extends BridgeComponent {
  static component = "share";

  open() {
    this.send("open", { url: window.location.href });
  }
}

This simple Stimulus controller doesn’t need to do much. It defines the bridge component’s name and an open function, which sends a message to the native layer with the current page URL as it’s data payload. Since we only need to send some data one way (to the bridge layer) when the open action is performed, we do not need to override the connect() function or define a callback function.

The Bridge component

// ShareComponent.swift
import HotwireNative
import UIKit

final class ShareComponent: BridgeComponent {
    override static var name: String { "share" }

    override func onReceive(message: Message) {
        guard
            let data: MessageData = message.data(),
            let url = URL(string: data.url)
        else { return }

        openShareModal(url: url)
    }

    private var viewController: UIViewController? {
        delegate.destination as? UIViewController
    }

    private func openShareModal(url: URL) {
        let activityViewController = UIActivityViewController(activityItems: [url], applicationActivities: nil)
        viewController?.present(activityViewController, animated: true)
    }
}

private extension ShareComponent {
    struct MessageData: Decodable {
        let url: String
    }
}

The Swift component handles the native part of the implementation. When it receives a message from the share component, it creates a UIActivityViewController - iOS’s native sharing interface - with the url from the data payload, and opens it by passing it to the viewController. We only have one possible event (open), so there is no need to check for specific message types in the onReceive function and we can just assume it will always be that event.

There are some additional options to pass to the UIActivityViewController initializer, you can for example exclude certain activity types or sections. Check out the documentation for more information.

Tying it all together: the HTML part

<div data-controller="bridge--share">
  <button data-action="bridge--share#open">Share</button>
</div>

Implementing the HTML markup is straightforward. We add a button that triggers the open action on the bridge--share controller when clicked.

You can also combine this with other Hotwire Native components, for example inside a menu, because those will simply trigger a click event, which in turn triggers the action of our share component.

You probably want to hide the share button for non-native apps, as they have to use the browser’s share functionality and the button won’t have any functionality when clicked (as it only triggers the bridge message). You can do this by checking if view is rendered for a native app:

<% if hotwire_native_app? %>
  <div data-controller="bridge--share">
    <button data-action="bridge--share#open">Share</button>
  </div>
<% end %>

You can also add css classes to hide functionality for non-native apps. This has the added benefit of having less code in your views, and means there is only one version of the page, which makes caching a lot simpler. This article by Yaroslav Shmarov explains how to do this with Tailwind CSS.

If anyone has written the Android variant of this component, please let me know! I didn’t dive into Android development yet, so haven’t written it yet myself.

Benchmarking return data types

2024-01-16T00:00:00+01:00

In a previous article, I discussed several approaches to handling returned data in API responses. These ranged from using plain Ruby hashes to more type-strict solutions like dry-struct.

I also wanted to benchmark all of them to compare their performance. In any real-world application, the raw performance of each method is largely irrelevant, as the overhead of the web request and response time of the API itself is likely much larger by multiple orders of magnitude. However, running some benchmarks can still be a fun exercise.

First, I want to formulate some assumptions about what I would expect. This is a valuable exercise for improving your ability to make ballpark estimations and train your intuition when it comes to performance.

So, here are my predictions:

Nothing beats the performance of Hash, simply for the fact that all other structures need a hash as input, so per definition that’s the absolute lower limit of performance.
Hashes with symbolized keys or indifferent access (both string and symbol) are a bit slower, but not twice as slow. So let’s end in the middle and guess 1.5 times slower.
All the Ruby class like structures have roughly the same performance and are a couple of times slower than Hash.
OpenStruct performs very bad, because I already know this before I started on this article and the docs are so explicit about it. It performs the worst of all structures, about 10 times as slow.
The structures that have some form of type checking are also slower because there’s a lot more going on. It needs to check types and cast types for example. I expect those to be twice as slow as the regular class like structures.

I’ve decided to split the tests into two parts, one where I test parsing JSON into hashes (with string keys, symbol keys and indifferent access), and one for converting those hashes into more complex structures. The reason for this is that all the other methods need a Hash as input anyway, so comparing pure performance make no sense, and I feel there is a distinct different between a hash structure and a more refined object-like structures.

I also want to have a look at memory usage, just to see if anything interesting shows up there. Memory usage might be a better to reason to use one or the other in any real life application, more so than raw performance, as API responses can be quite large.

💎 I ran these tests on a 2021 Macbook Pro equipped with a M1 Max chip and 32 GB of ram. I used Ruby 3.3.0 with YJIT enabled. (ruby 3.3.0 (2023-12-25 revision 5124f9ac75) +YJIT [arm64-darwin23])

For these tests I convert the full output of the Github User API for my personal account, which has about 22 simple string/integer fields in it. I wrote (with some help from Github Copilot) simple wrapper classes that take all fields as attributes. For the structures that have types I set up the correct types.

First the results for hash conversion:

Hash               164.407k (± 1.4%) i/s -    837.318k in   5.093985s
Hash w/ symbols    147.386k (± 1.4%) i/s -    738.750k in   5.013394s
Hash w/ ind. xs    115.527k (± 0.6%) i/s -    586.143k in   5.073812s

Comparison:
Hash:              164407.2 i/s
Hash w/ symbols:   147386.3 i/s - 1.12x  slower
Hash w/ ind. xs:   115527.4 i/s - 1.42x  slower

Hash:                  4328 allocated
Hash w/ symbols:       4488 allocated - 1.04x more
Hash w/ ind. xs:       5360 allocated - 1.24x more

I expected the symbolized keys and indifferent access hashes to be about 1.5 times slower, so these results are about what I expected. Memory wise there are a few more allocations, but nothing serious.

Now onto the more interesting data structures.

                PORO      1.615M (± 0.7%) i/s -      8.209M in   5.083925s
              Struct    979.275k (± 2.1%) i/s -      4.991M in   5.099120s
          OpenStruct    216.668  (±18.5%) i/s -      1.072k in   5.107021s
                Data    996.112k (± 3.0%) i/s -      4.989M in   5.013517s
         Dry::Struct    179.454k (± 2.5%) i/s -    914.175k in   5.097592s
         ActiveModel    125.635k (± 0.8%) i/s -    638.612k in   5.083395s
        Hashie::Mash     61.640k (± 1.2%) i/s -    314.132k in   5.097024s
        Hashie::Dash    132.436k (± 2.0%) i/s -    663.850k in   5.014691s

Comparison:
                PORO:  1614715.8 i/s
                Data:   996112.0 i/s - 1.62x  slower
              Struct:   979275.1 i/s - 1.65x  slower
         Dry::Struct:   179454.0 i/s - 9.00x  slower
        Hashie::Dash:   132436.3 i/s - 12.19x  slower
         ActiveModel:   125634.8 i/s - 12.85x  slower
        Hashie::Mash:    61639.7 i/s - 26.20x  slower
          OpenStruct:      216.7 i/s - 7452.49x  slower

                PORO:        320 allocated
              Struct:       1232 allocated - 3.85x more
                Data:       1232 allocated - 3.85x more
         ActiveModel:       1856 allocated - 5.80x more
        Hashie::Dash:       3808 allocated - 11.90x more
          OpenStruct:      18256 allocated - 57.05x more
         Dry::Struct:      24170 allocated - 75.53x more
        Hashie::Mash:     183756 allocated - 574.24x more

The Plain Ruby Object is the clear winner here. In general you could say that Data and Struct perform the same, being a bit slower than a simple Ruby object, but not as much as the more complex structures.

We can also group together the more complex structures like Dry::Struct, regular Hashie and ActiveModel. They perform a few times slower than the simpler structures, but still seem to be pretty fast. Dry::Struct does use a lot more memory though, I assume this is because of the type checking and type casting it needs to do.

The only real outlier is OpenStruct, which is a whopping 2500 times slower (!) and uses 57 times more memory. Next to that, Hashie::Mash is also really memory hungry, needing almost than 575 times more allocations than a simple Ruby object.

I think the main conclusion to draw from these benchmarks are:

There is no reason to ever use OpenStruct.
Any other structure is probably fine.

To circle back to my predictions I made at the start of the article:

✅ Hash is the fastest (that was easy 😅).
✅ Stringified keys is a bit slower, but not 2 times.
✅ Regular Ruby objects perform about the same.
❌ OpenStruct is not 10 times slower, but 2500 times.
❌ Typed structures are not 2 times slower, but more like between 5 and 10 times.

Embedding Superset dashboards in React applications

2024-01-10T00:00:00+01:00

Superset is an open-source data visualization platform, while Preset is a hosted SaaS solution for Superset. A notable capability of Superset is its ability to embed dashboards within other applications. This feature allows for easy dashboard management using Superset, without requiring users to leave your application. Additionally, Superset offers security rules to ensure data is correctly filtered for each user or team.

To embed dashboards, Superset provides an SDK that renders an iframe within your application. This process requires a special guest token, which you can generate on your application’s backend by interacting with the Superset API.

This article presumes that you’ve already set up and configured Superset and written the backend code to generate guest tokens. If not, please refer to the official Preset (or Superset) documentation.

The primary challenge I encountered while integrating Superset into our React application was making sure I called the embed code at the right moment and only once. The library and needs access to a DOM element to insert the iframe. However, it wouldn’t render correctly when other parts of the page were still loading (and the mounting point wouldn’t exist yet) and would suffer from unnecessary additional calls caused by re-renders.

My initial attempts used just useEffect and useLayoutEffect hooks, which didn’t solve the problems consistently. My next attempt involved useRef with a reference to the mounting point. However, useRef does not trigger re-renders by design, so there’s no way to re-trigger the effect once the current reference is set after the element is added to the DOM.

Luckily, there’s an alternative process where we can pass a callback function directly to ref. This method, known as a “ref callback function”, passes the DOM node you set the ref on as an argument:

When the <div> DOM node is added to the screen, React will call your ref callback with the DOM node as the argument.

<div ref={(node) => console.log(node)} />

This perfectly suits our needs as it will only be called when the element is available in the DOM.

The final point to address is to make sure that the embedding code is called only once, not every time the component is re-rendered, for example when a parent gets re-rendered. This can be achieved by keeping a simple ‘mounted’ state, which can then be used to make sure the code gets called only once.

Combining these elements, we can create a custom hook. This custom hook takes one argument, the id of the dashboard, and returns a callback function that takes the mounting point as the sole argument. This function can then be passed into the ref as the direct callback function in your component:

import { useCallback } from "react";
import { embedDashboard } from "@superset-ui/embedded-sdk";

// Implement your actual API backend call here (through a Promise).
const fetchGuestToken = () => { /* ... */ };

export const useSupersetEmbed = (id: string) => {
  const [mounted, setMounted] = useState(false);

  const ref = useRef(null);

  useEffect(() => {
    if (!ref.current) return;
    if (mounted) return;

    void embedDashboard({
      id,
      supersetDomain: "https://....",
      mountPoint: ref.current,
      fetchGuestToken,
      // dashboardUiConfig: {},
      // debug: true,
    });

    setMounted(true);
  }, [id, mounted];

  return ref;
};

export const SupersetExampleDashboard = () => {
  const embed = useSupersetEmbed("your-dashboard-id-here");

  return <div ref={embed} />;
};

And that’s it! You can now embed Superset dashboards in your React application without any reloading or rendering issues.