原文链接：https://geeknote.net/Rei/posts/3253

---

我一直认为，把 Rails 作为前后端分离项目的后端是一种浪费。类似于在 Mac 上安装 Windows 系统，没有什么可以阻止你这样做，而且看起来很美好：Windows 系统更大众化，Mac 硬件做工好，似乎是强强联合。但是深度 Mac 用户会知道，这丢失了很多软硬件一体化设计的优势。

Rails 优势在于前后端紧密集成，有的功能只有在全栈环境下才能使用，Turbo Stream Broadcast 就是其中一个。Broadcast 在官方文档中只有一个小节的介绍，并且没有完整示例，可能很多人会忽略。我在掌握这个功能之后，发现 broadcast 对于开发实时更新的应用提供了很大便利。

最近我开发了一个 AI Chat 应用，其中核心功能是聊天部分：

这个功能是通过 broadcast 实现的。当用户发送一条消息时，服务端会保存这条消息，同时生成一个和 AI 交互的后台任务，在任务执行过程中又会创建新的消息。消息的创建和更新都通过 broadcast 更新到页面上。

关键部分的代码如下：

# app/models/message.rb
class Message < ApplicationRecord
  belongs_to :conversation

  broadcasts_to :conversation
end

<!-- app/views/rooms/show.html.erb -->
<div id="messages">
  ...
</div>

<%= turbo_stream_from @conversation %>

<!-- app/views/messages/_message.html.erb -->
<div id="<%= dom_id(message) %>">
  ...
</div>

有了这些代码，message 对象就会在创建、更新和删除的时候通过 action cable 发送消息，在页面更新内容。

其中最浓缩的代码是这一行：

broadcasts_to :conversation

初见可能比较难理解，将它展开成完整参数的形式：

broadcasts_to(
  :conversation,
  inserts_by: :append,
  updates_by: :replace,
  target: "messages",
  partial: "messages/message",
  locals: ->(message) { { message: message } }
)

这些参数的意思是：

• 将 message 的变动发布到关联的 conversation 频道。
• 渲染 message 的时候使用 messages/message 模版。
• 新增时插入到 #messages 元素。
• 更新时替换 dom_id(message) 元素。
• 删除时删除 dom_id(message) 元素。

Broadcast 默认提供 CRUD 的 turbo stream action，前面例子的消息内容流式更新使用了自定义的 turbo stream action。为避免文章篇幅过长不在这里展开，有兴趣的可以看项目源码：https://github.com/chloerei/llmrpg 。

broadcasts_to 就像 belongs_to，不了解细节的时候会觉得它充满魔法，了解细节之后会觉得原来如此，然后自觉使用默认配置。

对应的，前端部分需要插入 <%= turbo_stream_from @conversation %> 来订阅 @conversation 频道的消息，这样它就能在后台数据变动的时候更新页面内容。

Broadcast 功能需要视图、控制器、模型、后台任务等模块高度集成，才能实现这么精炼的代码。试想一下如果没有这个功能，自己就需要解决 websocket 服务端/客户端开发、通信协议，还有两端开发带来的沟通问题。而使用 Rails 全栈，只需要 broadcasts_to。

如果你需要为应用增加一些实时功能，推荐使用 turbo stream broadcast。你也许会对 Rails 高集成带来的开发效率有全新的认识。