Shopify is one of the biggest e-commerce platforms in the world, and here is a secret: Shopify was built with Rails. Because of this, the Shopify ecosystem is incredibly friendly to Rails developers.
Building a Shopify app is basically building a standard Rails app that lives inside another website’s dashboard. It is a fantastic way for a solo developer to make passive income because Shopify handles the customers, the billing, and the marketing for you.
Here is the quickest way to build your first Shopify app as a complete beginner.
Before you write any code, you need to join the club.
We don’t build the connection to Shopify from scratch. Shopify provides an official gem that handles all the complex “handshake” logic (OAuth) for us.
Add this to your Gemfile:
gem 'shopify_app'
Run bundle install.
Now, run the Shopify generator. This will turn your boring Rails app into a Shopify-ready engine:
rails generate shopify_app
This command will ask you for your API Key and Secret Key. You can find these in your Shopify Partner Dashboard under your App settings.
This is where beginners usually get stuck. Shopify needs to talk to your Rails app, but your Rails app is currently hidden inside your laptop (localhost).
Shopify cannot see your laptop. You need to create a “Tunnel” to the internet.
The Shopify CLI comes with a built-in tunnel tool. Run this in your terminal:
shopify app dev
This will give you a public URL like https://random-words.cloudflare.com. Copy this URL and paste it into the “App Setup” section of your Shopify Partner Dashboard. Now, Shopify can finally send data to your Rails code.
When a shop owner opens your app, they expect it to look like Shopify. They don’t want to see a custom “bootstrap” design.
Shopify uses a design system called Polaris. In a previous article, I mentioned the polaris_view_components gem. This is the best way to make your app look professional instantly.
<!-- app/views/home/index.html.erb -->
<%= render Polaris::Page.new(title: "My Discount Tool") do %>
<%= render Polaris::Card.new(sectioned: true) do %>
<p>Welcome! This app will help you manage your store better.</p>
<%= render Polaris::Button.new(primary: true) { "Create Discount" } %>
<% end %>
<% end %>
With just a few lines of Ruby, your app now looks like a multi-million dollar software product.
This is the most important concept in Shopify apps. A “Webhook” is Shopify calling your app to say: “Hey, a customer just bought something!” or “Hey, the store owner just deleted a product!”
The shopify_app gem handles this for you. You just define which events you want to listen to in config/initializers/shopify_app.rb:
config.webhooks = [
{ topic: 'orders/create', address: 'https://your-tunnel.com/webhooks/orders_create' }
]
Then, you create a simple background job (using Solid Queue) to process the data when the order comes in.
Building a Shopify app is the ultimate “One-Person Framework” project.
If you have a weekend and a good idea for a small store utility, you can have an app live and potentially making money by Monday morning.
]]>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.
User.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.
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
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");
}
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!");
}
}
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
Web Push is the “Pro” way to bring users back to your app.
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.
]]>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.
First, log into your Cloudflare dashboard and create a new R2 Bucket.
Once the bucket is created, you need to generate “API Tokens.”
The endpoint will look something like this:
https://<account_id>.r2.cloudflorage.com
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.
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!
Finally, update your production environment to use the new service.
# config/environments/production.rb
config.active_storage.service = :cloudflare
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.”
Switching from AWS S3 to Cloudflare R2 is one of the smartest “business” moves a solo developer can make.
By combining Rails 8, Kamal 2, and Cloudflare R2, you are building a production stack that is fast, secure, and incredibly cheap to run.
]]>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.
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.
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.
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| %>.
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:
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.
direct_upload: true to your form.Your Puma threads will thank you, and your users will love the snappy experience.
]]>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.
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>
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>
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()
}
}
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:
The user perceives a lightning-fast, reactive live filter, but you are just writing standard, boring Rails code.
As a solo developer, your goal is to stay out of “JavaScript Land” as much as possible. By leveraging Turbo 8 Page Morphing:
This is the “One-Person Framework” at its best: high-end features with zero-maintenance code.
]]>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.
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.
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"
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.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
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...'}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.
Solid Cable helps with that!).data-signals) for things like toggling menus or form validation without needing to write a full Stimulus controller.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.
]]>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.
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.
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.
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.
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.
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.
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.
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.
Learning Go will make you a more disciplined developer. It teaches you to think about memory, types, and how the computer actually works.
]]>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.
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.
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.
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.
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.
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.
If you are a Rails developer today, you are in a great position. You already think in “Systems.”
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.
]]>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.
The core of the magic is a very strict naming rule. Rails assumes that your file names match your class names perfectly.
User, the file must be user.rb.UserCredential, the file must be user_credential.rb.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.
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.
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.
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.
Even the best magic has limits. You will usually run into “Autoloading Errors” in two cases:
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).config/initializers only run once when the server starts. If you change a file there, you must restart the server.Rails “magic” is just a very smart agreement between you and the framework.
snake_case and your classes CamelCase.require.Once you respect the naming conventions, the magic stays out of your way and lets you focus on building features.
]]>cus_M1p7abc123 or ch_3Oixyz456.
These are called Prefixed IDs. They are great for two reasons:
inv_... in your logs, you immediately know it’s an Invoice without looking at the table name.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.
Add the gem to your Gemfile:
gem "custom_id"
Run in your terminal
bundle install
rails custom_id:install
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
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.
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.
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
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.
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.
cid 'prefix' to your model.It’s a tiny change that makes your Rails monolith feel significantly more polished and “pro.”
]]>