基于NodeJS的先后端分离

简介

在制定网站的总体框架时候，很是强调架构的上的先后端分离。这种分离意味着数据层、复杂业务逻辑与前端展示和交互的层次分离。

WHY (为何要这么作)

• 清晰的结构。先后端的融合是经过一套中间层的协议来完成的，实现上是后端对前端只露出API接口。在软件设计层面，流动的数据，让先后端能够独立的专一的作本身，而不是被对方所绑架。

• 同步开发。不被对方所绑架，就意味着，在开发时，经过事先的约定，前端和后端能够同步进行。而交接层经过单元测试保证交付。能够缩短项目进度

在作此次设计以前，着重参考了淘宝大牛们的中途岛方案。感谢他们让我走出了一套代码吃遍先后端的理想回归了现实。

REQUIREMENT (需求)

在作url设计的时候，提出了这样一个概念：

当浏览以服务端渲染页面为主时，url的path部分由服务端负责解析、渲染最后输出页面，当到达浏览器端，js负责渲染hash部分的数据和视图

当页面的形式以webaap为主时，url的path和hash部分都由js负责渲染

在这样的过程当中，力图解决两个问题：

• webapp的seo问题

• url追溯问题

TODO (作了什么)

与淘宝Midway的思想一致，在浏览器端和服务端，共享是模板，基于此也参考低版本浏览器的一些性能问题，前端选型上，使用了CanJS，由于其模板引擎是ejs能够被expressjs兼容，同时CanJS在低版本浏览器上的新能是非突出，因此选型用了CanJS

CanJS中View的生命周期扩展

如上图所示，默认的生命周期只有start和end两个阶段，咱们显示的加入了render和supplement两个阶段。

• render定义为主渲染阶段，这部分能够在浏览器端进行渲染，也能够在服务端端进行渲染，服务端渲染完成以后，会在根节点上加入data-status="ready"的属性，来标示渲染完毕，当浏览器检测到这个属性时，就不会重复渲染。

• supplement定义为补充渲染阶段，这部分在浏览器端进行渲染，其数据参数经过hash被传入

EXAMPLE (案例)

sf-haitao-webapp-seo这个项目的代码就是具体的案例，因为在实践初期，代码变更会很是快。

启动代码以后，分别访问两个连接：

• 由服务端进行渲染: http://127.0.0.1:3000/paint/2023013

• 由浏览器负责渲染: http://127.0.0.1:3000/render/2023013

注：这里的2023013是豆瓣里面惟一能够随意访问的，请不要用其余的id吧，见谅

两个连接访问以后，在尾巴后加入以下hash，看看会有什么结果

#!case/29

HOWTO (如何去作)

1. 须要安装NodeJS环境和Bower加载器

2. Clone代码到本，默认目录为sf-haitao-webapp-seo

3. 进入目录，安装依赖库

   npm install

   bower install

4. 在根目录上运行

   node bin\www

项目地址： https://github.com/leewind/sf-haitao-webapp-seo

DISCUSS (讨论)

思考这样一个问题：既然不纠结于服务端和浏览器端代码一致，那么是否是有可能用其余的替代Nodejs来作服务端渲染的工做，好比：Sprint MVC、.Net MVC、Python Tornado？

在CanJS中默认推荐两种模板：ejs和mustache。我没有找到其余语言对于ejs模板的支持，可是mustache在其余语言上的应用作的很是的好，具体能够参考mustache官方站点

那反过来想，有没有其余的语言模板能够在Nodejs环境下可使用的，而后我找到了Velocity.js，我想若是前端CanJS能够兼容Velocity.js的模板，那么在作渲染的时候，可能我有第二套方案：用Java Velocity去作render逻辑的渲染！

对于mustache用于多语言平台的拓展和Velocity对CanJS的扩展是我下一步的实践目标

REFERENCE (参考)

• 深刻详解前端轻量级MVC框架新贵CanJS(1)

• 也谈基于NodeJS的全栈式开发（基于NodeJS的先后端分离）

• 先后端分离模式下的安全解决方案