DEV Community: reinteractive

reinteractive: Shaping the Future of Rails Through Leadership Insights

reinteractive — Tue, 15 Jul 2025 01:26:41 +0000

reinteractive is on a mission to understand and help shape the future trajectory of the Rails industry. We believe that the most valuable insights come directly from those at the forefront of innovation and decision-making.

To achieve this, reinteractive is currently conducting a crucial survey, inviting CTOs, Founders, and key leaders within the Rails ecosystem to share their perspectives. This isn't just about gathering data; it's about building a comprehensive understanding of where the industry is headed, directly from the minds that are guiding it.

Participants are invited to engage in a brief 15-minute discussion. All responses are handled with the utmost confidentiality and will be shared anonymously in the collated results. Once these insights are gathered, reinteractive is committed to sharing them publicly, with plans to present the findings at future industry conferences.

Understanding that leaders are often busy, reinteractive offers flexible scheduling, allowing participants to book a time that suits them, even if their next few weeks are particularly demanding. The survey will remain open for an extended period to ensure the broadest possible range of insights and perspectives are captured.

reinteractive is dedicated to fostering a collaborative environment where industry leaders can contribute to a collective vision for the future of Rails.

To contribute your insights, book a time with reinteractive here: https://calendar.app.google/15kqwmgNfQ9oQDSu9

Introducing SecretLink: The Secure Way to Share Sensitive Information

reinteractive — Thu, 29 May 2025 03:13:01 +0000

Credited to: Errol Schmidt

IN A NUTSHELL

SecretLink offers essential, free, open-source security for sharing sensitive development data like API keys.

SecretLink’s open-source model ensures transparency and trust, a key factor for modern tech teams.

Use SecretLink to experience simple, self-destructing data transfer, eliminating insecure sharing via email or chat

Introduction

One of the tools we utilise at reinteractive for our own development projects is Secretlink. It is a tool that allows our clients and developers to securely share project information that requires high levels of security. This includes environment variables, API keys, user passwords etc.

We developed and maintain Secretlink to avoid passing around sensitive information using emails or Slack.

How SecretLink Works

Secretlink encrypts your secrets and only the recipient of the secret is provided the key to decrypt. Secretlink does not store the decryption key making the data secure. This is a one-way cipher.

As soon as the secret has been opened by the recipient the encrypted data is removed from the database and cannot be accessed by anyone again.

This allows you to send any form of sensitive information without the risk of it being accessed by any other party.

Who can use Secretlink

Secretlink is available to anyone as a free service. All you need to do is enter your email address and you will be sent a token to set up your secret and enter the recipient.

Feel free to share Secretlink and make it available to anyone within your team or network.

We have a number of our clients who use Secretlink for the transfer of secrets internally with their own team. It is a much better solution than using emails which can accidentally be forwarded, exposing secrets to the wrong recipients.

Open Source

Secretlink is an Open Source project under a GPL licence. It is written in Ruby on Rails and actively maintained to the latest rails versions. Any developer can fork the code and utilise it for their own purposes. We only ask that you don’t use it for commercial or competitive purposes, but use it for your own clients and staff.

Feel free to make any recommendations for improvements of the code, through raising an issue or a pull request.

Setting up the app locally is relatively easy to do. All of the instructions are covered within the Readme.md file.

The repo can be accessed via this link github/reinteractive/secretlink

Conclusion

We wrote Secretlink for our own purposes, and are happy for it to be used by the Rails community. Please add your enhancements and create any pull requests you think will make the service better.

Rails Action Mailer: Rendering Charts or Graphs in your Email

reinteractive — Tue, 29 Apr 2025 11:07:58 +0000

Credited to: Charles Martinez

Recently, I had to look into a few ways to embed a chart into Rails mailer views. Most of the time, I just use chartkick because its simple and easy to use. But in mailers, Chartkick can’t be used directly, so you have to embed an image of the chart for it to work.

Generating Chart Images

After a while, I bumped into QuickChart an Open Source library to generate chart images by just generating the url with the correct query parameters. And it offers a lot of chart options https://quickchart.io/gallery/

https://quickchart.io/chart?c={type:'bar',data:{labels:['Q1','Q2','Q3','Q4'], datasets:[{label:'Users',data:[50,60,70,180]},{label:'Revenue',data:[100,200,300,400]}]}}

And another thing, there’s also a gem that acts as a Ruby client for QuickChart -https://github.com/typpo/quickchart-ruby
Given that, you can very simply generate a QuickChart object.

u/chart = QuickChart.new(
  {
    type: 'bar',
    data: {
      labels: ['Q1', 'Q2', 'Q3', 'Q4'],
      datasets: [
        {
          label: 'Users',
          data: [50, 100, 120, 150]
        },
        {
          label: 'Revenue',
          data: [100, 200, 300, 450]
        },
      ]
    },
    options: {
      title: {
        display: true,
        text: 'Users vs Revenue',
        fontSize: 16,
        padding: 16,
      },
    },
  }
)

And then render the URL of that object in your Mailer View.

# apps/views/sample_mailer/sample_email.html.erb

<img src="<%= @chart.get_url %>">

And that’s it! You can now embed and render charts in your Mailer Views. Very simple and quick to implement.

Refinement: The Correct Way To Monkey-Patch in Ruby

reinteractive — Mon, 28 Apr 2025 03:58:40 +0000

Credited to: Allan Andal

Ruby's Refinement feature emerged as an experimental addition in Ruby 2.0 and became a full-fledged feature starting with Ruby 2.1. It’s a neat way to tweak a class’s methods without messing with how it works everywhere else in your app. Instead of monkey-patching—where you’d change something like String or Integer and it impacts your whole program—Refinements let you keep those changes contained to a specific module or class. You activate them when needed with using keyword. This addresses monkey-patching’s danger of silent—bugs, conflicts, and maintenance woes.

Old way

Let's say you want to add a new method that converts a string "Yes" and "No" to a boolean value. All we need to do is reopen the class and add the method:

class String
  def to_bool
    case downcase
      when *%w[true yes 1] then true
      when *%w[false no 0] then false
      else raise ArgumentError, "Invalid boolean string: #{self}"
    end
  end
end

"True".to_bool
=> true

"FALSE".to_bool
=> false

Easy right? However, some problems can arise with this approach:

Its everywhere. It gets applied to all String objects in the application.
Subtle bugs: Monkey patches are hard to track. A method added in one file might break logic in another, with no clear trail to debug.
Library conflicts: Some gems monkey-patch core classes (no need to look far, active_support does it).
Maintenance hell. Tracking global changes becomes a nightmare when teams of multiple developers patch the same class. Monkey-patching’s flexibility made it a staple in early Ruby code, but its lack of discipline often turned small tweaks into big problems.

Using Refinements

Refinements replace monkey-patching by scoping changes to where they’re needed. Instead of polluting String globally, you define a refinement in a module:

module BooleanString
  refine String do
    def to_bool
      case downcase
        when *%w[true yes 1] then true
        when *%w[false no 0] then false
        else raise ArgumentError, "Invalid boolean string: #{self}"
      end
    end
  end
end

# Outside the refinement, String is unchanged
puts "true".to_bool rescue puts "Not defined yet"

# Activate the refinement
using BooleanString
puts "true".to_bool   # => true
puts "no".to_bool     # => false
puts "maybe".to_bool  # => ArgumentError: Invalid boolean string: maybe

Compared to the old way, using Refinements offer clear benefits:

Scoped Changes: Unlike monkey-patching’s global reach, to_bool exists only where BooleanString is activated, leaving String untouched elsewhere.
No Conflicts: Refinements avoid clashing with gems or other code, as their effects are isolated.
Easier Debugging: If something breaks, you know exactly where the refinement is applied—no hunting through global patches.
Cleaner Maintenance: Scoping makes it clear who’s using what, simplifying teamwork and long-term upkeep.

Even better approach (Ruby 2.4+, using `import_methods`)

Since Ruby 2.4, import_methods lets you pull methods from a module into a refinement, reusing existing code. Suppose you have a BooleanString module with to_bool logic:

module BooleanString
  def to_bool
    case downcase
      when *%w[true yes 1] then true
      when *%w[false no 0] then false
      else raise ArgumentError, "Invalid boolean string: #{self}"
    end
  end
end

module MyContext
  refine String do
    import_methods BooleanString
  end
end

# Outside the refinement, String is unchanged
puts "true".to_bool rescue puts "Not defined yet"

# Activate the refinement
using MyContext
puts "true".to_bool   # => true
puts "no".to_bool     # => false
puts "maybe".to_bool  # => ArgumentError: Invalid boolean string: maybe

Why Refinements?

Refinements address the old monkey-patching problems head-on:

Large Projects: Monkey-patching causes chaos in big codebases; Refinements keep changes isolated, reducing team friction.
Library Safety: Unlike global patches that "can" break gems, Refinements stay private, ensuring compatibility.
Prototyping: Refinements offer a sandbox for testing methods, unlike monkey patches that commit you to global changes.

With Ruby 3.4's reduced performance overhead makes Refinements a practical replacement, where monkey-patching’s simplicity once held sway.

Some Tips

Scope Tightly: Instead of making blanket changes on classes (specially on based Ruby data types), use only on specific classes or methods.
Name Clearly: This probably is the hardest part (naming things), but pick module names to show intent, avoiding monkey-patching’s ambiguity.
Debug Smartly: Ruby 3.4’s clearer errors beat tracing global patches—check using if methods vanish.
Reuse Code: Use import_methods to share logic, a step up from monkey-patching’s copy-paste hacks.

Wrapping Up

Whether you’re building new features, dodging library issues, or just playing around with ideas, Refinements are a small change that makes a huge difference. Next time you’re tempted to reopen a class and go wild, give Refinements a shot—you’ll thank yourself later.

Adding an AI chat to your Ruby on Rails application

reinteractive — Wed, 02 Apr 2025 03:34:00 +0000

Credited to: Todd Price

Unless you've been living under a rock for the last couple of years, you've heard about AI and how one day it will do everything for you. Well, we aren't quite at AGI yet but we are certainly on the way. So to better understand our future computer overlords I've spent a lot of time using them and have recently been experimenting with the RubyLLM Gem. It's a great gem which makes it very easy to integrate the major LLM providers into your rails app (at the time of writing only Anthropic, DeepSeek, Gemini and OpenAI are supported).

To demonstrate, I'm going to add an AI chat to a new rails 8 application but you can just as easily apply most of this to your existing rails application. We'll go beyond the most basic setup and allow each user to have their own personal chats with the AI.

Let's start by setting up the a new app:

rails new ai_chat --database postgresql

and then follow Suman's post to use the new built-in rails user auth. Alternatively, use your preferred user & auth setup.

Now we're ready to add in ruby_llm:

# Gemfile
gem "dotenv"   # for managing API keys, you may want to handle them differently
gem "ruby_llm"

bundle install

Add in an initializer to set the API key for your provider(s) of your choice

# config/initializers/ruby_llm.rb
RubyLLM.configure do |config|
  config.anthropic_api_key = ENV["ANTHROPIC_API_KEY"]
  config.deepseek_api_key = ENV["DEEPSEEK_API_KEY"]
  config.gemini_api_key = ENV["GEMINI_API_KEY"]
  config.openai_api_key = ENV["OPENAI_API_KEY"]
end

