DEV Community: Rob Race

Free Rails Architecture Checkup: run it in Codex, Claude Code, Cursor, etc. It shows where your app gives agents conflicting instructions, hides key architecture, or leaves risky decisions up to guesswork. https://railsbaseline.com/checkup/try/

Rob Race — Fri, 11 Sep 2026 00:03:23 +0000

Try the Rails Architecture Checkup — Rails Baseline

Run a free repo-aware architecture checkup against an existing Rails application with Codex, Claude Code, Cursor, or another coding agent.

railsbaseline.com

Your Webhook Endpoint is a Tiny Distributed System

Rob Race — Thu, 10 Sep 2026 00:07:36 +0000

If you want the Rails implementation version of this, Webhooks in Rails goes deeper on verification, durable receipt, idempotency, retries, jobs, testing, and provider-specific behavior, and includes an Agent Companion for repo-aware coding agents.

Already have webhook code in an existing Rails application? The free Webhook Architecture Checkup is a repo-aware prompt for tracing the flow you already have and finding the important gaps.

Webhook endpoints always seem simple when you build the first version.

Add a route, create a controller action, parse some JSON, update a record and return 200. Pretty standard Rails stuff.

Then the real requirements start showing up. You need to verify that Stripe or GitHub actually sent the request. The provider wants a response quickly, so the useful work moves into a background job. The same event arrives twice. A worker dies after doing half of the work. Two related events get processed at the same time. Another event shows up out of order.

At some point, that little controller action has picked up a surprising amount of infrastructure around it.

Nobody starts by saying, "I need a distributed system for this webhook." You normally get there one completely reasonable requirement at a time.

It is still a small system, of course. We are not building Kafka and twelve services here. But once a webhook is production-ready, you have an external trust boundary, durable ingress, asynchronous workers, duplicate delivery, retries, concurrency, ordering problems and a handful of failure states that all need to agree with each other.

That is the part of webhooks I find interesting. A tiny HTTP endpoint becomes a pretty good microcosm of a much larger distributed system.

First, can you trust the request?

A webhook is public ingress into your application, so before doing anything useful with the payload, you need to answer the obvious security question: did the provider actually send this?

Most providers solve this with a shared secret and a signature over the request body. GitHub, for example, sends an HMAC-SHA256 signature in X-Hub-Signature-256. Stripe signs its payload and includes a timestamp in Stripe-Signature.

The important detail is that those signatures are based on the raw request body, not a Ruby hash after Rails has parsed it.

So the order here matters:

Read the exact request body.
Verify the signature.
Parse the payload only after you trust it.

Rails gives us request.raw_post for the first part.

A minimal GitHub controller can look something like this:

class Webhooks::GithubController < ApplicationController
  skip_forgery_protection

  def create
    raw_body = request.raw_post

    return head :unauthorized unless valid_signature?(raw_body)

    payload = JSON.parse(raw_body)

    # Persist and dispatch the verified event here.

    head :accepted
  rescue JSON::ParserError
    head :bad_request
  end

  private
    def valid_signature?(raw_body)
      secret = Rails.application.credentials.dig(:github, :webhook_secret)

      expected = "sha256=" + OpenSSL::HMAC.hexdigest(
        OpenSSL::Digest.new("sha256"),
        secret,
        raw_body
      )

      provided = request.headers["X-Hub-Signature-256"].to_s

      ActiveSupport::SecurityUtils.secure_compare(expected, provided)
    end
end

There are only a few lines here, but each one matters. The signature is compared with Rails' secure_compare, the body is not parsed until after verification, and the endpoint skips normal browser CSRF protection because this request is not coming from one of our application's browser sessions. The provider signature is what authenticates this request.

For Stripe snapshot events, I would use the SDK instead of rebuilding its signature format myself:

raw_body = request.raw_post
signature = request.headers["Stripe-Signature"]
secret = Rails.application.credentials.dig(:stripe, :webhook_secret)

event = Stripe::Webhook.construct_event(raw_body, signature, secret)

Stripe's verifier also validates the signed timestamp against its tolerance, which helps with replay protection. Stripe's docs are also very specific about passing the unmodified request body to the verifier.

Stripe's newer thin events use a different SDK entry point, so this example is specifically for the snapshot Event objects used by the rest of this article.

So even before we process the event, the webhook endpoint already has its own trust boundary and its own security rules.

Receiving and processing are two different jobs

Ok, now that we trust the request, the next problem is how long we keep the provider waiting.

The webhook provider is making a normal HTTP request to our application. It does not want to wait while we update a bunch of records, call another API, generate something, send email or do whatever the event actually triggers.

GitHub.com expects a 2xx response within 10 seconds. Stripe's guidance is to return a successful 2xx before doing complex processing that could time out.

That leads to a fairly boring ingress path, which is exactly what I want:

verify
  ↓
validate enough to identify the event
  ↓
persist a durable receipt
  ↓
enqueue work
  ↓
return 2xx

Personally, I do not want the request itself provisioning an account, recalculating billing, synchronizing a repository or doing some other multi-step business process. The request should establish that I trust the event and that my application has accepted responsibility for it.

New Rails 8 applications use Solid Queue as the default Active Job backend in production. A dispatch job can stay very normal Rails code:

class WebhookDispatchJob < ApplicationJob
  queue_as :webhooks

  def perform(delivery_id)
    delivery = WebhookDelivery.find(delivery_id)

    # Dispatch to provider/event-specific handling.
  end
end

That gets the slow work out of the HTTP request, but just throwing perform_later into the controller is not the whole reliability story.

If you return a 2xx and then discover that the event never made it into a durable place, the provider thinks you have the event and you may not actually have it anymore.

This is where the acknowledgement boundary becomes important.

What does `2xx` actually mean?

I like storing a durable webhook receipt in the application database before telling the provider the event was accepted.

The first version does not need to be complicated:

class CreateWebhookDeliveries < ActiveRecord::Migration[8.0]
  def change
    create_table :webhook_deliveries do |t|
      t.string :provider, null: false
      t.string :external_id, null: false
      t.string :event_type, null: false
      t.json :payload, null: false
      t.datetime :processed_at
      t.datetime :failed_at
      t.text :last_error
      t.timestamps
    end

    add_index :webhook_deliveries,
      [:provider, :external_id],
      unique: true
  end
end

With that in place, GitHub ingress can start looking more like this:

def create
  raw_body = request.raw_post
  return head :unauthorized unless valid_signature?(raw_body)

  delivery_id = request.headers["X-GitHub-Delivery"].presence
  event_type = request.headers["X-GitHub-Event"].presence

  return head :bad_request unless delivery_id && event_type

  payload = JSON.parse(raw_body)

  delivery = WebhookDelivery.create_or_find_by!(
    provider: "github",
    external_id: delivery_id
  ) do |record|
    record.event_type = event_type
    record.payload = payload
  end

  WebhookDispatchJob.perform_later(delivery.id)

  head :accepted
rescue JSON::ParserError
  head :bad_request
end

One thing to call out here: the unique database index is doing real work. An exists? check followed by create! still has a race between those two queries. Two concurrent requests can both pass the check. The unique (provider, external_id) constraint is the final guard that prevents two receipt rows for the same provider event.

The receipt also gives us somewhere to recover from the slightly awkward gap between inserting application data and enqueuing a job.

Solid Queue has an important detail here. In a default Rails 8 production setup, Solid Queue is configured on a separate database from the application's primary database. Creating a WebhookDelivery in one database and inserting a Solid Queue job in another is not one atomic transaction.

In the controller above, create_or_find_by! has already finished its transaction before perform_later runs, so the receipt is committed before enqueueing starts. If receipt creation and enqueueing happen inside a larger application transaction, Rails gives Active Job enqueue_after_transaction_commit to defer the enqueue until that transaction commits:

class WebhookDispatchJob < ApplicationJob
  queue_as :webhooks
  self.enqueue_after_transaction_commit = true
end

That prevents work from being enqueued for a transaction that later rolls back. It still does not create one atomic transaction across the application and queue databases.

If the receipt commits and the queue insertion fails, I still want that event to be recoverable. A recurring reconciliation job that looks for old, unprocessed receipts is a simple solution and gives you another chance to enqueue the work.

Now 2xx has a much more useful meaning. It does not mean all of the business logic finished. It means the application has durably accepted the event and can recover the remaining work if something goes wrong.

Duplicate delivery is normal

This is probably the first webhook problem that surprises people when they have only worked with the happy path.

Imagine this:

Stripe sends an event.
Your application processes it successfully.
The response gets lost or arrives too late.
Stripe does not know the work succeeded.
Stripe sends the event again.

That is not some wild production edge case. Two systems communicated over a network and disagreed about whether the operation finished.

Stripe explicitly documents that the same event can be delivered more than once. GitHub gives every delivery an X-GitHub-Delivery GUID and keeps that same GUID when a delivery is redelivered.

This is why the (provider, external_id) unique index is useful. It gives us delivery idempotency. Receiving the same provider event over and over does not create a new logical event in our application every time.

However, delivery idempotency is not the same as business idempotency.

Suppose two different webhook events can both lead to the same business operation. Or suppose a job calls an external API successfully and dies before it records processed_at. The unique webhook receipt does not stop that external operation from happening again on the retry.

For those cases, I like the idempotency boundary to describe the actual operation:

class CreateProvisioningOperations < ActiveRecord::Migration[8.0]
  def change
    create_table :provisioning_operations do |t|
      t.references :account, null: false, foreign_key: true
      t.string :operation_key, null: false
      t.datetime :completed_at
      t.timestamps
    end

    add_index :provisioning_operations,
      [:account_id, :operation_key],
      unique: true
  end
end

That operation_key could be based on a provider object ID and the action you are performing. If the next external service supports its own idempotency keys, I would use those too when making that request.

This is also why I try not to think in terms of "exactly once" webhook processing. We do not control exactly how many times a provider attempts delivery, how many times a job is retried or whether a worker dies at a convenient point.

What we can control is whether doing the work again is safe.

Idempotency does not remove concurrency

There is another small wrinkle in the controller example above.

Two copies of the same event can both resolve to the same WebhookDelivery, and both requests can enqueue WebhookDispatchJob.

If the job starts with this:

return if delivery.processed_at?

...that helps with a later retry, but it does not protect against two workers starting at the same time. Both workers can read processed_at == nil before either one updates it.

For work that stays entirely inside our database, a row lock can make that state transition explicit:

class WebhookDispatchJob < ApplicationJob
  queue_as :webhooks

  def perform(delivery_id)
    delivery = WebhookDelivery.find(delivery_id)

    delivery.with_lock do
      return if delivery.processed_at?

      Webhooks::Github::Dispatch.call(delivery)
      delivery.update!(processed_at: Time.current)
    end
  end
end

That example assumes Dispatch is doing database work that belongs inside the transaction.

I would not keep a row lock open while making a slow request to another service. Once the handler has external side effects, that business operation should normally have its own durable idempotency protection instead of assuming a database lock in Rails can control what another system does.

So now our tiny webhook endpoint has a concurrency model too. Fun!

There are two retry systems

Once processing moves to Solid Queue, there are two completely separate retry loops to think about: the provider retrying webhook delivery and our application retrying the async processing.

For Stripe, the flow looks roughly like this:

Stripe
  ↓ webhook delivery
Rails ingress
  ↓ durable receipt
Solid Queue
  ↓ processing attempt
business state

If Rails does not return a successful response, Stripe can retry the webhook delivery for up to three days in live mode using exponential backoff.

Once Rails has accepted the event, the job can fail independently. Active Job does not automatically retry every failed job for you; retry behavior is something you configure. A transient network failure could use something like:

class WebhookDispatchJob < ApplicationJob
  queue_as :webhooks

  retry_on Net::OpenTimeout,
    Net::ReadTimeout,
    wait: :polynomially_longer,
    attempts: 5

  def perform(delivery_id)
    # ...
  end
end

I would not put every exception behind one giant retry rule. A timeout to another API may be temporary. A malformed payload is not. A missing mapping or a bug in the handler probably needs a fix rather than five delayed attempts at the exact same broken code.

Provider behavior is not universal here either. GitHub does not automatically redeliver a failed webhook delivery. You can redeliver manually or through the API, but that is very different from Stripe retrying failed deliveries on its own.

That is another reason I like owning the durable receipt and having a reconciliation path inside the Rails application. Recovery should not depend entirely on whatever retry policy the provider happens to use.

And then events arrive out of order

Even after making every individual event safe to retry, you can still get the wrong result if your code assumes events arrive in the order they happened.

Stripe does not guarantee event ordering. GitHub also documents that webhook deliveries can arrive in a different order than the underlying events occurred.

A billing flow could end up looking like this:

subscription.updated
subscription.deleted
subscription.updated   # delayed older event

If each handler blindly writes its payload to the local record, that delayed event can move the local state backward.

The fix depends on the provider. Sometimes there is a useful sequence or version. Be careful with timestamps: Stripe's snapshot Event created value only has second-level precision, and Stripe says not to use it to determine event order.

For important state, another option is to treat the webhook as a notification that something changed and then fetch the provider's current canonical object before making a local decision. That read can fail when the object has been deleted or is no longer available, and it is not an ordering guarantee by itself. Concurrent handlers still need a provider-specific version or sequence when one exists, local serialization, or a reconciliation rule.

The main point is to make the ordering assumption explicit. "This is the webhook I am processing now" does not automatically mean "this is the newest state."

At this point we have duplicate messages, retries, concurrent workers and events showing up out of order. The distributed-system comparison is doing a lot less metaphorical work than it did at the beginning.

Every provider has its own little rules

There is definitely common webhook infrastructure worth sharing, but I would be careful about trying to make Stripe, GitHub, Shopify, Twilio and every other provider look identical too early.

Verification happens before trust. Durable receipts can share a lifecycle. Jobs can share dispatch infrastructure. Logging and admin tooling can be normalized.

The provider details still matter.

Stripe and GitHub alone are enough to show the differences:

Signatures: Stripe uses a timestamped Stripe-Signature format and provides an SDK verifier. GitHub uses X-Hub-Signature-256 with HMAC-SHA256.
Retry behavior: Stripe automatically retries failed live deliveries for up to three days. GitHub does not automatically redeliver failures.
Ordering: both document that deliveries can arrive out of order.
Delivery identity: Stripe events have event IDs. GitHub provides a delivery GUID in X-GitHub-Delivery that stays the same across redelivery.
Response expectations: GitHub expects a 2xx within 10 seconds. Stripe recommends returning a 2xx quickly before complex processing.

I normally prefer a common ingress shape with provider-specific verification and dispatch over a generic abstraction that hides details the application actually needs to know.

In Rails, this can stay pretty conventional:

Webhooks::GithubController
        ↓
GithubSignatureVerifier
        ↓
WebhookDelivery
        ↓
WebhookDispatchJob
        ↓
Webhooks::Github::Dispatch
        ↓
provider/event-specific handler

There does not need to be a framework behind every box. The useful part is having an obvious place for each responsibility so that Stripe-specific logic does not slowly leak into GitHub processing and vice versa.

A `200` is not observability

Once the useful work is asynchronous, the HTTP request stops telling us very much about what eventually happened.

A successful webhook response can mean the signature passed, a receipt was stored and the work was enqueued while absolutely none of the actual business processing has happened yet.

Eventually you need to answer questions about the event lifecycle instead of the HTTP request.

Did we receive delivery abc123? Was it a duplicate? What event type was it? Did processing ever finish? How many times did it fail? What was the last error? Can I replay it after fixing the bug?

This is another place where the WebhookDelivery model earns its keep. It gives logs, admin tooling, reconciliation and manual replay a stable record to work from.

I usually want enough state to distinguish something along these lines:

received → processing → processed
                  ↘ failed

You do not need to build a workflow engine for this. A few timestamps, an error field and a clear job boundary may be plenty. But once processing can happen seconds or minutes after the request, "the endpoint returned 200" is not a useful debugging answer anymore.

Ok, so we built a tiny distributed system

Let's look back at everything our original controller picked up along the way.

We now have an untrusted network boundary, cryptographic verification, a durable message receipt, database uniqueness, an asynchronous queue, concurrent workers, duplicate delivery, an internal retry policy, a provider retry policy, out-of-order events, business idempotency, failure state, reconciliation, replay and observability.

None of those are especially exotic problems by themselves. The interesting part is how many of them get packed into a feature that started as POST /webhooks/stripe.

This does not mean the first webhook endpoint needs fifteen classes and a homegrown framework. I would still start pretty small. I just want the important boundaries to be obvious:

POST /webhooks/:provider
        ↓
verify the raw payload
        ↓
persist one durable receipt
        ↓
enqueue Solid Queue work
        ↓
provider-specific handler
        ↓
idempotent business operation
        ↓
record the outcome

From there, add complexity when a real failure mode calls for it.

The controller can stay boring. That is probably the best outcome.

The complicated part was never parsing the JSON. It was accepting work from another system when you do not control how many times the message arrives, when it arrives, what order it arrives in or which process eventually finishes it.

That is a lot hiding behind one Rails controller action.

I Tested Rails Baseline by Leaving Architecture Out of the Prompt

Rob Race — Fri, 28 Aug 2026 05:56:53 +0000

Note: Rails Baseline is the production-ready Rails foundation I tested here. It gives a new SaaS application and the coding agents working in it clear, conventional patterns to build from.

I did something a little different before shipping Rails Baseline 1.0.

Instead of spending another week adding starter features I thought somebody might need, I took the actual packaged ZIP, opened it as if I had just bought it, and handed it to fresh coding-agent sessions.

Then I gave them product prompts.

I did not tell them to use Pundit. I did not say to scope records through the current account, use public IDs, put paid access behind Entitlements, or use Solid Queue for background work. Those were all patterns already in the repository, and I wanted to see if the agent would find them without the prompt turning into an architecture checklist.

One test used Claude. The other used Codex.

Both went pretty well.

That sentence is intentionally boring. I was not trying to figure out which model could win a Rails benchmark. I wanted to test the codebase.

Why test the starter this way?

Rails Baseline is a normal Rails application, but part of the reason I built it was for coding agents.

I have spent years building SaaS apps and eventually wrote Build A SaaS App in Ruby on Rails 8. A lot of the hard-won stuff from doing that is not a particular controller action or gem install. It is knowing where certain decisions belong and trying not to make a different version of the same decision six months later.

Coding agents make this more obvious because they can produce so much code so quickly.

If the repository has a good pattern, the agent can usually find and continue it. If the repository is silent, the agent still has to build something. At that point it either asks, guesses, or follows whatever general Rails pattern seems reasonable from training.

A starter that claims to work well with agents should probably be tested by giving an agent incomplete product instructions and seeing what happens.

So that is what I did.

Test one: build a feedback board

The first test started from the RC1 release ZIP, outside the Rails Baseline source repository. I onboarded it as a new application and gave a fresh Claude session a prompt to build a small feedback board product.

The basic product was pretty normal SaaS stuff. Accounts could create boards, anonymous visitors could leave feedback, feedback had statuses, and plan limits changed how many boards an account could have. Paid accounts also got a CSV export.

I intentionally described those things as product requirements.

I did not say something like:

Use Current.account for tenancy.
Use Pundit for authorization.
Use Entitlements.enabled? for paid capabilities.
Use Limits.value for board counts.
Use HasPublicId for URLs.

That would prove I can write a detailed prompt. I already know I can do that.

The more interesting question was whether Claude would inspect the app and reach those conclusions itself.

It mostly did.

The board records were account-owned. Authorization followed the existing policy shape. The free and paid board counts went through the application's plan-limit boundary instead of being scattered through controllers. The paid CSV feature used the entitlement layer. Public URLs followed the existing public-ID convention.

There was also a policy-scope mistake during the build. Claude caught it and fixed it during its own pass.

Good. That is much closer to what I actually want from an agent session than a first pass that looks impressive but quietly breaks account isolation.

The useful miss

The CSV export exposed something Rails Baseline had not really answered yet.

Where should a generated file live?

It would have been easy to react by adding Active Storage, S3 setup, an Export model, and some generic file-delivery service to the starter. That felt like exactly the kind of thing I did not want Baseline to become.

A lot of products do need durable generated files. Plenty do not. A CSV that can be generated quickly and downloaded immediately may not need to be stored at all.

So the answer became documentation instead of another core subsystem. I added a generated-artifacts recipe that talks through when synchronous generation is enough and when durable storage becomes a product decision.

That gave me something else to test later.

Test two: build an endpoint monitor

The second test started from RC2 and used a fresh Codex session.

This prompt was more demanding. Build an account-owned endpoint monitor that checks public HTTP/HTTPS URLs on a schedule. Free accounts get three monitors checked every 15 minutes. Paid accounts get 25 monitors checked every five minutes. Keep recent check history, support a paid CSV export, and optionally expose a public status page.

Again, the prompt described the product. I did not name the Rails Baseline implementation pieces I expected it to discover.

Codex found most of them.

It used account scoping and the existing Pundit context. It used persisted public IDs, Entitlements, Limits, tenant-aware jobs, and the Solid Queue recurring configuration. For the CSV export, Codex found the generated-artifacts recipe from the first dogfood and chose not to invent persistent storage for a file that could be generated on demand.

That last part made me pretty happy. The first test found a missing decision. I documented it, and a completely fresh agent used that documentation in the second test.

That is basically the behavior I wanted from Rails Baseline in the first place.

The second app found harder gaps

An endpoint monitor has one security problem that a feedback board does not have: the application has to make HTTP requests to URLs supplied by users.

Codex correctly treated that as an SSRF problem instead of just checking whether the string started with https://.

Its implementation resolved DNS, rejected private and other unsafe address ranges, pinned the connection to the validated address, used explicit timeouts, verified TLS, disabled environment proxies, and did not follow redirects.

Rails Baseline did not teach any of that.

I do not really consider that a failure of the starter. Safe outbound HTTP is one of those capabilities that only some products need, and there are enough security details that "just use Net::HTTP" is not much of a recipe.

Still, the test found a real boundary where an agent had to leave the existing precedent and design something new. That became one of the small recipes added before 1.0.

The scheduling side found another one.

Baseline already showed recurring Solid Queue work and tenant context inside jobs, but it did not show the shape needed when each account's schedule depends on product state. Codex ended up with a minute-level dispatcher that finds monitors which are due and enqueues their actual check jobs.

That also became a short recipe instead of a new scheduling framework.

And, yes, the agent still wrote a bug

The endpoint monitor app ended up calling the model HttpMonitor because Monitor collides with a Ruby constant and EndpointMonitor collided with the onboarded application namespace.

The routes still used the product-facing name:

resources :monitors

At one point, a view used Rails' polymorphic routing shortcut:

<%= link_to monitor.name, monitor %>

Rails saw an HttpMonitor instance and looked for http_monitor_path, which did not exist. The route helper was monitor_path.

