我的消费券

我在 Fly.io 工作并创建了 Phoenix，一个 Elixir 网络框架。Phoenix 提供了在其他语言和框架中难以实现的开箱即用功能。这是一篇关于我们如何创建我们的旗舰功能 LiveView 的文章。
LiveView 剥离了抽象层，因为它在一个抽象中同时解决了客户端和服务器。HTTP 几乎完全消失了。没有更多的休息。没有更多的 JSON。没有 GraphQL API、控制器、序列化器或解析器。您只需编写 HTML 模板，一个有状态的进程将它与浏览器同步，仅在需要时更新它。并且无需编写 JavaScript。
你还记得 Ruby on Rails 是什么时候发布的吗？我愿意。Rails 也是一场革命。它想到了使用富有表现力的语言和一些精心挑选的统一抽象来大大简化开发的想法。很难记住 Rails 之前的 CRUD 应用程序开发是什么样的，因为该框架影响很大。
今天，我使用一种叫做Elixir的语言工作。我每天都在构建Phoenix，这是 Elixir 的 goto Web 框架。与 Rails 不同，Phoenix 不仅仅是一个 Elixir Web 框架。在构建 Phoenix 的过程中，我相信我们已经找到了一些新想法，它们将改变我们对构建应用程序的看法，就像 Rails 为 CRUD 应用程序所做的那样。
这是一个很大的要求。为了支持它，我想向您介绍 Phoenix 的历史、我们正在尝试做的事情以及我们在此过程中解决的一些问题。有很多话要说。我会像这样分解它：
实时应用功能如何让我考虑同步更新，而不是呈现静态内容，作为将应用服务器连接到浏览器的正确原语。
尝试使用 Ruby 构建 sync.rb 是如何引导我使用 Elixir 的，以及为什么我认为 Elixir 是解决这些问题的独特之选。
Elixir 是如何点亮“分布式计算”的，它不是作为复杂数据库的放射性核心，而是作为任何 Web 应用程序的基本构建块。
分布式计算和来自 sync.rb 的想法如何最终形成一个名为 LiveView 的 Phoenix 功能。
最后，我们一直在用我们提出的这些构建块做些什么。
让我们开始吧。
##### 2013 年：Ruby on Rails
我认为可以肯定地说，如果我得到了 2013 年在 37signals 申请的工作，就不会有 Phoenix 框架了。我喜欢使用 Rails 进行构建，而且毫无疑问我会致力于开发新的 Rails 功能而不是发明凤凰。
这是因为 Rails 是一个非常高效的代码传输框架。这是关于流量的。当您构建 Rails 团队想到的东西时，流程是强大而有趣的。Rails 人对此有一个名字；他们称之为“黄金之路”。
但是，当您需要“实时”功能（例如聊天或活动提要）时，您就偏离了黄金路径，并且无法进行流程。您从使用 Ruby 抽象编写 Ruby 代码到使用 Javascript 和一组完全不同的抽象。然后你写了一堆 HTTP 胶水，让两个世界互相通信。
所以，我做了一个简单的想法：“如果我们能够取代Rails的什么render与sync和自动的UI更新？”。几天后，我有了sync.rb。
Sync.rb 是这样工作的：浏览器 WebSockets 到服务器，随着 Rails 模型的变化，模板在服务器上重新渲染并推送到客户端。从服务器呈现的 HTML 会将防篡改订阅签署到 DOM 中，供客户端通过 WebSockets 收听。该库为浏览器运行提供了 JavaScript，但 sync.rb 程序员不必自己编写任何代码。所有的动态行为都是在服务器端用 Ruby 完成的。
这实际上奏效了！的种类。
Sync.rb 提供了并发抽象，而 Rails 并不是特别并发。所以我建立在EventMachine 之上，它是一个运行 IO 事件循环的 Ruby/C++ 库。EventMachine 是一个有用的库，但它与核心 Ruby 及其生态系统的关系不稳定，其中大部分都不需要并发代码。
我的 EventMachine 线程会在没有错误的情况下无声无息地消亡。我必须检查 EventMachine 线程是否已经秘密死亡，并在每次调用、每个用户、每次我们想要异步发布更新时重新启动它。我想在我熟悉和喜爱的堆栈中构建动态功能，但我没有信心该平台可以交付我试图构建的东西。
尽管如此，它仍然有效。我有最少的可行演示，并且知道如果我能找到一种方法使其可靠，这种方法就可以工作。我查看了其他语言如何大规模解决“实时”问题。我找到了 Elixir。
Elixir 是 José Valim 在Erlang VM上构建的以开发人员为中心的语言。Erlang 是一种久经考验的语言，专为电信应用程序设计，以其运行的虚拟机的质量和可靠性而著称。Erlang 支持 WhatsApp，它为每台服务器服务 1000 万用户。19B 美元的 Facebook 收购也是一张不错的名片。
一看 Elixir，我立刻就被吸引住了。我看到了 Erlang VM 的所有强大功能和传统，但也看到了现代功能，如协议、我见过的最好的构建工具/代码运行器/任务运行器、真正的宏和一流的文档。它所需要的只是一个网络框架。
##### 2014-2015：凤凰
我创建了 Phoenix 来构建实时应用程序。在它甚至可以呈现 HTML 之前，Phoenix 就支持实时消息传递。为此，Phoenix 提供了一个称为Channels的抽象。
要了解 Channels，您需要了解一些有关 Erlang 的知识。Erlang VM 中的并发性是一流的。Erlang 应用程序由“进程”组成，这些进程是与消息而不是共享内存进行通信的轻量级线程。您可以在单个 VM 中运行数百万个进程。Erlang 的弹性是出了名的：进程可以退出（甚至崩溃）并无缝重启。进程使用邮箱和PubSub等抽象来相互发送消息；消息在服务器之间透明地路由。
通道利用 Elixir/Erlang 消息与外部客户端对话。它们是双向的且与传输无关。
通道通常通过 WebSockets 承载，但你可以在任何东西上实现它们——社区甚至展示了一个工作的 Telnet 客户端。
在 Web 应用程序中，浏览器会打开一个 WebSocket，它在通道和进程之间进行多路复用。由于 Elixir 是预先调度的，因此会在 IO和 CPU上进行负载平衡。您可以在一个频道上屏蔽，在另一个频道上转码视频，而其他频道则保持流畅。
这与 Rails 应用程序的工作方式截然不同。Rails 也使用“进程”，但它们是“重”类型的。通常，Rails 请求处理程序会垄断整个 OS 进程，从设置到拆卸。Rails 是“并发”的，因为底层数据库是并发的，多个操作系统进程可以更新它。这使本该简单的事情变得复杂。例如，运行一个以间隔触发事件的计时器需要一个后台作业框架，以及一个通过持久存储将消息中继回的方案。这种摩擦会改变和限制您对构建事物的思考方式。
在 Phoenix 中，通道在 WebSocket 连接的生命周期内保持状态，并且可以跨服务器队列中继事件。它们垂直和水平缩放。
2015 年 11 月，我们对 Elixir/Erlang 承诺进行了测试。我们对 Channels 进行了负载测试，将200 万个并发 WebSocket 连接发送到单个 Phoenix 服务器，在所有客户端之间广播聊天消息。仅打开那么多连接就需要 45 个客户端服务器。我们的 128GB Phoenix 服务器有 45GB 的可用内存。我们本来可以运行更多的客户端，但是当我们用完 Linux 内核支持的文件描述符时，我们就停止了。
Phoenix 做了 sync.rb 做不到的事。数以百万计的并发 websockets 用户，拥有简单的用户土地代码。我们知道我们已经为开发人员友好的实时应用程序框架奠定了基础。我们只需要弄清楚如何让它唱歌。
##### 2016-2017：存在
2016 年，开发人员通常不认为他们在构建实时应用程序。“实时”一般让人们想到 WhatsApp 和 Twitter 和 Slack。许多人并不清楚为什么他们甚至想要实时，或者实施这些东西的成本太高。尽管如此，每个人都需要标准的网络应用程序。核心团队花了很多时间使 Phoenix 成为一个很好的 MVC 框架，用于构建基于传统数据库的 Web 应用程序。但我的头脑仍然处于实时功能中。
因此，我们发布了Phoenix Presence，这是一个分布式组管理器，具有由CRDT支持的元数据。Presence 广泛地解决了“谁在线？”的问题。特征。
想象一下，您的老板要求您显示有多少其他访客正在查看几乎售罄的商品以转换销售额，或者您的客户询问显示哪些团队成员当前在线有多难。你不再需要弄清楚这些事情。应用程序通过实时状态功能变得更加有趣。事实上，大多数协作应用程序通过此功能变得更有趣，即使它们在任何其他方面都不是“实时”的。
关于 Presence，有两件重要的事情需要了解。第一个是它可以正常工作，具有自我修复能力并且不依赖于外部消息队列或数据库。Elixir 内置了所有这些功能，而 Presence 则充分利用了这些优势。您不必考虑如何使其工作。
第二个是 Presence 利用了强大的通用抽象。基于 CRDT 的状态保持具有在线好友列表之外的应用程序。Presence 在 IOT 应用程序中用于跟踪设备、汽车和其他事物。如果您没有 Presence 之类的东西，您可能不会考虑构建它支持的各种功能。当您拥有它时，它会改变您可以在应用程序中合理完成的工作的边界。
##### 2018 年：LiveView
现在是 2018 年。我们已经发布了多个次要版本。两本凤凰图书已出版，社区正在成长和快乐。
我对 Channels 感到很兴奋。它们是可扩展的客户端应用程序的绝佳抽象，其中服务器主要负责发送数据和处理客户端事件。它们仍然是 JavaScript 和本机应用程序的 Phoenix 首选。
但我知道我还没有完全到达那里。Phoenix 仍然依赖 SPA 库来实现实时 UI。但是我已经从那个体系结构转移了，并内化了一种在 Elixir 中构建应用程序的新方法。
想想一个普通的 Web 应用程序是如何工作的。一切都是无状态的。当用户做某事时，您获取世界，将其加工成某种格式，然后通过网络将其发送给客户端。然后你把所有的状态都扔掉了。你对下一个请求一遍又一遍地重复，每秒数百或数千次。它在 PHP 和 Perl::Mason 中以这种方式工作，并且在 Rails 等现代框架中仍然以这种方式工作。
但是 Elixir 可以做有状态的应用程序。它允许您将整个用户访问建模为服务器上的廉价并发，并直接与浏览器对话。我们可以在事情发生时更新 UI，这些更新可以来自任何地方——用户、服务器，甚至是我们集群中的其他服务器。
您不想像在其他框架中那样在 Elixir 中构建应用程序。
我瞥见了有状态的 UI 应用程序是如何在客户端使用 React.js 工作的。我们借用了 React 编程模型并将其移至我们的 Elixir 服务器。
使用 React，任何状态更改都会触发重新渲染，然后是浏览器 DOM 的有效补丁。LiveView 是一样的，除了服务器重新渲染模板并保持状态。React 模板使用客户端事件注释 DOM，例如<button onClick={this.clicked()}在 LiveView 中它是 RPC 事件，例如<button phx-click="clicked">. 使用 React，你仍然在上下文切换和使用 HTTP 和序列化器粘合东西。不适用于 LiveView。互动功能是无摩擦的。
这再次改变了您可以在应用程序中合理执行的操作的边界。Elixir 应用程序不需要安排库的集合以及传输格式和生命周期来构建动态更新的 UI；动态服务器渲染是内置的。一旦您适应了服务器端有状态的 UI，您就会以不同的方式看待您的应用程序。无需为使功能动态化而支付 SPA 复杂性税，因此任何有意义的动态都会变得动态。
尽管如此，在这一点上，与 SPA 替代方案相比，我们只有一种更糟就是更好的方法。任何微小的变化都会重新渲染整个模板。服务器不仅重新计算模板，还重新发送冗余数据，通常只是修补页面的一小部分。为了使 LiveView 成为开发人员挑选的第一个现成工具，我们需要它更好地扩展。
##### 2019-2020：LiveEEx
React 的部分神奇之处在于它是一个强大的抽象和高效的实现。当 React 应用程序底层的一小部分状态发生变化时，React 会限制更新，并将其差异化到位，从而最大限度地减少对 DOM 的更改。
通过 José Valim 在 LiveEEx 引擎上的工作，Phoenix LiveView 模板变得具有差异意识。它们在编译时从模板中提取静态和动态数据。我们计算一个最小的差异，仅将已更改的动态数据发送给客户端。
抽象不会改变。您编写与之前相同的代码。但是现在我们发送一个比最好的手写 JSON API 优化得更好的有效负载。这听起来好得令人难以置信。让我们通过一个小模板来了解它是如何检查的。
想象一下，我们正在为带有 LiveView 的恒温器构建界面。我们称它为“Roost”。Roost 可以显示当前温度，您可以使用 UI 控件上下颠簸。
第一次加载 Roost 界面时，它会随您的页面发送一个常规的 HTML 响应。接下来，建立一个 WebSocket 连接，LiveView 向浏览器发送初始负载，并将模板的静态和动态部分分开：
浏览器现在有一个缓存，不仅仅是模板，还有支持它的状态数据。浏览器知道如何合并来自服务器的差异。UI 更新很容易。LiveView 的浏览器代码使用动态压缩静态值，为模板生成新的 HTML 字符串。它将字符串交给morphdom以有效地仅修补 DOM 中已更改的那些区域。
假设一位房客希望它更暖和。他们单击该<button phx-click="inc">+</button>元素。这连接到服务器上的 RPC 函数，它只会增加@val：