Set up your .env file if using dotenv (however you choose to save these keys, keep them secure, don't commit to version control)

OPENAI_API_KEY=sk-proj-

Now we create the new models.
First, we create our Chat model which will handle the conversation:

# app/models/chat.rb
class Chat < ApplicationRecord
  acts_as_chat
  belongs_to :user
  broadcasts_to ->(chat) { "chat_#{chat.id}" }
end

The acts_as_chat method comes from RubyLLM and provides:

Message management
LLM provider integration
Token tracking
History management

Next, we create our Message model to handle individual messages in the chat. Each message represents either user input or AI responses:

# app/models/message.rb
class Message < ApplicationRecord
  acts_as_message
end

The acts_as_message method from RubyLLM provides:

Role management (user/assistant/system)
Token counting for both input and output
Content formatting and sanitization
Integration with the parent Chat model
Tool call handling capabilities

Finally, the ToolCall model. I'll cover this in another post, but you need to add it here for RubyLLM to work.

# app/models/tool_call.rb
class ToolCall < ApplicationRecord
  acts_as_tool_call
end

Next we link the chats to users:

# app/models/user.rb
class User < ApplicationRecord
  # ...existing code

  has_many :chats, dependent: :destroy

  # ...existing code
end

Create the migrations:

# db/migrate/YYYYMMDDHHMMSS_create_chats.rb
class CreateChats < ActiveRecord::Migration[8.0]
  def change
    create_table :chats do |t|
      t.references :user, null: false, foreign_key: true
      t.string :model_id
      t.timestamps
    end
  end
end


# db/migrate/YYYYMMDDHHMMSS_create_messages.rb
class CreateMessages < ActiveRecord::Migration[8.0]
  def change
    create_table :messages do |t|
      t.references :chat, null: false, foreign_key: true
      t.string :role
      t.text :content
      t.string :model_id
      t.integer :input_tokens
      t.integer :output_tokens
      t.references :tool_call
      t.timestamps
    end
  end
end


# db/migrate/YYYYMMDDHHMMSS_create_tool_calls.rb
class CreateToolCalls < ActiveRecord::Migration[8.0]
  def change
    create_table :tool_calls do |t|
      t.references :message, null: false, foreign_key: true
      t.string :tool_call_id, null: false
      t.string :name, null: false
      t.jsonb :arguments, default: {}
      t.timestamps
    end

    add_index :tool_calls, :tool_call_id
  end
end

Run the migrations:

rails db:migrate

Then we'll set up ActionCable so we can stream the chat and make it appear as though the AI is typing out the response.
For further details on this, see the Rails Guides

# app/channels/application_cable/connection.rb
# This file was created by rails g authentication so if you are using a different auth setup you'll need to adapt this
module ApplicationCable
  class Connection < ActionCable::Connection::Base
    identified_by :current_user

    def connect
      set_current_user || reject_unauthorized_connection
    end

    private
      def set_current_user
        if session = Session.find_by(id: cookies.signed[:session_id])
          self.current_user = session.user
        end
      end
  end
end


# app/channels/application_cable/channel.rb
module ApplicationCable
  class Channel < ActionCable::Channel::Base
  end
end


# app/channels/chat_channel.rb
class ChatChannel < ApplicationCable::Channel
  def subscribed
    chat = Chat.find(params[:id])
    stream_for chat
  end
end

// app/javascipt/channels/consumer.js
import { createConsumer } from "@rails/actioncable"

export default createConsumer()


// app/javascipt/channels/chat_channel.js
import consumer from "./consumer"

consumer.subscriptions.create(
  { channel: "ChatChannel", id: this.element.dataset.chatId }
)

Now we set up our controllers.

First, our ChatsController which will handle the overall conversation. It provides:

Index action for listing all user's chats
Create action for starting new conversations for a user
Show action for viewing a user's individual chats
Scoped queries to ensure users can only access their own chats

# app/controllers/chats_controller.rb
class ChatsController < ApplicationController
  def index
    @chats = chat_scope
  end

  def create
    @chat = chat_scope.new

    if @chat.save
      redirect_to @chat
    else
      render :index, status: :unprocessable_entity
    end
  end

  def show
    @chat = chat_scope.find(params[:id])
  end

  private

  def chat_scope
    Current.user.chats
  end
end

Next, we create our MessagesController to handle individual message creation and the AI response.

# app/controllers/messages_controller.rb
class MessagesController < ApplicationController
  def create
    @chat = find_chat

    GenerateAiResponseJob.perform_later(@chat.id, params[:message][:content])
    redirect_to @chat
  end

  private

  def find_chat
    Current.user.chats.find(params[:chat_id])
  end

  def message_params
    params.require(:message).permit(:content)
  end
end

Add the necessary routes:

# add to config/routes.rb
resources :chats, only: [ :index, :new, :create, :show ] do
  resources :messages, only: [ :create ]
end

Considering AIs can take a bit of time to "think", we're making the call in a background job:

class GenerateAiResponseJob < ApplicationJob
  queue_as :default

  def perform(chat_id, user_message)
    chat = Chat.find(chat_id)

    thinking = true

    chat.ask(user_message) do |chunk|
      if thinking && chunk.content.present?
        thinking = false
        Turbo::StreamsChannel.broadcast_append_to(
          "chat_#{chat.id}",
          target: "conversation-log",
          partial: "messages/message",
          locals: { message: chat.messages.last }
        )
      end

      Turbo::StreamsChannel.broadcast_append_to(
        "chat_#{chat.id}",
        target: "message_#{chat.messages.last.id}_content",
        html: chunk.content
      )
    end
  end
end

The ask method from RubyLLM will add 2 new messages to the chat. The first one is the message from the user and the second is for the AI's response. The response from the LLM comes back from the provider in chunks and each chunk is passed to the block provided. We wait for the first non-empty chunk before appending the chat's last message (the one created for the AI) to the conversation log. After that we can stream the content of subsequent chunks and append them to the message.

Tip: You can customize the AI's behavior by adding system prompts to the chat instance, see the RubyLLM docs

Finally, we create the views:

<%# app/views/chats/index.html.erb %>
<div>
  <h1>Chats</h1>

  <% if @chats.empty? %>
    <p>No chats found. Create a new chat.</p>
  <% else %>
    <div>
      <% @chats.each do |chat| %>
        <div>
          <span>ID: <%= chat.id %></span>
          <span><%= chat.created_at.strftime('%Y-%m-%d %H:%M:%S') %></span>
          <span>
            <%= link_to 'View', chat_path(chat) %>
          </span>
        </div>
      <% end %>
    </div>
  <% end %>

  <div>
    <%= link_to 'New Chat', chats_path, data: { turbo_method: :post } %>
  </div>
</div>


<%# app/views/chats/show.html.erb %>
<div data-controller="chat" data-chat-id="<%= @chat.id %>">
  <%= turbo_stream_from "chat_#{@chat.id}" %>

  <div>
    <h1>Chat #<%= @chat.id %></h1>
    <div>Created: <%= @chat.created_at.strftime('%Y-%m-%d %H:%M:%S') %></div>
  </div>

  <div id="conversation-log">
    <% if @chat.messages.present? %>
      <%= render @chat.messages %>
    <% else %>
      <p>No messages yet.</p>
    <% end %>
  </div>

  <div>
    <%= render "messages/form", chat: @chat, message: @chat.messages.new %>
  </div>

  <div>
    <%= link_to 'Back to Chats', chats_path %>
  </div>
</div>


<%# app/views/messages/_message.html.erb %>
<div id="message_<%= message.id %>">
  <div>
    <span><%= message.role %>:</span>
    <span><%= message.created_at.strftime('%H:%M:%S') %></span>
  </div>
  <div id="message_<%= message.id %>_content">
    <%= message.content %>
  </div>
</div> 


<%# app/views/messages/_form.html.erb %>
<%= form_with(model: [chat, message], url: chat_messages_path(chat), id: "new_message") do |form| %>
  <div>
    <%= form.text_area :content, placeholder: "Enter message", rows: 2 %>
  </div>
  <%= form.submit "Send" %>
<% end %>

And that's it!

What's Next?

Now you should have a working AI chat that allows users to have persistent conversations with AI models. In terms of usefulness to your app, this is only the beginning. The real power comes when we let the AI interact with our application's data and functionality through Tools.
If you were to set this up in an e-commerce app, you could use tools to allow an AI to check inventory, calculate shipping costs or search for a specific order. We'll dive into this and explain tools in the next post.

For now, try adding this to your own Rails app and don't forget to add some proper error handling and security measures before deploying to production.

Re-Revisiting Performance in Ruby 3.4.1

reinteractive — Wed, 26 Mar 2025 02:38:14 +0000

Credited to: Miko Dagatan

Updated: 27 Mar 2025

Introduction

In this article, I’ll be benchmarking Ruby 3.4.2, I’ve had my previous article, Revisiting Performance in Ruby 3.4.1, published and have received various reactions regarding it through this reddit page. I would like to say I'm very thankful for those who have provided their feedback so that I could improve on benchmarking code and presenting my observations.

There are 3 points that have come to importance from all the feedback:

The articles (the first, which is an Alchemist article and second, which is a medium article) I provided do not support my past observation that "Structs are powerful and could be used to define some of the code in place of the Class"
Use benchmark-ips to better benchmark the code I'm benchmarking.
My new conclusion that Classes are now faster than Structs holds false when I use benchmark-ips

I understand these points challenge my observations and I would like to further dive deeper to support my initial findings.

Past observation: Structs are powerful and could be used to define some of the code in place of the Class

I've been reading articles and comments that claim Structs could be used instead of other code. Some said in place of Hashes, some said in place of Classes. Structs provide structure, organisation, and readability to your data so it's better to use instead of Hashes in that regard.

This Stack Overflow comment said that structs are better than hashes.
This Stack Overflow comment said that in ruby 3.0.0p0, structs are faster than hashes.
This Stack Overflow comment points out the real advantage of Structs in 2015 and that is it's faster.
This GitHub gist that compares hashes, ostructs, and structs shows the initialisation (write-only) of data. Hashes are faster in here, but there's still a clear advantage of using Structs.
This Crystal forum page shows that in 2020, structs are faster than classes. Things like these, practically performance comparisons with classes, are what appealed to me.
This Honeybadger article's point is to not use Open Structs. However, it also shows in the benchmarks that Structs were faster compared to the classes.

So, there you go. I've added more links to help give a general understanding of what I understood the majority claims in previous years, that Structs are faster than Classes, and it's great to make use of it as much as possible when your coding situation permits it. The Alchemist article provides a great explanation on when to use it.

Should have checked three times!

In my previous article I've claimed that throughout the years, Ruby may have improved Classes to the point that in certain cases they are faster than Structs. When I initially tested it, I was shocked to find it out, and was very excited to share it to the world. I made adjustments to the benchmarks to ensure that I'm definitely seeing this correctly. Then I've put the article for the world to see.

One of the first comments in the Reddit thread was a suggestion to use benchmark-ips, and that my code should separate the reads and the writes. I followed his advice on the benchmark-ips but while trying to retain my code (to explain later), and what do you know? Turns out that Struct is still faster than Classes. I've been wrong about it! I guessed that I should have probably checked three times before!

Here's the result when using the benchamrk-ips to my benchmarking code. attr_reader is the Class object.

ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24]