That one made it through the agent's test suite, and I hit it manually while clicking around the app.

The fix was easy, but I liked finding this too. A coding agent following the architecture well does not mean it stops making normal implementation mistakes. It also gave Baseline one more small Rails-specific recipe: if your model class and route resource intentionally use different names, either avoid polymorphic routing there or test a navigation path that exercises it.

No framework required.

What I actually learned from the tests

The useful result was not "Claude passed" or "Codex passed."

Both agents were capable enough that the interesting differences came from what the repository gave them to work with.

When Rails Baseline had a clear local pattern, the agents usually found it. Account ownership, authorization, plan access, limits, jobs, IDs, and normal Rails/Hotwire UI conventions all carried through into new product code without me naming those pieces in the prompt.

When the app did not have a pattern, the agent had to make a product decision. Sometimes that was exactly right. Other times it exposed a missing piece of documentation that was general enough to add back to the starter.

That seems like a healthier way to build an agent-friendly codebase than trying to anticipate every future feature with another abstraction.

I would rather have 20 boring, well-used patterns and a handful of good recipes than 80 generic service objects waiting for a use case.

I will probably keep doing this

The best part of the process was how close it felt to an actual customer using the product.

I was not running tests inside the Baseline source repo and congratulating myself because they were green. The ZIP was packaged, copied somewhere else, onboarded into a new app, and then handed to an agent that had no history from building Rails Baseline.

That caught setup issues, product gaps, documentation gaps, and one wonderfully ordinary Rails routing bug.

For future Baseline releases, I think this kind of test is more valuable than adding another sample feature just so the feature list gets longer.

Give a fresh agent a product request. See what it copies. See where it guesses. Fix the parts that should have been obvious from the repository.

Then stop before the starter turns into the product it is supposed to help you build.

If you want to see the Rails app these tests were run against, Rails Baseline is at railsbaseline.com.

Print Smarter in Ruby - Know When and How to Use Each Method

Rob Race — Tue, 20 May 2025 00:20:03 +0000

If you've ever stared at a blob of console output wondering what the hell you just printed, you're not alone. Ruby gives you a handful of ways to print stuff, but knowing when to use which one is the real trick. In this post, we'll go through the five most common ways to print output in Ruby, plus one gem that makes your console look like it's had a glow-up.

`puts`: Standard Output with Automatic Newlines

puts is your go-to for dumping simple output to the console. It stands for "put string" and adds a newline at the end of each argument. It's as friendly and low-drama as it sounds:

puts "Hello, World!"
puts 123
puts ["Ruby", "Rails"]

Output:

Hello, World!
123
Ruby
Rails

Arrays get printed line-by-line, so don't be surprised when each item shows up on its own line.

`print`: Continuous Output Without Newlines

Want to print multiple things on the same line? Use print. It's like puts, but without the automatic newlines:

print "Hello, "
print "World!"

Output:

Hello, World!

If you want a newline, you'll have to add it manually:

print "Hello, World!\n"

`p`: Debugging with Inspect Output

p is the debug sibling of puts. It shows the inspect version of the object and means strings keep their quotes, and you get more detail:

p "Hello, World!"
p [1, 2, 3]
p({name: "Rob", age: 39})

Output:

"Hello, World!"
[1, 2, 3]
{:name=>"Rob", :age=>39}

If you're debugging and want raw visibility into what you're working with, p is your friend.

`pp`: Pretty Print for Enhanced Readability

For more complex stuff like nested hashes, pp (pretty print) makes things readable:

require 'pp'

complex_hash = {name: "Rob", hobbies: ["coding", "fitness", {sports: ["cycling", "lifting"]}]}
pp complex_hash

Output:

{:name=>"Rob",
 :hobbies=>["coding", "fitness", {:sports=>["cycling", "lifting"]}]}

Think of it like p, but with spatial awareness.

`y`: YAML Output in IRB

The y method is only available in IRB (Interactive Ruby), but it's a great way to spit out YAML-formatted data without much effort:

# In IRB
data = {name: "Rob", languages: ["Ruby", "JavaScript"]}
y data

Output:

---
:name: Rob
:languages:
- Ruby
- JavaScript

It's tidy, structured, and way more readable when you're dealing with nested stuff.

Quick Summary

Method	When to Use
`puts`	General output, automatic newline
`print`	Continuous output without newline
`p`	Debugging with inspect details
`pp`	Pretty printing for readability
`y`	YAML-formatted output (IRB only)

If you just want something quick and readable, puts and p will get you far. But if you're working with nested hashes from an API and don't want to burn your eyes out reading the raw dump then read on.

`awesome_print`: Enhanced Pretty Printing with Style

If pp gets the job done, awesome_print gets the job done with flair. It pretty-prints Ruby objects in full color, indents them beautifully, and makes your console output feel like VS Code decided to move in.

Installation

Using Bundler:

group :development do
  gem 'awesome_print'
end

Then run:

bundle install

Or install it directly:

gem install awesome_print

Usage

require 'awesome_print'

data = {
  name: "Rob",
  hobbies: ["coding", "fitness", { sports: ["cycling", "lifting"] }]
}

ap data

Output:

{
    :name => "Rob",
    :hobbies => [
        [0] "coding",
        [1] "fitness",
        [2] {
            :sports => [
                [0] "cycling",
                [1] "lifting"
            ]
        }
    ]
}

To make it the default in IRB:

require 'awesome_print'
AwesomePrint.irb!

Once you've used awesome_print, going back to puts feels like reading minified JSON with no line breaks.

That's your tour of Ruby's printing options. Use puts and p when you're starting out. Graduate to pp and awesome_print when your objects get gnarly. And next time you're knee-deep in nested hashes wondering why nothing looks right, don't forget your options.

Avoiding N+1 Queries in Rails: Easy Performance Wins for Beginners

Rob Race — Thu, 15 May 2025 18:02:41 +0000

Performance issues in Rails apps can sneak up on you, especially if you're working with ActiveRecord and are unaware of the infamous N+1 query problem. This post will walk you through what N+1 queries are, how to detect them, and how to fix them using simple techniques. If you're a beginner or intermediate Rails developer, this is one of the easiest ways to level up your performance game.

What is an N+1 Query?

Imagine going to the store with a shopping list of 10 items and making a separate trip for each one instead of buying them all at once. That’s what an N+1 query does: it performs 1 query to fetch a list of records (say Post.all), and then 1 additional query for each associated record (like post.comments).

# N+1 problem example
Post.all.each do |post|
  puts post.comments.count
end

This triggers one query to get all posts, and then one query per post to fetch its comments. If you have 10 posts, that’s 11 queries. Scale that up to 100 posts, and you're dealing with 101 queries, most of them unnecessary.

How to Detect N+1 Queries

1. Check Your Logs

In development, check your log/development.log or Rails server output. You'll often see the same query being run repeatedly.

2. Use the `bullet` Gem

The bullet gem is designed to catch N+1 queries and notify you.

Setup:

# Gemfile
group :development do
  gem 'bullet'
end

Configuration:

# config/environments/development.rb
config.after_initialize do
  Bullet.enable = true
  Bullet.alert = true
  Bullet.bullet_logger = true
  Bullet.rails_logger = true
end

You'll get an alert in your browser or console when Bullet detects a potential N+1.

How to Fix N+1 Queries

Use Eager Loading with `.includes`

Eager loading tells Rails to fetch associated records in the same query using LEFT OUTER JOIN.

# Fixing the N+1 problem
Post.includes(:comments).each do |post|
  puts post.comments.count
end

Now, instead of 11 queries for 10 posts, you only make 2: one for the posts, and one for the associated comments.

When to Use `.joins` or `.preload`

Use .joins when you're filtering or ordering based on associated data.
Use .preload when you want to load associations but don’t need joins.

Common Mistakes and Gotchas

Forgetting to use eager loading in controllers or views.
Not eager loading nested associations (post.comments.user requires Post.includes(comments: :user)).
Overusing .includes can also hurt performance if you load too much data.

Real-World Example

Say you're building a blog app and rendering a list of posts with their comments:

<% @posts.each do |post| %>
  <h2><%= post.title %></h2>
  <% post.comments.each do |comment| %>
    <p><%= comment.body %></p>
  <% end %>
<% end %>

If @posts = Post.all, you’re triggering N+1 queries. Instead, use:

@posts = Post.includes(:comments)

This change alone can dramatically cut down your query count and improve performance.

Preventing N+1s Going Forward

Use the bullet gem in development to get real-time alerts.
Build a habit of checking logs when building or refactoring features.
Write performance tests if your app grows in size or complexity.

Want to keep improving your Rails performance? There's a performance chapter in my Build A SaaS App in Ruby on Rails 8 book that covers this and more.

Leveraging Turbo 8: Best Additions to Implement in Rails 8 Projects

Rob Race — Tue, 01 Oct 2024 00:06:06 +0000

This article will explore Turbo 8's powerful features and a little bit of code. You will be surprised by how little extra code is needed to implement all of this!

This tutorial is a distillation of the type of information you'll find in one of the two books I am writing, Realtime Rails

We will be starting over but using many of the same concepts from the previous article. Let's get into it!

Setup

First, we can create a new Rails app from the main branch to get all of the Rails 8 goodies (though, soon, this will be available through alpha/beta gem releases).

rails new --main blabber

Now, as we will be adding a few features related to user interactions, we will need to create users and a way to log them in. Short of using the new Rails 8 authentication generators, we can add two quick models, a small number of controller methods, and a few view templates.

First, the models via Rails generators:

rails g model user email:string password_digest:string
rails g model post user:references message:text

These generators will create two models and migrations for the Users and Posts. Let's add a few lines to the User model for validation and authentication:

class User < ApplicationRecord
  validates :email, presence: true, uniqueness: true
  has_secure_password

end

The significant addition here is the has_secure_password line which includes code to set and authenticate passwords via bcrypt. Now, on the Post model, the user reference should exist, and we can add a quick validation:

class Post < ApplicationRecord
  belongs_to :user

  validates :message, length: { minimum: 1, maximum: 280 }
end

Finally, here is a quick bin/rails db:migrate to get those tables created.

Now, we can move on to the controller and views for logging in. We want to make this simple, just for this tutorial, so we'll handle logging in and logging out, their responsive routes, and some basic views.

First, the routes:

Rails.application.routes.draw do
  get "/login", to: "sessions#new", as: "login"
  post "/sessions", to: "sessions#create"
  get "/logout", to: "sessions#destroy", as: "logout"

  resources :posts, only: %i[index create]

  root "posts#index"
end

These will be all the routes we need for the whole app: the first three for sessions, a resource helper for posts, and setting the root route.

Now we can add the SessionsController at app/controllers/sessions_controller.rb:

class SessionsController < ApplicationController

  def create
    @user = User.find_by(email: params.dig(:user, :email))
    if @user && @user.authenticate(params.dig(:user, :password))
      sign_in(@user)
      redirect_to root_path, notice: "You have successfully logged in!"
    else
      flash.now[:alert] = "There was a problem logging in."
      render :new, status: 422
    end
  end

  def destroy
    sign_out
    redirect_to login_path, notice: "You have successfully logged out!"
  end

  private

  def sign_in(user)
    session[:user_id] = user.id
  end

  def sign_out
    session.delete(:user_id)
  end
end

Pretty simple here. If we find a user and that user authenticates with the included authenticate method from the User model, we will call sign_in, which sets a session for the user. Real quick, we can add a helper method in ApplicationController to use current_user throughout controllers and views through the app:

  def current_user
    @current_user = User.find_by(id: session[:user_id]) if session[:user_id]
  end
  helper_method :current_user

