一个真实的 wasm 到 htmx 移植

Joe Fioti

当我在大学时，我编写了一些客户服务软件，它将我训练的一些自定义 AI 模型、OpenAI API、数据库以及一些社交媒体 API 整合在一起，制作了 Sidekick 的第一个版本。

被误导

在接下来的几年里，我致力于添加更多功能并扩展用户群。作为一名独资创始人，我本该专注于销售、营销和市场发现。然而，作为一名工程师，我想要手工打造完美的 Web 技术栈。我坚信前端和后端之间的网络差距可以被抽象化，从而使编写 Web 应用程序像编写原生应用程序一样简单。这与我的业务、产品或客户有任何关系吗？完全没有，但正如许多技术创始人所做的那样，我相信如果我完善了技术，客户就会出现。

我的设计决策很天真，但也让人联想到当今行业中的情况：我希望后端和前端共享一种语言（Rust），我希望在网络边界进行编译时检查，我希望像编写应用程序一样编写前端代码（响应式），并且我希望实现几乎即时的重新加载时间。从中我得到的是一个充满 bug 的混乱局面。

我发明了一个系统，其中简单的 Rust 函数可以通过宏标记来生成后端路由和前端请求函数，因此你可以像调用标准函数一样调用该函数，而它会在后端运行。这是一个真正的穷人版 GraphQL。我想要在前端编写 Rust 的愿望要求我编译一个 WASM 包。我对即时加载时间的渴望要求实现同构 SSR。所有这些复杂性，本质上只是一个简单的 CRUD 站点。

更好的方式

此时，Sidekick 已经成长起来，它现在有一个负责每天处理不小流量量的代码库。有一个时刻，我研究了 HTMX、多页面网站和 HATEOAS，并意识到 Sidekick 代码库——它已经扩展到分布在 8 个不同 crate 中的约 36k 行代码——可以折叠成一个单一的 crate，一个运行后端的单一二进制文件，它通过模板按需生成前端，并且 HTMX 可以满足我们所需的所有交互性。

大型重构通常记录不佳，因此我们编写了一个快速而粗糙的站点部分简化版本来说服自己它可行。在充分说服后，我们进行了完整重写。总而言之，重写大约花了 3 周的密集工作。结果是戏剧性的：

sidekick_port_loc.jpg

重写进行的比我想象的要好得多。它肯定不会代表每一次经历，我们的应用程序确实特别适合 HTMX。Axum 和一些自定义中间件也在共享站点共同基础设施方面发挥了很大作用。虽然我们没有适当的指标，但我们从轶事中注意到加载时间显著改善。

反思

我将以在我看来最大的好处结束：根据客户要求添加新功能变得异常容易。一个原本需要 2 周来完整实现、测试和发布的特性，现在只需一两天。作为一个有大量客户需求的小型初创公司，这是基本要求。

Sidekick 没有筹集 VC 资金，因此我无法雇佣大量开发者。有了 HTMX，我们不需要。

</>