Calculating -------------------------------------
               array     27.014M (± 1.6%) i/s   (37.02 ns/i) -    136.720M in   5.062568s
            sym_hash     21.751M (± 2.4%) i/s   (45.98 ns/i) -    110.675M in   5.091684s
            str_hash     20.719M (± 4.6%) i/s   (48.27 ns/i) -    105.263M in   5.094066s
         attr_reader      7.954M (± 1.0%) i/s  (125.72 ns/i) -     40.392M in   5.078593s
              struct     10.973M (± 1.7%) i/s   (91.13 ns/i) -     54.974M in   5.011294s
                data      6.813M (± 1.3%) i/s  (146.77 ns/i) -     34.326M in   5.038833s

Comparison:
               array: 27013631.8 i/s
            sym_hash: 21750676.4 i/s - 1.24x  slower
            str_hash: 20718679.0 i/s - 1.30x  slower
              struct: 10973472.4 i/s - 2.46x  slower
         attr_reader:  7954235.5 i/s - 3.40x  slower
                data:  6813492.5 i/s - 3.96x  slower

An unbelievable twist!

There was a comment that came about in the Reddit thread. I've already spent days trying to grind at my job. So I forgot to check on it. The commenter said "Am I reading the same articles? The first(Alchemist) articles mentions that OpenStruct is terrible for performance (among other reasons), and it states "Performance has waned recently where structs used to be more performant than classes"

It was odd for me because I definitely understood that the articles I referenced are promoting the use of Structs and support my understanding that the general opinion is to make use of them when you can over classes and hashes. So, I re-read both articles, Medium article, which was a faster read, then the Alchemist article. This took a long time, but I enjoyed re-reading it. I noticed that the writer of the article wrote "Performance has waned recently where structs used to be more performant than classes" in the article, and I was sure that I never read that before. I took a look at when it's last updated. Turns out it got updated after I wrote the article, and the Alchemist article got updated the same day as my previous article. February 4, 2025 That makes sense, now I understand why some readers looked confused in their comments about it.

What strikes me is that the Alchemist article changed its stance to support the claim I made in my previous article! Yes, indeed, my article became thoroughly confusing because of that. However, it's more interesting that the Alchemist article supports my initial claim!

The article's benchmark was great because it has 5 attributes instantiated into the objects. It's closer to real-life use, as we're silly to simply use these different data structures, yet provide only one attribute.

I'll copy the code it provided, but I'll try to add more code into it to provide more scenarios. Let's see how these things fare in 2025.

Why Benchmark both Read & Write?

When benchmarking these objects A reddit user mentioned that it's best to test the read and write of the objects in isolation. However, I cannot agree with that as I see in the multitude of codebases I've touched, there's always a write and there can be more than one read when using these objects. I prefer to be close to the real life scenarios.

In my previous article's benchmarks, I've only simulated 1:1 read-write benchmarking. But today, I'll double down on this perspective and benchmark 1:1, 2:1, 3:1, 5:1, and 10:1 read-write situations. This will give us a better understanding of the real-life scenarios for these objects.

Benchmarking

We're using the benchmarking code from the Alchemist's article, and we're adding a few more things there. Here's the new code for benchmarking. I've also added a "Hash string" test so that we can also determine the difference between symbolized hashes and stringified hashes (with frozen string literal comment). I didn't use YJIT for this case because there's already a lot of code and benchmarking results. Try the benchmarking code on your end for YJIT:

Benchmarking Code

#! /usr/bin/env ruby
# frozen_string_literal: true

# Save as `benchmark`, then `chmod 755 benchmark`, and run as `./benchmark`.

require "bundler/inline"

gemfile true do
  source "https://rubygems.org"
  gem "benchmark-ips"
  gem "debug"
  gem "ostruct"
end

Warning[:performance] = false

require "ostruct"

DataDemo = Data.define :a, :b, :c, :d, :e
StructDemo = Struct.new :a, :b, :c, :d, :e

ClassDemo = Class.new do
  attr_reader :a, :b, :c, :d, :e

  def initialize a:, b:, c:, d:, e:
    u/a = a
    u/b = b
    u/c = c
    u/d = d
    u/e = e
  end
end

DataDemoTen = Data.define(:a, :b, :c, :d, :e, :f, :g, :h, :i, :j)
StructDemoTen = Struct.new(:a, :b, :c, :d, :e, :f, :g, :h, :i, :j)

ClassDemoTen = Class.new do
  attr_reader :a, :b, :c, :d, :e, :f, :g, :h, :i, :j

  def initialize a:, b:, c:, d:, e:, f:, g:, h:, i:, j:
    u/a = a
    u/b = b
    @c = c
    @d = d
    @e = e
    @f = f
    @g = g
    @h = h
    @i = i
    @j = j
  end
end



puts "--- 1 Read to 1 Write ---"
Benchmark.ips do |benchmark|
  benchmark.config time: 5, warmup: 2

  benchmark.report("Array") { arr = [1, 2, 3, 4, 5]; arr[0] }
  benchmark.report("Hash") { hash = {a: 1, b: 2, c: 3, d: 4, e: 5}; hash[:a] }
  benchmark.report("Hash String") { hash = {'a' => 1, 'b' => 2, 'c' => 3, 'd' => 4, 'e' => 5}; hash['a'] }
  benchmark.report("Data") { data = DataDemo[a: 1, b: 2, c: 3, d: 4, e: 5]; data.a }
  benchmark.report("Struct") { struct = StructDemo[a: 1, b: 2, c: 3, d: 4, e: 5]; struct.a }
  benchmark.report("OpenStruct") { ostruct = OpenStruct.new a: 1, b: 2, c: 3, d: 4, e: 5; ostruct.a }
  benchmark.report("Class") { klass = ClassDemo.new a: 1, b: 2, c: 3, d: 4, e: 5; klass.a }

  benchmark.compare!
end

puts "--- 2 Reads to 1 Write ---"
Benchmark.ips do |benchmark|
  benchmark.config time: 5, warmup: 2

  benchmark.report("Array") { arr = [1, 2, 3, 4, 5]; arr[0]; arr[1] }
  benchmark.report("Hash") { hash = {a: 1, b: 2, c: 3, d: 4, e: 5}; hash[:a]; hash[:b] }
  benchmark.report("Hash String") { hash = {'a' => 1, 'b' => 2, 'c' => 3, 'd' => 4, 'e' => 5}; hash['a']; hash['b'] }
  benchmark.report("Data") { data = DataDemo[a: 1, b: 2, c: 3, d: 4, e: 5]; data.a; data.b }
  benchmark.report("Struct") { struct = StructDemo[a: 1, b: 2, c: 3, d: 4, e: 5]; struct.a; struct.b }
  benchmark.report("OpenStruct") { ostruct = OpenStruct.new a: 1, b: 2, c: 3, d: 4, e: 5; ostruct.a; ostruct.b }
  benchmark.report("Class") { klass = ClassDemo.new a: 1, b: 2, c: 3, d: 4, e: 5; klass.a; klass.b }

  benchmark.compare!
end

puts "--- 3 Reads to 1 Write ---"
Benchmark.ips do |benchmark|
  benchmark.config time: 5, warmup: 2

  benchmark.report("Array") { arr = [1, 2, 3, 4, 5]; arr[0]; arr[1]; arr[2] }
  benchmark.report("Hash") { hash = {a: 1, b: 2, c: 3, d: 4, e: 5}; hash[:a]; hash[:b]; hash[:c] }
  benchmark.report("Hash String") { hash = {'a' => 1, 'b' => 2, 'c' => 3, 'd' => 4, 'e' => 5}; hash['a']; hash['b']; hash['c'] }
  benchmark.report("Data") { data = DataDemo[a: 1, b: 2, c: 3, d: 4, e: 5]; data.a; data.b; data.c }
  benchmark.report("Struct") { struct = StructDemo[a: 1, b: 2, c: 3, d: 4, e: 5]; struct.a; struct.b; struct.c }
  benchmark.report("OpenStruct") { ostruct = OpenStruct.new a: 1, b: 2, c: 3, d: 4, e: 5; ostruct.a; ostruct.b; ostruct.c }
  benchmark.report("Class") { klass = ClassDemo.new a: 1, b: 2, c: 3, d: 4, e: 5; klass.a; klass.b; klass.c }

  benchmark.compare!
end

puts "--- 5 Reads to 1 Write ---"
Benchmark.ips do |benchmark|
  benchmark.config time: 5, warmup: 2

  benchmark.report("Array") { arr = [1, 2, 3, 4, 5]; arr[0]; arr[1]; arr[2]; arr[3]; arr[4] }
  benchmark.report("Hash") { hash = {a: 1, b: 2, c: 3, d: 4, e: 5}; hash[:a]; hash[:b]; hash[:c]; hash[:d]; hash[:e] }
  benchmark.report("Hash String") { hash = {'a' => 1, 'b' => 2, 'c' => 3, 'd' => 4, 'e' => 5}; hash['a']; hash['b']; hash['c']; hash['d']; hash['e'] }
  benchmark.report("Data") { data = DataDemo[a: 1, b: 2, c: 3, d: 4, e: 5]; data.a; data.b; data.c; data.d; data.e }
  benchmark.report("Struct") { struct = StructDemo[a: 1, b: 2, c: 3, d: 4, e: 5]; struct.a; struct.b; struct.c; struct.d; struct.e }
  benchmark.report("OpenStruct") { ostruct = OpenStruct.new a: 1, b: 2, c: 3, d: 4, e: 5; ostruct.a; ostruct.b; ostruct.c; ostruct.d; ostruct.e }
  benchmark.report("Class") { klass = ClassDemo.new a: 1, b: 2, c: 3, d: 4, e: 5; klass.a; klass.b; klass.c; klass.d; klass.e }

  benchmark.compare!
end

puts "--- 10 Reads to 1 Write (5 attributes) ---"
Benchmark.ips do |benchmark|
  benchmark.config time: 5, warmup: 2

  benchmark.report("Array") { arr = [1, 2, 3, 4, 5]; arr[0]; arr[1]; arr[2]; arr[3]; arr[4]; arr[0]; arr[1]; arr[2]; arr[3]; arr[4] }
  benchmark.report("Hash") { hash = {a: 1, b: 2, c: 3, d: 4, e: 5}; hash[:a]; hash[:b]; hash[:c]; hash[:d]; hash[:e]; hash[:a]; hash[:b]; hash[:c]; hash[:d]; hash[:e] }
  benchmark.report("Hash String") { hash = {'a' => 1, 'b' => 2, 'c' => 3, 'd' => 4, 'e' => 5}; hash['a']; hash['b']; hash['c']; hash['d']; hash['e']; hash['a']; hash['b']; hash['c']; hash['d']; hash['e'] }
  benchmark.report("Data") { data = DataDemo[a: 1, b: 2, c: 3, d: 4, e: 5]; data.a; data.b; data.c; data.d; data.e; data.a; data.b; data.c; data.d; data.e }
  benchmark.report("Struct") { struct = StructDemo[a: 1, b: 2, c: 3, d: 4, e: 5]; struct.a; struct.b; struct.c; struct.d; struct.e; struct.a; struct.b; struct.c; struct.d; struct.e }
  benchmark.report("OpenStruct") { ostruct = OpenStruct.new a: 1, b: 2, c: 3, d: 4, e: 5; ostruct.a; ostruct.b; ostruct.c; ostruct.d; ostruct.e; ostruct.a; ostruct.b; ostruct.c; ostruct.d; ostruct.e }
  benchmark.report("Class") { klass = ClassDemo.new a: 1, b: 2, c: 3, d: 4, e: 5; klass.a; klass.b; klass.c; klass.d; klass.e; klass.a; klass.b; klass.c; klass.d; klass.e }

  benchmark.compare!
