首页 > 代码库 > API优先的Web框架Synth,以及社区的不同声音

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)为这个开源项目做出贡献。