API 优先的 Web 框架 Synth，以及社区的不同声音

在近期 Google 的 AngularJS 会议上， Synth 浮出水面，它是一套基于 Node.js 构建的 API 优先的 Web 应用框架。

自 Synth 被披露以来，在一个半月的时间里，其 GitHub 项目从 1 星增长到了超过 500 星。但 Synth 的创造者 Jon Abrams 表示，更广泛的开发者社区依旧对该框架感到迷茫。

Jon Abrams 表示，Synth 项目不同于传统 Node.js Web 框架。它的设计目的，是简化后端资源的创建过程——这些资源可以在加载 AngularJS 视图的时候自动预加载。

Synth 的特性包括在页面加载的时候预加载 Angular 模型数据、预加载 HTML 视图，以及一套简化的项目结构——前端代码放在“前端”文件夹里，后端代码（Node 的代码和包）放在“后端”文件夹中。

Abrams 对预加载做了详细说明：

自动预加载数据的特性，将解决加载特定 Web 视图的时候，出现数据呈现延迟的问题。

许多人可能还记得 Twitter 最早切换到单页面应用（SPA）架构时的情况。如果点击某个链接，在线跳转到一条特定的 Tweet 时，该单页面应用首先进行渲染，然后经过一阵延迟后，该条 Tweet 才最终呈现出来。

如果当时 Twitter 能够使用 Synth，那么这条 Tweet 将在页面渲染完成后即刻呈现，因为使用 Synth 后将无需发送获取数据的 API 请求。

预加载特性得益于在 Synth 的 API 处理函数中增加的对“承诺”特性的支持。由于 API 处理器不再需要与 Express 响应对象直接对话，Synth 复用了 API 处理器。现在，当请求某个特定 Web 视图的时候，API 处理器将发挥作用，而不是只有当相应的 API 被调用的时候才调用这些处理器。这将有助于减少移动 Web 应用中常见的高延迟问题。

Synth 还希望通过使用特定的方式创建文件夹和命名函数，来简化新的 RESTful API 资源创建的过程。Synth 扫描资源文件夹查找.js（或.coffee）文件，而后基于它们所处的文件夹的名字，生成 API。要创建备忘录资源，开发者应该创建一个同名目录，然后在资源路径中的某个文件里，声明一份用于特定 HTTP 方法的请求处理器——可以通过指派一个导出函数来完成。

对于 Synth，来自开发者社区的反应混合了不同的声音。Abrams 表示，AngularJS 社区的反馈非常正面，特别是在 Twitter 上。然而，随着他的 Synth 演讲最近登上了 Hacker News 的首页，Abrams 发现一些人对于 Synth 旨在解决的问题产生了混淆。

芬兰的 Cybercom 公司的软件设计者 Panu Horsmalahti 对于命名函数评价道：

从我的经验来看，记忆能够对功能产生影响的新的命名约定，让一切变得更困难而不是更简单。我们可以创建一份有趣的 Demo 效果——展现创建这样的 Demo 有多“容易”和“快捷”，但是一旦我们对应用进行扩展，一切将变得更为混乱，而这个时候或许命名约定将开始遇到限制。

此外，当我们拥有这些在任何地方都将创建功能的命名约定时，学习代码基变得更加困难。

其他评论者甚至质疑 Abrams 的思维能力。软件工程师 Richard Bishop表示：

任何时候，当我看到“某些服务器特别用于一些客户侧框架”，我都会感到作者失去了理智。

浏览器只不过是个客户端。所有针对浏览器的框架只不过（应该是）为了创建动态浏览器应用而生的抽象。如果我们需要创建服务器端的框架，而且特别用于与客户端框架配合工作，那么这其实代表着一种信号：我们应该停下了想一想，到底是哪里出了错误。

Abrams回应道：

我知道这个想法很疯狂。我喜欢疯狂的想法，越疯狂越好。

但对于浏览器仅仅是个客户端这一点，我并不同意。如果我们愿意，可以把它当作客户端对待，但我们也可以走另一条路：客户端代码可以由相同的服务器提供，该服务器能够访问客户端应用的数据。而这正是 Synth 的设计目的。

Synth 尚停留在 Beta 版本，而且正处于积极开发中。因此它还离应用到产品中还有一段距离。InfoQ 读者可以通过其 GitHub 项目（以及子项，例如 synth-api ）为这个开源项目做出贡献。

查看英文原文： Synth, API-First Web Framework, Confuses Community