end

puts "--- 10 Reads to 1 Write (10 attributes) ---"
Benchmark.ips do |benchmark|
  benchmark.config time: 5, warmup: 2

  benchmark.report("Array") { arr = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]; arr[0]; arr[1]; arr[2]; arr[3]; arr[4]; arr[5]; arr[6]; arr[7]; arr[8]; arr[9] }
  benchmark.report("Hash") { hash = {a: 1, b: 2, c: 3, d: 4, e: 5, f: 6, g: 7, h: 8, i: 9, j: 10}; hash[:a]; hash[:b]; hash[:c]; hash[:d]; hash[:e]; hash[:f]; hash[:g]; hash[:h]; hash[:i]; hash[:j] }
  benchmark.report("Hash String") { hash = {'a' => 1, 'b' => 2, 'c' => 3, 'd' => 4, 'e' => 5, 'f' => 6, 'g' => 7, 'h' => 8, 'i' => 9, 'j' => 10}; hash['a']; hash['b']; hash['c']; hash['d']; hash['e']; hash['f']; hash['g']; hash['h']; hash['i']; hash['j'] }
  benchmark.report("Data") { data = DataDemoTen.new(a: 1, b: 2, c: 3, d: 4, e: 5, f: 6, g: 7, h: 8, i: 9, j: 10); data.a; data.b; data.c; data.d; data.e; data.f; data.g; data.h; data.i; data.j }
  benchmark.report("Struct") { struct = StructDemoTen.new(1, 2, 3, 4, 5, 6, 7, 8, 9, 10); struct.a; struct.b; struct.c; struct.d; struct.e; struct.f; struct.g; struct.h; struct.i; struct.j }
  benchmark.report("OpenStruct") { ostruct = OpenStruct.new(a: 1, b: 2, c: 3, d: 4, e: 5, f: 6, g: 7, h: 8, i: 9, j: 10); ostruct.a; ostruct.b; ostruct.c; ostruct.d; ostruct.e; ostruct.f; ostruct.g; ostruct.h; ostruct.i; ostruct.j }
  benchmark.report("Class") { klass = ClassDemoTen.new(a: 1, b: 2, c: 3, d: 4, e: 5, f: 6, g: 7, h: 8, i: 9, j: 10); klass.a; klass.b; klass.c; klass.d; klass.e; klass.f; klass.g; klass.h; klass.i; klass.j }

  benchmark.compare!
end

ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24]

1 read to 1 write

Calculating -------------------------------------

               Array     25.764M (± 0.9%) i/s   (38.81 ns/i) -    128.815M in   5.000339s

                Hash     21.860M (± 0.4%) i/s   (45.75 ns/i) -    111.235M in   5.088522s

         Hash String     20.215M (± 0.4%) i/s   (49.47 ns/i) -    102.154M in   5.053419s

                Data      4.158M (± 2.3%) i/s  (240.52 ns/i) -     21.125M in   5.083854s

              Struct      4.101M (± 1.9%) i/s  (243.83 ns/i) -     20.603M in   5.025646s

          OpenStruct    122.586k (± 0.7%) i/s    (8.16 μs/i) -    616.400k in   5.028558s

               Class      4.540M (± 1.7%) i/s  (220.25 ns/i) -     22.995M in   5.066432s

Comparison:

               Array: 25763513.4 i/s

                Hash: 21860209.5 i/s - 1.18x  slower

         Hash String: 20215108.6 i/s - 1.27x  slower

               Class:  4540193.3 i/s - 5.67x  slower

                Data:  4157661.5 i/s - 6.20x  slower

              Struct:  4101170.2 i/s - 6.28x  slower

          OpenStruct:   122586.4 i/s - 210.17x  slower

2 reads to 1 write

Calculating -------------------------------------

               Array     20.633M (± 0.7%) i/s   (48.47 ns/i) -    103.215M in   5.002565s

                Hash     18.106M (± 1.2%) i/s   (55.23 ns/i) -     92.276M in   5.097036s

         Hash String     16.850M (± 0.4%) i/s   (59.35 ns/i) -     84.474M in   5.013416s

                Data      4.088M (± 2.0%) i/s  (244.64 ns/i) -     20.519M in   5.021858s

              Struct      4.034M (± 1.6%) i/s  (247.90 ns/i) -     20.316M in   5.037631s

          OpenStruct    120.040k (± 1.0%) i/s    (8.33 μs/i) -    605.064k in   5.041019s

               Class      4.440M (± 1.5%) i/s  (225.21 ns/i) -     22.449M in   5.056871s

Comparison:

               Array: 20633383.1 i/s

                Hash: 18106481.9 i/s - 1.14x  slower

         Hash String: 16849875.2 i/s - 1.22x  slower

               Class:  4440226.6 i/s - 4.65x  slower

                Data:  4087571.4 i/s - 5.05x  slower

              Struct:  4033868.2 i/s - 5.12x  slower

          OpenStruct:   120039.9 i/s - 171.89x  slower

3 reads to 1 write

Calculating -------------------------------------

               Array     18.320M (± 0.9%) i/s   (54.58 ns/i) -     92.829M in   5.067386s

                Hash     16.198M (± 0.4%) i/s   (61.74 ns/i) -     82.530M in   5.095210s

         Hash String     14.845M (± 0.8%) i/s   (67.36 ns/i) -     74.947M in   5.048993s

                Data      3.993M (± 2.6%) i/s  (250.45 ns/i) -     20.235M in   5.071372s

              Struct      3.721M (± 8.3%) i/s  (268.72 ns/i) -     18.474M in   5.030555s

          OpenStruct    109.286k (±16.7%) i/s    (9.15 μs/i) -    504.820k in   5.042702s

               Class      4.311M (± 1.8%) i/s  (231.98 ns/i) -     21.626M in   5.018517s

Comparison:

               Array: 18320261.7 i/s

                Hash: 16197886.7 i/s - 1.13x  slower

         Hash String: 14844935.0 i/s - 1.23x  slower

               Class:  4310699.6 i/s - 4.25x  slower

                Data:  3992742.9 i/s - 4.59x  slower

              Struct:  3721375.0 i/s - 4.92x  slower

          OpenStruct:   109285.6 i/s - 167.64x  slower

5 reads to 1 write

Calculating -------------------------------------

               Array     15.308M (± 2.2%) i/s   (65.32 ns/i) -     77.630M in   5.073563s

                Hash     14.129M (±21.2%) i/s   (70.78 ns/i) -     64.798M in   4.984178s

         Hash String     12.384M (± 1.6%) i/s   (80.75 ns/i) -     62.810M in   5.073061s

                Data      3.740M (± 2.1%) i/s  (267.40 ns/i) -     18.929M in   5.063717s

              Struct      3.731M (± 1.6%) i/s  (267.99 ns/i) -     18.722M in   5.018610s

          OpenStruct    114.473k (± 1.0%) i/s    (8.74 μs/i) -    578.442k in   5.053565s

               Class      4.142M (± 1.2%) i/s  (241.42 ns/i) -     20.902M in   5.046783s

Comparison:

               Array: 15308341.0 i/s

                Hash: 14129046.7 i/s - same-ish: difference falls within error

         Hash String: 12384465.8 i/s - 1.24x  slower

               Class:  4142199.3 i/s - 3.70x  slower

                Data:  3739735.6 i/s - 4.09x  slower

              Struct:  3731458.8 i/s - 4.10x  slower

          OpenStruct:   114472.7 i/s - 133.73x  slower

10 reads to 1 write -- 5 attributes

Calculating -------------------------------------

               Array     10.777M (± 0.7%) i/s   (92.79 ns/i) -     54.867M in   5.091625s

                Hash      8.618M (± 1.2%) i/s  (116.04 ns/i) -     43.838M in   5.087596s

         Hash String      7.962M (± 1.0%) i/s  (125.60 ns/i) -     40.308M in   5.062987s

                Data      3.440M (± 1.8%) i/s  (290.74 ns/i) -     17.278M in   5.025126s

              Struct      3.416M (± 1.2%) i/s  (292.75 ns/i) -     17.342M in   5.077662s

          OpenStruct    113.327k (± 0.8%) i/s    (8.82 μs/i) -    568.500k in   5.016805s

               Class      3.576M (± 1.4%) i/s  (279.64 ns/i) -     18.189M in   5.087567s

Comparison:

               Array: 10776504.7 i/s

                Hash:  8617805.7 i/s - 1.25x  slower

         Hash String:  7962076.7 i/s - 1.35x  slower

               Class:  3575982.6 i/s - 3.01x  slower

                Data:  3439532.9 i/s - 3.13x  slower

              Struct:  3415890.4 i/s - 3.15x  slower

          OpenStruct:   113326.8 i/s - 95.09x  slower

10 reads to 1 write -- 10 attributes

Calculating -------------------------------------

               Array     10.711M (± 0.6%) i/s   (93.36 ns/i) -     53.734M in   5.016788s

                Hash      4.271M (± 1.7%) i/s  (234.13 ns/i) -     21.775M in   5.099576s

         Hash String      3.852M (± 2.0%) i/s  (259.59 ns/i) -     19.270M in   5.004605s

                Data      1.923M (± 2.3%) i/s  (520.06 ns/i) -      9.783M in   5.090560s

              Struct      6.601M (± 1.5%) i/s  (151.49 ns/i) -     33.252M in   5.038446s

          OpenStruct     59.513k (± 1.7%) i/s   (16.80 μs/i) -    297.550k in   5.001175s

               Class      1.885M (± 1.4%) i/s  (530.46 ns/i) -      9.427M in   5.001555s

Comparison:

               Array: 10711256.7 i/s

              Struct:  6601054.0 i/s - 1.62x  slower

                Hash:  4271204.4 i/s - 2.51x  slower

         Hash String:  3852188.8 i/s - 2.78x  slower

                Data:  1922861.9 i/s - 5.57x  slower

               Class:  1885149.8 i/s - 5.68x  slower

          OpenStruct:    59513.5 i/s - 179.98x  slower

Current Observations - What a rollercoaster!

That's a lot of benchmarking! I was really hoping that with many reads, that Structs comes out more performant and it did! So, I'm happy with the results. What we can see is that Structs have performed very well even compared to Hashes when there are many attributes, in this case, in the 10 reads to 1 write -- 10 attributes. So, while we are grateful that Classes has gotten more performant than Struct in the 5 attribute case, but Struct still is a great choice as a standard when passing around data, due to its good scalability.

Stringified Hashes are also performant under the frozen string literal comment, so there's not much impact on using between symbolized and stringified Hashes.

~~## Surprising Observation~~

What surprises me is how exponentially slow the Data, Classes, and Structs are when dealing with 10 attributes. Having 50-60 times slower performance than Arrays has got to be excruciatingly painful on dealing with. (Hash to - Class: 21.68x, Hash to - Data: 19.77, Hash to Struct - 24.26x) So, if you're dealing with large data (well, 10 seems large enough considering the impact), it would be best to use more primitive data objects, like Arrays and Hashes, especially Hashes since it has at least some structure on to it.

The 5th Time

