DEV Community: Zil Norvilis

How Turbo 8 Morphing Makes Rails Frontend Development Feel Like Magic

Zil Norvilis — Mon, 20 Apr 2026 23:22:43 +0000

When Hotwire first came out, it felt like a superpower. We could finally update our web pages without full browser reloads, and we didn't have to write a single line of React or Vue.

But after building a few apps with it, a new problem appeared.

To update the page dynamically, we had to write Turbo Streams. If a user added a new comment to a post, you had to write a specific .turbo_stream.erb file that told the browser: "Find the div with the ID of comments_list, and append this new HTML to the bottom of it. Oh, and also find the comments_counter div and replace it."

Very often I found myself writing tons of these little manual instructions. It started to feel just as annoying as writing custom JavaScript.

With the release of Turbo 8, the Rails team solved this completely. They introduced Page Morphing. It allows you to delete almost all of your Turbo Stream files and go back to writing plain, simple Rails controllers.

Here is exactly how it works and how to use it.

The Problem with Turbo Streams

In the old way (Turbo 7), if you wanted to like a post without losing your scroll position, your controller looked like this:

# app/controllers/likes_controller.rb
def create
  @post = Post.find(params[:post_id])
  @post.likes.create(user: current_user)

  respond_to do |format|
    # You had to explicitly render a stream
    format.turbo_stream 
  end
end

Then you had to create a matching view:

<!-- app/views/likes/create.turbo_stream.erb -->
<%= turbo_stream.replace "post_#{@post.id}_likes", partial: "likes/count", locals: { post: @post } %>

This is fine for one button. But if an action updates 5 different parts of the screen (the sidebar, the navbar, the main content), you have to write 5 different stream instructions.

What is Page Morphing?

Page Morphing asks a very simple question: What if we just reload the entire page, but the browser is smart enough to only update the pixels that actually changed?

Under the hood, Turbo 8 uses a library called idiomorph. When your server sends back a fresh HTML page, the browser compares the new HTML to the old HTML currently on your screen. It finds the differences, and smoothly morphs the DOM.

It does not blink. It does not lose your scroll position. It does not delete the text you are currently typing in an input box. It just updates the data seamlessly.

STEP 1: Enabling Morphing

To use this magic, you don't need complex JavaScript. You just need to add two meta tags to the <head> of your application layout.

<!-- app/views/layouts/application.html.erb -->
<head>
  <!-- ... other tags ... -->

  <%= turbo_refreshes_with method: :morph, scroll: :preserve %>
</head>

This tells Turbo: "Whenever a form is submitted or a link is clicked, don't do a hard page replace. Morph the page, and keep my scroll position exactly where it is."

STEP 2: Simplifying the Controller

Now that morphing is turned on, we can delete our .turbo_stream.erb file entirely.

Our controller goes back to looking like a classic, boring Rails 4 controller. We just redirect back to the page!

# app/controllers/likes_controller.rb
def create
  @post = Post.find(params[:post_id])
  @post.likes.create(user: current_user)

  # No more respond_to. Just redirect.
  redirect_to posts_path
end

When the redirect happens, Rails sends the fresh HTML for the posts_path. Turbo catches it, diffs it against your current screen, and updates the like counter instantly. Your user doesn't even notice the page reloaded.

STEP 3: Real-Time Magic (`broadcasts_refreshes`)

This is where it gets absolutely insane.

What if you want the screen to update when someone else likes the post? Like a real-time WebSocket update?

In the old days, you had to use broadcast_replace_to inside your model. Now, you just add one line to your ActiveRecord model:

# app/models/like.rb
class Like < ApplicationRecord
  belongs_to :post
  belongs_to :user

  # This replaces all manual broadcasting!
  broadcasts_refreshes
end

When a new Like is created in the database, Rails automatically sends a tiny WebSocket signal to anyone currently looking at that post. The signal simply says: "Hey, something changed. Please refresh your page."

The user's browser silently fetches the new HTML in the background and morphs the screen. The new like appears instantly. You achieved full real-time reactivity with one line of Ruby code.

Summary

As a solo developer, your goal is to write as little code as possible while delivering the best possible user experience.

Manual Turbo Streams (append, replace, remove) are still useful for very specific, complex animations. But for 95% of your application, you should be using Morphing.

Add the <%= turbo_refreshes_with %> tag to your layout.
Delete your .turbo_stream.erb files.
Use redirect_to in your controllers.
Use broadcasts_refreshes in your models for real-time updates.

Stop trying to manually manage the state of your HTML. Let the browser do the heavy lifting for you.

How to Add a Visual Page Builder to Your Rails App in 10 Minutes

Zil Norvilis — Sun, 19 Apr 2026 23:22:39 +0000

The Quickest Way to Build a Drag-and-Drop Landing Page Builder in Rails 8

Often when I am building a SaaS or a client project, and the client asks for a feature I always dread: "Can I have a page where I can build my own landing pages?"

If you try to build a drag-and-drop page builder from scratch using pure Ruby and Javascript, it will take you months. You have to handle layout grids, CSS saving, image uploads, and responsive design.

Instead of reinventing the wheel, the quickest and easiest way to do this in Rails 8 is to embed an open-source library called GrapesJS. It is a massive, production-ready page builder that outputs clean HTML and CSS. We can easily wrap it inside a Stimulus controller and save the output to our Rails database.

Here is how to add a drag-and-drop landing page builder to your Rails app in 5 steps.

STEP 1: The Database Setup

First off, we need a place to save the pages our users create. We don't need a complex schema. A landing page basically just consists of two things: the HTML structure and the CSS styles.

Let's generate a simple Page model:

rails g model Page title:string html_content:text css_content:text
rails db:migrate

STEP 2: Loading GrapesJS

GrapesJS is a heavy library. It requires both Javascript and CSS to work.

For the Javascript, we can use Rails 8 Importmaps to pin it:

bin/importmap pin grapesjs

For the CSS, GrapesJS needs its core stylesheet to make the editor look good. The easiest way to include this without fighting the asset pipeline is to just drop the CDN link directly into the view where the editor will live.

STEP 3: The Editor View

Now we create the view where the user will actually build the page. We will create a div for the editor, and attach a Stimulus controller to it. We also need a "Save" button to send the data back to Rails.

<!-- app/views/pages/edit.html.erb -->

<!-- 1. Load the GrapesJS CSS -->
<link rel="stylesheet" href="https://unpkg.com/grapesjs/dist/css/grapes.min.css">

<div data-controller="page-builder" data-page-builder-id-value="<%= @page.id %>">

  <div class="header">
    <h2>Editing: <%= @page.title %></h2>
    <!-- This button triggers the save method in our Stimulus controller -->
    <button data-action="click->page-builder#save">Save Page</button>
  </div>

  <!-- This is the empty canvas where GrapesJS will inject the builder -->
  <div id="gjs" data-page-builder-target="editor">
    <!-- Load existing content if the user is editing a saved page -->
    <style><%= @page.css_content %></style>
    <%= @page.html_content&.html_safe %>
  </div>

</div>

STEP 4: The Stimulus Controller (The Magic)

Next, we generate our Stimulus controller to initialize the builder:

rails g stimulus page_builder

Open the file and add the initialization logic. We import GrapesJS, tell it to attach to our #gjs div, and write a simple fetch request to save the data.

// app/javascript/controllers/page_builder_controller.js
import { Controller } from "@hotwired/stimulus"
import grapesjs from "grapesjs"

export default class extends Controller {
  static targets = ["editor"]
  static values = { id: Number }

  connect() {
    // Initialize the drag-and-drop builder
    this.editor = grapesjs.init({
      container: this.editorTarget,
      fromElement: true, // Loads the existing HTML/CSS we put in the view
      height: '800px',
      width: '100%',
      storageManager: false, // We will handle saving to our database manually

      // Enable the default built-in blocks (text, images, columns, etc)
      blockManager: {
        appendTo: '#blocks',
      }
    });
  }

  save() {
    // Grab the clean HTML and CSS generated by the user
    const html = this.editor.getHtml();
    const css = this.editor.getCss();

    const csrfToken = document.querySelector("[name='csrf-token']").content;

    // Send it to our Rails controller
    fetch(`/pages/${this.idValue}`, {
      method: "PATCH",
      headers: {
        "Content-Type": "application/json",
        "X-CSRF-Token": csrfToken
      },
      body: JSON.stringify({ 
        page: { 
          html_content: html, 
          css_content: css 
        } 
      })
    }).then(response => {
      if (response.ok) {
        alert("Page saved successfully!");
      }
    });
  }
}

STEP 5: Rendering the Final Page

Now the user has dragged their blocks, changed the colors, and clicked "Save". The data is in our database.

When a public visitor goes to view the page, we just need a very simple Rails controller and a view to spit that code back out.

# app/controllers/pages_controller.rb
class PagesController < ApplicationController
  # ... standard update action ...

  def show
    @page = Page.find(params[:id])
    # Tell Rails to use an empty layout so our standard app navbar 
    # doesn't ruin their custom landing page design
    render layout: false 
  end
end

And the view is literally just two lines of code:

<!-- app/views/pages/show.html.erb -->

<!-- Inject the custom CSS the user created -->
<style>
  <%= @page.css_content.html_safe %>
</style>

<!-- Inject the custom HTML -->
<%= @page.html_content.html_safe %>

Summary

Building a drag-and-drop builder sounds like a terrifying task, but by combining GrapesJS with a simple Stimulus controller, you can give your users a massive, professional landing page builder in about 10 minutes.

You don't need React, you don't need Webpack, and you keep all the data safely stored in your own Postgres or SQLite database.

How I Built a Native Android App with Almost Zero Kotlin Experience

Zil Norvilis — Sat, 18 Apr 2026 23:22:41 +0000

Turning a Rails App into an Android App: Testing Hotwire Native

Recently I wanted to test Hotwire Native in the real world. Having a sensitive stomach, I couldn't find a decent FODMAP diet app that was fast, simple, and didn't have annoying ads.

So, as developers do, I decided to build one myself.

My goal was to build a simple web app first, and then see how hard it would actually be to wrap it into a real Android application using Hotwire Native. To my surprise, turning this web app into an Android app was incredibly easy.

Here is the process of how I built it (you can check out the live web version here:https://fodmap.norvilis.com/).

The Foundation: Building the Rails App

I wanted to keep the backend as simple as possible. I didn't need a massive database, so I used SQLite to store the pre-gathered data of hundreds of food items and their FODMAP levels. SQLite is incredibly fast for this kind of "read-heavy" application.

For the user interface, I relied heavily on Hotwire to make it feel like a Single Page Application (SPA).

Live Filter: I added a search bar at the top. As you type, it uses a Stimulus controller to submit the form automatically, and a Turbo Frame swaps out the food list instantly without reloading the page.
The Modal: When you click on a food item to read more details, instead of loading a new page, it opens a clean modal popup using Turbo Frames.

It took a few hours, and the web version worked perfectly. But I wanted this on my phone.

The Magic: Enter Hotwire Native

If you build an app in React, to get it on a phone, you usually have to rewrite your UI in React Native.

With Hotwire Native, you don't rewrite anything. You create a basic "shell" Android app, and you tell it to load your Rails URL. But unlike a standard web-view, Hotwire Native intercepts your clicks and uses real native mobile transitions to move between screens.

Here is how the Android setup works.

STEP 1: The Android Project

First off, you need to download Android Studio. You create an empty project and add the Hotwire Native dependency to your build.gradle file:

dependencies {
    implementation("dev.hotwire:core:<latest-version>")
    implementation("dev.hotwire:navigation-fragments:<latest-version>")
}

STEP 2: Pointing to the Rails App

In Hotwire Native, you configure a Session. This tells the Android app where your Rails server lives. You just give it the URL of your app.

Inside your main Kotlin activity file, you set the starting URL:

// MainActivity.kt
class MainActivity : HotwireActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        enableEdgeToEdge()
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        findViewById<View>(R.id.main_nav_host).applyDefaultImeWindowInsets()
    }

    override fun navigatorConfigurations() = listOf(
        NavigatorConfiguration(
            name = "main",
            startLocation = "https://fodmap.norvilis.com",
            navigatorHostId = R.id.main_nav_host
        )
    )
}

STEP 3: The Path Configuration

You might have noticed the path.json file in the code above. This is the secret weapon of Hotwire Native.

It is a simple JSON file that lives in your Rails app (usually in public/configurations/android_v1.json). It tells the Android app how different URLs should behave.

For example, when a user clicks on a food item, I want the Android app to slide the new screen up from the bottom (like a native modal), instead of just pushing it sideways.

{
    "settings": {
        "register_with_account": false
    },
    "rules": [
        {
            "patterns": [
                "/new$",
                "/edit$",
                "/foods/[0-9]+$"
            ],
            "properties": {
                "context": "modal",
                "uri": "hotwire://fragment/web/modal/sheet"
            }
        },
        {
            "patterns": [
                ".*"
            ],
            "properties": {
                "context": "default",
                "uri": "hotwire://fragment/web"
            }
        }
    ]
}
}

When the Android app sees a URL that matches /foods/1, it reads this JSON file and says, "Ah! The Rails developer wants this to be a modal." It then uses native Android animations to open the screen.

Why I Love This Approach

I have almost zero experience writing Kotlin or Java. I am a Ruby developer.

But with Hotwire Native, I didn't need to build an API. I didn't need to write a separate mobile frontend.

My live search filter worked out of the box because Turbo works the same way inside the mobile wrapper.
My SQLite database and Rails controllers served both the web users and the Android users at the same time.
If I want to fix a typo or add a new food item, I deploy my Rails app, and the Android app is updated instantly. No app store reviews required.

That's pretty much it. If you have a Rails app and you have been avoiding making a mobile version because you don't want to learn a new language, you really need to try Hotwire Native. It is the ultimate superpower for a solo developer.

Making Sense of JavaScript in Rails: Webpack, Rollup, esbuild, and Importmaps

Zil Norvilis — Fri, 17 Apr 2026 23:21:40 +0000

Very often I find myself talking to developers who are incredibly confused by the JavaScript ecosystem in Rails.

If you run rails new my_app today, Rails asks you how you want to handle JavaScript. You look at the options - Importmaps, esbuild, Webpack, Rollup - and your brain hurts. You just want to write some code, but first, you have to choose a compilation strategy.

For a long time, the Rails community was stuck using Webpacker. It was slow, the configuration files were massive, and upgrading it broke everything. Thankfully, in 2026, we have much better options.

Here is my honest, simple breakdown of the four major JavaScript tools, how they work, and which one you should actually pick for your next project.

1. Webpack (The Heavyweight Dinosaur)

Webpack is the grandfather of modern JavaScript bundlers. If you worked on Rails 5 or 6, you probably have nightmares about the webpacker gem.

How it works: It takes every single JavaScript file, CSS file, and image in your project, builds a massive dependency graph, and compiles it all into one or two giant .js files.

// Webpack loves to bundle absolutely everything, even CSS
import "./style.css";
import React from "react";

The Good: It can do literally anything. It has thousands of plugins. If you are building a massive enterprise SPA (Single Page Application) with a dedicated frontend team, Webpack is battle-tested.
The Bad: It is notoriously slow to compile. The configuration files (webpack.config.js) are almost impossible to understand for a solo developer.
The Verdict: Do not use Webpack for a new Rails project unless you have a very specific, complex legacy requirement.

2. Rollup (The Library Builder)

Rollup came out as an alternative to Webpack. It introduced a cool concept called "Tree Shaking" (throwing away code you imported but never actually used to make the file smaller).

The Good: It creates incredibly small, optimized bundles.
The Bad: It is not really meant for building entire web applications. It was designed to build JavaScript libraries (like if you are publishing a package to NPM).

Note: While you probably won't use Rollup directly in Rails, it is worth knowing about because modern tools like **Vite* actually use Rollup under the hood for their production builds.*
The Verdict: Skip it for standard Rails apps.

3. esbuild (The Speed Demon)

When Rails 7 dropped Webpacker, they introduced jsbundling-rails and made esbuild the new star of the show.

How it works: esbuild does exactly what Webpack does (bundles all your JS into one file), but it is written in Go instead of JavaScript.

