DEV Community: Zil Norvilis

Real-Time Engagement: Web Push Notifications in Rails 8

Zil Norvilis — Tue, 23 Jun 2026 18:27:06 +0000

For a long time, if you wanted to send a "Push Notification" to a user’s phone or laptop, you needed a native mobile app. For solo developers, this was a huge barrier. We had to rely on emails that nobody reads or expensive SMS services.

In 2026, the Web Push API is supported by almost every browser, including Safari on iOS. This means you can send native-style alerts directly from your Rails app to your user's device without them ever downloading anything from an App Store.

It sounds complex because it involves Service Workers and Cryptography, but with the right gems, it is actually very manageable. Here is how to set up Web Push in Rails 8.

The Mental Model: How Web Push Works

Subscription: The user clicks "Allow" in their browser. The browser gives us a "Subscription" object (a URL and some secret keys).
Storage: We save that object in our database, linked to the User.
The Push: When an event happens, our Rails server signs a message and sends it to the browser's "Push Service" (Google, Apple, or Mozilla).
Delivery: The Service Worker on the user's device wakes up and shows the notification.

STEP 1: The VAPID Keys

To send secure notifications, you need a pair of VAPID keys (Public and Private). These identify your server so that the browser knows the notification isn't from a hacker.

Add the gem to your Gemfile:

gem "web-push"

Run this in your terminal to generate your keys:

# Generate keys
web-push generate-vapid-keys

Copy these keys into your .kamal/secrets or your credentials file.

STEP 2: The Database Setup

We need to store the subscription for each user. A user might have multiple subscriptions (one for their phone, one for their laptop).

rails g model WebPushSubscription user:references endpoint:string p256dh_key:string auth_key:string
rails db:migrate

STEP 3: The Service Worker (Javascript)

Service Workers must live in the public/ folder to have access to the whole site. Create a file at public/service-worker.js. This file listens for the "push" event even when your website is closed.

// public/service-worker.js
self.addEventListener("push", (event) => {
  const data = event.data.json();

  event.waitUntil(
    self.registration.showNotification(data.title, {
      body: data.body,
      icon: "/logo.png"
    })
  );
});

Now, register this worker in your app/javascript/application.js:

if ("serviceWorker" in navigator) {
  navigator.serviceWorker.register("/service-worker.js");
}

STEP 4: Creating the Subscription

We need a Stimulus controller to ask the user for permission and send the subscription to Rails.

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

export default class extends Controller {
  async subscribe() {
    const registration = await navigator.serviceWorker.ready;

    const subscription = await registration.pushManager.subscribe({
      userVisibleOnly: true,
      applicationServerKey: "YOUR_PUBLIC_VAPID_KEY"
    });

    // Send this JSON to your Rails controller
    await fetch("/web_push_subscriptions", {
      method: "POST",
      headers: { "Content-Type": "application/json", "X-CSRF-Token": document.querySelector("[name='csrf-token']").content },
      body: JSON.stringify(subscription)
    });

    alert("Subscribed!");
  }
}

STEP 5: Sending the Notification (The Ruby Part)

Finally, we send the notification from a background job so we don't slow down the app.

# app/jobs/send_web_push_job.rb
class SendWebPushJob < ApplicationJob
  queue_as :default

  def perform(user_id, title, body)
    user = User.find(user_id)

    user.web_push_subscriptions.each do |sub|
      Webpush.payload_send(
        message: { title: title, body: body }.to_json,
        endpoint: sub.endpoint,
        p256dh: sub.p256dh_key,
        auth: sub.auth_key,
        vapid: {
          subject: "mailto:admin@example.com",
          public_key: ENV["VAPID_PUBLIC_KEY"],
          private_key: ENV["VAPID_PRIVATE_KEY"]
        }
      )
    rescue Webpush::InvalidSubscription # If user revoked permission
      sub.destroy
    end
  end
end

Summary

Web Push is the "Pro" way to bring users back to your app.

VAPID keys handle the security.
Service Workers handle the delivery while the user is away.
Solid Queue handles the background sending.

As a solo developer, you can now build an app that feels like a native mobile experience using nothing but Rails and a tiny bit of Javascript.

The Budget-Friendly Monolith: Rails File Uploads with Cloudflare R2

Zil Norvilis — Sun, 21 Jun 2026 18:13:36 +0000

If you have been using AWS S3 for your Rails file uploads, you know the pain of the monthly bill. It’s not just the storage cost; it’s the Egress Fees. Every time a user downloads a file or views an image, AWS charges you for the data leaving their servers.

For a solo developer or a small startup, these "hidden" fees can grow very fast.

In 2026, the best alternative is Cloudflare R2. It is an object storage service that is 100% compatible with the S3 API, but with one massive advantage: Zero Egress Fees. You only pay for the space you use.

Because it uses the S3 API, setting it up with Rails ActiveStorage is incredibly easy. Here is how to do it in 4 steps.

STEP 1: The Credentials

First, log into your Cloudflare dashboard and create a new R2 Bucket.

Once the bucket is created, you need to generate "API Tokens."

Go to R2 > Manage R2 API Tokens.
Create a new token with Edit permissions.
Save your Access Key ID, Secret Access Key, and the Jurisdiction-specific endpoint.

The endpoint will look something like this:
https://<account_id>.r2.cloudflorage.com

STEP 2: The Gems

Even though we are using Cloudflare, we still use the official AWS S3 gem because Cloudflare built R2 to be a "drop-in" replacement.

Add this to your Gemfile:

gem "aws-sdk-s3", require: false

Run bundle install.

STEP 3: Configuration (`storage.yml`)

Now we need to tell Rails how to talk to the R2 bucket. Open your config/storage.yml and add a new section for Cloudflare.