Someone in this new reddit thread has pointed out to me that my 10 reads to 1 write -- 10 attributes case was written in such a way that we defined them inside the benchmark. I'm correcting the code, I have re-evaluated my observations once again. The mistake is what got me writing the Surprising Observation, wherein I thought that having more attributes greatly affects Classes, Structs, and Data compared to Hashes, but I was wrong. So, I'm very grateful for that as the correction has changed the narrative to recommend the usage of Structs vs Classes (and Hashes) if you're solely looking for performance.

Struct as a Value Object

I think one of the most important thing with Structs (and Data) is that they're value objects. In my own words, it means that you can compare them by themselves. Class instances cannot be compared by themselves, and that's the only disadvantage I could see with classes, considering they're more performant in most cases now.

Take a look at the Class code to show this behavior:

irb(main):001* class A

irb(main):002*   attr_reader :a

irb(main):003*   def initialize(a)

irb(main):004*     @a = a

irb(main):005*   end

irb(main):006> end

=> :initialize

irb(main):007> a = A.new(1)

=> #<A:0x000000012529f560 @a=1>

irb(main):008> b = A.new(1)

=> #<A:0x000000011fb11488 @a=1>

irb(main):009> a == b

=> false

Conclusion

I think it was a great decision to write this second article, because I've learned more things with the wonderful Ruby language. I hope you've enjoyed reading as I've enjoyed writing this.

Here are my takeaways on this:

In Ruby 3.4.2, Classes are slightly more performant than Structs when we use 5 attributes, but with 10 attributes, Structs come out on top even compared to Hashes.
The order of priority (in terms of scalable performance) when using data structures are Arrays, Hashes, Structs, Classes, Data. But of course, these get used differently. When you want more structure, Structs are definitely on top of the list.
Symbolised Hashes are better than Stringified Hashes even with the frozen string literal comment, but not very far off.
Always use the frozen string literal comment.
Don't check twice, check 3, 4, 5 times!
Articles you reference update themselves and make your referring article confusing.

Real Time Page Updates with Rails and Hotwire - Turbo Broadcasts

reinteractive — Mon, 24 Mar 2025 02:26:35 +0000

Credited to: Charles Martinez

Hotwire has been the default frontend framework for Rails Application since Rails 7. And one of the most important framework within Hotwire is Turbo which uses multiple techniques to provide a SPA experience within our application.

And one of the things I really like about Turbo is the ability to provide real time page updates quickly and easily and without having to write any javascript code with it.

In this example, Let's say we have an Event app where you can register to, And we will apply real time page updates on any modifications to the Events table or whenever someones registers for an event. Below with be the end result we would want to achieve

Turbo Broadcast

Turbo Broadcast allows us to broadcast messages via Websockets to multiple clients in real-time and which is what we will be using in this example. This is the source code for Turbo Broadcast and its worth taking a look at because it provides some example usages in the inline comments https://github.com/hotwired/turbo-rails/blob/main/app/models/concerns/turbo/broadcastable.rb

So lets say we have an existing table of upcoming events, The first thing we need to do is inject this line turbo_stream_from "events" within the html file that renders this table, and add an ID to the HTML element that contains the data and HTML elements we would want to update in real-time

<main>
  <%= turbo_stream_from "events" %>  <!-- Add this line !-->

  <h3 class="header mb-4"> Upcoming Events </h3>

  <table class="table">
    <thead>
      <th> Event Name </th>
      ...
    </thead>

    <tbody id='eventsTable'> <!-- Assign an ID !-->
      <% @events.each do |event| %>
        <%= render partial: "event", locals: { event: event } %>
      <% end %>
    </tbody>
  </table>
</main>

What this do is establishes a websocket connection on that page to subscribes users to that channel. That helper method would produce something like this, where signed-stream-name is the signed version of the passed string "events"

<turbo-cable-stream-source
  channel="Turbo::StreamsChannel"
  signed-stream-name="signed-version-of-passed-string"
>
</turbo-cable-stream-source>

So in this context, All of the users currently in that events page are subscribed to the Turbo::StreamsChannel and waiting for broadcasts that will be made on the events stream

Also, on the _event.html.erb partial, we needd to add an ID per each event row

# app/views/events/_event.html.erb

<tr id="<%= dom_id event %>">
  <td> <%= event.name %> </td>
  ...
</tr>

dom_id is a Rails helper that will return a string of the model name and ID e.g event_1

Now that we have that turbo stream setup and added the IDs that we needded, we need to add 3 lines of active record callbacks to the Event model

class Event < ApplicationRecord
  include ActionView::RecordIdentifier
  has_many :bookings

  after_create_commit { broadcast_prepend_to "events", target: "eventsTable" }
  after_update_commit { broadcast_replace_to 'events', target: dom_id(self) }
  after_destroy_commit { broadcast_remove_to 'events', target: dom_id(self) }
end

To explain further on, The broadcast method's first argument is the stream_name which is events coming from the stream name we've passed in <%= turbo_stream_from "events" %>

The target parameter is the ID of the HTML element we would want to be modified. So you can notice that on create, We would want to modify the Table Body which we defined the ID as eventsTable.

And of course on update and destroy, we will modify the actual table row that the event is rendered to.

It also accepts a parameter called partial, But we don't need to add it in here. The naming convention that Turbo Broadcasts maps to by default will be based on the Model name. So in our case the Event Model, Turbo will then try to find a partial /events/_event if the partial parameter has not beed provided.

A thing to note, We need to include ActionView::RecordIdentifier so that we could use the dom_id helper inside the Model class. And thats it! With these few lines of code, The Events page will receive real time updates given any modification, addition or deletion in the Events table.

But this only covers any changes on the Event table, We need to be able to update the events page whenever a booking is created.

There are two options, First, we can add touch: true on that Booking model

class Booking < ApplicationRecord
  belongs_to :event, touch: true
end

This will update the associated event's updated_at timestamp whenever a booking is created. But often times that not, This is not the behavior we intend to, So we can just define an active record callback as well to this model

class Event < ApplicationRecordd
  ...
  after_update_commit { broadcast_updates! }

  def broadcast_updates!
    broadcast_prepend_to "events", target: "eventsTable"
  end
end

class Booking < ApplicationRecord
  belongs_to :event

  after_create_commit { event.broadcast_updates! }
end

We define a reusable instance method for broadcasting update changes so that we can define it both on the Event and Booking Model. And now we have real time page updates whenever someone registers for an event

Adding Loading and Transitions on broadcasts

We have setup real time page updates on the events page, But ideally we want to be able to improve the user experience by adding loading and transitions whenever something changes on the events page. We can do that by adding and updating a few lines of code.

First thing, we need to add another event partial that will render a loading row, In this context, Im using Bootstrap spinner for simplicity.

# app/views/event/_loading_event.html

<tr id="<%= dom_id event %>">
  <td> <div class="spinner-border" role="status"></td>
  <% 4.times do %>
    <td> ... </td>
  <% end %>
</tr>

Which would look like this

Then we would want to add a simple in out transition css class, and allow the event partial to receive an optional transition_class parameter

# CSS

.in-out {
  animation: fade-in 0.5s ease-out,
             slide-in 0.5s ease-out;
}

# app/views/events/_event.html.erb

<% transition_class ||= nil %>

<tr id="<%= dom_id event %>" class="<%= transition_class %>">
  ...
</tr>

Then in the Events Model, We would want to change our callbacks

class Event < ApplicationRecord
  ...

  after_create_commit { broadcast_create! }
  after_update_commit { broadcast_updates! }
  after_destroy_commit { broadcast_remove_to 'events', target: dom_id(self) }

  def broadcast_create!
    broadcast_prepend_to "events", target: "eventsTable", partial: "/events/loading_event"
    sleep(0.5)
    broadcast_replace_to 'events', target: dom_id(self), locals: { event: self, transition_class: "in-out" }
  end

  def broadcast_updates!
    broadcast_replace_to 'events', target: dom_id(self) , partial: "/events/loading_event"
    sleep(0.5)
    broadcast_replace_to 'events', target: dom_id(self), locals: { event: self, transition_class: "in-out" }
  end
end

On event creations and updates, We will broadcast 2 messages,

To Load the loading event partial
- Notice here, That we explicitly passed the partial argument, By default, The Turbo Broadcast will find a partial based on the model name e.g if the model name is Event, it would look for /app/views/events/_event.html. That is the reason we didn't need to pass the partial argument previously.
And after some delay, replace the loading event partial with the actual event partial with updated data
- And notice that we are passing the in_out transition class to give an transition effect when the turbo stream renders the updated element

And the end result with would be something like this

And that's a wrap! Thanks to Turbo, With a few lines of code, We can implement real time page updates on our application with a few lines of code.

Building a Ruby on Rails Chat Application with ActionCable and Heroku

reinteractive — Thu, 20 Mar 2025 01:56:28 +0000

Credited to: Rodrigo Souza

In this guide we'll create a real-time chat application using Rails 8.0.1 and Ruby 3.4.2.

Project Setup

source "https://rubygems.org"

ruby "3.4.2"

gem "rails", "~> 8.0.1"
gem "turbo-rails"

Prerequisites

To get started, ensure you have:

Proper Action Cable configuration in cable.yml
Working user authentication system
Turbo Rails properly installed and configured

This implementation provides a robust foundation for a real-time chat application, leveraging Rails 8's modern features for seamless real-time updates with minimal JavaScript.

Key Technical Aspects

Turbo Streams and Broadcasting

Turbo Streams: Handles real-time updates through WebSocket connections
Action Cable: Powers the WebSocket functionality (built into Rails)
Scoped Broadcasting: Messages only broadcast to specific room subscribers
Partial Rendering: Keeps code DRY and maintains consistent UI updates

Let's break down the key broadcasting mechanisms:

Room Broadcasting:

broadcasts_to ->(room) { room }

This establishes the room as a broadcast target, allowing Turbo to track changes to the room itself.

Message Broadcasting:

after_create_commit -> { broadcast_append_to room }

This ensures new messages are automatically broadcast to all room subscribers.

JavaScript Integration

Stimulus: Manages form behavior and DOM interactions
Minimal JavaScript: Most real-time functionality handled by Turbo
Automatic DOM Updates: No manual DOM manipulation required

Models

Room Model

class Room < ApplicationRecord
  has_many :messages, dependent: :destroy
  validates :name, presence: true, uniqueness: true

  broadcasts_to ->(room) { room }
end

Message Model

class Message < ApplicationRecord
  belongs_to :room
  belongs_to :user
  validates :content, presence: true

  after_create_commit -> { broadcast_append_to room }
end

Controllers

Rooms Controller

class RoomsController < ApplicationController
  def index
    @rooms = Room.all
  end

  def show
    @room = Room.find(params[:id])
    @messages = @room.messages.includes(:user)
    @message = Message.new
  end

  def create
    @room = Room.create!(room_params)
    redirect_to @room
  end

  private

  def room_params
    params.require(:room).permit(:name)
  end
end

Messages Controller

class MessagesController < ApplicationController
  def create
    @message = Message.new(message_params)
    @message.user_id = session[:user_id] || create_anonymous_user.id
    @message.save!

    respond_to do |format|
      format.turbo_stream
    end
  end

  private

  def message_params
    params.require(:message).permit(:content, :room_id)
  end

  def create_anonymous_user
    random_id = SecureRandom.hex(4)
    user = User.create!(
      nickname: "Anonymous_#{random_id}",
      email: "new-email-#{random_id}@test.com",
    )
    session[:user_id] = user.id
    user
  end