# How you build with esbuild in your terminal
esbuild app/javascript/* --bundle --sourcemap --outdir=app/assets/builds

The Good: It is unbelievably fast. A project that takes Webpack 30 seconds to compile will take esbuild 0.3 seconds. You literally don't even see it compiling. It also perfectly handles JSX if you are writing React code.
The Bad: You still need to install Node.js, manage a package.json, and deal with the node_modules black hole on your computer.
The Verdict: If your app uses React, Vue, or heavily customized Tailwind/PostCSS, esbuild is the absolute best choice. It gives you the power of a bundler without the waiting time.

4. Importmaps (The Rails Default / No-Build)

This is the default choice for new Rails applications, and it completely changes how frontend development works.

How it works: Importmaps do not bundle your code. There is no build step. You do not need Node.js or npm installed on your computer at all.

Instead of compiling libraries into one big file, your browser downloads the libraries directly from a fast CDN (Content Delivery Network) when the user loads the page.

# config/importmap.rb
# Rails simply maps the name to a CDN URL
pin "lodash", to: "https://ga.jspm.io/npm:lodash@4.17.21/lodash.js"

// app/javascript/application.js
// The browser fetches this directly from the CDN!
import _ from "lodash";

The Good: It is the ultimate "One Person Framework" tool. You never have to wait for JavaScript to compile. You hit save in your editor, refresh the browser, and it is instantly there. Your project folder stays tiny.
The Bad: You cannot use JSX or TypeScript, because those languages require a build step to be converted into plain JavaScript before the browser can read them.
The Verdict: If you are building a standard Rails app using Hotwire (Turbo + Stimulus), this is the winner.

Summary: Which one should you pick?

Don't overcomplicate your stack before you even write your first line of code. Follow this simple rule:

Are you using React, Vue, or TypeScript? Use esbuild. It is blazing fast and handles compiling perfectly.
Are you sticking to the Rails "Omakase" menu (Hotwire, Turbo, Stimulus)? Use Importmaps. Ditching node_modules will make your developer life so much happier.

Webpack was great for its time, but in 2026, we value speed and simplicity.

How to Build a Custom Affiliate System in Ruby on Rails

Zil Norvilis — Thu, 16 Apr 2026 23:14:37 +0000

When you are launching a new SaaS, getting your first users is the hardest part. One of the best ways to grow is to create an affiliate (or referral) program. You basically pay your existing users a commission to bring in new users.

Very often I see developers jumping straight to third-party tools like Rewardful or PartnerStack. These tools are amazing, but they usually start at $49 to $99 a month. If your app is brand new and making zero money, that is a huge expense.

Building a basic affiliate tracking system in Rails is actually very easy. You just need to generate a code, track a cookie, and connect two users together.

Here is how to build your own custom affiliate system in 5 simple steps.

STEP 1: The Database Setup

First off, we need to update our database. Our User model needs two new columns:

A unique code that they can share with their friends.
An ID that points to the person who referred them.

Let's generate the migration:

rails g migration AddAffiliateFieldsToUsers referral_code:string:uniq referred_by_id:integer:index

Run rails db:migrate to update your database.

STEP 2: The User Model Associations

Now we need to tell our User model how these fields work. A user can have many "referred users", and a user can belong to a "referrer".

We also want to automatically generate a unique referral_code every time a new user signs up.

# app/models/user.rb
class User < ApplicationRecord
  # The person who invited this user
  belongs_to :referrer, class_name: 'User', foreign_key: 'referred_by_id', optional: true

  # The people this user has invited
  has_many :referred_users, class_name: 'User', foreign_key: 'referred_by_id'

  before_create :generate_referral_code

  private

  def generate_referral_code
    # Generates a random 8-character string (e.g. 'aB9xYz2p')
    loop do
      self.referral_code = SecureRandom.alphanumeric(8)
      break unless User.exists?(referral_code: self.referral_code)
    end
  end
end

STEP 3: Tracking the Clicks (Cookies)

When a user shares their link, it will look something like this: https://myapp.com/?ref=aB9xYz2p.

If someone clicks that link, they might not sign up immediately. They might browse the homepage, read the pricing page, and then sign up 10 minutes later. We need to "remember" who sent them using a browser Cookie.

We can do this inside our ApplicationController so it catches the ref parameter on any page of our website.

# app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  before_action :track_affiliate_click

  private

  def track_affiliate_click
    if params[:ref].present?
      # Save the referral code in a cookie that expires in 30 days
      cookies[:affiliate_id] = {
        value: params[:ref],
        expires: 30.days.from_now,
        domain: :all # This ensures it works across subdomains if you use them
      }
    end
  end
end

STEP 4: Applying the Referral on Signup

Now, when a user finally fills out the registration form and clicks "Sign Up", we need to check if they have that cookie. If they do, we link them to the referrer.

If you are using Devise, you can just override the create method in your RegistrationsController, or hook into the user creation process.

Here is a standard controller example:

# app/controllers/users_controller.rb
class UsersController < ApplicationController
  def create
    @user = User.new(user_params)

    # Check if the user has an affiliate cookie
    if cookies[:affiliate_id].present?
      referrer = User.find_by(referral_code: cookies[:affiliate_id])
      @user.referrer = referrer if referrer.present?
    end

    if @user.save
      # Clear the cookie so we don't use it again accidentally
      cookies.delete(:affiliate_id, domain: :all)

      session[:user_id] = @user.id
      redirect_to root_path, notice: "Welcome!"
    else
      render :new, status: :unprocessable_entity
    end
  end
end

STEP 5: Creating the Affiliate Link

That's the entire backend tracking system! Now, you just need to show the user their link so they can copy it and share it.

In your view (like app/views/dashboards/show.html.erb), you can add this:

<div class="affiliate-box">
  <h3>Earn 20% for every friend you invite!</h3>
  <p>Share your unique link:</p>

  <input type="text" readonly value="<%= root_url(ref: current_user.referral_code) %>">

  <p>You have invited <%= current_user.referred_users.count %> friends.</p>
</div>

What about the Payouts?

This tutorial covers the tracking part, which is 90% of the battle.

For payouts, the easiest way is to use Stripe. When your new user buys a subscription, you can attach their referrer_id to the Stripe Customer metadata. Then, once a month, you just write a quick Ruby script to loop through your users, see how many active referrals they have, and add account credits or send them money via Stripe Connect (or PayPal).

Building it yourself takes about 15 minutes, saves you a lot of money on monthly subscriptions, and gives you total control over how your referral system works.

It Looks Like Ruby, But It’s Not: How to Understand Elixir

Zil Norvilis — Wed, 15 Apr 2026 23:16:57 +0000

If you write Ruby, you will eventually get curious about Elixir. The creator of Elixir, José Valim, was a huge figure in the Ruby on Rails community. Because of this, when you look at Elixir code for the first time, it feels very familiar. It has def, do, and end.

But here is the trap: Elixir is not Ruby.

Very often I see Ruby developers try to write Elixir as if it was Ruby. They get frustrated because things don't work the way they expect. Ruby is Object-Oriented. Elixir is Functional.

To learn Elixir, you don't need to learn a crazy new syntax. You just need to rewire how you think about data. Here is a simple guide translating Ruby concepts into Elixir concepts.

1. Classes vs Modules

In Ruby, everything is an Object. You create a Class, initialize an object, and that object holds its own data (state).

# ruby
class User
  attr_accessor :name

  def initialize(name)
    @name = name
  end

  def upcase_name!
    @name = @name.upcase
  end
end

user = User.new("zil")
user.upcase_name!
puts user.name # Outputs: ZIL

In Elixir, there are no objects and no classes. Data is just data, and functions are just functions. They live separately. Instead of Classes, you group functions together inside Modules.

# elixir
defmodule User do
  # We just take data in, and return new data out
  def upcase_name(user_map) do
    Map.update!(user_map, :name, &String.upcase/1)
  end
end

user = %{name: "zil"}
# We pass the data into the module's function
new_user = User.upcase_name(user)
IO.puts new_user.name # Outputs: ZIL

2. Method Chaining vs The Pipe Operator

Ruby developers love method chaining. You take an object and call methods on it in a row.

# ruby
"hello world".upcase.split(" ").join("-")
# Outputs: "HELLO-WORLD"

Because Elixir doesn't have objects, you can't call .upcase on a string. You have to pass the string into a String module. Doing this normally looks very messy and nested: Enum.join(String.split(String.upcase("hello world"), " "), "-").

To fix this, Elixir uses the Pipe Operator (|>). It takes the result of the left side and passes it as the very first argument to the function on the right side.

# elixir
"hello world"
|> String.upcase()
|> String.split(" ")
|> Enum.join("-")
# Outputs: "HELLO-WORLD"

Once you get used to the Pipe Operator, you will actually miss it when you go back to Ruby. It makes reading the flow of data incredibly easy.

3. Hashes vs Maps

In Ruby, we use Hashes everywhere to store key-value data.

# ruby
user = { name: "Zil", role: "admin" }
puts user[:name]

In Elixir, the equivalent is called a Map. The syntax is almost identical, except you put a % sign in front of it.

# elixir
user = %{name: "Zil", role: "admin"}
IO.puts user.name

The big difference: In Ruby, you can just change the hash later (user[:role] = "user"). In Elixir, data is immutable. You cannot change the map once it is created. You have to create a brand new map with the updated value.

# elixir
user = %{name: "Zil", role: "admin"}
# This creates a completely new map in memory
updated_user = %{user | role: "user"}

4. The Equals Sign is a Lie (Pattern Matching)

This is the hardest part for Rubyists to grasp.

In Ruby, = means assignment. You are saying "Put this value into this variable."

# ruby
name = "Zil"

In Elixir, = is actually the Match Operator. It is like an algebra equation. It tries to make the left side match the right side.

# elixir
name = "Zil" # This works, Elixir binds "Zil" to name to make it match.

# But you can also do this:
%{name: user_name} = %{name: "Zil", role: "admin"}

IO.puts user_name # Outputs: "Zil"

In that second example, Elixir looks at the right side, sees the map, and says: "To make the left side match, I need to extract the value of :name and put it into the user_name variable."

This is called Pattern Matching. It is the most powerful feature in Elixir. You use it everywhere - to extract data from APIs, to handle errors, and to route web requests.

Summary

Learning Elixir when you already know Ruby is a really fun experience. You don't have to fight with ugly brackets or semicolons.

Just remember the golden rules of Elixir:

Data never changes (Immutability).
Data and Functions live separately.
Use |> to push data through your functions.

That's pretty much it. Even if you never build a production app in Elixir, learning how functional programming works will absolutely make you a better, cleaner Ruby developer.

Pundit vs CanCanCan vs Action Policy: Which Rails Auth Gem Wins?

Zil Norvilis — Tue, 14 Apr 2026 23:17:20 +0000

Sometimes I find myself starting a new Rails project, and almost immediately, I hit a wall: User Permissions.

Guests can read posts, users can edit their own posts, and admins can delete everything. You need an authorization system to manage this. If you try to write this logic directly inside your controllers or views with a bunch of if/else statements, your code will become an unreadable mess within a week.

For a long time, the Rails community was divided. Today, we have three main gems to handle this: CanCanCan, Pundit, and the newer Action Policy.

Here is my honest breakdown of how they work, the pros and cons of each, and which one you should actually use for your next app.

1. CanCanCan (The Legacy Giant)

If you learned Rails 5 or 6 years ago, you probably used CanCanCan (a community continuation of the original cancan gem).

How it works:
It is highly centralized. You define absolutely every permission for your entire application inside one single file called the Ability class.

# app/models/ability.rb
class Ability
  include CanCan::Ability

  def initialize(user)
    user ||= User.new # guest user

    if user.admin?
      can :manage, :all
    else
      can :read, Post
      can :update, Post, user_id: user.id
    end
  end
end

Then, in your controller, you just call authorize! :update, @post.

The Good: For a very small app, it is incredibly fast to set up. You can see all the rules in one place.
The Bad: As your app grows, the Ability file becomes a nightmare. I have seen production apps with an ability.rb file that is 2,000 lines long. It becomes impossible to test and incredibly slow to load, because Rails has to evaluate that entire massive file on every single request.

2. Pundit (The Object-Oriented Standard)

Pundit was created to solve the "giant file" problem of CanCanCan. It threw away the custom syntax and went back to plain, simple Ruby.

How it works:
Instead of one big file, you create a separate "Policy" class for every single model in your app.

# app/policies/post_policy.rb
class PostPolicy
  attr_reader :user, :post

  def initialize(user, post)
    @user = user
    @post = post
  end

  def update?
    user.admin? || post.user_id == user.id
  end
end

In your controller, you use the same authorize @post method, and Pundit automatically looks for the PostPolicy and calls the update? method.

The Good: It is incredibly clean. Because it is just plain Ruby objects returning true or false, writing tests for your policies is super easy. It scales perfectly with huge applications.
The Bad: It can feel a bit repetitive. You end up writing a lot of boilerplate initialize methods for every single policy file.

3. Action Policy (The Modern Speed Demon)

Action Policy is the newest challenger, built by the team at Evil Martians. It looked at Pundit and said: "This is great, but we can make it faster and require less typing."

How it works:
It looks very similar to Pundit, but it gives you a base class to inherit from, which removes the need to write initialize methods. It also adds powerful features right out of the box.

# app/policies/post_policy.rb
class PostPolicy < ApplicationPolicy
  # We can alias methods so we don't repeat code!
  alias_rule :edit?, :destroy?, to: :update?

  def update?
    user.admin? || record.user_id == user.id
  end
end

The Good:

Performance: It is heavily optimized. It caches authorization results during a request. If you check if a user can update a post 50 times in a view loop, Action Policy only calculates it once. Pundit calculates it 50 times.
Less Code: Features like alias_rule save you from writing duplicate methods.
GraphQL Integration: If you are building a modern API with Ruby-GraphQL, Action Policy integrates flawlessly.

The Bad: It has a slightly larger learning curve if you want to use its advanced caching and scoping features compared to the absolute simplicity of Pundit.

Summary: Which one should you pick?

Don't overcomplicate your decision. Here is the golden rule I follow today:

Do not use CanCanCan for new projects. It is great for legacy codebases, but the centralized design pattern is an anti-pattern for modern, scalable web apps.
Use Pundit if you want the most "standard" approach. Almost every Rails developer knows how to read Pundit code, and the documentation is everywhere.
Use Action Policy if you are building a highly performant app, an API, or if you just hate writing boilerplate code.

Personally, I have completely switched to Action Policy for all my new Rails 8 apps. The built-in caching and the cleaner syntax make it the absolute winner for modern Ruby development.

Wise Testing: What to Test (and Ignore) as a Solo Rails Developer

Zil Norvilis — Mon, 13 Apr 2026 23:22:57 +0000

Solo founders fail for a completely preventable reason. It’s not because their idea was bad, and it’s not because they couldn't code. It’s because they spent 4 weeks writing unit tests for a product that had zero paying customers.

In the enterprise world, 100% test coverage is an insurance policy. In the startup world, as a One-Person Team, 100% test coverage is a death sentence. You will run out of momentum and quit before you launch.

But you can't just ship with zero tests, or you will be too terrified to deploy updates on a Friday.

You need Wise Testing. This is the art of getting 90% confidence with 10% of the code. By sticking to Rails defaults (Minitest and Fixtures), you can build a safety net that protects your business without slowing down your MVP.

Here is my exact guide on what to test, and more importantly, what to completely ignore.

RULE 1: What NOT to Test (The Time Wasters)

The biggest mistake beginners make is testing the Rails framework. Rails has thousands of contributors who already tested ActiveRecord. You do not need to test it again.

Do NOT test validations:

# A useless test
test "user is invalid without an email" do
  user = User.new(email: nil)
  assert_not user.valid?
end

If you wrote validates :email, presence: true in your model, trust that Rails works.

Do NOT test basic CRUD controllers:
Don't write isolated controller tests just to check if the index action returns a 200 status code. It is a massive waste of time. Your System Tests will catch if the page crashes.

Do NOT test third-party UI:
If you are using Tailwind UI or a component library, don't write tests to ensure a button is blue.

RULE 2: The "Golden Path" System Tests (High ROI)

If you only have time to write one type of test, write System Tests.

A system test boots up a real browser (using Capybara and Selenium/Playwright), navigates your app, and clicks buttons like a real human.

Why is this the best use of your time? Because one system test implicitly tests your routing, your controller, your database, and your view rendering all at once.

Identify the "Golden Paths" of your app. These are the 2 or 3 flows that must work for your business to survive.

For a SaaS, the Golden Path is usually:

User signs up.
User creates the core resource (e.g., a "Project").
User upgrades to a paid plan.

# test/system/onboarding_test.rb
require "application_system_test_case"

class OnboardingTest < ApplicationSystemTestCase
  test "user can sign up and create a project" do
    # 1. Sign up
    visit new_user_registration_path
    fill_in "Email", with: "founder@example.com"
    fill_in "Password", with: "secret123"
    click_on "Sign Up"

    # 2. Core Business Action
    click_on "New Project"
    fill_in "Name", with: "My Awesome MVP"
    click_on "Save"

    # 3. Verify Success
    assert_text "Project was successfully created."
    assert_text "My Awesome MVP"
  end
end

If this single test passes, you have a 90% guarantee that your app is functional.

RULE 3: Surgical Unit Tests (The Money and the Math)

You skipped testing basic models and controllers. So when do you write unit tests?

You write them for Custom Business Logic. If a method calculates a tax rate, processes a Stripe webhook, or filters sensitive data, you must test it in isolation.

Always extract this complex logic into Plain Old Ruby Objects (Service Objects), and test those.

# test/services/commission_calculator_test.rb
require "test_helper"

class CommissionCalculatorTest < ActiveSupport::TestCase
  test "calculates 10 percent commission for standard affiliates" do
    # Standard math logic that MUST be right
    calculator = CommissionCalculator.new(amount: 100_00, rate: 0.10)
    assert_equal 10_00, calculator.payout
  end

  test "returns zero if order is refunded" do
    calculator = CommissionCalculator.new(amount: 100_00, rate: 0.10, refunded: true)
    assert_equal 0, calculator.payout
  end
end

Test the things that would cause you to lose money or leak private data if they broke.

RULE 4: Embrace Rails Fixtures (Skip FactoryBot)

The RSpec world loves FactoryBot. Factories are great, but they dynamically generate and insert database records on every single test run. As your app grows, this makes your test suite agonizingly slow.

Rails defaults to Fixtures. Fixtures are simply YAML files that get loaded into your test database once when the test suite boots.

# test/fixtures/users.yml
zil:
  email: zil@example.com
  encrypted_password: <%= User.new.send(:password_digest, 'password') %>
  plan: pro

# Inside your tests, you just reference the name:
user = users(:zil)

For a solo developer, Fixtures are the ultimate speed hack. Your Minitest suite will run in a fraction of a second, meaning you will actually run it frequently while coding.

💡 Want the complete system?
If this pragmatic approach resonates with you and you want to see exactly how I set up my test suites from scratch, I’ve put my entire testing workflow into a comprehensive guide. Check out Wise Testing: The Solo Founder's Guide to Rails Quality to learn how to test Stripe webhooks, handle complex fixtures, and set up lightning-fast CI pipelines.

Summary: The Wise Testing Checklist

Before you write a test, ask yourself: "If this breaks, does the business fail, or does it just look a little weird?"

Do not test Rails. (Validations, associations, simple controllers).
Write 3-5 System Tests. Cover the absolute critical paths (Signup, Core Value, Checkout).
Write Surgical Unit Tests. Only test complex math, money, and security logic.
Use Minitest and Fixtures. Keep your test suite boring, fast, and dependency-free.

Ship the MVP. Let the users find the small bugs. Use your automated tests to protect the big ones.

Stop AI Spaghetti: Enforcing Rails Architecture in 2026

Zil Norvilis — Sun, 12 Apr 2026 23:12:24 +0000

We are fully in the era of autonomous coding. If you use tools like Cursor, Windsurf, or Copilot Workspace, you know how fast you can move. You type a prompt, and the AI generates an entire feature - controllers, models, and views—in 10 seconds.

But there is a dark side to this speed.

The AI does not know your personal architectural standards. If you don't watch it closely, it will put complex business logic directly into your ActiveRecord callbacks. It will make raw API calls from your ERB views. Give it a few months, and your beautiful Rails app will turn into an unmaintainable "Big Ball of Mud."

When you are generating code this fast, you cannot rely on willpower to keep things clean. You need automated guardrails. Here is how to ensure autonomously generated code stays consistent with your Rails architecture over time.

STEP 1: The Context File (`.cursorrules`)

The easiest way to fix bad AI code is to prevent it before it is written.

Modern AI code editors look for hidden context files in your project root (like .cursorrules or .windsurfrules). This file tells the AI how you expect it to behave in this specific repository.

Instead of typing "Use a service object" in every single prompt, you define your architectural boundaries once.

Create a .cursorrules file in your Rails root:

# Rails Architecture Guidelines for this Project

1. **Fat Models, Skinny Controllers are BANNED.** Controllers should only handle HTTP routing and params. Models should only handle database associations and strict validations.
2. **Business Logic:** ALL business logic must go into Plain Old Ruby Objects (POROs) inside `app/services/`. Do not use ActiveRecord callbacks (`after_save`, `after_create`) for business logic like sending emails or calling external APIs.
3. **Views:** Use Tailwind CSS for styling. Extract complex UI elements into `ViewComponent` classes instead of using Rails `_partials`.
4. **Testing:** Write Minitest System Specs for all new features. Do not write granular unit tests for private methods.

Now, when you tell the AI to "Build a user onboarding flow," it automatically knows to generate a UserOnboardingService instead of dumping 200 lines of code into the UsersController.

STEP 2: Ruthless Linting with RuboCop

AI is notoriously bad at code formatting. It will mix single and double quotes, mess up indentation, and write methods that are 50 lines long.

You need to enforce style programmatically. In Ruby, this means RuboCop. But you need to turn on the strict Rails-specific rules.

Add these to your Gemfile:

group :development, :test do
  gem 'rubocop', require: false
  gem 'rubocop-rails', require: false
  gem 'rubocop-performance', require: false
end

Create a .rubocop.yml file and set your boundaries. For example, if you want to stop the AI from writing massive, complex methods, enforce the MethodLength and Metrics/AbcSize cops.

# .rubocop.yml
require:
  - rubocop-rails
  - rubocop-performance

Metrics/MethodLength:
  Max: 15

Metrics/ClassLength:
  Max: 100

Rails/SkipsModelValidations:
  Enabled: true # Stops AI from using .update_attribute and skipping your validations

The Pro Move: Set your editor to "Auto-Fix on Save." When the AI generates a messy file, you just hit Cmd+S, and RuboCop instantly rewrites the syntax to match your standard.

STEP 3: Enforcing Boundaries (Packwerk)

If your app is growing large, the AI will eventually try to cross-wire different domains. It will make the Billing module call private methods inside the Inventory module.

To stop this structurally, you can use Shopify's Packwerk gem. Packwerk allows you to define strict boundaries between folders in your Rails app.

You create a package.yml file in your folders:

# app/services/billing/package.yml
enforce_privacy: true
enforce_dependencies: true

If the AI generates code in the Orders controller that tries to call an internal class inside the Billing package, Packwerk will throw a static analysis error before you even run the code. It literally blocks the AI from creating spaghetti dependencies.

STEP 4: System Tests over Unit Tests

When you use AI, your internal code changes very fast. You might ask the AI to refactor a Service Object, and it will completely rename all the internal methods.

If you have 100 granular Unit Tests checking those specific method names, your test suite will break every time you prompt the AI. You will spend hours fixing tests instead of shipping features.

To survive the AI era, you must rely on System Tests (Integration Tests).

# test/system/onboarding_test.rb
require "application_system_test_case"

class OnboardingTest < ApplicationSystemTestCase
  test "user can sign up and reach the dashboard" do
    visit new_user_registration_path
    fill_in "Email", with: "test@example.com"
    fill_in "Password", with: "password123"
    click_on "Sign up"

    assert_text "Welcome to your Dashboard"
  end
end

System tests don't care how the AI wrote the backend logic. They don't care if the AI used a Service Object or a background job. They only care that the user can click the button and get the result.

By writing System tests, you give the AI the freedom to refactor and optimize the internal architecture without breaking your test suite, while giving yourself 100% confidence that the app still works.

Summary

In 2026, your job is no longer just typing code. Your job is acting as the Editor-in-Chief for an incredibly fast, slightly reckless junior developer.

Give Context: Use .cursorrules to define your architecture up front.
Auto-Format: Use RuboCop to enforce syntax rules on save.
Set Boundaries: Use static analysis (like Packwerk) to prevent tangled dependencies.
Test the Output: Rely on System Tests to verify behavior, not internal implementation.

If you set up these guardrails on day one, you can let the AI run wild, knowing your Rails app will stay clean, modular, and easy to maintain.

How to Fix N+1 Queries in Rails Like a Pro

Zil Norvilis — Sat, 11 Apr 2026 23:11:25 +0000

There are Rails applications that run incredibly fast on a developer's laptop, but the moment they are deployed to production, they crawl to a halt. The pages take 3 seconds to load, and the database CPU is at 100%.

Almost every single time, the culprit is the exact same thing: The N+1 Query Problem.

ActiveRecord is amazing because it hides the complex SQL from you. But because it is so easy to use, it is also very easy to accidentally hammer your database with hundreds of unnecessary queries.

Here is exactly what the N+1 problem is, how to fix it using .includes, and how to handle complex nested data like a senior Rails developer.

The Problem: What is N+1?

Imagine you have a Post model and a User model (the author). You want to list 50 posts on your homepage and show the author's name next to each one.

You write this in your controller:

# app/controllers/posts_controller.rb
def index
  @posts = Post.limit(50)
end

And you write this in your view:

<!-- app/views/posts/index.html.erb -->
<% @posts.each do |post| %>
  <h2><%= post.title %></h2>
  <p>By: <%= post.user.name %></p>
<% end %>

This looks perfectly fine. But if you look at your terminal logs, you will see a nightmare.

Rails runs 1 query to fetch the 50 posts.
Then, as it loops through the HTML, it hits post.user.name. It doesn't have the user data in memory, so it asks the database: "Hey, get me the user for post 1."
Then it asks: "Get me the user for post 2."
It does this 50 times.

You just ran 51 queries to load a single webpage. If you have 1,000 posts, you run 1,001 queries. This is the N+1 problem.

LEVEL 1: The Basic Fix (`includes`)

To fix this, we need to tell ActiveRecord to fetch all the related data before we start looping in the view. We do this using Eager Loading via the .includes method.

Change your controller to this:

# app/controllers/posts_controller.rb
def index
  # We tell Rails: "Fetch the posts, AND fetch their users right now."
  @posts = Post.includes(:user).limit(50)
end

Now, look at your server logs. Rails will only run 2 queries:

SELECT * FROM posts LIMIT 50
SELECT * FROM users WHERE id IN (1, 2, 3, 4...)

Rails grabs all 50 users in one big query, and stitches them together in memory. The speed difference is massive.

LEVEL 2: Nested Includes (Going Deeper)

What if your data is more complex?
Let's say you want to show the Post, the User's name, the User's Profile picture, AND a list of all the Comments on the post.

If you just do .includes(:user), the comments and the profile will still trigger N+1 queries. You have to pass a Hash to .includes to load nested relationships.

def index
  @posts = Post.includes(
    comments: :author,    # Loads comments, AND the author of each comment
    user: :profile        # Loads the post user, AND the user's profile
  ).limit(50)
end

Using arrays and hashes, you can build a perfectly optimized data tree with a single line of code.

LEVEL 3: includes vs preload vs eager_load (The Pro Stuff)

When you use .includes, Rails does something very clever. It looks at your query and decides the best way to fetch the data. But as you get more advanced, you should know exactly what is happening under the hood.

ActiveRecord actually has three different methods for eager loading:

1. .preload (The Default)
This is what .includes usually does behind the scenes. It ALWAYS runs two separate queries.
SELECT * FROM posts and then SELECT * FROM users WHERE id IN (...).
It is very fast and uses less memory. But, you cannot use a where clause on the preloaded table. If you try Post.preload(:user).where(users: { active: true }), your app will crash.

2. .eager_load (The Giant Join)
This forces Rails to use a LEFT OUTER JOIN. It grabs all the posts and all the users in one single, massive query.
You use this when you specifically need to filter by the associated table:
Post.eager_load(:user).where(users: { active: true })

3. .includes (The Smart Manager)
.includes is the safe middle ground. By default, it acts like .preload. But if Rails sees that you added a .where referencing the joined table, it automatically switches to acting like .eager_load.

Rule of thumb: Just stick to .includes 90% of the time, and let Rails do the thinking.

LEVEL 4: Strict Loading (The Ultimate Safety Net)

Even senior developers accidentally introduce N+1 queries. You might add a new helper method in a view months later and forget to update the controller's .includes.

To prevent this from ever reaching production, modern Rails has a feature called Strict Loading.

If you turn this on, Rails will literally crash your app (raise an error) the moment it detects an N+1 query. It forces you to fix it immediately.

You can do this on a single record:

@post = Post.strict_loading.first
@post.user # => Raises ActiveRecord::StrictLoadingViolationError!

Or, you can do what I do and turn it on globally for your development and test environments.

# config/environments/development.rb
config.active_record.strict_loading_by_default = true

Now, you can never accidentally write a view that triggers an N+1 query without your local server screaming at you to add .includes. It is the best performance habit you can build.

Summary

ActiveRecord makes database interactions feel like magic, but you always have to pay attention to the logs.

Check your terminal. If you see the same SELECT statement repeating 50 times in a row, you have an N+1 problem.
Use .includes in your controller to fetch the data upfront.
Use Hashes for deeply nested associations.
Turn on strict_loading in development to catch the bugs before your users do.

That's pretty much it. Fixing N+1 queries is usually the easiest way to make a slow Rails app feel 10x faster.

Building a World-Class Search Engine in Rails with Searchkick

Zil Norvilis — Fri, 10 Apr 2026 23:03:11 +0000

Stop Using SQL LIKE: A Step-by-Step Guide to Elasticsearch in Rails

When you build a standard Rails app, searching your database usually starts with a simple ActiveRecord query: Product.where("name ILIKE ?", "%#{params[:q]}%").

This works fine when you have 100 products. But when you have 100,000 products, it gets very slow. Even worse, if a user searches for "iphne" instead of "iphone", your database returns zero results. Users expect Google-level search with auto-complete and typo forgiveness. Postgres can do basic Full Text Search, but setting it up perfectly is painful.

This is where Elasticsearch comes in.

Elasticsearch is essentially a secondary, NoSQL database completely optimized for searching text. Integrating it with Rails sounds intimidating, but thanks to an amazing gem called Searchkick, you can build enterprise-grade search in about 10 minutes.

Here is the step-by-step guide to adding Elasticsearch to your Rails app without losing your mind.

STEP 1: The Setup

First off, you need Elasticsearch running on your computer. The absolute easiest way to do this without messing up your Mac or Linux machine is to use Docker. Run this in your terminal to start a local server:

docker run -p 9200:9200 -e "discovery.type=single-node" docker.elastic.co/elasticsearch/elasticsearch:8.13.0

Now, let's add the gems to your Rails app. We need the official client and the Searchkick wrapper.

# Gemfile
gem 'elasticsearch'
gem 'searchkick'

Run bundle install.

STEP 2: Tell Your Model to Listen

Elasticsearch does not magically read your Postgres database. It is a separate engine. We need to tell our Rails model to sync its data to Elasticsearch.

Open your model (let's use a Product model) and add one word:

# app/models/product.rb
class Product < ApplicationRecord
  searchkick
end

That's it. From now on, whenever you create, update, or destroy a Product, Searchkick will automatically send a background request to Elasticsearch to keep the search index perfectly in sync with your database.

STEP 3: Index Your Existing Data

Because you just added the gem, Elasticsearch is currently empty. It doesn't know about the products you created yesterday.

You need to push your existing database records into Elasticsearch. Open your Rails console (rails c) and run:

Product.reindex

You will see a progress bar as Searchkick grabs all your products and sends them to the search engine. Anytime you make massive database changes (like a raw SQL bulk update), you should run this command.

STEP 4: The Search Query

Now for the fun part. Let's replace that ugly ILIKE query in our controller.

Searchkick gives us a .search method that feels just like ActiveRecord, but it queries Elasticsearch instead of Postgres.

# app/controllers/products_controller.rb
class ProductsController < ApplicationController
  def index
    query = params[:q].presence || "*"

    @products = Product.search(query, 
      fields: [:name, :description],
      match: :word_start,
      misspellings: { edit_distance: 2 }
    )
  end
end

Look at how powerful this is:

fields: We tell it to only look at the name and description.
match: :word_start allows for auto-complete. If they type "lap", it matches "laptop".
misspellings: This is the magic. If they type "lpatop", Elasticsearch knows they meant "laptop" because the "edit distance" (number of wrong letters) is within our limit.

STEP 5: Customizing the Index (The Pro Move)

By default, Searchkick sends every single column of your database to Elasticsearch. If you have a secret_cost column or a user_password column, you absolutely do not want that in your search index.

You should always control exactly what data gets indexed. You do this by overriding the search_data method in your model.

# app/models/product.rb
class Product < ApplicationRecord
  searchkick

  belongs_to :category

  def search_data
    {
      name: name,
      description: description,
      price: price,
      # We can even index associated data!
      category_name: category.name,
      in_stock: stock_count > 0
    }
  end
end

Now, when you run Product.reindex, only this specific JSON block is sent to Elasticsearch. Because we included category.name, users can now type "Electronics" in the search bar, and it will return the products belonging to that category, without doing any complex SQL JOIN queries.

Summary

That's pretty much it. Adding Elasticsearch used to require hundreds of lines of configuration and complex JSON mapping files.

With Searchkick, the workflow is incredibly simple:

Add the gem.
Add searchkick to your model.
Run Model.reindex.
Use Model.search("query").

If your app relies heavily on user discovery - like an e-commerce store, a directory, or a massive blog—ditching SQL for a dedicated search engine is the biggest UX upgrade you can make.

The Easiest Way to Add Drag and Drop to Your Rails App

Zil Norvilis — Thu, 09 Apr 2026 23:13:05 +0000

Building Drag and Drop in Rails 8 with SortableJS and Importmaps

Very often I find myself building apps where users need to reorder things. Maybe it is a list of tasks, a gallery of images, or steps in a project.

In the old days, we used jQuery UI for this. Then we moved to complex React drag-and-drop libraries. But if you are using modern Rails with Hotwire, adding drag and drop is actually incredibly simple. We don't even need Node.js or Webpack.

We can use a lightweight library called SortableJS, load it via Importmaps, and connect it to our database using a single Stimulus controller.

Here is exactly how to do it in 5 steps.

STEP 1: The Database Setup

First off, our database needs to know the order of our items. Let's assume we have a Task model. We need to add a position column to it.

Run this migration in your terminal:

rails g migration AddPositionToTasks position:integer
rails db:migrate

Pro tip: I highly recommend adding the acts_as_list gem to your Gemfile. It handles all the annoying math of shifting positions up and down in the database automatically.

If you use the gem, just add this to your model:

# app/models/task.rb
class Task < ApplicationRecord
  acts_as_list
end

STEP 2: Pin SortableJS (Importmap)

Because we are using Importmaps, we do not need to run npm install. We just pin the library directly from the CDN.

Run this in your terminal:

bin/importmap pin sortablejs

This will automatically add the correct URL to your config/importmap.rb file.

STEP 3: The HTML View

Now let's build the list in our view. We need to wrap our tasks in a div or ul and attach a Stimulus controller to it. We also need to give each item a data attribute so our Javascript knows which Task ID is being dragged.

<!-- app/views/tasks/index.html.erb -->

<h1>My Tasks</h1>

<!-- We attach the 'sortable' controller here -->
<ul data-controller="sortable">
  <% @tasks.order(:position).each do |task| %>

    <!-- We store the task ID on the list item -->
    <li data-id="<%= task.id %>" class="p-4 bg-white border mb-2 cursor-move">
      <%= task.name %>
    </li>

  <% end %>
</ul>

STEP 4: The Stimulus Controller

Next, we generate our Stimulus controller:

rails g stimulus sortable

Open the newly created file at app/javascript/controllers/sortable_controller.js. This is where the magic happens. We import SortableJS, initialize it, and tell it to send a network request to Rails whenever the user drops an item.

// app/javascript/controllers/sortable_controller.js
import { Controller } from "@hotwired/stimulus"
import Sortable from "sortablejs"

export default class extends Controller {
  connect() {
    // Initialize Sortable on the HTML element this controller is attached to
    this.sortable = Sortable.create(this.element, {
      animation: 150,
      onEnd: this.updatePosition.bind(this)
    })
  }

  updatePosition(event) {
    // Get the dragged item's ID and its new index in the list
    const id = event.item.dataset.id
    const newIndex = event.newIndex + 1 // ActsAsList is 1-indexed, JS is 0-indexed

    // Grab the CSRF token so Rails doesn't block our request
    const csrfToken = document.querySelector("[name='csrf-token']").content

    // Send an AJAX request to our Rails controller
    fetch(`/tasks/${id}/move`, {
      method: "PATCH",
      headers: {
        "Content-Type": "application/json",
        "X-CSRF-Token": csrfToken
      },
      body: JSON.stringify({ position: newIndex })
    })
  }
}

STEP 5: The Rails Controller & Route

The Javascript is sending a PATCH request to /tasks/:id/move. Let's create that route and the controller action to handle it.

Update your routes:

# config/routes.rb
resources :tasks do
  member do
    patch :move
  end
end

And finally, update the database in your TasksController:

# app/controllers/tasks_controller.rb
class TasksController < ApplicationController
  def move
    @task = Task.find(params[:id])

    # If you are using the acts_as_list gem, it is this simple:
    @task.insert_at(params[:position].to_i)

    # We don't need to render a view, just tell JS it was successful
    head :ok
  end
end

Summary

That's pretty much it!

We pinned the library via Importmap.
We initialized SortableJS in a 10-line Stimulus controller.
We used a standard fetch request to update the position in the database.

No massive React setups, no JSON API wrappers, and absolutely zero Webpack configurations. Just plain HTML, a tiny bit of Javascript, and standard Rails routing. This is why the modern Hotwire stack is so incredibly fast for building features.

DEV Community: Zil Norvilis

How Turbo 8 Morphing Makes Rails Frontend Development Feel Like Magic

The Problem with Turbo Streams

What is Page Morphing?

STEP 1: Enabling Morphing

STEP 2: Simplifying the Controller

STEP 3: Real-Time Magic (broadcasts_refreshes)

Summary

How to Add a Visual Page Builder to Your Rails App in 10 Minutes

The Quickest Way to Build a Drag-and-Drop Landing Page Builder in Rails 8

STEP 1: The Database Setup

STEP 2: Loading GrapesJS

STEP 3: The Editor View

STEP 4: The Stimulus Controller (The Magic)

STEP 5: Rendering the Final Page

Summary

How I Built a Native Android App with Almost Zero Kotlin Experience

Turning a Rails App into an Android App: Testing Hotwire Native

The Foundation: Building the Rails App

The Magic: Enter Hotwire Native

STEP 1: The Android Project

STEP 2: Pointing to the Rails App

STEP 3: The Path Configuration

Why I Love This Approach

Making Sense of JavaScript in Rails: Webpack, Rollup, esbuild, and Importmaps

1. Webpack (The Heavyweight Dinosaur)

2. Rollup (The Library Builder)

3. esbuild (The Speed Demon)

4. Importmaps (The Rails Default / No-Build)

Summary: Which one should you pick?

How to Build a Custom Affiliate System in Ruby on Rails

STEP 1: The Database Setup

STEP 2: The User Model Associations

STEP 3: Tracking the Clicks (Cookies)

STEP 4: Applying the Referral on Signup

STEP 5: Creating the Affiliate Link

What about the Payouts?

It Looks Like Ruby, But It’s Not: How to Understand Elixir

1. Classes vs Modules

2. Method Chaining vs The Pipe Operator

3. Hashes vs Maps

4. The Equals Sign is a Lie (Pattern Matching)

Summary

Pundit vs CanCanCan vs Action Policy: Which Rails Auth Gem Wins?

1. CanCanCan (The Legacy Giant)

2. Pundit (The Object-Oriented Standard)

3. Action Policy (The Modern Speed Demon)

Summary: Which one should you pick?

Wise Testing: What to Test (and Ignore) as a Solo Rails Developer

RULE 1: What NOT to Test (The Time Wasters)

RULE 2: The "Golden Path" System Tests (High ROI)

RULE 3: Surgical Unit Tests (The Money and the Math)

RULE 4: Embrace Rails Fixtures (Skip FactoryBot)

Summary: The Wise Testing Checklist

Stop AI Spaghetti: Enforcing Rails Architecture in 2026

STEP 1: The Context File (.cursorrules)

STEP 2: Ruthless Linting with RuboCop

STEP 3: Enforcing Boundaries (Packwerk)

STEP 4: System Tests over Unit Tests

Summary

How to Fix N+1 Queries in Rails Like a Pro

The Problem: What is N+1?

LEVEL 1: The Basic Fix (includes)

LEVEL 2: Nested Includes (Going Deeper)

LEVEL 3: includes vs preload vs eager_load (The Pro Stuff)

LEVEL 4: Strict Loading (The Ultimate Safety Net)

Summary

Building a World-Class Search Engine in Rails with Searchkick

Stop Using SQL LIKE: A Step-by-Step Guide to Elasticsearch in Rails

STEP 1: The Setup

STEP 2: Tell Your Model to Listen

STEP 3: Index Your Existing Data

STEP 4: The Search Query

STEP 5: Customizing the Index (The Pro Move)

Summary

The Easiest Way to Add Drag and Drop to Your Rails App

Building Drag and Drop in Rails 8 with SortableJS and Importmaps

STEP 1: The Database Setup

STEP 2: Pin SortableJS (Importmap)

STEP 3: The HTML View

STEP 3: Real-Time Magic (`broadcasts_refreshes`)

STEP 1: The Context File (`.cursorrules`)

LEVEL 1: The Basic Fix (`includes`)