Next, we can quickly add a PostsController that resembles much of what we used in the last tutorial, aside from now having a user_id:

class PostsController < ApplicationController
  before_action :require_login

  def index
    @posts = Post.all.order(created_at: :desc)
    @post = Post.new
  end

  def create
    @post = Post.new(post_params.merge(user_id: current_user.id))
    respond_to do |format|
      if @post.save
        redirect_to posts_path
      else
        render :index
      end
    end
  end

  private

  def post_params
    params.require(:post).permit(:message)
  end
end

Both the index and create actions are reasonably straightforward Rails-like methods for listing and creating Posts. The last part of the authentication puzzle here would be to add the before_action:require_login method to the ApplicationController and use the Rails Console to create two users (thus, we skipped building a signup interface).

# app/controllers/application_controller.rb


## redirect to login, if there is no current_user, meaning there is no authenticated user session
def require_login
  redirect_to login_path, alert: 'You must be logged in to access this page.' if current_user.nil?
end

Lastly, we can go ahead and knock out a few views to get all of the authentication, Bootstrap, and basic Post markup out of the way

<!DOCTYPE html>
<html>
  <head>
    <title><%= content_for(:title) || "Blabber" %></title>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <meta name="apple-mobile-web-app-capable" content="yes">
    <meta name="mobile-web-app-capable" content="yes">
    <% if current_user %>
      <meta name="current-user-id" content="<%= current_user.id %>">
    <% end %>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>
    <%= turbo_refreshes_with method: :morph, scroll: :preserve %>
    <%= yield :head %>

    <%# Enable PWA manifest for installable apps (make sure to enable in config/routes.rb too!) %>
    <%#= tag.link rel: "manifest", href: pwa_manifest_path(format: :json) %>

    <link rel="icon" href="/icon.png" type="image/png">
    <link rel="icon" href="/icon.svg" type="image/svg+xml">
    <link rel="apple-touch-icon" href="/icon.png">

    <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css" rel="stylesheet" type="text/css" />
    <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/js/bootstrap.bundle.min.js"></script>

    <%# Includes all stylesheet files in app/views/stylesheets %>
    <%= stylesheet_link_tag :app, "data-turbo-track": "reload" %>
    <%= javascript_importmap_tags %>
  </head>

  <body class="">
    <nav class="navbar navbar-expand-lg navbar-light bg-light">
         <div class="container-fluid">
           <a class="navbar-brand" href="/">Blabber</a>
           <span class="navbar-text">
             <% if current_user %>
               <%= current_user.email %>
               <%= link_to "Logout", logout_path, method: :delete, class: "btn btn-outline-danger" %>
             <% else %>
               <%= link_to "Login", login_path, class: "btn btn-outline-primary" %>
             <% end %>
            </span>
          </div>
      </nav>

    <% if flash[:notice] %>
      <div class="alert alert-success" role="alert">
        <%= flash[:notice] %>
      </div>
    <% end %>
    <% if flash[:alert] %>
      <div class="alert alert-danger" role="alert">
        <%= flash[:alert] %>
      </div>
    <% end %>
    <div class="container mt-5">
      <%= yield %>
    </div>

  </body>
</html>

A few code blocks to note:

<% if current_user %>
  <meta name="current-user-id" content="<%= current_user.id %>">
<% end %>

...will add the user ID to the front end for use in StimulusJS later.

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

...will allow Turbo 8 to morph the incoming DOM changes sent by Turbo.

Finally, Bootstrap is added over CDN for the simplicity of this tutorial, as well as a simple navbar and alerts.

Ok, three Post templates, and we're done with setup.

To display the list of posts, you can create an index.html.erb file in the app/views/posts directory. Here's an example of how the index view could look like:

<div class="container">
  <h1>Blabber</h1>
  <h4>A Rails, Hotwire demo</h4>

  <%= render partial: 'form' %>

  <%= render @posts %>
</div>

This code uses the _post.html.erb partial to render each post in the @posts collection.

<div class="card mb-2" id="<%= dom_id(post) %>">
  <div class="card-body">
    <h5 class="card-title text-muted">
      <small class="float-right">
        Posted <%= time_ago_in_words(post.created_at) %> ago
      </small>
      <%= post.user.email %>
    </h5>
    <div class="card-text lead mb-2"><%= post.message %></div>
  </div>
</div>

...and then the _form.html.erb

<%= form_with model: @post, id: dom_id(@post), html: {class: 'my-4' } do |f| %>
  <% if @post.errors.any? %>
    <div id="error_explanation">
      <h2>
        <%= pluralize(@post.errors.count, "error") %> prohibited this post from
        being saved:
      </h2>

      <ul>
        <% @post.errors.full_messages.each do |msg| %>
        <li><%= msg %></li>
        <% end %>
      </ul>
    </div>
  <% end %>
  <div class="form-group" data-controller="typing">
    <%= f.text_area :message, placeholder: 'Enter your blab', class: 'form-control',rows: 3 %>
  </div>

  <div class="actions my-2">
    <%= f.submit class: "btn btn-primary" %>
  </div>
<% end %>

This code uses the form_with helper to create a form for the @post object. The text_area helper creates a textarea input for the post's message attribute.

Ok! That's enough setup code!

Turbo Morph

If you followed along with the previous tutorial, there are only a couple of lines to add to get morphed updates out of the box! Earlier, we pre-empted the code to add with the line to the partial. To finish this off, we will add a line to the Post model and two through the Post views.

First, the line to the model:

class Post < ApplicationRecord
  belongs_to :user

  broadcasts_refreshes ## New line

  validates :message, length: { minimum: 1, maximum: 280 }
end

<div class="container">
  <h1>Blabber</h1>
  <h4>A Rails, Hotwire demo</h4>

  <%= render partial: 'form' %>


  <%= turbo_stream_from 'posts' %> <!-- This is that streams from the post collection -->
  <%= render @posts %>
</div>

<%= turbo_stream_from post %> <!-- This is that streams from each post -->
<div class="card mb-2" id="<%= dom_id(post) %>">
  <div class="card-body">
    <h5 class="card-title text-muted">
      <small class="float-right">
        Posted <%= time_ago_in_words(post.created_at) %> ago
      </small>
      <%= post.user.email %>
    </h5>
    <div class="card-text lead mb-2"><%= post.message %></div>
  </div>
</div>

That's it! If you create two users in the console, log on in, and then log another in on an incognito tab, you will see each page get updated with new posts from each user!

Presence Channel

Presence channels are a great way to show who is online in your application.

In our case, we will use an indicator next to the users' email addresses in the Post card. This indicator will be a simple green dot if the user is online and a red dot if the user is offline.

The first step here will be to include icons to use a circle and then color it based on the user's presence. We can easily include Bootstrap icons by adding the following line to the application.css file:

@import url("https://cdn.jsdelivr.net/npm/bootstrap-icons@1.11.3/font/bootstrap-icons.min.css");

Now, we can generate a quick migration to add an online boolean to the User model:

rails g migration add_online_to_users online:boolean
rails db:migrate

Next, we can add two simple methods to the User to adjust a user's presence status using the online boolean. We will also add a method to broadcast changes to the presence channel after a user's status changes and check for the online_previously_changed? (a built-in ActiveRecord field status method) in that method used by the callback:

class User < ApplicationRecord
  validates :email, presence: true, uniqueness: true
  has_secure_password

  after_commit :broadcast_changes

  def broadcast_changes
    if online_previously_changed?
      Turbo::StreamsChannel.broadcast_refresh_to(:presence)
    end
  end

  def came_online
    update!(online: true) unless online?
  end

  def went_offline
    update!(online: false) if online?
  end
end

Finally, we can add a line to the application.html.erb to listen for changes to the presence channel and then update the _post partial to include the presence indicator:

...
 <%= turbo_stream_from :presence, channel: PresenceChannel if current_user %>
...

The turbo_stream_from:presence will use the turbo_stream helpers from the turbo-rails gem to handle the automatic subscription to the presence channel. The PresenceChannel argument in this method sets which Channel will be specifically used in the streaming process.

<%= turbo_stream_from post %>
<div class="card mb-2" id="<%= dom_id(post) %>">
  <div class="card-body">
    <h5 class="card-title text-muted">
      <small class="float-right">
        Posted <%= time_ago_in_words(post.created_at) %> ago
      </small>
      <i class="bi bi-circle-fill align-middle text <%= post.user.online? ? 'text-success' : 'text-danger'%>" style="font-size: .5rem"></i>
      <%= post.user.email %>
    </h5>
    <div class="card-text lead mb-2"><%= post.message %></div>
  </div>
</div>

This uses the bi-circle-fill icon from Bootstrap and changes its color based on the user's presence status.

Lastly, we can create the PresenceChannel in the app/channels directory:

class PresenceChannel < ActionCable::Channel::Base
      extend Turbo::Streams::Broadcasts, Turbo::Streams::StreamName
      include Turbo::Streams::StreamName::ClassMethods

  def subscribed
    stream_from "presence"
    current_user.came_online
  end

  def unsubscribed
    current_user.went_offline
  end
end

This channel extends and includes some Turbo::Streams modules, so that it can broadcast to the presence channel and handle the stream name. The subscribed method will stream from the presence channel and then call the came_online method on the current user. The unsubscribed method will call the went_offline method on the current user. unsubscribe is a method that is called when the client disconnects from the channel by closing the window or logging out.

Now, if you tried to use the browser, you would see errors from your channel in the logs, as we have to set up one last piece, the current_user in the Connection class. This class is much like an ApplicationController but for the ActionCable connections. We can add a method to the Connection class to set the current_user:

module ApplicationCable
  class Connection < ActionCable::Connection::Base
    identified_by :current_user

    def connect
      self.current_user = find_verified_user
    end

    private
      def find_verified_user
        if current_user = User.find_by(id: @request.session[:user_id])
          current_user
        else
          reject_unauthorized_connection
        end
      end
  end
end

This module will set the current_user to the user found by the session[:user_id], which was set during the login, or reject the connection if the user is not found.

If you were to open two browsers (your current browser window and an incognito would work!) now and log into each user, you would see the presence indicator change in real time!

Note: This presence could become noisy with a lot of users, specifically because it will be writing a lot to the users table. This example was built for simplicity and not scale. With enough traffic on a real application, you may want to consider a second database or technology to store the data (e.g., Redis).

Typing Indicators

The last feature we'll build here is a typing indicator, which will show when a user is typing a message, much like you see in Slack. Of course, as this is just a simple app to demonstrate the capability, the typing indicator will be shown to all users but not the user typing.

First, we can generate a channel to handle the typing events and pin a debounce library to handle the typing events in a javascript controller a few files later:

bin/rails generate channel typing
bin/importmap pin lodash.debounce

Inside the TypingChannel, we can add a few methods to handle the typing and typing stopped events from the "Cable" side:

class TypingChannel < ApplicationCable::Channel
  def subscribed
    stream_from "typing"
  end

  def typing
    ActionCable.server.broadcast("typing", { action: 'typing', uid: current_user.id.to_s, user_email: current_user.email } )
  end

  def typing_stopped
    ActionCable.server.broadcast("typing", { action: 'typing_stopped', uid: current_user.id.to_s, user_email: current_user.email } )
  end

  def unsubscribed
    # Any cleanup needed when channel is unsubscribed
  end
end

This channel will stream from the typing channel and then broadcast the typing and typing_stopped events to the channel. The typing event will include the current user's uid and user_email. This information is needed to do two things. One, the user_id will be used to filter out the currently typing user from seeing the typing indicator. Second, the email address is used to display the message so as not to send the data to the front end differently. The unsubscribed method was added to the channel by default during the generation of the channel but can be removed as it is not needed.

With that out of the way, the next place to add some code is the markup by adjusting and adding some StimulusJS to the Posts form:

<%= form_with model: @post, id: dom_id(@post), html: {class: 'my-4' } do |f| %>
  <% if @post.errors.any? %>
    <div id="error_explanation">
      <h2>
        <%= pluralize(@post.errors.count, "error") %> prohibited this post from
        being saved:
      </h2>

      <ul>
        <% @post.errors.full_messages.each do |msg| %>
          <li><%= msg %></li>
        <% end %>
      </ul>
    </div>
  <% end %>
  <div class="form-group">
  <div class="form-group" data-controller="typing">
    <%= f.text_area :message, placeholder: 'Enter your blab', class: 'form-control', rows: 3 %>
    <%= f.text_area :message, placeholder: 'Enter your blab', class: 'form-control', data: { turbo_permanent: true, action: 'keydown->typing#typing keyup->typing#typingStopped' }, rows: 3 %>
    <div id="typingHint" class="form-text" data-typing-target="display"></div>
  </div>

  <div class="actions my-2">
    <%= f.submit class: "btn btn-primary" %>
  </div>
<% end %>

We replace two lines, adding StimulusJS markup of <div class="form-group" and action: 'keydown->typing#typing keyup->typing#typingStopped' for the StimulusJS controller to listen for keydown and keyup events. We add turbo_permanent: true so that the turbo morph updates will not clear out the form's current state (i.e., text that has been typed or bound javascript that StimulusJS is handling). Finally, the data-typing-target="display" will be used to update the message in the view when someone is typing.

Finally, we can add the StimulusJS controller to the app/javascript/controllers directory:

import { Controller } from "@hotwired/stimulus";
import consumer from "channels/consumer";
import debounce from "lodash.debounce";

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

  initialize() {
    this.typingStopped = debounce(this.typingStopped, 1000);
  }

  connect() {
    this.subscription = consumer.subscriptions.create("TypingChannel", {
      received: (data) => {
        if (data.uid != this.userId) {
          this.displayTarget.innerHTML =
            data.action == "typing" ? `${data.user_email} is typing...` : "";
        }
      },
    });
  }

  typing(_event) {
    this.subscription.perform("typing");
  }

  typingStopped(_event) {
    this.subscription.perform("typing_stopped");
  }

  get userId() {
    return document.head.querySelector("meta[name=current-user-id]")?.content;
  }
}

This controller has many moving parts; we'll go through them by behavior.

First, we create a getter for the userId, which will get the current-user-id from the meta tag in the head of the document, which was added way earlier when we first modified the application.html.erb. This will be used later in the event filtering process.

Then, in the connect method, we create a subscription to the TypingChannel and then listen for the received event. The received happens when the broadcast is sent from the TypingChannel. We'll come back to the if statement in a moment.

In the view, we used keydown->typing#typing to call the typing function when that event happens in the browser. The typing function then calls the perform method on the subscription to send the typing event to the TypingChannel. This event triggers the typing method in the TypingChannel to broadcast the typing event to the typing channel, which is handled by the received handler.

Additionally, we used keyup->typing#typingStopped in the view to call the typingStopped function. Here, we debounce the typingStopped function to only call it once every 1000 milliseconds or one second. This function will prevent the typingStopped method from being called too frequently and basically allow the controller to wait for the typing to be stopped. Using a debounce function is a common pattern in JavaScript to prevent a function from being called too frequently. We are using debounce from the lodash library to do this and was added in the import statement at the top of the file. The trick to getting the StimulusJS-based keydown event to use the lodash debounce is to set the controller's typingStopped function in the initializer to itself inside the debounce function call.

The typingStopped function then calls the perform method on the subscription to broadcast the typing_stopped event to the TypingChannel much like the same round trip for typing.

To get the controller ready to display text, we added data-typing-target="display" in the view to display the typing indicator and then added a static targets = ["display"]; to allow this controller to interact with that element.

Now, finally getting back to the code inside the received handler, we check if the uid in the data object does not equal the userId from the meta tag. If the uid is not equal to the userId, then we update the displayTarget with the user's email and a message that they are typing. Inside the innerHTML setter, we use a ternary operator to check if the action in the data object equals typing. If it is, we set the innerHTML to the user's email and a message they are typing. If the action is not equal to typing, then we set the innerHTML to an empty string which clears the message in the browser.

Now, suppose you were to open two browsers (again, a current browser and an incognito would work!) and log into each user. In that case, you would see the typing indicator change in real time as one user types; the other would see the indicator on their browser!

Conclusion

Anyway, closing out these tutorials always feel weird. Hope you learned something from this and leave a comment with any questions or feedback!

Rails Console in the Browser (on-demand)

Rob Race — Thu, 26 Sep 2024 18:09:45 +0000

Why in the browser?

While doing some research and working on some details for my new book Realtime Rails, I came across an issue where making changes to ActiveRecord objects in the terminal's rails console were not showing up in the web browser. When working in development, based on default settings for ActionCable and the Rails server, for the broadcast to show up, it needs to be using the same process instead of the separate process spaned by the rails console in the terminal.

Also, having the console show up in the browser on demand is a pretty cool setup. You can see the changes in real time and interact with the objects in the browser.

How to set it up

Tip
If you have a recent version of Rails, this gem should already be included, as Rails has been adding the web-console gem to the default Gemfile for a while now to show the console in the browser on exception pages.

If you need to set up the Rails console in the browser yourself instead, you will need to add the web-console gem to your Gemfile:

gem 'web-console', group: :development

Then, run bundle install to install the gem.

Once installed, you can add a web console to any view file by adding <%= console %>, then interact with the Rails console in the browser.

Taking it a step further

If you want to add some convenience to this process, you can add route, controller, and view (that are development only) to have the browser show up in the browser on a specific page in your application.

First, adding the development-only route:

if Rails.env.development?
 get '/console', to: 'console#show'
end

Then, create the controller:

class ConsoleController < ApplicationController
  def show
  end
end

And finally, the view:

<h1>Rails Console</h1>
<%= console %>

Now, when you visit /console in your development environment, you will have a console in the browser.

Alternate Idea

Another idea is to add a link to the console in your application's footer. This way, you can easily access the console from any page in your application.

Note
Web Console has CSS to make it sticky to the bottom of the page, so it will always be visible. There is no extra CSS to add when you want to add to any existing pages in your application.

Then, add the link to the console in your application.html.erb layout file, but since we're not relying on the route to show the console in the development environment only, we will need to add a conditional check in the template:

<% if Rails.env.development? %>
 <%= console %>
<% end %>

Personally, I'd rather have the console appear on a specific page, but this is a good alternative if you want the console available on every page in your application.

How to Build a Twitter Clone with Rails 8 and Turbo 8

Rob Race — Thu, 19 Sep 2024 18:20:40 +0000

Hotwire, StimulusJS, and Turbo have been out for the better part of half a decade, and there have been sweeping changes in the Turbo Broadcast and Stream patterns this past year. All of this gets bundled with Rails 8, plus other new features to make development even quicker, such as SolidQueue, SolidCache, and SolidCable. Two of those three make it dead simple to get this clone up and running super quick!

Note: I use Bootstrap when making something quick. You can throw an asset tag in the views/layout/application.html.erb or add Bootstrap to the rails --new command (but have yarn installed before running rails new). Additionally, I am using the --main flag to install Rails from the main branch in Github to get the currently unreleased but nearly ready Rails 8.

Without further ado, let's get started with a new app:

rails new blabber --main --css=boostrap

Rails will do its thing:
Install the application.
Install the gems.
Process the Bootstrap installation.
Install the yarn packages.

Hotwire and Turbo are now part of Rails, so installing anything extra is unnecessary! Just fire up bin/dev and start writing some code.

Now, let's make a model to hold the data to clone a tweet in this Twitter clone called Blabber. All basic attributes:

rails g model Post username body:text likes_count:integer repost_count:integer

To keep this closely resembling the previous article, we'll add the same validation in the Post model:

class Post < ApplicationRecord
 broadcasts_refreshes

 validates :body, length: { minimum: 1, maximum: 280 }
end

One difference you see is the broadcasts_refreshes line. This line is part of Turbo 8, where the backend changes (here, changes to the model) are broadcast as a refresh event in Turbo, to be picked up by the turbo.js front end. Hidden behind the scenes is all the work Rails does to connect browsers, expecting that particular model instance to have updates and all the connecting parts such as ActiveJob, ActionCable, SolidQueue, and SolidCable.

We'll make the same few minor adjustments to the generated migration file to add some database-level defaults (and allow us to keep the code around Post creation simple):

class CreatePosts < ActiveRecord::Migration[6.0]
  def change
 create_table :posts do |t|
 t.string :username, default: 'Blabby'
 t.text :body
 t.integer :likes_count, default: 0
 t.integer :repost_count, default: 0

 t.timestamps
    end
  end
end

Ok! Now, we're ready to run that migration!

rails db:migrate

Another change with this process of refreshes and streams is that our controller can now be unaware of the streams and does not need to have format-based responses or template files that closely resemble the same partials used for the non-dynamic part of the app.

class PostsController < ApplicationController

  def index
    @posts = Post.all.order(created_at: :desc)
    @post = Post.new
  end

  def create
    @post = Post.new(post_params)
 respond_to do |format|
      if @post.save
 redirect_to posts_path
      else
 render :index
      end
    end
  end

  def like
    Post.find_by(id: params[:post_id]).increment(:likes_count).save
 redirect_to posts_path
  end

  def repost
    Post.find_by(id: params[:post_id]).increment(:repost_count).save
 redirect_to posts_path
  end

  private

  def post_params
 params.require(:post).permit(:body)
  end
end

Simple controller. The index action returns a list of posts to @post. create uses StrongParameters, creates a new Post, and redirects back to the index template. like and repost are similar, except they increment the respective count columns.

Let's wire up a few routes to match up to those controller actions. Yes, these aren't perfect RESTful routes, but 1) They work. 2) This is a 10-minute tutorial. 3) POST requests did not get the other browser window to update with the changes in my small app here. (If anyone knows why, I'd be happy to hear!)

Rails.application.routes.draw do
 resources :posts, only: %i[index create] do
 get 'like'
 get 'repost'
  end

 root to: 'posts#index'
end

With a Model, Controller, and routes, we can put together some view templates. We can now add the "magic sauce" to the application layout to listen for refresh broadcasts.

<!DOCTYPE html>
<html>
  <head>
    <title><%= content_for(:title) || "Blabber" %></title>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <meta name="apple-mobile-web-app-capable" content="yes" />
    <meta name="mobile-web-app-capable" content="yes" />
    <%= csrf_meta_tags %> <%= csp_meta_tag %> <%= turbo_refreshes_with method:
    :replace, scroll: :preserve %> <%= yield :head %> <%# Enable PWA manifest
    for installable apps (make sure to enable in config/routes.rb too!) %> <%#=
    tag.link rel: "manifest", href: pwa_manifest_path %>

    <link rel="icon" href="/icon.png" type="image/png" />
    <link rel="icon" href="/icon.svg" type="image/svg+xml" />
    <link rel="apple-touch-icon" href="/icon.png" />

    <%# Includes all stylesheet files in app/views/stylesheets %> <%=
    stylesheet_link_tag :app, "data-turbo-track": "reload" %> <%=
    javascript_importmap_tags %> <%= stylesheet_link_tag "application",
    "data-turbo-track": "reload" %>
  </head>

  <body>
    <%= yield %>
  </body>
</html>

The yield :head by the rails new command, and just above it, we added <%= turbo_refreshes_with method: :replace, scroll: :preserve %> to tell the application to listen for refreshes.

The first view template up is the app/views/posts/index.html.erb:

<div class="container">
  <h1>Blabber</h1>
  <h4>A Rails, Hotwire demo</h4>

  <%= render partial: 'form' %> <%= turbo_stream_from 'posts' %> <%= render
  @posts %>
</div>

The view is a relatively simple Rails template. It uses a render @posts method to render the collection of @posts using a posts/_post partial. The turbo_stream_from:posts hooks up the view layer to listen to the Post model's broadcasts.

The partial is some pretty standard singular object markup with some Bootstrap classes thrown in to make it look half-decent:

app/views/posts/_posts.html.erb

<%= turbo_stream_from post %>
<div class="card mb-2" id="<%= dom_id(post) %>">
  <div class="card-body">
    <h5 class="card-title text-muted">
      <small class="float-right"> Posted at <%= post.created_at %> </small>
      <%= post.username %>
    </h5>
    <div class="card-text lead mb-2"><%= post.body %></div>
    <%= link_to post_repost_path(post), { class: 'card-link', data: {
    turbo_prefetch: false }} do %> Repost (<%= post.repost_count %>) <% end %>
    <%= link_to post_like_path(post), { class: 'card-link', data: {
    turbo_prefetch: false }} do %> Likes (<%= post.likes_count %>) <% end %>
  </div>
</div>

Another turbo_stream command is used to listen for broadcasted updates and deletions, and the dom_id helper is used to create conventional Rails View IDs model_resource-id. In this case, it would look like posts_1, etc.

Up next is a straightforward Rails form:

<%= form_with model: @post, id: dom_id(@post), html: {class: 'my-4' } do |f| %>
<% if @post.errors.any? %>
<div id="error_explanation">
  <h2>
    <%= pluralize(@post.errors.count, "error") %> prohibited this post from
    being saved:
  </h2>

  <ul>
    <% @post.errors.full_messages.each do |msg| %>
    <li><%= msg %></li>
    <% end %>
  </ul>
</div>
<% end %>
<div class="form-group">
  <%= f.text_area :body, placeholder: 'Enter your blab', class: 'form-control',
  rows: 3 %>
</div>

<div class="actions"><%= f.submit class: "btn btn-primary" %></div>
<% end %>

If you remember the index.html.erb, another frame wrapped the form's render call. Thus, we included the dom_id to allow the controller's create action to enable Turbo to manage the streams' markup.

Now we'll head back to the controller to talk about the create action in depth:

def create
    @post = Post.new(post_params)
    respond_to do |format|
      if @post.save
        redirect_to posts_path
      else
        render :index
      end
    end
  end

Previously, at this point, we'd discuss returning streams in the markup to be appended to the top-level frame, but Turbo 8's refreshes and broadcasts manage all of that without any extra changes.

At this point, you should have an app that you can open in two browsers, which should look like this!

There you go! If everything went well, this was the fastest Twitter clone tutorial yet and probably required the least lines of code! Time will tell how all of this will play well together and scale in complex real-world Rails applications, but for now, the reduction in developer complexity is a huge win!

How to Build a Twitter Clone with Rails and Hotwire

Rob Race — Fri, 28 Jul 2023 07:51:14 +0000

Hotwire is fresh out of the Basecamp Github and has set the Rails community ablaze. This quick write up is an update from How to Build a Twitter Clone with rails, ActionCable, and React to show a comparison between the two approaches.

Now, this doesn't mean to throw away any React code you may be using or StimulusReflex if you have already gone down that path. Those approaches are both more mature and widely discoverable.

I may follow this up with a video to do a more side-by-side look at these two approaches.

Without further ado, let's get started with a new app:

rails new blabber --no-spring

Rails will do its thing, install the application, install the gems, process the Webpacker install, and install the NPM packages.

Next, we will want to add the hotwire-rails gem to get the libraries needed:

gem "hotwire-rails", "~> 0.1.1"

Bundle and run the installer command for Hotwire:

bundle install
rails hotwire:install

Now, let's make a model to hold the data to clone a tweet in this Twitter clone called Blabber. All basic attributes:

rails g model Post username body:text likes_count:integer repost_count:integer

To keep this closely resembling the CableReady/StimulusReflex/React article, we'll add the same validation in the Post model:

class Post < ApplicationRecord
  after_create_commit { broadcast_prepend_later_to 'posts' }
  after_update_commit { broadcast_replace_later_to 'posts' }
  after_destroy_commit { broadcast_remove_to 'posts' }

  validates :body, length: { minimum: 1, maximum: 280 }
end

One difference you see is the callbacks. When using Hotwire, the prevailing convention is to use ActiveRecord callbacks. While working on the model collection, you can set up callbacks for create, update, and destroy broadcasts.

We'll make a few small adjustments to the generated migration file to add some database-level defaults (and allows us to keep the code around Post creation simple):

class CreatePosts < ActiveRecord::Migration[6.0]
  def change
    create_table :posts do |t|
      t.string :username, default: 'Blabby'
      t.text :body
      t.integer :likes_count, default: 0
      t.integer :repost_count, default: 0

      t.timestamps
    end
  end
end

Ok! Now, we're ready to run that migration!

rails db:migrate

With the Model and Database layer out of the way, we can move on to the controller and corresponding view templates!

def index
  @posts = Post.all.order(created_at: :desc)
  @post = Post.new
end

def create
  @post = Post.new(post_params)
  respond_to do |format|
    if @post.save
      format.html { redirect_to posts_path }
    else
      format.html { render :index }
      format.turbo_stream { render turbo_stream: turbo_stream.replace(@post, partial: 'posts/form', locals: { post: @post }) } ## New for this article
    end
  end
end

def like
  Post.find_by(id: params[:post_id]).increment(:likes_count).save ## New for this article
  redirect_to posts_path
end

def repost
  Post.find_by(id: params[:post_id]).increment(:repost_count).save ## New for this article
  redirect_to posts_path
end

private

def post_params
  params.require(:post).permit(:body)
end

Simple controller. The index action returns a list of posts to @post. create uses StrongParameters, creates a new Post, and addresses some Turbo::Stream usage (more on that soon), and redirects back to the index template. like and repost are similar except they increment the respective count columns.

Let's wire up a few routes to match up to those controller actions. Yes, these aren't perfect RESTful routes, but 1) They work. 2) This is a 10-minute tutorial. 3) Are GET requests making sure we do not have to worry about AJAX/fetch/CSRF in the front-end. You would work around these issues in a production application.

Rails.application.routes.draw do
  resources :posts, only: %i[index create] do
    get 'like'
    get 'repost'
  end

  root to: 'posts#index'
end

With a Model, Controller, and routes, we can put together some view templates. We'll start by adding Bootstrap CDN CSS. This way, we can wire up some UI interfaces pretty quickly!

<!DOCTYPE html>
<html>
  <head>
    <title>Blabber</title>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>

    <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
    <link href="https://stackpath.bootstrapcdn.com/bootstrap/4.4.1/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-Vkoo8x4CGsO3+Hhxv8T/Q5PaXtkKtu6ug5TOeNV6gBiFeWPGFN9MuhOf23Q9Ifjh" crossorigin="anonymous">
    <%= yield :head %>
    <%= turbo_include_tags %>
    <%= stimulus_include_tags %>
  </head>

  <body>
    <%= yield %>
  </body>
</html>

The yield :head, turbo_include_tags, and stimulus_include_tags were all added earlier by the hotwire:install command.

The first view template up is the app/views/posts/index.html.erb:

<div class="container">
  <h1>Blabber</h1>
  <h4>A Rails, Hotwire demo</h4>

  <%= turbo_frame_tag 'post_form' do %>
    <%= render partial: 'form' %>
  <% end %>

  <%= turbo_stream_from :posts %>
  <%= turbo_frame_tag 'posts' do %>
      <%= render @posts %>
  <% end %>
</div>

The view is a relatively simple usage of Rails, with a render @posts method, rendering the collection of @posts, using a posts/_post partial. The turbo_frame_tag's will allow the Turbo libraries to instantiate the "frames" that will manage the HTML partials sent over the wire from the broadcasted changes. A lot is going on with that process, but Hotwire and Rails are taking care of it all and merely managing the markup. Specifically, turbo_stream_from :posts hooks up the view layer to listen to the Post model's broadcasts.

The partial is some pretty standard singular object markup with some Bootstrap classes thrown in to make it look half decent:

app/views/posts/_posts.html.erb

<%= turbo_stream_from post %>
<div class="card mb-2" id="<%= dom_id(post) %>">
  <div class="card-body">
    <h5 class="card-title text-muted">
      <small class="float-right">
        Posted at <%= post.created_at %>
      </small>
      <%= post.username %>
    </h5>
    <div class="card-text lead mb-2"><%= post.body %></div>
    <a class="card-link" href="<%= post_repost_path(post) %>">
      Repost (<%= post.repost_count %>)
    </a>
    <a class="card-link" href="<%= post_like_path(post) %>">
      Likes (<%= post.likes_count %>)
    </a>
  </div>
</div>

Another turbo_stream command to listen for broadcasted updates and deletions, and the dom_id helper to create conventional Rails View IDs model_resource-id. In this case, it would look like posts_1, etc.

Up next is a straightforward Rails form:

<%= form_with model: @post, id: dom_id(@post), html: {class: 'my-4' } do |f| %>
<% if @post.errors.any? %>
<div id="error_explanation">
  <h2>
    <%= pluralize(@post.errors.count, "error") %> prohibited this post from
    being saved:
  </h2>

  <ul>
    <% @post.errors.full_messages.each do |msg| %>
    <li><%= msg %></li>
    <% end %>
  </ul>
</div>
<% end %>
<div class="form-group">
  <%= f.text_area :body, placeholder: 'Enter your blab', class: 'form-control',
  rows: 3 %>
</div>

<div class="actions">
  <%= f.submit class: "btn btn-primary" %>
</div>
<% end %>

If you remember the index.html.erb, another frame wrapped the form's render call. Thus we included the dom_id to allow the controller's create action to enable Turbo to manage the streams' markup.

Now we'll head back to the controller to talk about the create action in depth:

def create
  @post = Post.new(post_params)
  respond_to do |format|
    if @post.save
      format.html { redirect_to posts_path }
    else
      format.html { render :index }
      format.turbo_stream { render turbo_stream: turbo_stream.replace(@post, partial: 'posts/form', locals: { post: @post }) }
    end
  end
end

On a failed save, it will instruct the form's partial to update the form frame with the form template, but this time with the errors markup triggered.

At this point, it should look like this!

There you go! I bet with a fast enough system to work through the Rails install, gem install, and javascript package installs, you could make it through this tutorial in less than 10 minutes!

How to get a User's Timezone into Rails

Rob Race — Fri, 28 Jul 2023 07:45:42 +0000

You may have noticed most applications that you interact with and care about your timezone will, at one point, as you for your timezone and normally prepopulate the dropdown with your location's timezone.

However, if you look for this functionality out-of-the-box in Rails, it does not seem to be there (or at least through all my sleuthing for My new app I am building). Though, I have the answer for how you can add this in about ten lines of code through one StimulusJS controller and your neighborhood Rails helpers.

First thing first, you will want to ditch the time_zone_select helper as the values used in there are not the same as what the browser will use in identifying time zones (I think Rails is not using the standard here, but I didn't dig into too much while solving the technical issue). Instead, we will use a regular select and modify the array sent to a select tag:

<div data-controller="timezone">
  <%= f.select :timezone, ActiveSupport::TimeZone.all.collect {|tz| ["(UTC#{ActiveSupport::TimeZone.seconds_to_utc_offset(tz.utc_offset)}) #{tz.name}", tz.tzinfo.name]}, {}, data: {"timezone-target" => "tz"} %>
</div>

When using a select tag, you can provide the second argument an array of strings to represent the "text" and option "value" in the dropdown options. Here "(UTC#{ActiveSupport::TimeZone.seconds_to_utc_offset(tz.utc_offset)}) #{tz.name}" will construct a string with the offset and Rails timezone name (i.e., (UTC-08:00) Pacific Time (US & Canada)) and have the options value as the more accepted America/Los_Angeles. Additionally, at the very end, you can see where we are setting up the StimulusJS controller to interact with our select element, data: {"timezone-target" => "tz"}, which will produce data-timezone-target="tz" in the markup. Lastly, this select tag was wrapped in a div with an attribute to use the Timezone controller, data-controller="timezone".

Next, we can jump to the StimulusJS controller, which will also be simple. It is easiest to use the Rails CLI command to create the controller and update any other files that include controllers into the application.js:

bin/rails g stimulus timezone

Note - If you do not have Stimulus installed, you can do so with instructions here: https://github.com/hotwired/stimulus-rails.

In the new timezone_controller.js, you can add the following code:

import { Controller } from "@hotwired/stimulus"

export default class extends Controller {

  static targets = ['tz']

  initialize() {
    this.tzTarget.value = Intl.DateTimeFormat().resolvedOptions().timeZone;
  }
}

The Intl.DateTimeFormat().resolvedOptions().timeZone; is the browser's javascript command for retrieving the timezone. Then, this.tzTarget.value = sets the dropdown value when the StimulusJS controller initializes.

That's it! About five lines of custom code and another handful of edits to existing Rails tools to pre-select the user's timezone in your Rails application!

This code, as-is, will not work for select boxes that need to be updated as it does not account for not overwriting an existing selected timezone provided by the backend. That'd be as easy as checking for the selected target's value in Stimulus.

Using Action Mailbox in Rails 6 to Receive Mail

Rob Race — Mon, 13 Jul 2020 16:07:42 +0000

Sending mail from a Rails application has been covered by hundreds or thousands of articles, however, there is not a ton of articles about receiving, parsing and using the new ActionMailbox.

The following is an excerpt from my book Build A SaaS App in Rails 6 and is used in a new product I am building Mail Buffer. Thus, I am standing by the tutorial here with real world usage!

Lastly, as this is an excerpt, this takes into account the chapter leading up to this section where the reader will have created an application, models for a Standup, Todo/Did/Blockers (which are Tasks) and a few mailers for outgoing mail.

Here goes nothing...

Another aspect of email within a SaaS application is receiving mail. While this is far less normal or used in comparison to sending, it can be a great way to make end user's responses to email or action items quicker.

At a high level, there are a few different layers to this. The topmost layer is the email service, and this book's case, Sendgrid. This service handles sending outbound emails, as well as routing incoming emails to an address/domain name specified in their interface. Once the email is routed, it will be redirected to a route and processor file in your application. This file will be responsible for parsing the incoming email address and using logic to decide what to do with it.

In the case of the Standup App we are building, we can have directions to respond to an Email Reminder to create a new standup right from their email response! Some of the tools that we will be using are Sendgrid's email routing service and ngrok, an HTTP tunneling service. ngrok is very useful for a few solutions throughout the remainder of this book. It allows you to have a web-accessible URL, which tunnels(connects) to ports within your local machine. Meaning, that you will have a http://somesubdomain.ngrok.com that will forward to your computer and a specific port specified when you start ngrok. This allows you to test with external services such as Sendgrid, Stripe(later), Github(later), and more!

Let's get started with some setup:

Download and use ngrok
- Download ngrok
- Unzip and move the executable file to where you would like.
- In *nix OS's, open ngrok with: path/to/ngrok HTTP start 3000. This will be dependent on the port you are using for your Rails server. ngrok will now fire up a tunnel service with a randomly generated URL.
- Add config.hosts << "yoursubdomain.ngrok.io" to config/environments/development.rb
- Optionally, if you upgrade to a paid version of ngrok, you can set a subdomain, so you do not have to change your settings elsewhere every time you restart ngrok.
Follow your domain's DNS provider's instructions for adding an MX record for the subdomain or domain name you have chosen to use for inbound email. The MX record will be mx.sendgrid.net, with a priority of 10.

Now, before we head to the next part, we need to create and store a password for the incoming mail. You can use any method you like to create a password, and if you just can't think of any way to do so, you can run SecureRandom.alphanumeric in Rails console.

Now, to store this password you just came up with, we will need to introduce a new small, but powerful, feature, Rails Credentials. Since Rails 5.2, Rails provides a built-in way for storing secure credentials, that are encrypted.

To start using Rails Credentials, you will want to fire off the edit command:

EDITOR="atom --wait" rails credentials:edit

The editor I am using in this example is Atom. However, you can use any editor you like, and it's command line caller. Also, --wait is used to make sure that the editor will wait for Rails to finish decrypting the file before opening it in the editor.

Now that we have the encrypted file open, add the following lines:

action_mailbox:
  ingress_password: *password you just made*

Save the file and close the tab/editor to make sure Rails saves the file and encrypts it. You will notice when Rails first opened the file, there was some output text in your terminal. Which includes the master key, DO NOT LOSE THIS KEY. It will need to be used a the only text in a config/master.key to be able to encrypt and decrypt the credentials.

Now, with that out of the way, there is a little bit more setup we need to do for Action Mailbox.

First, two commands to get Rails and some tables set up for inbound email:

bin/rails action_mailbox:install
bin/rails db:migrate

Lastly, add the following line to the config/application.rb file to let Rails know we're using Sendgrid:

config.action_mailbox.ingress = :sendgrid

Ok, back to Sendgrid's setup:

In Sendgrid, go to the Inbound Parse link, under settings, to create the email route that will send the email. Enter the following settings:
- Enter app.yourdomain.com for the domain field. You can optionally choose an additional subdomain to receive emails within the Inbound Parse.
- Enter http://actionmailbox:THEPASSWORDFROMBEFORE@yoursubdomain.ngrok.io/rails/action_mailbox/sendgrid/inbound_emails as the destination URL.
- Check POST the raw, full MIME message, before pressing the submit button.

Ok, we're getting nearly done with the setup here. Next, we will need to set up the applications inbound email route and run a command to generate that mailbox class. First, in the application_mailbox.rb file that was created just a few commands ago, you will add routing /standups\.[0-9a-fA-F]{8}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{12}@/i => :standups. This says when an incoming mail matches that email address syntax, it will be routed to the standups mailbox class for processing.

After that, to create the mailbox file, you will just need to run a Rails generator:

bin/rails generate mailbox forwards

A few changes will be needed to allow Action Mailbox and its files to capture text from incoming replies.

First, we will update the EmailReminderMailer to create a unique reply-to address and include that email address as part of the outgoing email:

class EmailReminderMailer < ApplicationMailer
  def reminder_email(user, team)
    @user = user
    @team = team
    reply_to = "'Standups App' <standups.#{@user.id}@app.yourdomain.com>"
    make_bootstrap_mail(
      to: @user.email,
      subject: "#{team.name} Standup Reminder!",
      reply_to: reply_to
    )
  end
end

Here we are adding the reply_to string to so when someone replies to a reminder email, the reply will be routed through Sendgrid, to Action Mailbox, and then finally by the Standup Mailbox class.

Next, we will update the mailer template to have ##- Please type your reply above this line -## and some text letting the email recipient know they can add a standup by replying:

<div class="container">
  <span class="text-secondary text-center" style="font-size:8px">##- Please type your reply above this line -##</span>
  <h1 class="text-center mb-4">
    Standup App
  </h1>
  <div class="card mb-4">
    <div class="card-body">
      <h3 class="text-center mb-4"><%= @team.name%> Reminder! </h3>
      <p class="mb-4">
        Just wanted to remind you to add your standup for
        the team: <%= @team.name %>
      </p>
      <%= link_to "Add Your Standup", new_standup_url(), {class: "btn btn-primary btn-lg mx-auto mt-2", style: "width:95%"} %>
    </div>
  </div>
</div>

Lastly, we will need to add an extra column to the Standups table to track the Message-ID coming from the Mailgun routed emails. As you can not count on an email service to provide "just once" delivery, we will need to track these unique IDs ourselves on the Standup table.

rails g migration AddMessageIdToStandups message_id

Next, before the end of the newly created migrations change method, you will want to add add_index :standups, :message_id. This index will allow quick lookups as the Standups table grows. Finally, migrate the actual change:

rails db:migrate

Lastly, to make sure sidekiq picks up the queues that Rails uses for Action Mailbox, we will need to adjust the worker in the Procfile.dev to:

worker: bundle exec sidekiq -q default -q mailers -q action_mailbox_routing -q active_storage_analysis

With those changes out of the way we can now add the new StandupsMailbox class that will parse the incoming email:

class StandupsMailbox < ApplicationMailbox
  TASK_TYPE_HASH = {
    '[d]' => 'Did',
    '[t]' => 'Todo',
    '[b]' => 'Blocker'
  }

  def process
    # Get a user id from reply-to or bail
    reply_user = mail.to.first&.split('<')&.last&.split('@')&.first&.split('.')&.last
    return if reply_user.blank?

    # Find a user by the id or bail
    user = User.find_by(id: reply_user)
    return if user.nil?

    # Bail if standup with incoming message-id exists
    return if Standup.exists?(message_id: inbound_email.message_id)

    # Bail if a standup for today exists
    today = Date.today.iso8601
    return if Standup.exists?(standup_date: today)

    # Get content or bail
    safe_body = Rails::Html::WhiteListSanitizer.new.sanitize(mail_body)
    tasks_from_body = safe_body.scan(/(\[[dtb]{1}\].*)$/)
    return if tasks_from_body.blank? || tasks_from_body.empty?

    build_and_create_standup(
      user: user,
      tasks: tasks_from_body,
      date: today,
      message_id: inbound_email.message_id
    )
  end

  private

  def build_and_create_standup(user:, tasks:, date:, message_id:)
    standup = Standup.new(
      user_id: user.id,
      standup_date: date,
      message_id: message_id
    )

    tasks.each do |task|
      task_type, task_body = task.first.scan(/(\[[dtb]\])(.*)$/).flatten
      standup.tasks << Task.new(type: TASK_TYPE_HASH[task_type], title: task_body)
    end

    standup.save
  end

  def mail_body
    @mail_body ||= begin
      if mail.multipart?
        mail.parts[0].body.decoded
      else
        mail.decoded
      end
    end
  end
end

The class is relatively simple, but let's go over it section by section:

class StandupsMailbox < ApplicationMailbox
  TASK_TYPE_HASH = {
    '[d]' => 'Did',
    '[t]' => 'Todo',
    '[b]' => 'Blocker'
  }

  ...

Here we are setting up the StandupsMailbox to inherit from the ApplicationMailbox class, which handles the routing. Additionally, we are creating a hash to later use in the text content to Task type conversion.

...

def process
  # Get a user id from reply-to or bail
  reply_user = mail.to.first&.split('<')&.last&.split('@')&.first&.split('.')&.last
  return if reply_user.blank?

  # Find a user by the id or bail
  user = User.find_by(id: reply_user)
  return if user.nil?

  # Bail if standup with incoming message-id exists
  return if Standup.exists?(message_id: inbound_email.message_id)

  # Bail if a standup for today exists
  today = Date.today.iso8601
  return if Standup.exists?(standup_date: today)

  # Get content or bail
  safe_body = Rails::Html::WhiteListSanitizer.new.sanitize(mail_body)
  tasks_from_body = safe_body.scan(/(\[[dtb]{1}\].*)$/)
  return if tasks_from_body.blank? || tasks_from_body.empty?

...

Here we are grabbing some information used in the parsing, as well as giving the process method chances to exit early if the incoming email is not sufficient for processing and Standup creation. In the first section, the incoming email address is parsed to find the user's id. That string is then used to find a User. If there is no user, the method returns without adding a Standup.

The next line will exit the method early if there is already a standup with the current Message-ID. Again, this is making sure to guard against email providers, not guaranteeing "just once" delivery. That is followed up by generating a variable for the current date and making sure there is no standup with the current_user and current_date.

To get the mail's content, we will want to do two things, make sure we get the correct body from the mail object as email clients can send both an HTML and plain text version. Then we will want to make sure we only grab the content above the ##- Please type your reply above this line -## string by using the split method (which splits a string into as many parts based on the separator specified in the argument):

def mail_body
    @mail_body ||= begin
      body = if mail.multipart?
        mail.parts[0].body.decoded
      else
        mail.decoded
      end
      body.split('##- Please type your reply above this line -##').first
    end
  end

Finally, the actual email content is parsed with a regular expression. Regular Expression is a programming language that allows you to pattern match on a string and even capture parts of the pattern matching. This particular pattern(which you can get a more thorough syntax explanation here) searches for lines that begin with [d], [t] or [r]. If those are present, it captures the content to the end of the line. The .scan method on the content's body allows it to catch all occurrences of the above pattern. If the scan's output is empty, the process method exits.

  build_and_create_standup(
      user: user,
      tasks: tasks_from_body,
      date: today,
      message_id: email.headers["Message-ID"]
    )
  end

  private

  def build_and_create_standup(user:, tasks:, date:, message_id:)
    standup = Standup.new(
      user_id: user.id,
      standup_date: date,
      message_id: message_id
    )

    tasks.each do |task|
      task_type, task_body = task.first.scan(/(\[[dtb]\])(.*)$/).flatten
      standup.tasks << Task.new(type: TASK_TYPE_HASH[task_type], title: task_body)
    end

    standup.save
  end
end

The last section here is a culmination of all of the stored information so far to be saved into a new Standup. The user, tasks_from_body, today, and message_id are all passed into a method that will hand the actual save. The build_and_create_standup method creates a new Standup, with the user's ID, date, and message_id. Once the object is created, the task's strings are iterated over to build the Task with a type and assigned as child objects with the << syntax. Finally the new Standup object with children Tasks will be saved with standup.save

Lastly, you can test this all works if you reply back to an email(that was sent through Sendgrid SMTP and not letter_opener) with the following text:

[d] Did a thing
[d] And Another
[t] Something to do
[b] Something in the way. Some really long line about something or another

Testing this will require a new spec file with a few it blocks to test all the branches the StandupMailbox may encounter.

First, we will need to add one small change to the rails_helper.rb file to make sure RSpec has access to the Rails Action Mailbox test helpers. I'll add the new lines and a few lines above each, so you know where to put the new stuff:

...

require 'support/system_macros'
include Warden::Test::Helpers
require 'action_mailbox/test_helper' # <-- new line

...

RSpec.configure do |config|
  config.include Devise::Test::ControllerHelpers, type: :controller
  config.include Devise::Test::ControllerHelpers, type: :view
  config.include ActionMailbox::TestHelper, type: :mailbox # <-- new line

...

...and now the actual spec file itself:

require 'rails_helper'
include ActiveJob::TestHelper

RSpec.describe StandupsMailbox, type: :mailbox do
  let(:user) { FactoryBot.create(:user) }
  let(:to_email) { "standups.#{user.id}@app.buildasaasappinrails.com" }
  let(:body) do
    %Q(
      [d] Did a thing
      [d] And Another
      [t] Something to do
      [b] Something in the way. Some really long line about something or another

      ##- Please type your reply above this line -##
    )
  end

  subject do
    receive_inbound_email_from_mail(
      from: user.email,
      to: to_email,
      subject: 'Re: Reminder',
      body: body
    )
  end

  before do
    ActiveJob::Base.queue_adapter = :test
  end

  it 'saves standup record' do
    expect { subject }.to change(Standup, :count).by(1)
  end

  it 'saves task records' do
    expect { subject }.to change(Task, :count).by(4)
  end

  context 'fails on bad to email' do
    let(:to_email) {"standups@app.buildasaasappinrails.com"}

    it 'does not save standup record' do
      expect { subject rescue nil }.to_not change(Standup, :count)
    end
  end

  context 'fails on no user' do
    let(:to_email) {"standups.9a859af8-30ca-4473-b073-47105352d936@app.buildasaasappinrails.com"}

    it 'does not save standup record' do
      expect { subject rescue nil }.to_not change(Standup, :count)
    end
  end

  context 'fails on useless body' do
    let(:body) { 'asdj;oisaduaskd' }

    it 'does not save standup record' do
      expect { subject rescue nil }.to_not change(Standup, :count)
    end
  end

  context 'fails on empty body' do
    let(:body) { '' }

    it 'does not save standup record' do
      expect { subject rescue nil }.to_not change(Standup, :count)
    end
  end
end

While long and containing six examples, this spec is actually pretty straightforward. It is first testing the happy path where everything is set up and working. Then checks each failing path that doesn't create a standup, in order as those paths appear in the StandupsMailbox's .process method.

19 Must-Have Gems for 2020

Rob Race — Tue, 19 May 2020 23:15:49 +0000

An application can only be as good as the features it is providing for its end-users. Every developer toes the line between indiscriminately adding gems and building new functionality themselves. When time is of the essence, these are the gems I reach for:

local_time - An relatively older gem and stable, but this is a gem that includes a view helper and javascript helper to display relative time (i.e. 'updated 2 minutes ago')
devise - Devise is still the go-to gem for authentication in most Rails apps. Its ease of use and existing features make it dead-simple to add authentication. For those looking for a simpler gem with a smaller footprint, Authlogic gets a runner up in this list for authentication.
Interactor - When you start to follow the Service Object pattern, adding Interactor can help guide your context and result of those objects through a common interface.
rolify and cancancan - Rolify allows us to assign roles such as User or Admin then CanCanCan will enable us to take those roles and apply authorization policies. However, there is a case for Pundit for those who like the Policy Object approach's simplicity.
Lockbox - When you need to encrypt data in your database for compliance or even client security, Lockbox makes it very easy to do. Working with plenty of types out of the box, such as most database types, other Rails tools(ActiveStorage), and third-party gems(Shrine).
Sidekiq - This is the gem when it comes to running asynchronous tasks. Sidekiq is backed by Redis and has been long supported by the ActiveJob Rails abstractions.
Kaminari - A simple yet powerful approach to adding pagination into your Rails applications. In many places, it is as simple a few drop-in changes, but can be used to on anything from ActiveRecord collections to plain Arrays. It also has templates to be used in many of the most known CSS frameworks such as Bootstrap.
Bootstrap Email - Take the guesswork out of email design and CSS inlining inside of Rails Mailers. This gem allows you to use Bootstrap-like HTML structures, use a Bootstrap like design, and inline the CSS to work in most email browser/apps. Quite the timesaver!
money-rails - This will help standardize around common issues found when calculating money as well as providing a few template helpers.
Rack Mini Profiler - Everyone should know what their application is doing and where it is spending its time. This gem adds a profiler to the development pages and can include some nifty flame graphs when you really want to dig into the data.
rspec-rails, factory_bot_rails, simplecov - I personally like to use RSpec over the default Rails test framework. Though, the community can be quite divisive on testing tools! With every test suite, I include FactoryBot to easily spin up objects for those specs and SimpleCov to dig into my test coverage.
letter_opener - Still my #1 gem for working with email in a Rails app. In your local development, it catches the outgoing mail and opens in a browser, rendering it as it would an email.
Faraday or HTTParty - When I am looking to handle an extensive HTTP API or system, I will reach for the infinitely configurable Faraday. Still, when there are only a few HTTP interactions needed, HTTParty is super simple to use to make HTTP calls.

Note: This list is the type of content you would find in my upcoming book Build A SaaS App in Rails 6. The book guides you from humble beginnings by deploying an app to production. The book is now in pre-sale (but not for long), and you can grab a free chapter right now!

DEV Community: Rob Race

Free Rails Architecture Checkup: run it in Codex, Claude Code, Cursor, etc. It shows where your app gives agents conflicting instructions, hides key architecture, or leaves risky decisions up to guesswork. https://railsbaseline.com/checkup/try/

Try the Rails Architecture Checkup — Rails Baseline

Your Webhook Endpoint is a Tiny Distributed System

First, can you trust the request?

Receiving and processing are two different jobs

What does 2xx actually mean?

Duplicate delivery is normal

Idempotency does not remove concurrency

There are two retry systems

And then events arrive out of order

Every provider has its own little rules

A 200 is not observability

Ok, so we built a tiny distributed system

I Tested Rails Baseline by Leaving Architecture Out of the Prompt

Why test the starter this way?

Test one: build a feedback board

The useful miss

Test two: build an endpoint monitor

The second app found harder gaps

And, yes, the agent still wrote a bug

What I actually learned from the tests

I will probably keep doing this

Print Smarter in Ruby - Know When and How to Use Each Method

puts: Standard Output with Automatic Newlines

print: Continuous Output Without Newlines

p: Debugging with Inspect Output

pp: Pretty Print for Enhanced Readability

y: YAML Output in IRB

Quick Summary

awesome_print: Enhanced Pretty Printing with Style

Installation

Usage

Avoiding N+1 Queries in Rails: Easy Performance Wins for Beginners

What is an N+1 Query?

How to Detect N+1 Queries

1. Check Your Logs

2. Use the bullet Gem

How to Fix N+1 Queries

Use Eager Loading with .includes

When to Use .joins or .preload

Common Mistakes and Gotchas

Real-World Example

Preventing N+1s Going Forward

Leveraging Turbo 8: Best Additions to Implement in Rails 8 Projects

Setup

Turbo Morph

Presence Channel

Typing Indicators

Conclusion

Rails Console in the Browser (on-demand)

Why in the browser?

How to set it up

Taking it a step further

Alternate Idea

How to Build a Twitter Clone with Rails 8 and Turbo 8

How to Build a Twitter Clone with Rails and Hotwire

How to get a User's Timezone into Rails

Using Action Mailbox in Rails 6 to Receive Mail

19 Must-Have Gems for 2020

What does `2xx` actually mean?

A `200` is not observability

`puts`: Standard Output with Automatic Newlines

`print`: Continuous Output Without Newlines

`p`: Debugging with Inspect Output

`pp`: Pretty Print for Enhanced Readability

`y`: YAML Output in IRB

`awesome_print`: Enhanced Pretty Printing with Style

2. Use the `bullet` Gem

Use Eager Loading with `.includes`

When to Use `.joins` or `.preload`