end

Views

Room Index

<div class="container mx-auto px-4">
  <h1 class="text-2xl font-bold mb-4">Chat Rooms</h1>

  <div class="mb-4">
    <%= form_with(model: Room.new, class: "flex gap-2") do |f| %>
      <%= f.text_field :name, class: "rounded border px-2 py-1" %>
      <%= f.submit "Create Room", class: "bg-blue-500 text-white px-4 py-1 rounded" %>
    <% end %>
  </div>

  <%= turbo_frame_tag "rooms" do %>
    <div class="grid gap-4">
      <%= render @rooms %>
    </div>
  <% end %>
</div>

Room Partial

<%= link_to room_path(room),
    class: "block p-4 border rounded hover:bg-gray-50",
    data: { turbo_frame: "_top" } do %>
  <%= room.name %>
<% end %>

Room Show (Chat Interface)

<div class="container mx-auto px-4" data-controller="reset-form">
  <h1 class="text-2xl font-bold mb-4"><%= @room.name %></h1>

  <%= turbo_stream_from @room %>

  <%= turbo_frame_tag "messages",
      class: "block mb-4 h-96 overflow-y-auto border rounded p-4",
      data: { reset_form_target: "messages" } do %>
    <%= render @messages %>
  <% end %>

  <%= turbo_frame_tag "new_message", target: "_top" do %>
    <%= form_with(model: [@room, @message],
        class: "flex gap-2",
        data: { action: "turbo:submit-end->reset-form#reset" }) do |f| %>
      <%= f.hidden_field :room_id, value: @room.id %>
      <%= f.text_field :content,
          class: "flex-1 rounded border px-2 py-1",
          data: { reset_form_target: "content" } %>
      <%= f.submit "Send", class: "bg-blue-500 text-white px-4 py-1 rounded" %>
    <% end %>
  <% end %>
</div>

Message Partial

<div class="message mb-3">
  <strong><%= message.user.email %>:</strong>
  <%= content_tag :span, message.content, class: "break-words" %>
</div>

JavaScript

Reset Form Controller

import { Controller } from "@hotwired/stimulus"

export default class extends Controller {
  static targets = ["content", "messages"]

  connect() {
    this.scrollToBottom()
  }

  reset() {
    this.contentTarget.value = ""
    this.scrollToBottom()
  }

  scrollToBottom() {
    this.messagesTarget.scrollTop = this.messagesTarget.scrollHeight
  }
}

Routes

  resources :rooms do
    resources :messages, only: [:create]
  end

  root 'rooms#index'

How It All Works Together

Room Creation and Listing
- Users can view available rooms on the index page
- Each room is rendered using the _room.html.erb partial
Entering a Chat Room
- Clicking a room link takes users to the show page
- The show page establishes a Turbo Stream connection
- Existing messages are loaded and displayed
Real-time Message Broadcasting
- When a message is created:
  - The form submits to MessagesController#create
  - Message is saved to the database
  - after_create_commit triggers broadcasting
  - All room subscribers receive the update
  - New message appears instantly for all users
Form Handling
- The Stimulus controller manages form behavior
- After successful submission, the form is cleared
- The UI remains responsive throughout

Code In Action

You should see something like this in your browser:

The Chat room should be like this:

Deploying the application on Heroku

To deployment on Heroku platform is pretty straighfoward. The prerequisites are:

Heroku CLI installed
Git repository initialized

After covering all the prerequisites, let's dive into the steps to the deployment:

Create a new Heroku application

heroku create your-chat-app-name

Add the necessary Add-ons

# Add Redis add-on
heroku addons:create heroku-redis:hobby-dev

# Add PostgreSQL add-on
heroku addons:create heroku-postgresql:mini

Configure RAILS_MASTER_KEY ENV variable

heroku config:set RAILS_MASTER_KEY=$(cat config/master.key)

Deploy the application

# Push to Heroku
git push heroku main

# Run database migrations
heroku run rails db:migrate

Request a Web Dyno

heroku ps:scale web=1

Verify the deployment

Check the logs from the deployment process and open the application:

# Open the application
heroku open

# Monitor logs
heroku logs --tail

Why Ruby on Rails is the Best First Framework for New Developers

reinteractive — Thu, 13 Mar 2025 02:19:44 +0000

Credited to: Rodrigo Souza

Introduction

Selecting your first programming language to study is a big choice for all new developers. The menu is huge, and feeling lost is very common. If your objective is to work on web application development, we have a great suggestion for you. Ruby on Rails! It's the best option if you want to build your applications quickly while you learn lots of good programming fundamentals.

Ruby on Rails is a framework built upon Ruby programming language focused on web application development. It is very easy to learn, readable, and productivity-oriented. Rails provides a well-documented path and the structure that can help you to work on your projects or get your first job as a web applications developer.

In this article, we will see why development beginners should begin with Ruby on Rails. You will learn how Rails makes programming easy, allows you to build full-stack apps, and gives you job and freelance prospects. So, let's begin!

1. Beginner-Friendly Language & Framework

Readable and Expressive Syntax

Languages like Java or C++ have a complex syntax. This is one of the biggest challenges for beginners, and that's why Ruby shines. Ruby was specially designed to be human readable. In other words, Ruby syntax is very similar to the English language. For example, this is how you run through each item of a list:

users.each do |user|
  puts user.name
end

This simplicity makes it easier for new developers to focus on problem-solving rather than struggling with syntax.

Less Boilerplate Code

Avoiding the usual setup boilerplate, Rails provides built-in features that reduce repetitive configuration tasks. You don't need to write lot's of configuration files or manage dependencies manually. Rails takes care of most of it for you, allowing you to start coding you application.

2. Fast Learning Curve & High Productivity

Convention Over Configuration (CoC)

Following the "Convention Over Configuration" principle, Rails makes some default assumptions that help beginners to reduce the setup time for some tasks. For example, Rails "automagically" expects a user's table if the application have a Model called User. Pretty cool, no?

Don’t Repeat Yourself (DRY)

That is one of the best principles Ruby on Rails encourages. It helps us to write reusable and cleaner code. Rails itself implements it, providing us helper methods, partials and modules that can allow you to efficiently organise your code. It's usable in any language, and you'll learn it using Ruby on Rails.

Scaffolding & Generators

When you're learning, getting quick feedback keeps motivation high. Rails makes this possible with scaffolding and generators, which allow you to create entire database-backed applications with a single command:

rails generate scaffold Post title:string body:text

This command generates everything needed for a fully functional CRUD (Create, Read, Update, Delete) interface, giving beginners an instant hands-on experience with web development.

3. Full-Stack Web Development in One Framework

Covers Backend & Frontend

Rails is a full-stack framework, meaning you can build an entire web application using just Rails. You’ll learn how to:

Handle client requests and routing
Store and retrieve data from a database
Render an HTML page using (or not) Javascript

Active Record (ORM) – Simplified Database Management

In order to make database interactions simple, Rails brings an Object-Relational Mapping (ORM) tool. It's called Active Record. It's a huge library (Gem) that can write complex SQL queries for you while you just code something like this:

User.find(1)

The SQL version will be as follows:

SELECT * FROM users WHERE id = 1;

This makes it easier to understand and work with databases.

Built-in Testing Tools

In a very competitive world, where all the tasks should be delivered faster, build automatic tests accurately is a crucial step to have a reliable application. Rails includes built-in support for unit testing and system testing, helping you to adopt the best practices early on.

4. Strong & Supportive Community

Well-Established Ecosystem

One of the most incredible things about Ruby on Rails is the ecosystem. Ruby on Rails has been around since 2004 and has a mature ecosystem with thousands of gems (plugins) available. The options range from authentication to an entire DSL for API integrations. Of course, it saves time and effort.

Helpful Community & Mentorship

New developers are welcome in the Rails community. There are tons of free tutorials, guides, and discussion forums where you can ask for help and get support. Lots of experienced developers actively mentor newcomers, making it easier to learn.

Contributing to Open Source

In the Ruby on Rails community, we have many open-source projects that allow the new developer to contribute to real-world applications, learn from others, and gain experience that will help with job opportunities.

5. Great for Building Real-World Projects

Popular for Startups

Several successful startups, including GitHub, Shopify, Airbnb, and Basecamp, built their products on Rails. If you wish to create your own startup or side projects, Rails is a perfect tool because it helps you build and deploy applications instantly.

Fast Prototyping

Rails allows you to go from idea to working prototype in days, not weeks or months. It is perfect for new developers who want to quickly experiment with their ideas without having to spend much time on installing their environment.

Used by Big Companies

Even with newer frameworks coming out every day, Ruby on Rails is still utilized by numerous big companies. Learning Ruby on Rails framework gears you up for actual development, making it more likely for you to be hired.

6. Job Opportunities & Freelancing Potential

High Demand in Web Development

Even though new technologies emerge all the time, Rails is still widely used in web development, especially among startups. Many companies look for junior Rails developers, making it a great first step toward employment.

Freelancing & Side Projects

Rails is an excellent choice for freelancers because you can build entire applications on your own without needing a team. This allows you to offer custom web development services and work on personal projects without external dependencies.

Great Foundation for Learning Other Languages

Rails teaches core programming concepts like:

MVC (Model-View-Controller) – Used in many frameworks (Django, Laravel, ASP.NET).
RESTful APIs – A standard in web development.
Object-Oriented Programming (OOP) is a foundation for many modern languages.
Once you master Rails, transitioning to languages like Python, JavaScript, or Elixir will be much easier.

Conclusion

As you can see, Ruby on Rails is one of the best choices for new developers because it aligns a friendly learning experience and a supportive community with a super productive development process. Avoiding the complexities of web development, you will learn many important programming concepts that you will bring to you benefits idependent of the language you choose next.

Hash Replacement with `sub` and `gsub` in Ruby on Rails

reinteractive — Tue, 04 Mar 2025 11:39:03 +0000

Credited to: Suman Awal

sub/gsub is the widely used substitution method in ruby. These methods replace (substitute) content of the string with the
new string based on the provided logic. In SAAS application, we offen encounter the condition where we need to generate dynamic content for a single action based on the customer. For example generating a dynamic welcome message to the customer for the different client. There are lots of ways to get the result however in this article we will use the one of the mostly used ruby method sub and gsub

`sub` and `gsub` ruby methods

Before we get started, let's understand what sub and gsub do:

sub: Replaces the first occurrence of pattern in a string with replacement string.
gsub: Replaces all occurrences of pattern in a string with replacement string.

Both methods use a regular expression as the pattern and a string or a block as the replacement. Here we will explain using a block (hash) for dynamic replacement based on our hash.

Here's a simple example:

replacements = {
  'name' => 'Glenn Maxwell',
  'country' => 'Australia'
}

template = "Hi, my name is {{name}} and I am from {{country}}."

result = template.gsub(/{{(.*?)}}/) { |match| replacements[$1] || match }

puts result # Output: "Hi, my name is Glenn Maxwell and I am from Australia"

In this example:

We define a replacements hash containing the key-value pairs we want to use for the replacement in the string.
We define a template string containing placeholders enclosed in double curly braces ({{}}).
We use gsub with the regular expression /{{(.*?)}}/ to find all occurrences of these placeholders.
The block is executed for each match. Inside the block:

Using `sub` for Single Replacements

If you only need to replace the first occurrence of a pattern, you can use sub instead of gsub. The logic remains the same.