# config/storage.yml
cloudflare:
  service: S3
  access_key_id: <%= ENV['CLOUDFLARE_R2_ACCESS_KEY_ID'] %>
  secret_access_key: <%= ENV['CLOUDFLARE_R2_SECRET_ACCESS_KEY'] %>
  region: auto # R2 handles regions automatically
  bucket: my-app-uploads
  # This is the endpoint you got from Step 1
  endpoint: https://<account_id>.r2.cloudflarestorage.com
  force_path_style: true

Note: Make sure to add those ENV variables to your .kamal/secrets or your production server!

STEP 4: Tell Rails to use R2

Finally, update your production environment to use the new service.

# config/environments/production.rb
config.active_storage.service = :cloudflare

Bonus: Enabling Direct Uploads (CORS)

In a previous article, I talked about Direct Uploads to save your server from freezing. If you want to use Direct Uploads with R2, you must configure CORS (Cross-Origin Resource Sharing).

Cloudflare makes this easy. Go to your Bucket settings in the dashboard and paste this JSON into the CORS section:

[
  {
    "AllowedOrigins": ["https://yourdomain.com"],
    "AllowedMethods": ["GET", "PUT", "POST"],
    "AllowedHeaders": ["*"],
    "ExposeHeaders": ["Content-Type", "ETag"]
  }
]

This tells Cloudflare: "It is safe to let users from my website upload files directly to this bucket."

Summary

Switching from AWS S3 to Cloudflare R2 is one of the smartest "business" moves a solo developer can make.

Compatibility: You don't have to change your Ruby code.
Predictability: No more surprise bills because an image went viral.
Simplicity: One less AWS console to navigate.

By combining Rails 8, Kamal 2, and Cloudflare R2, you are building a production stack that is fast, secure, and incredibly cheap to run.

Pro File Uploads in Rails 8: Speed and Scalability with Direct Uploads

Zil Norvilis — Fri, 19 Jun 2026 18:28:00 +0000

Imagine a user trying to upload a 100MB video or a high-resolution photo to your app. If you use the standard Rails file upload, that file travels from the user's browser to your Rails server, and then your server sends it to S3 or Google Cloud.

This is a terrible way to do it. While that 100MB file is transferring, your Rails worker (Puma) is frozen. It can't handle other users. If three people upload large files at once, your whole app will stop responding.

In 2026, the professional way to handle this is Direct Uploads.

With Direct Uploads, the file goes directly from the user's browser to your cloud storage (S3, R2, etc.). Your Rails server only handles a tiny bit of metadata. It is faster for the user and much safer for your server. Here is how to set it up in Rails 8.

STEP 1: Configure Your Storage

First, make sure you aren't using the local disk for production. You need a cloud provider like AWS S3 or Cloudflare R2.

In your config/storage.yml:

amazon:
  service: S3
  access_key_id: <%= ENV['AWS_ACCESS_KEY_ID'] %>
  secret_access_key: <%= ENV['AWS_SECRET_ACCESS_KEY'] %>
  region: us-east-1
  bucket: my-app-uploads
  # Crucial for Direct Uploads!
  public: true

Note: You must configure CORS in your S3/R2 dashboard to allow requests from your domain. If you don't do this, the browser will block the upload.

STEP 2: The Rails Form

Rails makes the backend part incredibly easy. You just add one attribute to your file field: direct_upload: true.

<!-- app/views/users/_form.html.erb -->
<%= form_with(model: user) do |f| %>
  <div class="field">
    <%= f.label :avatar %>
    <%= f.file_field :avatar, direct_upload: true %>
  </div>

  <%= f.submit "Save Profile" %>
<% end %>

When you add direct_upload: true, Rails automatically includes a JavaScript library that handles the "handshake" with S3.

STEP 3: Adding a Progress Bar (The UX Win)

Direct uploads can take a few seconds. If nothing happens on the screen, the user will think your app is broken. We can use the built-in ActiveStorage events to show a beautiful progress bar.

First, add a small piece of HTML to your form:

<div class="upload-progress hidden" id="progress-bar">
  <div class="bg-blue-600 h-2 transition-all" id="progress-fill" style="width: 0%"></div>
</div>

Now, we create a tiny Stimulus controller to watch the upload progress.

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

export default class extends Controller {
  connect() {
    this.element.addEventListener("direct-upload:progress", event => {
      const { progress } = event.detail
      const bar = document.getElementById("progress-fill")
      const container = document.getElementById("progress-bar")

      container.classList.remove("hidden")
      bar.style.width = `${progress}%`
    })

    this.element.addEventListener("direct-upload:error", event => {
      alert("Upload failed! Please check your connection.")
    })
  }
}

Attach this to your form: <%= form_with(model: user, data: { controller: "upload" }) do |f| %>.

STEP 4: Why this is the "One-Person" Superpower

As a solo developer, you want to avoid "Scaling Issues" as long as possible.

The traditional upload method requires you to have a large server with lots of RAM to handle big file streams. If your app goes viral, you’ll have to pay for a massive server just to move files around.

By using Direct Uploads:

Cost: You can stay on a tiny $5 VPS because S3 does 99% of the work.
Speed: Users see a progress bar immediately.
Reliability: If your server restarts in the middle of an upload, the upload doesn't necessarily fail because it’s not talking to your server!

Summary

Don't let file uploads slow down your monolith. It takes 5 minutes to switch to Direct Uploads, but it makes your app feel like an enterprise product.

Use Cloud Storage (S3/R2).
Enable CORS on your bucket.
Add direct_upload: true to your form.
Add a Stimulus progress bar for that "premium" feel.

Your Puma threads will thank you, and your users will love the snappy experience.

Zero-JS Search: Building a Live-Filter with Turbo 8 Page Morphing

Zil Norvilis — Thu, 18 Jun 2026 18:15:43 +0000

I’ve lost count of the number of hours I’ve spent in the past building "Live Search" features.

In the old days, you had to write custom AJAX listeners, handle the "white flash" of reloads, and manually manage the browser's history. Later, with Turbo 7, we used Turbo Frames, but that meant wrapping everything in specific tags and losing the "state" of the rest of the page.