def handle_event("inc", _, socket) do
      {:noreply, update(socket, :val, &(&1 + 1))
    end
服务器传播更新。但是变化不大！上面，您可能已经注意到，我们2在初始状态下传递了键下的当前温度（一个动态状态变量）。这就是我们需要更新的全部内容；我们只是发送{2: 70}到浏览器。这是发生的事情：
围绕应用程序状态更新的编码格式展开了战争。在这里，我们回避了争议。变量发生变化，我们重新计算链接的模板，结果在线上。
现在，有人打开了一扇窗户，温度正在变化。服务器通知，并让客户端知道它：
Pubsub.broadcast(MyApp.PubSub, "device:#{id}", {:set_temp, val})
每个 LiveView 进程都会接收广播：

def handle_info({:set_temp, new_val}, socket) do
      {:noreply, assign(socket, :val, new_val)}
    end
每个人的浏览器都会收到另一个微小的{2: 68}负载，无论他们连接到哪个服务器。我们也不执行其他模板代码，如<%= strftime(@time, "%r") %>，因为我们知道它没有改变。
当然，不仅仅是数字。让我们建立一个在线词典，并让它自动完成。忍受我，这很整洁。
这是一个简单的 HTML 表单：

defmodule DemoWeb.SearchLive do
          use DemoWeb, :live_view
    
          def render(assigns) do
            ~H"""
            <.form phx-change="suggest" phx-submit="search">
              <input type="text" name="q" value="{@query}" list="matches">
              <datalist id="matches">
                <%= for match <- @matches do %>
                  <option value={match}><%= match %></option>
                <% end %>
              </datalist>
              <pre><%= @result %></pre>
            </.form>
            """
          end
当用户suggest输入内容时，我们会触发事件以及文本字段的内容。这是一个处理程序：

def handle_event("suggest", %{"q" => q}, socket) when byte_size(q) <= 100 do
        {words, _} = System.cmd("grep", ~w"^#{q}.* -m 5 /usr/share/dict/words")
        {:noreply, assign(socket, matches: String.split(words, "\n"))}
      end
我们更新matches了这个连接，它更新datalist了模板中的 。从差异引擎中掉出来的只是新的字符串！同样重要的是，我们不会考虑这是如何发生的，也不会提前做出安排；它只是有效。
对于构建动态服务器呈现应用程序的许多人来说，这是一个熟悉的问题。您希望在用户单击按钮时提供 CSS 反馈。但是服务器可以在任何时候发送与客户端无关的更新。那些正在进行的更新会清除您想要反馈的 CSS 加载状态。看起来服务器处理了点击，但由于竞争条件，用户界面在撒谎。这会导致用户体验混乱和破碎。
Phoenix 团队通过使用phx-ref我们附加到客户端差异有效负载的属性来注释 DOM 解决了这个问题。这些 ref 表示 DOM 的某些区域被锁定，直到服务器确认该特定消息 ref。所有这一切都会为用户自动发生。
像这样的功能并不迷人，但它们是动态实时应用程序概念验证与实际工作应用程序之间的区别。
##### 2021 年：LiveView 上传、重定向和 HEEx
首先，我们提供了二进制上传。将现有的 LiveView WebSocket 连接上传给我们。您可以获得带有文件进度和预览的简单交互式文件上传。再一次，您不必考虑如何使其工作；它只是。
我们还找到了一个解决方案，允许您使用相同的代码执行直接到云端的上传。您可以从简单开始并直接上传到服务器，然后在有意义的时候转向云上传。让我们看看它的实际效果：
实现这一点的代码小得令人震惊。上面，我们有文件进度、文件元数据验证、交互式文件选择/修剪、错误消息、拖放和预览。这只需60 行。
您不必了解所有这些代码，但我想提请注意这一点：

def mount(_params, session, socket) do
            {:ok,
             socket
             |> assign(:uploaded_files, [])
             |> allow_upload(:avatar, accept: ~w(.jpeg .png), max_entries: 3)}
          end
请注意声明性allow_uploadAPI如何允许您指定要允许的上传内容，然后定义的模板会在render/1发生任何更新时对其做出反应。
通过 WebSockets 上传很整洁。我们绝对可以肯定，该文件位于访问者最初随机负载平衡的同一 Elixir 服务器上。这允许 LiveView 进程（您的代码）对同一个盒子上的本地文件进行任何后处理。您可以在此处观看实时编码上传深入了解。
我们也运了live_redirect和live_patch功能，它允许您通过浏览pushState客户端上没有页面重新加载在现有的WebSocket连接。这可能看起来像pjax或turbolinks。但事实并非如此。导航发生在 WebSockets 上。没有额外的 HTTP 握手，没有解析认证头，没有重新获取世界。UX 比 SPA 框架更快、更干净，延迟减少，并且更容易构建。
您可能还注意到~H前面示例中的Elixir 印记。这是HEEx，它是新的。它是一种 HTML 感知模板语法，包括编译时的验证。与 React JSX 一样，组件可以表示为自定义标签。它看起来像这样：

<div class="profile">
      <Avatar.icon for={@user} width="100" height="100"/>
      <%= for suggestion <- @suggested_users do %>
        <.follow_button target={@suggestion} />
      <% end %>
    </div>
HEEx 引擎使用标记语法扩展了标准 Elixir EEx 模板，例如在<Avatar.icon for={@user} …内部编译为<%= component &Avatar.icon/1, for: @user %>宏调用。它是结构化的标记，并且与 HTML 组合得很好。
有了基本的 HEEx 引擎，我们预见了一个新兴的 Elixir 生态系统，它由现成的组件组成，用于构建 LiveView 应用程序。在我们继续扩展我们的 HEEx 引擎时，请注意这个空间，其中包括用于编译时检查的插槽和声明性分配等功能。
##### 未来
我们很高兴能够在全球范围内使用 LiveView。Fly.io 让您可以轻松地将 LiveView 流程部署在靠近用户的位置——当 LiveView 靠近您的用户时，可以立即进行交互。我们已经在服务器上探索乐观 UI ，我们可以在其中使用 Channels 预先运行数据库事务，在客户端反映乐观更改，并在数据库事务传播时进行协调。现在，通过一些工作，在 LiveView 中已经可以实现大部分功能，但是通过我们脚下的交钥匙全球部署，Phoenix 团队可以真正深入挖掘并探索使这些以前闻所未闻的想法成为日常的现状LiveView 应用程序。敬请关注！

我们如何进入 LiveView