replacements = {
  'name' => 'Glenn Maxwell'
}

template = "Hi, my name is {{name}} and my friend's name is also {{name}}."
result = template.sub(/{{(.*?)}}/) { |match| replacements[$1] || match }
# Output: Hi, my name is Glenn Maxwell and my friend's name is also {{name}}.

Real-World Rails Examples

This technique is useful in various Rails scenarios:

Generate dynamic emails: You can store email templates with placeholders in your database and replace them with user-specific data.
Create dynamic reports: Generate reports with data pulled from various sources, using a hash to map placeholders to the correct values.
Localize content: Store localized strings in a hash and replace placeholders in your views based on the user's locale.

Here you can find one of the widely used example to Generate dynamic emails for the SAAS application.

Generate dynamic emails using hash replacement

Scenario

You have a Rails application that serves multiple clients. Each client has their own set of customers. When a new customer registers for a specific client, the application sends a welcome email. The content of the welcome email is dynamically generated based on a template stored in the database, which is specific to each client.

Sample codes

Create models

  # app/models/client.rb
  class Client < ApplicationRecord
    has_many :customers
    has_one :welcome_email_template
  end

  # app/models/customer.rb
  class Customer < ApplicationRecord
    belongs_to :client
  end

  # app/models/welcome_email_template.rb
  class WelcomeEmailTemplate < ApplicationRecord
    belongs_to :client
  end

Migrations

  # db/migrate/xxxxxx_create_clients.rb
  class CreateClients < ActiveRecord::Migration[7.1]
    def change
      create_table :clients do |t|
        t.string :name
        t.string :subdomain # For identifying clients (e.g., client1.example.com)

        t.timestamps
      end
    end
  end

  # db/migrate/xxxxxx_create_customers.rb
  class CreateCustomers < ActiveRecord::Migration[7.1]
    def change
      create_table :customers do |t|
        t.string :email
        t.string :name
        t.references :client, foreign_key: true

        t.timestamps
      end
    end
  end

  # db/migrate/xxxxxx_create_welcome_email_templates.rb
  class CreateWelcomeEmailTemplates < ActiveRecord::Migration[7.1]
    def change
      create_table :welcome_email_templates do |t|
        t.references :client, foreign_key: true
        t.text :template # The email template with placeholders

        t.timestamps
      end
    end
  end

Database seed

# db/seeds.rb
Client.destroy_all
Customer.destroy_all
WelcomeEmailTemplate.destroy_all

client1 = Client.create!(name: 'Client One', subdomain: 'client1')
client2 = Client.create!(name: 'Client Two', subdomain: 'client2')

WelcomeEmailTemplate.create!(
  client: client1,
  template: "Welcome, {{customer_name}}!\n\nThank you for joining Client One. Your account has been created.\n\nBest regards,\nThe Client One Team"
)

WelcomeEmailTemplate.create!(
  client: client2,
  template: "Hello {{customer_name}},\n\nWelcome to Client Two! We're excited to have you on board.\n\nSincerely,\nThe Client Two Team"
)

Customer Registration

# app/controllers/customers_controller.rb
class CustomersController < ApplicationController
  before_action :set_client

  def new
    @customer = @client.customers.build
  end

  def create
    @customer = @client.customers.build(customer_params)

    if @customer.save
      send_welcome_email(@customer)
      redirect_to root_path, notice: 'Customer registered successfully!'
    else
      render :new, status: :unprocessable_entity
    end
  end

  private

  def set_client
    # Assumes you have a way to identify the client, e.g., via subdomain
    @client = Client.find_by(subdomain: request.subdomain)
    unless @client
      render plain: "Client not found", status: :not_found
    end
  end

  def customer_params
    params.require(:customer).permit(:email, :name)
  end

  def send_welcome_email(customer)
    template = @client.welcome_email_template.template
    welcome_message = generate_welcome_message(customer, template)
    CustomerMailer.welcome_email(customer, welcome_message).deliver_later
  end

  def generate_welcome_message(customer, template)
    replacements = {
      'customer_name' => customer.name
    }

    template.gsub(/{{(.*?)}}/) { |match| replacements[$1] || match }
  end
end

Routes

# config/routes.rb
constraints subdomain: 'client1' do
  scope module: 'client1', as: 'client1' do
    resources :customers, only: [:new, :create]
  end
end

constraints subdomain: 'client2' do
  scope module: 'client2', as: 'client2' do
    resources :customers, only: [:new, :create]
  end
end

# Non-subdomain routes (e.g., for admin panel)
resources :clients

This example provides a basic application for handling multiple clients with customized welcome messages for their customer.

Conclusion

Using sub and gsub with hash replacement provides a flexible and efficient way to dynamically generate string and can be used in real application.

Imagine: Rails 8 Solid Trifecta: Cache, Cable, Queue

reinteractive — Tue, 18 Feb 2025 06:23:30 +0000

Credited to: Allan Andal

Rails 8 - Solid Trifecta Comparison

The "Solid Trifecta" is a suite of database-backed solutions—Solid Cache, Solid Cable, and Solid Queue—added in Ruby on Rails 8 to simplify application architecture by reducing the need for external services like Redis and Memcached. These components are built on top of existing database infrastructure to handle caching, WebSocket messaging, and background job processing.

Solid Cache

Traditional RAM-based caching systems are replaced by Solid Cache which uses disk storage, including SSDs and NVMe drives. This method provides bigger cache storage at lower costs which leads to extended cache retention times and enhanced application performance. As an example, Basecamp has adopted Solid Cache to store 10 terabytes of data with a 60-day retention window, which has resulted in a significant reduction in render times.

Comparison: Solid Cache vs. Dalli/Memcached vs. Redis

Overview

Feature	Solid Cache	Dalli + Memcached	Redis
Storage Type	Disk-based (local SSD)	In-memory (RAM)	In-memory (RAM) + optional persistence
Persistence	Yes (disk-based, survives restarts)	No (data lost on restart)	Yes (via RDB & AOF)
Scalability	Scales with disk size	Scales with RAM	Scales with RAM, supports clustering
Performance	Slower (disk access)	Very fast	Very fast
Concurrency	Good for multi-threaded apps	High concurrency	High concurrency
Data Structures	Key-value store only	Key-value store only	Supports lists, hashes, sets, sorted sets, streams, etc.
Best For	Apps needing persistence and local caching	High-speed caching across multiple servers	Caching, real-time analytics, session storage, message queues

Performance & Scalability

Memcached and Redis are much faster than Solid Cache since they store data in-memory rather than on disk.
Memcached is simpler and optimized for high-speed key-value lookups, but it lacks persistence.
Redis can be persistent (with RDB or AOF) and supports advanced data types, making it more versatile than Memcached.
Solid Cache is slower but allows for larger cache sizes (limited by disk, not RAM).

Use Cases

Use Case	Solid Cache	Dalli + Memcached	Redis
Persistent caching (survives restart)	✅ Yes	❌ No	✅ Yes
Distributed caching (multi-server)	❌ No	✅ Yes	✅ Yes
Fastest performance	❌ No (disk I/O)	✅ Yes (RAM)	✅ Yes (RAM)
Large dataset caching	✅ Yes (limited by disk)	❌ No (limited by RAM)	✅ Yes (with clustering)
Session storage	✅ Yes	✅ Yes	✅ Yes
Message queue	❌ No	❌ No	✅ Yes (Pub/Sub, Streams)
Complex data structures	❌ No	❌ No	✅ Yes (lists, sets, sorted sets, etc.)

Ease of Use & Setup

Feature	Solid Cache	Dalli + Memcached	Redis
Setup Simplicity	✅ Easiest (built-in Rails cache store)	❌ Requires Memcached server	❌ Requires Redis server
Integration with Rails	✅ Yes (out-of-the-box)	✅ Yes (via `dalli`)	✅ Yes (via `redis-rails`, supports up to Rails 7 only)
Maintenance Overhead	✅ Low	✅ Low	❌ Higher (needs persistence configuration & monitoring)

Conclusion: Which is Best?

Use Solid Cache if you need persistence, local caching, and simple Rails integration, but can tolerate slower performance.
Use Memcached if you need the fastest possible caching performance and don’t need persistence.
Use Redis if you need fast caching plus advanced features (persistence, pub/sub, sorted sets, etc.).

💡 Best overall caching solution?

If you only need simple, fast caching → Memcached.
If you need caching + persistence + advanced features → Redis.
If you want a simple Rails-native cache that persists to disk → Solid Cache.

Solid Cable

Solid Cable acts as a database-backed option to manage WebSocket connections so applications do not need an additional pub/sub server such as Redis. The system sends messages between application processes and clients using fast polling methods which support near real-time performance. The database stores messages for at least a day which helps developers review live update history.

Comparison: Solid Cable vs. AnyCable vs. Action Cable

Overview

Feature	Solid Cable	AnyCable	Action Cable
Performance	Slower than Action Cable	Fastest (gRPC/WebSockets)	Fast (in-memory, event-driven)
Concurrency	Slower uses database polling	Very High (gRPC & WebSockets)	Uses threads (Puma) and Redis Pub/Sub for real-time message broadcasting
Scalability	Sacles with database	Best for large-scale apps	Scales well with Redis
Persistence	Yes (database)	No (in-memory)	No (in-memory)
Best For	Lower-traffic apps	Large-scale, distributed WebSockets	High-traffic apps

Performance & Scalability

AnyCable is the fastest since it offloads WebSocket handling to a separate gRPC server (often using Golang).
Action Cable is faster because it multi-threaded, even-driven.
Solid Cable is slowest because of DB read/write and database operation however it is the simpliest setup.

Scalability

Feature	Solid Cable	AnyCable	Action Cable
Multi-server scaling	✅ Yes (database)	✅ Yes (Redis)	✅ Yes (Redis)

Ease of Use & Setup

Feature	Solid Cable	AnyCable	Action Cable
Setup Complexity	✅ Easy (drop-in replacement for Action Cable)	❌ Complex (requires AnyCable server)	✅ Easy (built into Rails)
Integration with Rails	✅ Yes	✅ Yes	✅ Yes
Requires extra infrastructure	❌ No	✅ Yes (gRPC server)	❌ No
Works with existing Action Cable code	✅ Yes	✅ Yes	✅ Yes

Conclusion: Which is Best?

Use AnyCable if you need massive scalability and low-latency WebSockets across multiple servers.
Use Action Cable if you need better performance than Solid Cable.
Use Solid Cable if you just need basic real-time updates and want the simplest setup.

💡 Best overall WebSockets solution?

If you want basic real-time features for a small Rails app without extra infrastructure → Solid Cable.
If you need WebSockets at scale with thousands of connections → AnyCable.
Otherwise → Action Cable.

Solid Queue

For background job processing Solid Queue presents a database-driven solution that makes Sidekiq and Resque external job runners unnecessary. Solid Queue utilizes database features such as FOR UPDATE SKIP LOCKED to efficiently manage job queues. This service can function as a Puma plugin as well as through a dedicated dispatcher giving users flexible job management capabilities.

Comparison: Solid Queue vs. Sidekiq vs. Resque

Overview