In 2026, the game has changed. With Turbo 8 Page Morphing, we can build a live-filtering search bar that feels like a heavy React app, but uses 100% standard Rails controllers and almost zero custom JavaScript.

The secret is that Turbo 8 can "morph" the page - it refreshes the HTML but keeps your scroll position and the focus inside the search input perfectly intact. Here is how to build it in 3 steps.

STEP 1: Enable Morphing

First, we need to tell our application that we want to use the new Morphing behavior instead of the old "Replace" behavior.

Open your main application layout and add these two tags to the <head>.

<!-- app/views/layouts/application.html.erb -->
<head>
  <!-- ... -->
  <%= turbo_refreshes_with method: :morph, scroll: :preserve %>
  <%= yield :head %>
</head>

STEP 2: The Search Form and Controller

We are going to use a standard HTML form. No remote: true, no complex setups. Just a simple GET request.

# app/controllers/products_controller.rb
class ProductsController < ApplicationController
  def index
    @products = Product.all

    if params[:query].present?
      @products = @products.where("name ILIKE ?", "%#{params[:query]}%")
    end
  end
end

In your view, create the search bar. The "trick" here is that we want the form to submit as the user types. Since HTML doesn't do this natively, we use a tiny 2-line Stimulus controller that I keep in every project as a "utility" tool.

<!-- app/views/products/index.html.erb -->
<div class="p-8">
  <div data-controller="autosave">
    <%= form_with url: products_path, method: :get, 
                  data: { autosave_target: "form", turbo_frame: "_top" } do |f| %>

      <%= f.text_field :query, 
            placeholder: "Search products...", 
            value: params[:query],
            data: { action: "input->autosave#save" },
            class: "border-2 border-black p-2 w-full" %>
    <% end %>
  </div>

  <div id="products_list" class="mt-8 grid grid-cols-3 gap-4">
    <%= render @products %>
  </div>
</div>

STEP 3: The Utility Controller (The only JS you need)

This is the only JavaScript we need. It is a reusable "autosave" controller that simply submits the form whenever you type.

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

export default class extends Controller {
  static targets = ["form"]

  save() {
    // This triggers the standard Rails form submission
    this.formTarget.requestSubmit()
  }
}

How it works (The Magic)

In the old days, calling requestSubmit() as you typed would be a disaster. The page would reload, you would lose focus on the text box, and the cursor would jump to the beginning of the line.

With Turbo 8 Morphing:

You type the letter "A".
Stimulus tells the form to submit.
Rails returns the entire index page with only the "A" products.
Turbo 8 compares the new HTML to the current page.
It sees that the text input is the same, so it leaves it alone (preserving your cursor and focus).
It sees the product list has changed, so it morphs those elements seamlessly.

The user perceives a lightning-fast, reactive live filter, but you are just writing standard, boring Rails code.

Summary

As a solo developer, your goal is to stay out of "JavaScript Land" as much as possible. By leveraging Turbo 8 Page Morphing:

No JSON APIs: You don't need to build a search endpoint.
No Manual DOM Updates: You don't have to write code to append or remove items.
No Focus Issues: Browsers handle the state of the input automatically.

This is the "One-Person Framework" at its best: high-end features with zero-maintenance code.

Datastar in Rails 8: Real-Time UI Without the WebSocket Headache

Zil Norvilis — Wed, 17 Jun 2026 18:28:00 +0000

I am a huge fan of Hotwire. It’s what allowed me to stop writing massive React apps and go back to enjoying Ruby. But recently, a new player has entered the "Hypermedia" world that every Rails developer should keep an eye on: Datastar.

If you think of HTMX as the "venerable grandfather" and Hotwire as the "official Omakase choice," then Datastar is the "high-performance specialist."

The biggest difference? While Hotwire uses WebSockets (ActionCable) for real-time updates, Datastar uses Server-Sent Events (SSE) by default. It is incredibly lightweight (only 13kb), requires zero dependencies, and makes fine-grained reactivity feel like magic.

Here is how to get Datastar running in your Rails 8 app in 4 easy steps.

The Concept: What makes Datastar different?

In Hotwire, when you want real-time updates, you have to set up a WebSocket connection. WebSockets are powerful, but they are "stateful" - they keep a heavy connection open.

Datastar uses SSE. This is a standard HTTP connection that stays open just to "stream" data from the server to the browser. It’s much easier to scale, easier to debug in your Network tab, and it feels faster because it uses a technology called "Signals" (like Solid.js or Preact) to update only the tiny parts of the page that changed.

STEP 1: Installation (The No-Build Way)

Since we are on Rails 8, we don't want node_modules. We just pin the library using Importmaps.

bin/importmap pin @starfederation/datastar

Then, in your app/javascript/application.js, just import it to initialize the global listeners:

import "@starfederation/datastar"

STEP 2: The Frontend "Signal"

Datastar uses attributes that look a lot like Alpine.js or Vue. Let’s build a simple counter that updates on the server.

<!-- app/views/counters/show.html.erb -->
<div data-signals="{count: 0}">
  <h2 data-text="$count">0</h2>

  <button data-on-click="@post('/increment')">
    Increment on Server
  </button>
</div>

What is happening here?

data-signals: This is a tiny piece of client-side memory.
data-text: This binds the header text to that memory.
data-on-click: This sends a POST request to our Rails controller.

STEP 3: The Rails Controller (Streaming SSE)

This is where the magic happens. We aren't returning a regular HTML page or a Turbo Stream. We are returning a Datastar SSE stream.

You’ll want to add a tiny helper or a gem like datastar-rails to handle the formatting, but here is what the raw response looks like:

# app/controllers/counters_controller.rb
class CountersController < ApplicationController
  include ActionController::Live # Allows us to keep the connection open

  def increment
    # 1. Update your logic
    new_count = params[:count].to_i + 1

    # 2. Set the correct header for SSE
    response.headers['Content-Type'] = 'text/event-stream'

    # 3. Send the Datastar "Fragment"
    # This tells Datastar to update the 'count' signal on the client
    response.stream.write "event: datastar-merge-signals\ndata: signals {count: #{new_count}}\n\n"
  ensure
    response.stream.close
  end
end

STEP 4: The Real-Time Win

Because Datastar is built on SSE, you can keep the connection open and "push" updates as many times as you want.

Imagine a background job is processing an image. You can keep the increment method open and send:

data: signals {status: 'Processing...'}
Wait 2 seconds...
data: signals {status: 'Done!', progress: 100}

The browser will update the UI every time a new line is sent from Ruby, without the user ever clicking anything again.

Why try this over Hotwire?

Fine-grained control: You can update individual variables (Signals) inside an HTML element without re-rendering the whole element.
No WebSocket Overhead: SSE is just plain HTTP. It works perfectly with standard load balancers and doesn't require "Sticky Sessions" or complex Redis setups (though Rails 8 Solid Cable helps with that!).
Client-side logic: You get a little bit of client-side state (data-signals) for things like toggling menus or form validation without needing to write a full Stimulus controller.

Summary

Datastar is perfect for the "Pragmatic Solo Developer" who wants real-time features but finds ActionCable or heavy JS frameworks a bit too much.

It keeps the logic in Ruby, uses the browser's native streaming capabilities, and results in a UI that feels incredibly snappy. If you are starting a new project this weekend, give Datastar a look—it might just become your new favorite tool in the hypermedia stack.

Go for Rubyists: A Practical Guide to Learning Golang

Zil Norvilis — Tue, 16 Jun 2026 18:05:10 +0000

I love Ruby. It is the language that made me happy to write code. But as a Rails developer, I eventually hit a wall. Maybe I needed to process a 2GB CSV file, or build a real-time notification service that handles 10,000 connections.

In those moments, Ruby can feel a bit slow or memory-heavy. This is why many Rails developers (including the team at Basecamp) have started using Go (Golang) for high-performance side-services.

If you are a Ruby developer, Go will feel very different. It has no "magic," it is strictly typed, and it is incredibly fast. Here is my guide on how to learn Go without losing your mind.

1. The Big Shift: No More Magic

In Rails, we are used to "magic." You type User.find(1) and it just works. You don't see the SQL, you don't see the imports, and you don't worry about types.

Go is the opposite. There is zero magic.

If you use a variable, you must define its type.
If you import a library and don't use it, the code won't even compile.
Everything is explicit.

At first, this is very annoying. You will feel like you are typing too much. But after a week, you realize that because there is no magic, you can read any Go file and know exactly what it does.

2. Syntax Translation

Let's look at a simple function comparison.

Ruby:

def greet(name)
  "Hello, #{name}!"
end

puts greet("Zil")

Go:

package main

import "fmt"

// We must say name is a string, and the function returns a string
func greet(name string) string {
    return "Hello, " + name + "!"
}

func main() {
    fmt.Println(greet("Zil"))
}

Notice the package main and import. Every Go file needs these. Also, notice the curly braces {}. As a Rubyist, you'll miss do...end at first, but you'll get used to it.

3. Dealing with Errors (The "if err != nil" loop)

In Ruby, we use begin...rescue to handle errors. Or we just let the app crash and check the logs.

In Go, errors are not "exceptions." They are just values that functions return. You will see this pattern in every single Go project:

user, err := findUser(1)

if err != nil {
    // Something went wrong, handle it here
    return err
}

// If no error, continue
fmt.Println(user.Name)

It feels repetitive to write this 50 times a day, but it means your app almost never crashes in production because you are forced to handle every single edge case while you type.

4. The Killer Feature: Goroutines

This is the main reason to learn Go. In Ruby, if you want to do 10 things at once, you need Sidekiq and Redis.

In Go, you have Goroutines. You just put the word go in front of a function call, and it runs in the background on a different CPU thread instantly.

func sendEmail(email string) {
    // slow logic
}

func main() {
    // This runs in the background. No Redis needed!
    go sendEmail("test@example.com") 

    fmt.Println("Moving on...")
}

It is incredibly lightweight. You can run 100,000 goroutines on a cheap $5 laptop.

5. Deployment: The Single Binary

As someone who loves Kamal and Docker, Go is a dream for deployment.

When you build a Go app, it compiles into one single file (a binary). This file contains your code and all your libraries. You don't need to install Ruby, Bundler, or Node on your server. You just move that one file to the server and run it. It makes Docker images tiny and deployments incredibly fast.

Summary: Should you switch?

I don't recommend replacing Rails with Go for your main web app. Rails is still much faster for building UIs and CRUD logic.

Instead, use Go as a tool in your belt.

Use Rails for the main app.
Use Go for that one specific microservice that needs to be blazing fast or handle massive amounts of data.

Learning Go will make you a more disciplined developer. It teaches you to think about memory, types, and how the computer actually works.

Is Coding Over? 5 Career Pivots for Rails Devs in the AI Era

Zil Norvilis — Thu, 11 Jun 2026 18:05:29 +0000

If you spend any time on Tech Twitter lately, you might feel like the sky is falling. People are saying that "coding is dead" and that AI will replace every developer by 2027.

I don't think coding is dead, but I do think the Job of the Coder is changing.

The era of being paid $100k a year just to know the syntax of has_many :through is coming to an end. AI can write syntax better and faster than you. But Rails developers have a unique advantage: we are usually Product Engineers. We know how to build entire systems, not just small functions.

If you are worried about AI taking over and want to pivot your career into something more "future-proof," here are the 5 best paths for a Rails developer in 2026.

1. The AI Orchestrator (AI Engineer)

This is the most natural pivot. You aren't leaving Rails; you are just changing what you do with it. Instead of writing CRUD logic, you spend your time building Agentic Workflows.

You become the person who connects the Rails monolith to OpenAI, Anthropic, and local LLMs. You design the RAG (Retrieval-Augmented Generation) pipelines and the "verification loops" that ensure the AI doesn't hallucinate.

Why it’s safe: AI models are powerful, but they are "brains in a jar." They need an engineer to give them hands and feet (APIs, Databases, and Logic) to actually do useful work.

2. The Solution Architect

In a world where AI can generate 1,000 lines of code in a second, the world is about to be flooded with terrible, messy code.

Companies will be desperate for "Architects" - people who can look at the big picture and say: "Wait, we shouldn't use a microservice here just because the AI suggested it. We need a Majestic Monolith to keep our data consistent."

Why it’s safe: AI is a great bricklayer, but it’s a terrible city planner. It doesn't understand long-term maintenance, technical debt, or business constraints.

3. The Technical Product Manager (PM)

As a Rails dev, you already understand how a database works, how a checkout flow works, and how long a feature actually takes to build.

If you have good "people skills," moving into Product Management is a huge win. You become the person who defines what to build, while the AI (managed by a junior dev) does the actual typing.

Why it’s safe: AI doesn't have "Taste." It doesn't know what users find annoying or what feature will actually make the company money. Empathy and market intuition cannot be automated.

4. The Solopreneur / Indie Hacker

This is my favorite path. If AI makes development 10x faster and 10x cheaper, the biggest winner is the Solo Developer.

In the past, you needed a team of 5 to launch a serious SaaS. Today, you can use Rails 8 and Cursor to build, test, and deploy a profitable product by yourself in a month.

Why it’s safe: You stop being an "expense" on someone else's balance sheet and start being the owner of the assets. AI becomes your free labor force, allowing you to compete with big companies.

5. Cybersecurity and Compliance

AI is going to make it easier for hackers to find bugs in software. As more code is generated autonomously, the "attack surface" of every company is going to explode.

Moving into security - specifically specialized Rails security or GDPR/Data Privacy compliance - is a very high-paying niche.

Why it’s safe: Trust is the one thing AI cannot generate. A company will always want a human being to be responsible for ensuring their customer data is safe and their servers are locked down.

Summary: Don't Panic, Adapt

If you are a Rails developer today, you are in a great position. You already think in "Systems."

Stop focusing on being a faster typer.
Start focusing on Architecture, Product Vision, and AI Orchestration.
Learn how to manage AI agents like you would manage a team of junior developers.

The "Junior Developer" role is the one most at risk. If you can move up the chain and become the Editor-in-Chief or the Product Owner, AI won't replace you - it will make you rich.

Demystifying Rails Magic: How Autoloading Actually Works

Zil Norvilis — Wed, 10 Jun 2026 18:09:35 +0000

I remember when I first started learning Ruby outside of Rails. I was building a small script, and my code kept crashing with NameError: uninitialized constant. I was so confused because I knew the file existed. I realized that in plain Ruby, you have to manually add require './user' at the top of every single file.

In Rails, you never do this. You just type User.first or OrderService.new and it "just works." People often call this "Rails Magic," but it isn't magic at all. It is a very structured system called Zeitwerk.

Understanding how this works will help you stop fighting the file system and start using the framework properly. Here is the breakdown of how Rails manages to "auto-import" your code.

Level 1: The Convention (Snake Case to CamelCase)

The core of the magic is a very strict naming rule. Rails assumes that your file names match your class names perfectly.

If your class is User, the file must be user.rb.
If your class is UserCredential, the file must be user_credential.rb.
If your class is inside a folder like app/services/billing/payout_manager.rb, the class name must be Billing::PayoutManager.

If you break this rule - for example, naming your file payouts.rb but naming the class PayoutManager - Rails will crash. It uses these names to find the files on your hard drive.

Level 2: The Engine (Zeitwerk)

Since Rails 6, the engine that handles this is called Zeitwerk.

When your Rails app starts up, Zeitwerk scans all the folders inside app/ (models, controllers, jobs, etc.). It builds a map of all the files.

When you type User in your code, Ruby looks at its own memory and says: "I don't know what 'User' is." Normally, this would trigger an error. But Zeitwerk intercepts that error and says: "Wait! I know where that is. Based on the name 'User', it should be in app/models/user.rb."

Zeitwerk then runs a hidden require for that file, loads the class into memory, and your code continues running as if the class was always there.

Level 3: Why This is Different from Elixir

In Elixir, you don't have "autoloading" in the same way. Elixir is a compiled language. When you start a Phoenix app, the compiler reads all your modules and links them together before the app even starts.

In Rails, everything is dynamic. Classes can be loaded, deleted, and reloaded while the app is running. This leads us to the most useful feature for solo developers: Reloading.

Level 4: Hot Reloading in Development

It is very annoying to restart your server every time you change a line of code. Because Rails uses Zeitwerk for autoloading, it can also do "autounloading."

In development mode, Zeitwerk watches your files. When you save user.rb, Zeitwerk wipes the User class from Ruby's memory. The next time a request comes in, Zeitwerk sees that User is missing, finds the updated file, and loads it again.

This is why you can edit a Rails app and see the changes instantly in the browser.

Level 5: When the Magic Fails

Even the best magic has limits. You will usually run into "Autoloading Errors" in two cases:

The lib/ folder: By default, Rails does NOT autoload files in the lib/ directory. If you put a class there, you still have to use require. (Most devs fix this by adding lib to the config.autoload_paths in application.rb).
Initializers: Files in config/initializers only run once when the server starts. If you change a file there, you must restart the server.

Summary

Rails "magic" is just a very smart agreement between you and the framework.

Strict Naming: Name your files snake_case and your classes CamelCase.
Zeitwerk: The engine that handles the loading so you don't have to write require.
Efficiency: Only the code you actually use gets loaded into memory.

Once you respect the naming conventions, the magic stays out of your way and lets you focus on building features.

Stripe-Style IDs in Rails: A Guide to the custom_id Gem

Zil Norvilis — Tue, 09 Jun 2026 18:16:16 +0000

If you have ever used the Stripe API, you’ve noticed their IDs look awesome. Instead of a random number or a long, confusing UUID, they look like this: cus_M1p7abc123 or ch_3Oixyz456.

These are called Prefixed IDs. They are great for two reasons:

Context: When you see inv_... in your logs, you immediately know it’s an Invoice without looking at the table name.
Security: It hides your business volume. Hackers can't guess that your next user is ID 501.

In the past, setting this up in Rails required a lot of custom code in your models. But recently, I found a gem that makes this process incredibly simple: custom_id.

Here is how to implement professional, Stripe-style IDs in your Rails 8 app in 4 steps.

STEP 1: Install the Gem

Add the gem to your Gemfile:

gem "custom_id"

Run in your terminal

bundle install
rails custom_id:install

STEP 2: The Migration

Just like with ULIDs or Snowflake IDs, we need to tell the database that our primary key is a string and not an integer.

rails g model Project name:string

Open the migration file and disable the automatic ID:

# db/migrate/XXXXXXXXXXXXXX_create_projects.rb
class CreateProjects < ActiveRecord::Migration[8.0]
  def change
    create_table :projects, id: false do |t|
      # We use string for the prefixed ID
      t.string :id, primary_key: true
      t.string :name
      t.timestamps
    end
  end
end

STEP 3: Configure the Model

This is where the gem shines. You just use the custom_id macro. You tell it what prefix you want to use, and it handles the rest.

# app/models/project.rb
class Project < ApplicationRecord
  # This tells the gem to generate an ID starting with 'prj_'
  cid "usr"
end

By default, the gem uses a collision-resistant loop with database uniqueness check.

STEP 4: Seeing it in Action

Open your Rails console (bin/rails c) and create a project:

project = Project.create(name: "Cloud Empire")

puts project.id
# => "prj_7k2n9zp1m5r8"

It looks professional, it’s easy to read in your logs, and it’s perfectly unique.

Advanced: Customizing your IDs

The custom_id gem is very flexible. You can change the length of the random part if you have a massive amount of data and want to avoid collisions.

class User < ApplicationRecord
  # Use a 3-letter prefix and a longer 20-character random string
  cid :usr, size: 32
end

Why I prefer this over UUIDs?

I love UUIDs for their uniqueness, but I hate how they look in URLs.
/users/550e8400-e29b-41d4-a716-446655440000 is ugly and hard to double-click and copy.

/users/usr_7k2n9zp1m5r8 is clean, tells me exactly what the object is, and fits perfectly in a mobile app UI or a support email.

Summary

The custom_id gem is a "Quality of Life" improvement for Rails developers. It takes an enterprise-level feature (Prefixed IDs) and turns it into a one-line setup.

Install the gem.
Set your primary key to string.
Add cid 'prefix' to your model.

It’s a tiny change that makes your Rails monolith feel significantly more polished and "pro."

Rapid UI Development: Top 4 Component Kits for Solo Rails Devs

Zil Norvilis — Mon, 08 Jun 2026 18:10:29 +0000

I remember the days when building a professional-looking dashboard in Rails meant spending a whole week wrestling with CSS flexbox and custom SVG icons. You’d get the backend working in an hour, but the frontend would take forever.

In 2026, the "One-Person Framework" philosophy has finally fixed this. We now have high-quality, pre-built component libraries that give us a "premium" look instantly.

Instead of building a "Modal" or a "DataTable" from scratch, you just install a library and render a component. Here are the top pre-built libraries you should use to ship your next Rails 8 project in record time.

1. Shadcn Rails (The Solo Developer's Favorite)

If you have been watching the React world, you know that Shadcn is the biggest thing in design. It’s famous because you don't "install" it as a black-box library; you copy-paste the code into your project so you have 100% control.

The Rails community now has Shadcn Rails, and it is amazing.

Why it works:
It uses ViewComponent and Tailwind CSS. When you add a component, it generates a Ruby class and an ERB file in your app/components folder.

The Workflow:

You find a component (like a Command Palette or a Calendar) on their site.
You run a simple command to "add" it to your app.
You use it in your view: <%= render UI::Button.new { "Save" } %>.

Because the code is now yours, you can easily tweak the Tailwind classes to match your brand without fighting a gem's internal CSS.

2. Polaris ViewComponents (The Enterprise Choice)

If you want your app to feel as solid and reliable as Shopify, you should use Polaris ViewComponents.

Polaris is the official design system for Shopify. Since Shopify is built on Rails, their component library is one of the most battle-tested in the world.

Why it works:
It is extremely high-quality. It handles accessibility (A11y), keyboard navigation, and complex states perfectly. If you are building a B2B SaaS or a complex internal tool, this is the "No-Brainer" choice.

The Catch:
Your app will look a lot like the Shopify admin. If you want a unique, "funky" startup look, you might find Polaris a bit too "corporate."

3. PhlexUI (The Speed King)

If you have moved away from ERB and are using Phlex (the pure Ruby view engine), then PhlexUI is your best friend.

Why it works:
It is built specifically for the Phlex ecosystem. Because there are no HTML templates to parse, it is incredibly fast. The components are beautifully designed using Tailwind and are very easy to customize because they are just plain Ruby classes.

The Workflow:

render PhlexUI::Card.new do
  render PhlexUI::Card::Header.new do
    render PhlexUI::Typography::H3.new { "Revenue" }
  end
  render PhlexUI::Card::Content.new do
    render PhlexUI::Typography::P.new { "$12,400" }
  end
end

It feels like writing a script rather than writing a webpage. For a solo dev, the "Flow State" you get from staying in pure Ruby is a huge productivity boost.

4. Flowbite / DaisyUI (The "Light" Alternative)

Sometimes, a full ViewComponent library is overkill. You might just want some pre-styled Tailwind classes. In that case, Flowbite or DaisyUI are great.

They don't give you Ruby classes. Instead, they give you a set of "standard" HTML structures and Tailwind classes that make things like tooltips and accordions work using the native popover and details HTML tags.

The Workflow:
You copy a snippet of HTML from their docs and paste it into your Rails view. It’s the fastest way to get a single component, but it’s harder to maintain than a structured library like Shadcn Rails.

Summary: Which one should you pick?

Choose Shadcn Rails if you want a modern "Linear/Vercel" look and want total control over the code.
Choose Polaris if you are building an enterprise tool where reliability and accessibility are more important than a unique brand.
Choose PhlexUI if you are already using Phlex and want the fastest possible development experience.

That's pretty much it. Stop spending your time on CSS gradients. Pick a library, snap the components together, and get back to building the features that actually make you money.

ViewComponent vs. Phlex: Which Ruby UI Library Should You Choose?

Zil Norvilis — Sun, 07 Jun 2026 18:13:28 +0000

I remember when my app/views folder was a complete disaster. I had deeply nested partials, instance variables floating everywhere, and logic hidden inside HTML tags. If I wanted to change the color of a button, I had to search through 50 different files.

In 2026, we don't build Rails apps like that anymore. We use Components.

Components allow you to treat your UI like Lego blocks. You build a "Button" once, and you reuse it everywhere. It makes your code cleaner, easier to test, and much faster to write.

Here are the best Rails component libraries you should be using today to keep your monolith organized.

1. ViewComponent (The Gold Standard)

Created by the team at GitHub, ViewComponent is the most popular choice. It turns your views into Ruby objects.

Why I like it:
Instead of a "dumb" partial, you get a Ruby class and an HTML file. You can pass data into the class, and Ruby will yell at you if you forget a required parameter. It makes your UI "Type Safe."

# app/components/button_component.rb
class ButtonComponent < ViewComponent::Base
  def initialize(title:, url:)
    @title = title
    @url = url
  end
end

<!-- app/components/button_component.html.erb -->
<%= link_to @title, @url, class: "bg-blue-500 text-white p-2 rounded" %>

The best part? You can Unit Test your UI. You don't need a slow browser test just to see if a button has the right text. You can test it in milliseconds using standard Minitest.

2. Phlex (The Speed Demon)

If you hate context-switching between Ruby and ERB, you will love Phlex.

Phlex is a new challenger that is taking the Rails world by storm. It doesn't use .html.erb files at all. You write your HTML in Pure Ruby.

# app/components/card.rb
class Card < Phlex::HTML
  def template
    div(class: "p-4 border rounded shadow") do
      h1 { "Hello from Phlex" }
      p { "This is 10x faster than ERB." }
    end
  end
end

Why I like it:

Performance: It is significantly faster than rendering ERB templates.
No context switching: You stay in Ruby land. You can use standard Ruby loops, conditions, and methods without the messy <% %> tags.
High ROI: For a solo developer, Phlex makes building complex UI kits feel like writing a normal script.

3. Lookbook (The Designer's Secret)

If you are using ViewComponent or Phlex, Lookbook is a mandatory tool.

Think of it as a "Storybook" but for Rails. It creates a private dashboard in your development environment where you can see every component you've built.

How to use it:

Install the gem.
Mount the engine in your routes.rb.
Visit /lookbook.

You can now click through your buttons, modals, and navigation bars to see how they look with different data. It is the best way to maintain a consistent design system without getting lost in your own code.

4. Tailwind-Stimulus-Components

Components aren't just about HTML; they are also about Behavior.

If you use Tailwind CSS (which you should), you don't want to write custom JavaScript for every single dropdown or modal. This library gives you pre-written Stimulus controllers that handle the "boring" stuff.

Instead of writing a "modal-open" script, you just add a data attribute:

<div data-controller="modal">
  <button data-action="click->modal#open">Open</button>
  <div data-modal-target="container" class="hidden">
     <!-- Modal Content -->
  </div>
</div>

It is a perfect match for the "One-Person Framework" philosophy: use standard, battle-tested behavior so you can focus on the business logic.

Summary: Which one should you pick?

If you are a solo developer trying to choose a stack today, here is my recommendation:

Choose ViewComponent if you want the safest, most documented option. It is used by GitHub and Shopify, so it isn't going anywhere.
Choose Phlex if you are a Ruby purist who wants the absolute maximum speed and hates ERB syntax.
Always use Lookbook to keep yourself organized.

Moving from partials to components is the single biggest "Level Up" you can take as a Rails developer. It turns your messy views into a professional, modular system.

The AI Support Agent: Connecting n8n, OpenAI, and Your Rails DB

Zil Norvilis — Sat, 06 Jun 2026 18:14:28 +0000

I used to wake up every morning to a wall of support emails. As a solo developer, this is the ultimate "flow-state" killer.

Someone can't find their invoice. Someone else wants to know why their "Pro" features aren't active yet. To answer these, I had to open my Rails console, look up the user by email, check their plan_id and stripe_customer_id, and then type out a polite response.

It takes 10 minutes per ticket. If you have 10 tickets, your first two hours of work are gone before you've even touched your code.

In 2026, I’ve automated 90% of this work. I don't let AI talk directly to my customers (that’s dangerous), but I do let AI draft the replies for me, with full context from my production database.

Here is how I built a "Support Sidekick" using n8n, OpenAI, and a PostgreSQL connection.

The Strategy: The "Human-in-the-Loop"

We aren't building a bot that auto-replies. We are building a system that:

Catches an incoming support email.
Looks up the user's data in our real Rails database.
Asks OpenAI to write a draft based on that data.
Sends the draft to a private Discord channel for us to "Approve & Send."

STEP 1: The Trigger (Email or Webhook)

First, you need a way for n8n to see the support request.

The Easy Way: Use the Gmail or Outlook node in n8n to watch for new emails with the subject "Support."
The Pro Way: Use a Webhook node. If you use a tool like HelpScout or Crisp, they can send a webhook to n8n every time a new ticket is created.

STEP 2: Connecting the Production DB (Security First)

To give the AI context, it needs to know who the user is.

CRITICAL SECURITY RULE: Never connect n8n to your production database using an admin account.
Create a Read-Only user in Postgres that can only see the users and subscriptions tables.

-- Run this in your production DB once
CREATE USER n8n_read_only WITH PASSWORD 'your_password';
GRANT CONNECT ON DATABASE my_app_production TO n8n_read_only;
GRANT USAGE ON SCHEMA public TO n8n_read_only;
GRANT SELECT ON public.users, public.subscriptions TO n8n_read_only;

In n8n, add a PostgreSQL node. Use the email from the incoming ticket to find the user:
SELECT * FROM users WHERE email = '{{ $json.from_email }}' LIMIT 1;

STEP 3: The AI Brain (OpenAI)

Now we add the OpenAI node. We want to use a high-context model like GPT-4o.

The secret here is the System Prompt. You need to give the AI the data you just pulled from the database.

System Prompt Example:

"You are a support assistant for [App Name]. Here is the user's data:
Plan: {{ $node.postgres.json.plan_name }}
Joined: {{ $node.postgres.json.created_at }}
Last Payment: {{ $node.postgres.json.last_payment_date }}

Use this data to draft a polite, helpful response to the user's question. If they are on a Free plan, suggest they upgrade for priority support. If they are a Pro user, be extra thankful."

STEP 4: The Delivery (Discord or Slack)

Finally, we send the AI's draft to where we spend our time: Discord.

Add a Discord node (or Slack). Set the message content to:

New Support Ticket from {{ $json.from_email }}

User Question: {{ $json.subject }}

AI Drafted Reply:
{{ $node.openai.json.content }}

Why this is a game changer

When I see a notification on my phone now, I don't have to go digging through my database. I see the user's status and a perfectly written draft immediately.

I just copy the AI draft, make a tiny tweak if needed, and hit "Send" in my email client. What used to take 10 minutes now takes 30 seconds.

Summary

As a solo developer, you should only do "High Value" work.

High Value: Fixing a critical bug, building a new feature.
Low Value: Looking up a user's sign-up date for a support ticket.

By using n8n to bridge the gap between your Production Database and OpenAI, you offload the low-value research work to the machines. Your Rails monolith stays clean, and your brain stays focused on the code.

DEV Community: Zil Norvilis

Real-Time Engagement: Web Push Notifications in Rails 8

The Mental Model: How Web Push Works

STEP 1: The VAPID Keys

STEP 2: The Database Setup

STEP 3: The Service Worker (Javascript)

STEP 4: Creating the Subscription

STEP 5: Sending the Notification (The Ruby Part)

Summary

The Budget-Friendly Monolith: Rails File Uploads with Cloudflare R2

STEP 1: The Credentials

STEP 2: The Gems

STEP 3: Configuration (storage.yml)

STEP 4: Tell Rails to use R2

Bonus: Enabling Direct Uploads (CORS)

Summary

Pro File Uploads in Rails 8: Speed and Scalability with Direct Uploads

STEP 1: Configure Your Storage

STEP 2: The Rails Form

STEP 3: Adding a Progress Bar (The UX Win)

STEP 4: Why this is the "One-Person" Superpower

Summary

Zero-JS Search: Building a Live-Filter with Turbo 8 Page Morphing

STEP 1: Enable Morphing

STEP 2: The Search Form and Controller

STEP 3: The Utility Controller (The only JS you need)

How it works (The Magic)

Summary

Datastar in Rails 8: Real-Time UI Without the WebSocket Headache

The Concept: What makes Datastar different?

STEP 1: Installation (The No-Build Way)

STEP 2: The Frontend "Signal"

STEP 3: The Rails Controller (Streaming SSE)

STEP 4: The Real-Time Win

Why try this over Hotwire?

Summary

Go for Rubyists: A Practical Guide to Learning Golang

1. The Big Shift: No More Magic

2. Syntax Translation

3. Dealing with Errors (The "if err != nil" loop)

4. The Killer Feature: Goroutines

5. Deployment: The Single Binary

Summary: Should you switch?

Is Coding Over? 5 Career Pivots for Rails Devs in the AI Era

1. The AI Orchestrator (AI Engineer)

2. The Solution Architect

3. The Technical Product Manager (PM)

4. The Solopreneur / Indie Hacker

5. Cybersecurity and Compliance

Summary: Don't Panic, Adapt

Demystifying Rails Magic: How Autoloading Actually Works

Level 1: The Convention (Snake Case to CamelCase)

Level 2: The Engine (Zeitwerk)

Level 3: Why This is Different from Elixir

Level 4: Hot Reloading in Development

Level 5: When the Magic Fails

Summary

Stripe-Style IDs in Rails: A Guide to the custom_id Gem

STEP 1: Install the Gem

STEP 2: The Migration

STEP 3: Configure the Model

STEP 4: Seeing it in Action

Advanced: Customizing your IDs

Why I prefer this over UUIDs?

Summary

Rapid UI Development: Top 4 Component Kits for Solo Rails Devs

1. Shadcn Rails (The Solo Developer's Favorite)

2. Polaris ViewComponents (The Enterprise Choice)

3. PhlexUI (The Speed King)

4. Flowbite / DaisyUI (The "Light" Alternative)

Summary: Which one should you pick?

ViewComponent vs. Phlex: Which Ruby UI Library Should You Choose?

1. ViewComponent (The Gold Standard)

2. Phlex (The Speed Demon)

3. Lookbook (The Designer's Secret)

4. Tailwind-Stimulus-Components

Summary: Which one should you pick?

The AI Support Agent: Connecting n8n, OpenAI, and Your Rails DB

The Strategy: The "Human-in-the-Loop"

STEP 1: The Trigger (Email or Webhook)

STEP 3: Configuration (`storage.yml`)