DEV Community: Juan Vasquez

From Turbo Streams to Turbo Morph: Simplifying Real-Time Rails

Juan Vasquez — Mon, 06 Apr 2026 14:30:00 +0000

The Setup

I'm building a multitenant order management system for cafes and restaurants. Orders come in, the kitchen sees a live queue, waiters track item status — all updating in real time across multiple screens.

The natural first choice in Rails? Turbo Streams — targeted DOM updates over WebSocket. Replace this partial, append to that list, remove that element.

It worked. Until it didn't.

I Almost Kept Targeted Broadcasts

On March 13, I made a deliberate decision to keep targeted Turbo Stream broadcasts. The infrastructure worked, the tests passed, and I'd already invested time building it. I documented the decision and moved on.

Six days later, I reversed it.

What changed? I started building the kitchen queue — a live view where cooks see incoming orders. The queue needed to stay in sync with the order page, the tables view, and the takeout view. Every item status change had to update all four screens simultaneously.

That's when the targeted approach fell apart. Not because of a single bug, but because the coordination cost grew faster than the features. Each new view multiplied the number of broadcast methods, target IDs, and partials I had to keep in sync.

The moment I caught myself writing the fifth broadcast method for a single status change, I knew the architecture was wrong.

The Problem With Targeted Broadcasts

Here's what my LineItem model looked like with targeted Turbo Stream broadcasts:

after_update_commit :broadcast_item_update, if: :saved_change_to_status?

private

def broadcast_item_update
  broadcast_replace_to "order_#{order_id}",
    target: "line_item_#{id}",
    partial: "line_items/line_item",
    locals: { item: self, order: order }

  broadcast_kitchen_update
  broadcast_spot_update
end

def broadcast_kitchen_update
  case status
  when "cooking"
    broadcast_append_to "store_#{order.store_id}_kitchen",
      target: "kitchen-queue",
      partial: "kitchen/line_item_card",
      locals: { item: self }
  when "ready"
    broadcast_replace_to "store_#{order.store_id}_kitchen",
      target: "kitchen_line_item_#{id}",
      partial: "kitchen/line_item_card",
      locals: { item: self }
  when "cancelled", "delivered"
    broadcast_remove_to "store_#{order.store_id}_kitchen",
      target: "kitchen_line_item_#{id}"
  end
end

def broadcast_spot_update
  broadcast_replace_to "store_#{order.store_id}_tables",
    target: "spot_#{order.spot_id}",
    partial: "tables/table",
    locals: { spot: order.spot, order: order }

  if order.spot.takeout?
    broadcast_replace_to "store_#{order.store_id}_takeouts",
      target: "takeout_order_#{order.id}",
      partial: "takeouts/order_card",
      locals: { order: order }
  end
end

That's one model. The Order model had a similar amount. In total, roughly 120 lines of broadcast code across two models.

Every broadcast needed:

The correct channel name
The correct DOM target ID
The correct partial path
The correct locals with fresh data

And here's the real problem: every new real-time feature multiplied the complexity. Adding the kitchen queue meant adding broadcast methods for every status transition. Adding takeout support meant more targets, more partials, more conditionals.

The Bugs

Targeted broadcasts introduced two categories of bugs that morph eliminates entirely.

1. Stale Data

When a callback fires, self may have fresh attributes — but associations are still cached in memory.

# self.status is "ready" (correct)
# self.order.line_items still has the OLD status in memory
broadcast_replace_to "order_#{order_id}",
  partial: "orders/order_summary",
  locals: { order: order }

The order summary partial reads order.line_items to compute readiness. Since the association is stale, it renders with outdated data. The fix was manual .reload calls scattered across the code.

2. Double Broadcasts

When multiple models trigger broadcasts on the same commit, the same DOM target can get replaced twice in rapid succession, causing visible flicker.

The Switch to Morph

Turbo 8 introduced page refresh with morphing via turbo_refreshes_with method: :morph. Instead of surgically replacing individual DOM elements, it tells every subscribed browser: "re-fetch this page and I'll morph the differences."

Here's the same LineItem after the migration:

after_update_commit :broadcast_refreshes, if: :saved_change_to_status?

private

def broadcast_refreshes
  broadcast_refresh_to "order_#{order_id}"
  broadcast_refresh_to "store_#{order.store_id}_kitchen"
  broadcast_refresh_to "store_#{order.store_id}_tables"
  broadcast_refresh_to "store_#{order.store_id}_takeouts"
end

Four lines. No partials, no target IDs, no locals, no stale data.

What Changed in the Views

Each page that subscribes to real-time updates needs two things:

A turbo_stream_from tag (same as before)
A morph declaration

<%= turbo_refreshes_with method: :morph, scroll: :preserve %>
<%= turbo_stream_from "store_#{Current.store.id}_kitchen" %>

The scroll: :preserve part is important. Without it, every refresh scrolls the page to the top — completely unusable for a kitchen queue that staff are actively watching during service. With it, Turbo preserves scroll position, focus, and form state across morphs.

What Changed in the Controllers

Before, controllers had to handle both HTML and Turbo Stream responses:

def ready
  @line_item.mark_ready!(by: Current.user)
  @order.reload
  respond_to do |format|
    format.turbo_stream
    format.html { redirect_to order_path(@order) }
  end
end

Each action had a matching .turbo_stream.erb template with its own set of turbo_stream.replace calls.

After:

def ready
  @line_item.mark_ready!(by: Current.user)
  redirect_back fallback_location: order_path(@order),
    notice: t("kitchen.marked_ready")
end

Plain redirects. The model callbacks handle all real-time updates. I deleted three Turbo Stream templates and simplified every action method.

What We Deleted

The migration removed:

What	Lines
Model broadcast methods	~120
Turbo Stream templates	~30
Stimulus controllers (audio/queue)	~118
Total	~268

Three Stimulus controllers were deleted because they existed solely to coordinate DOM updates that morph now handles automatically — things like updating the queue count badge or toggling empty states.

The Flow After Morph

Here's how the real-time update cycle works now:

1. Kitchen staff taps "Listo" on a cappuccino
   → PATCH /orders/:id/line_items/:id/ready

2. Controller: mark_ready! → redirect_back

3. Model callback fires broadcast_refreshes:
   → broadcast_refresh_to order_42
   → broadcast_refresh_to store_1_kitchen
   → broadcast_refresh_to store_1_tables
   → broadcast_refresh_to store_1_takeouts

4. Every subscribed browser re-fetches its page.
   Turbo morphs the DOM diff.

   /kitchen    → card moves from "cooking" to "ready"
   /orders/42  → item badge turns green
   /tables     → table status updates
   /takeouts   → order card updates

5. No flicker. Scroll preserved. Focus preserved.

No partial coordination. No target ID matching. The server always renders the truth.