Feature	Solid Queue	Sidekiq	Resque
Performance	High (multi-threaded)	High (multi-threaded)	Moderate (single-threaded)
Concurrency	High (multi-threaded)	Very High (multi-threaded)	Moderate (single-threaded)
Scalability	Scales well (single server)	Excellent (distributed)	Good (distributed)
Persistence	Yes (supports Redis)	Yes (supports Redis)	Yes (supports Redis)
Retry Logic	Yes (configurable)	Yes (configurable)	Yes (configurable)
Job Prioritization	Yes	Yes	Yes
Best For	High-performance background jobs	High-concurrency, real-time jobs	Simple, reliable job processing

Performance & Scalability

Solid Queue is built for performance with Ruby’s async model, making it faster than Resque (single-threaded) and comparable to Sidekiq.
Sidekiq is known for its high concurrency with multi-threading, handling jobs in parallel across multiple threads, which makes it extremely fast.
Resque uses a single-threaded model (in Ruby), meaning it's slower than both Sidekiq and Solid Queue for high-volume workloads.

Feature	Solid Queue	Sidekiq	Resque
Multi-server scaling	✅ Yes	✅ Yes	✅ Yes
Pub/Sub support	✅ Yes	✅ Yes	✅ Yes
External adapters	✅ Database	✅ Redis	✅ Redis
Job retry	✅ Yes	✅ Yes	✅ Yes
Concurrency Model	High (async)	Very high (multi-threaded)	Low (single-threaded)

Use Cases

Use Case	Solid Queue	Sidekiq	Resque
Simple background job processing	✅ Yes	✅ Yes	✅ Yes
High concurrency, real-time background jobs	✅ Yes	✅ Yes	❌ No
Large-scale job processing	✅ Yes	✅ Yes	✅ Yes
Job prioritization	✅ Yes	✅ Yes	✅ Yes
Queue with multiple workers	✅ Yes	✅ Yes	✅ Yes
Handling thousands of jobs per second	✅ Yes	✅ Yes	✅ No

Ease of Use & Setup

Feature	Solid Queue	Sidekiq	Resque
Setup Complexity	✅ Easy (out-of-the-box integration)	✅ Moderate (setup Redis and multi-threading)	✅ Moderate (setup Redis and single-threaded workers)
Integration with Rails	✅ Yes	✅ Yes	✅ Yes
Requires extra infrastructure	❌ No (use existing database)	✅ Yes (Redis, multi-threading setup)	✅ Yes (Redis)
Job Management UI	❌ No (CLI-based)	✅ Yes (web UI for monitoring)	✅ Yes (web UI for monitoring)

Conclusion: Which is Best?

Use Solid Queue if you need high-performance background job processing with single-server scaling and can benefit from Ruby-based async performance.
Use Sidekiq if you need multi-threaded, high-concurrency job processing with real-time capabilities and distributed scaling.
Use Resque if you need simple background job processing and don’t need high concurrency or performance optimization, but still want reliability.

💡 Best overall background job processor?

If you need high-performance job processing with Ruby → Solid Queue.
If you need extreme concurrency and distributed job processing → Sidekiq.
If you need a simple, reliable queue system with less focus on performance → Resque.

Can the Solid Trifecta replace Redis/Memcached?

The Solid Trifecta replaces external services like Redis and Memcached through its built-in database-driven solutions. Most applications that require moderate performance levels will find these integrated solutions suitable because they provide necessary features without increasing deployment complexity. Traditional solutions remain preferable for applications with demanding performance requirements because Redis and Memcached deliver optimized functionality.

Rails 8's Solid Trifecta enables developers to build more streamlined systems when caching messaging and job processing by utilizing existing database systems. These solutions provide many benefits for simplicity and cost-effectiveness but application users should evaluate their particular needs to decide if they can substitute traditional services before choosing Redis or Memcached.

Key Takeaways:

New apps should start with fewer dependencies using Rails 8’s built in solutions.

Scaling for performance: To keep costs low, use specialized tools only for higher speed requirements as the app scales.

Large applications should continue using high performing tools like Sidekiq for job processing along with Memcached for caching where required.

Revisiting Performance in Ruby 3.4.1

reinteractive — Wed, 12 Feb 2025 07:48:01 +0000

Credited to: Miko Dagatan

Introduction

Before, there are few articles that rose up saying that in terms of performance, Structs are powerful and could be used to define some of the code in place of the Class. Two of these are this one and this one.

Let's revisit these things with the latest Ruby version, 3.4.1, so that we can see whether this perspective still holds true.

Code for Benchmarking

class BenchmarkHashStruct
  class << self

    NUM = 1_000_000

    def measure
      array
      hash_str
      hash_sym
      klass
      struct
      data
    end

    def new_class
      @class ||= Class.new do
        attr_reader :name
        def initialize(name:)
          @name = name
        end
      end
    end

    def array
      time = Benchmark.measure do
        NUM.times do
          array = [Faker.name]
          hash[0]
        end
      end

      puts "array: #{time}" 
    end

    def hash_str
      time = Benchmark.measure do
        NUM.times do
          hash = { 'name' => Faker.name }
          hash['name']
        end
      end

      puts "hash_str: #{time}" 
    end

    def hash_sym
      time = Benchmark.measure do
        NUM.times do
          hash = { name: Faker.name }
          hash[:name]
        end
      end

      puts "hash_sym: #{time}" 
    end

    def struct
      time = Benchmark.measure do
        struct = Struct.new(:name) # Structs are only initialized once especially for large datasets
        NUM.times do |i|
          init = struct.new(name: Faker.name)
          init.name
        end

      end
      puts "struct: #{time}"
    end

    def klass
      time = Benchmark.measure do
        klass = new_class
        NUM.times do
          a = klass.new(name: Faker.name)
          a.name
        end
      end

      puts "class: #{time}"
    end

    def data
      time = Benchmark.measure do
        name_data = Data.define(:name)
        NUM.times do
          a = name_data.new(name: Faker.name)
          a.name
        end
      end

      puts "data: #{time}"
    end
  end
end

Explanation

In this file, we're simply trying to create benchmark measures for arrays, hashes with string keys, hashes with symbolized keys, structs, classes, and data. In a the lifetime of these objects, we understand that we instantiate them then we access the data we stored. So, we'll simulate only that for our tests. We use 1 million instances of these scenarios and see the results. The measure method will show all of these measurements together.

Results

performance(dev)> BenchmarkHashStruct.measure
array:   0.124267   0.000000   0.124267 (  0.129573)
hash_str:   0.264137   0.000000   0.264137 (  0.275421)
hash_sym:   0.174082   0.000000   0.174082 (  0.181514)
class:   0.308020   0.000000   0.308020 (  0.321165)
struct:   0.336229   0.000000   0.336229 (  0.350576)
data:   0.345480   0.000000   0.345480 (  0.360232)
=> nil

performance(dev)> BenchmarkHashStruct.measure
array:   0.090669   0.000378   0.091047 (  0.094786)
hash_str:   0.264261   0.000000   0.264261 (  0.275104)
hash_sym:   0.172333   0.000000   0.172333 (  0.179407)
class:   0.311545   0.000060   0.311605 (  0.324390)
struct:   0.335436   0.000000   0.335436 (  0.349203)
data:   0.346124   0.000071   0.346195 (  0.360396)
=> nil

performance(dev)> BenchmarkHashStruct.measure
array:   0.088372   0.003872   0.092244 (  0.096181)
hash_str:   0.265748   0.000464   0.266212 (  0.277565)
hash_sym:   0.174393   0.000000   0.174393 (  0.181831)
class:   0.309411   0.000000   0.309411 (  0.322613)
struct:   0.346008   0.000000   0.346008 (  0.360760)
data:   0.344666   0.000000   0.344666 (  0.359361)
=> nil

performance(dev)> BenchmarkHashStruct.measure
array:   0.077396   0.000038   0.077434 (  0.080771)
hash_str:   0.242372   0.000140   0.242512 (  0.252853)
hash_sym:   0.159206   0.000000   0.159206 (  0.166007)
class:   0.273878   0.009250   0.283128 (  0.295201)
struct:   0.322791   0.000323   0.323114 (  0.336889)
data:   0.346099   0.000038   0.346137 (  0.360901)
=> nil

I've run measure 4 times to account for any random changes that may have come and completely ensure of the performance of these tests. As expected, we see array at the top while symbolized hashes goes as a general second. We see that stringified hashes falls at the 3rd, with a huge gap when compared the the symbolized hashes. Then, when we look at class vs structs, it seems that structs have fallen a little bit behind compared to the classes. We could surmise that there is probably a performance boost done to classes in the recent patches.

Also, we could see that the Data object that was introduced in Ruby 3.2.0+ was falling behind the Struct object. This may be problematic since the Data object is basically a Struct that is immutable, so there's already disadvantages of using Data over Struct. We may still prefer Struct over Data considering that there's a bit of a performance bump over the Data.

Conclusion

There are 2 takeaways from this test. First, it's really important that we use symbolized hashes over stringified hashes as the former 1.5x faster than the latter. Meanwhile, if not using hashes, it's better to use Classes over Structs, unlike what was previously encouraged. Classes are now 1.07x - 1.14x times faster than structs, so it's encouraged to keep using them.

DEV Community: reinteractive

reinteractive: Shaping the Future of Rails Through Leadership Insights

Introducing SecretLink: The Secure Way to Share Sensitive Information

Introduction

How SecretLink Works

Who can use Secretlink

Open Source

Conclusion

Rails Action Mailer: Rendering Charts or Graphs in your Email

Generating Chart Images

Refinement: The Correct Way To Monkey-Patch in Ruby

Old way

Using Refinements

Even better approach (Ruby 2.4+, using import_methods)

Why Refinements?

Some Tips

Wrapping Up

Adding an AI chat to your Ruby on Rails application

What's Next?

Re-Revisiting Performance in Ruby 3.4.1

Introduction

Past observation: Structs are powerful and could be used to define some of the code in place of the Class

Should have checked three times!

An unbelievable twist!

Why Benchmark both Read & Write?

Benchmarking

Benchmarking Code

1 read to 1 write

2 reads to 1 write

3 reads to 1 write

5 reads to 1 write

10 reads to 1 write -- 5 attributes

10 reads to 1 write -- 10 attributes

Current Observations - What a rollercoaster!

The 5th Time

Struct as a Value Object

Conclusion

Real Time Page Updates with Rails and Hotwire - Turbo Broadcasts

Turbo Broadcast

Adding Loading and Transitions on broadcasts

Building a Ruby on Rails Chat Application with ActionCable and Heroku

Project Setup

Prerequisites

Key Technical Aspects

Turbo Streams and Broadcasting

Room Broadcasting:

Message Broadcasting:

JavaScript Integration

Models

Room Model

Message Model

Controllers

Rooms Controller

Messages Controller

Views

Room Index

Room Partial

Room Show (Chat Interface)

Message Partial

JavaScript

Reset Form Controller

Routes

How It All Works Together

Code In Action

Deploying the application on Heroku

Why Ruby on Rails is the Best First Framework for New Developers

Introduction

1. Beginner-Friendly Language & Framework

Readable and Expressive Syntax

Less Boilerplate Code

2. Fast Learning Curve & High Productivity

Convention Over Configuration (CoC)

Don’t Repeat Yourself (DRY)

Scaffolding & Generators

3. Full-Stack Web Development in One Framework

Covers Backend & Frontend

Active Record (ORM) – Simplified Database Management

Built-in Testing Tools

4. Strong & Supportive Community

Well-Established Ecosystem

Even better approach (Ruby 2.4+, using `import_methods`)

`sub` and `gsub` ruby methods

Using `sub` for Single Replacements