🔥

Campfire (37signals)

The DHH style textbook — real-time chat built with only Rails built-ins

Campfire is a self-hosted chat app released under 37signals' ONCE brand. It implements real-time chat using only Rails built-in features, making it the most complete practical example of the DHH coding style.

Please refer to the Korean version for the detailed directory structure and pattern analysis, including: CRUD controllers with zero custom actions, state management via records instead of booleans, authentication without Devise using has_secure_password, Concern separation to prevent model bloat, the Current pattern, and 6 dedicated Action Cable channels.

The ONCE philosophy is directly reflected in the code: SQLite by default, Solid Queue/Cache/Cable, email/password without OAuth, single-server deployment with Kamal.

Architecture Diagram

CRUD Mapping Pattern

Typical approach (custom actions)

RoomsController

def index ... end

def show ... end

def create ... end

def close ... end

def reopen ... end

def archive ... end

def ban_user ... end

7+ actions = Fat Controller

Campfire approach (CRUD separation)

RoomsController index / show / create ↗

Rooms::ClosedsController create / destroy ↗

Messages::BoostsController create / destroy ↗

Users::BansController create / destroy ↗

Each controller only has CRUD = Skinny Controllers

State = Record (ERD)

👤 User has_secure_password ↗

id, email_address, password_digest, name, role

has_many ↓

🚫

Ban

user_id
administrator_id
created_at

Exists = Banned

⚡

Boost

message_id
user_id
content

Exists = Boosted

🔗

Membership

room_id
user_id
created_at

Exists = Joined

Key point: Instead of <strong>is_banned: boolean</strong>, determine state by <strong>Ban record existence</strong>
Naturally records who changed what and when

Concern Separation Structure

👤 User Model concerns/ ↗

include User::Bannable Ban

include User::Mentionable @Mention

include User::Role Role

include User::Transferable Transfer

💬 Message Model concerns/ ↗

include Message::Broadcasts Cable

include Message::Pagination Page

include Message::Searchable Search

Action Cable Channel Structure

🌐 Browser (Stimulus Controllers)

WebSocket (Solid Cable)

↓↑

Action Cable Server channels/ ↗

↓

🗄️ Database (Solid Cable — No Redis)

Key Points

Open basecamp/once-campfire repository on GitHub

config/routes.rb → check resource nesting and CRUD mapping patterns

app/controllers/rooms/ → analyze closeds, opens, directs controllers

app/models/user.rb → verify has_secure_password auth (no Devise)

app/models/user/*.rb → learn Concern separation patterns

app/models/ban.rb, boost.rb → check state-as-record management pattern

app/channels/ → analyze 6 Action Cable channel structures

app/javascript/controllers/ → check Stimulus controller patterns

Apply patterns one by one to your own project

Pros

✓ The most complete real-world example of DHH style
✓ CRUD mapping patterns verifiable in actual code
✓ Understand the right scale of Concern separation
✓ Reference 6 production Action Cable channel implementations
✓ Experience the simple architecture of the ONCE philosophy
✓ ~30 production Stimulus controller patterns

Cons

✗ Single-tenant, difficult to directly apply to multi-tenant apps
✗ Small-scale chat app, differs from large-scale services
✗ Minitest + Fixtures — may be unfamiliar to RSpec users
✗ Native CSS — differs from Tailwind trend
✗ ONCE license limits forking/modification

Use Cases

CRUD mapping: rooms/closeds_controller.rb — close room = create, reopen = destroy CRUD mapping: messages/boosts_controller.rb — boost = create/destroy CRUD mapping: users/bans_controller.rb — ban = create/destroy Record state: Ban, Boost, Membership — records instead of booleans Concern separation: User::Bannable, Message::Broadcasts, etc. Current pattern: request-scoped global state management Auth without Devise: has_secure_password + Authentication concern

💎

DHH's Rails Coding Style

Vanilla Rails is enough — The 37signals philosophy

→

← 💎 DHH's Rails Coding Style 📖 Writebook (37signals) →