One thing worth noting: turbo_stream_from uses signed stream names by default, so your tenant-scoped channels (like store_#{id}_kitchen) are safe from unauthorized subscriptions out of the box.

Try It Yourself

Here's a minimal example you can drop into any Rails 8 app with Action Cable configured:

# app/models/message.rb
class Message < ApplicationRecord
  after_create_commit -> { broadcast_refresh_to "messages" }
  after_update_commit -> { broadcast_refresh_to "messages" }
  after_destroy_commit -> { broadcast_refresh_to "messages" }
end

<%# app/views/messages/index.html.erb %>
<%= turbo_refreshes_with method: :morph, scroll: :preserve %>
<%= turbo_stream_from "messages" %>

<h1>Messages</h1>

<% @messages.each do |message| %>
  <div id="<%= dom_id(message) %>">
    <p><%= message.body %></p>
    <small><%= time_ago_in_words(message.created_at) %> ago</small>
  </div>
<% end %>

Open two browser tabs. Create a message in one — the other updates instantly. No JavaScript, no stream templates, no target IDs. That's the entire real-time layer.

The Tradeoff

Morph re-renders the entire page on the server for every broadcast, instead of rendering a single partial. At scale, this matters.

At cafe/restaurant scale? It's negligible. A kitchen queue page with 15 items is trivial to re-render.

The other tradeoff: no more client-side reactions to specific events. With targeted streams, you could play a sound when an item was appended to the kitchen queue. With morph, you just get a re-rendered page — there's no "this specific thing changed" signal.

For audio notifications, I'll need a different approach — likely a small Stimulus controller listening to a dedicated Action Cable channel. Action Cable custom channels handle this cleanly.

When to Use Which

This experience gave me a clearer mental model:

Use Turbo Morph when:

Multiple views need to stay in sync
The data being displayed has complex interdependencies
You want real-time updates without managing DOM coordination
Your pages are lightweight enough to re-render

Use Targeted Turbo Streams when:

You need to react to specific events on the client (animations, sounds)
Re-rendering the full page is genuinely expensive
You have a single, well-defined target that changes in isolation

Final Thoughts

The most surprising part of this migration was how much incidental complexity the targeted approach had introduced. Code that felt necessary — all those broadcast methods, stream templates, Stimulus controllers — turned out to be scaffolding around a coordination problem that morph solves at a lower level.

I documented a decision to keep targeted broadcasts, then reversed it six days later. That's not a failure — that's the system working. The decision document forced me to articulate why I was keeping the old approach, which made it obvious when the reasons no longer held.

Sometimes the right move is to stop trying to be precise and let the framework do the work.

Migrating a Rails App from Heroku to Railway

Juan Vasquez — Tue, 31 Mar 2026 14:00:00 +0000

Last weekend I migrated my Doctors App from Heroku to Railway.

It's a multi-tenant Rails app where each hospital gets its own subdomain — one.doctors.com, two.doctors.com, and so on.

Five hospitals, around 25,000 appointments, 9,700+ patients. Not huge, but not trivial either.

Here's how it went, including the part where I accidentally broke the database.

The setup

I already had a Railway project running with a test domain (*.juanvasquez.dev) from earlier experiments. The web service was deployed from GitHub and the Postgres 17 instance was co-located in us-east4. Cloudflare R2 handles file storage — that stays the same regardless of where the app runs.

The plan was simple: put Heroku in maintenance mode, dump the database, restore it to Railway, flip the DNS, and go home.

The database restore

First, I captured a fresh Heroku backup and downloaded it:

heroku pg:backups:capture --app doctors
heroku pg:backups:download --app doctors --output /tmp/heroku_backup.dump

Then I wiped the Railway database and restored:

# Wipe
psql -h <railway-host> -p <port> -U postgres -d database_name \
  -c "DROP SCHEMA public CASCADE; CREATE SCHEMA public;"

# Restore
pg_restore --verbose --no-owner --no-acl \
  -h <railway-host> -p <port> -U postgres -d database_name /tmp/heroku_backup.dump

The restore threw two errors — both about the unaccent extension. Heroku installs extensions in a heroku_ext schema that doesn't exist on Railway. The fix is to just create it manually afterward:

psql -h <railway-host> -p <port> -U postgres -d database_name \
  -c "CREATE EXTENSION IF NOT EXISTS unaccent;"

Everything else restored cleanly. I verified every table:

Table	Heroku	Railway
users	9,752	9,752
appointments	25,481	25,481
addresses	9,835	9,835
patient_referrals	1,211	1,211
hospitals	5	5

All 12 tables matched exactly. If you take one thing from this post: always verify row counts after a restore.

The moment I broke the database

With the data restored, I wanted to trigger a deploy on the web service. I ran:

railway up --detach

Without --service web.

That command deployed my Rails application code onto the Postgres service. It replaced the PostgreSQL 17 container with Puma. The database was now a Rails web server that couldn't handle Postgres connections.

The logs told the story immediately:

HTTP parse error, malformed request: #<Puma::HttpParserError:
Invalid HTTP format, parsing fails. Are you trying to open
an SSL connection to a non-SSL Puma?>

The web service was trying to connect to Postgres, but Postgres was now running Puma, responding to TCP connections with HTTP errors.

The fix was to roll back the Postgres service to its last good deployment. Railway's CLI doesn't have a rollback command, so I used the dashboard to roll back the deployment.

After about 45 seconds, Postgres was back. Data intact. Lesson learned: always pass --service web when deploying.

Flipping the domain

Removing the test domain was another adventure. Railway's CLI can add domains but can't delete them. I used the dashboard to remove it.

Then I added the production wildcard domain:

railway domain "*.doctors.com" --service web --port 8080

Railway returned the DNS records I needed. In Squarespace (my domain registrar), I added:

Type	Host	Value
CNAME	`*`	`znjcefnu.up.railway.app`
CNAME	`_acme-challenge`	`znjcefnu.authorize.railwaydns.net`

There was also a _railway-verify record for domain ownership. I initially tried adding it as a CNAME, but Squarespace rejected the value — it's actually a TXT record, not a CNAME. Small thing, but it tripped me up.

DNS propagated fast. Within a couple of minutes, Railway confirmed the domain was verified and SSL was provisioned.

One more thing: RACK_ENV

The first request to demo.doctors.com returned a 500. I checked the logs and saw... a Rails development error page. RACK_ENV was set to development. A quick variable update and redeploy fixed it:

railway variable set RACK_ENV=production --service web

Then all five hospital subdomains came back with 200s.

Trial plan limitations

Railway's trial plan only allows one custom domain per service. The wildcard *.doctors.com uses that single slot, which works great for multi-tenancy — every subdomain routes correctly. But I can't also add the root domain doctors.com. For now, I'll handle that with a redirect at the registrar level.

Pricing

	Heroku	Railway
Web service	$7/mo (Basic dyno)	Usage-based (~$5/mo)
Postgres	$5/mo (Mini)	Included (500MB)
Custom domains	Included	1 per service (trial)
SSL	Automatic	Automatic
Chrome buildpack	Required for old PDF setup	Not needed (using Prawn now)

For my scale, Railway is slightly cheaper. The real win is simplicity — no buildpack configuration, no add-on marketplace to navigate, and Postgres is just there.

What I also did

While I was at it, I replaced Sentry with Honeybadger (referral link) for error tracking. Sentry's initializer still referenced Heroku env vars, so it was a good time to clean house. Honeybadger has a free plan, built-in uptime monitoring, and the Rails setup is just a YAML file:

# config/honeybadger.yml
api_key: <%= ENV.fetch("HONEYBADGER_API_KEY", "") %>
env: <%= Rails.env %>
exceptions:
  enabled: <%= Rails.env.production? %>

I also updated the CI pipeline — upgraded Postgres from 10.13 to 17 (matching production) and Node.js from 20 to 22 (matching package.json). Removed the Puppeteer and Chrome setup steps that were left over from when the app used Grover for PDF generation.

Things I'd tell myself before starting

Verify row counts after every restore. Don't trust "no errors" — count the rows.
Always specify --service when running Railway CLI commands. Especially railway up.
Railway's CLI can't do everything. Domain deletion and deployment rollbacks need to be done through the dashboard.
railway run executes locally, not on Railway's infrastructure. Use railway shell for remote access.
Heroku's heroku_ext schema for extensions doesn't exist on Railway. Expect restore errors for extensions, and re-create them manually.
Check your RACK_ENV. It seems obvious, but it's easy to forget when you're focused on the database.
The _railway-verify DNS record is a TXT record, even though it looks like it could be a CNAME. Your registrar will reject it if you pick the wrong type.

Fair warning

Since migrating, I've seen reports from other developers that give me pause. One team experienced persistent 150–200ms request queuing on Railway that they couldn't resolve even with Pro plan support — response times that were 40ms on Heroku, Render, and DigitalOcean. Another long-time customer reported a caching misconfiguration that leaked user data between accounts, on top of weeks of near-daily incidents.

I measured my own response times after reading these reports, and for my scale they're good enough. But if you're running something larger, do thorough stress testing before committing, and have a rollback plan. Railway is young, and that cuts both ways: fast iteration, but also growing pains.

Was it worth it?

The whole migration took about an hour. Most of that was waiting for DNS propagation and debugging the Postgres incident. The actual work — dump, restore, set variables, flip DNS — was maybe 30 minutes.

Railway feels like what Heroku should have become. The dashboard is clean, deploys are fast, and the Postgres integration just works. I miss heroku run (Railway's local execution model is confusing at first), but railway shell covers most cases.

For a small multi-tenant Rails app like mine, it's a good fit. But I'm keeping my Heroku knowledge fresh — just in case.

Alacritty-Themes release 4.1.2 🌈😍

Juan Vasquez — Tue, 21 Sep 2021 16:28:23 +0000

Today, was released alacritty-themes 4.1.2

Bug Fixes

stop removing existing comments on the alacritty file #42 98a5d68, closes #30

test it here Themes for Alacritty: A cross-platform GPU-accelerated Terminal emulator

Dogs are most responsive to commands spoken in Spanish.

Juan Vasquez — Fri, 13 Aug 2021 12:39:03 +0000

Dogs are most responsive to commands spoken in Spanish.

True 🟢 False 🔴 ?

If you know why, how, when, or whatever interesting things related to the question, Please share with us.

if you cry in space. the tears will stick to your face.

Juan Vasquez — Thu, 12 Aug 2021 19:05:09 +0000

if you cry in space. the tears will stick to your face.

True 🟢 False 🔴 ?

If you know why, how, when, or whatever interesting things related to the question, Please share with us.

The first pair of scissors manufactured was left handed.

Juan Vasquez — Wed, 11 Aug 2021 12:59:22 +0000

The first pair of scissors manufactured was left handed.

True 🟢 False 🔴 ?

If you know why, how, when, or whatever interesting things related to the question, Please share with us.

The seahorse is the only fish that can swim backwards.

Juan Vasquez — Tue, 10 Aug 2021 12:27:16 +0000

The seahorse is the only fish that can swim backwards.

True 🟢 False 🔴 ?

If you know why, how, when, or whatever interesting things related to the question, Please share with us.

Just like fingerprints, everyone has a unique tongue print.

Juan Vasquez — Tue, 10 Aug 2021 12:26:47 +0000

Just like fingerprints, everyone has a unique tongue print.

True 🟢 False 🔴 ?

If you know why, how, when, or whatever interesting things related to the question, Please share with us.

The Queen of England's password number is 1.

Juan Vasquez — Tue, 10 Aug 2021 12:23:28 +0000

The Queen of England's password number is 1.

True 🟢 False 🔴 ?

If you know why, how, when, or whatever interesting things related to the question, Please share with us.

Error on rails assets:precompile on production (solved)

Juan Vasquez — Sun, 08 Aug 2021 14:45:40 +0000

Once I started the project I update the @rails/webpacker npm package from version 5 to version ^6.0.0-pre.2.

Thinking it was the last possible version, which btw it works great on development mode, the problem was when I tried to upload to Heroku (production) I got the following error message:

ERROR in Conflict: Multiple assets emit different content to the same filename js/.br
ERROR in Conflict: Multiple assets emit different content to the same filename .br

I hadn't any idea 💡 what the heck is the .br format, in fact, I haven’t heard anything about it.

After a little bit of research here we have what the .br format is.

At the end, I just update the webpacker version to 6.0.0-beta.7 and now it works as expected in a production environment.

commit

Note: BTW, was fixed up in this PR.

See you next time!

E-mail was invented before the World Wide Web?

Juan Vasquez — Wed, 04 Aug 2021 20:24:58 +0000

E-mail was invented before the World Wide Web?

🟢 True
🔴 False

If you know why, how, when, or whatever interesting things related to the question, Please share with us.

We got a tailwind CSS template

Juan Vasquez — Sat, 24 Jul 2021 05:53:45 +0000

I'm used to use Bootstrap CSS framework, I have been wanted to work with tailwind and today I did it, it was shocking to get it working and I'm not sure if it was my computer or me but I felt it slow. I need to do more research about it.

Well, we finally have the Tailwind Layout.

Better Dev Thank you for this useful tailwind tutorial.
:party: