前端架构经验谈之三
in Web with 0 comment

前端架构经验谈之三

in Web with 0 comment

多页面应用

传统多页面是由后端控制一个 url 对应一个 html 文件,页面之间的跳转需要根据后端给出的 url 跳转到新的 html 上。比如:

http://www.example.com/page1 -> path/to/page1.html
http://www.example.com/page2 -> path/to/page2.html
http://www.example.com/page3 -> path/to/page3.html

多数情况下,这种方式都是没问题的,但对一些业务逻辑相似,重前端的应用就不是很友好了,比如系统管理应用。

单页面应用

单页面应用(single page application),就是只有一个页面的应用,页面的刷新和内部子页面的跳转完全由 js 来控制。一般单页面应用都有以下几个特点:

路由

一般来说,单页面应用的路由从表现形式上来说分为两种:Hash Router 与 Browser Router

Hash Router(哈希路由)

通过 location hash 定义路由。

http://www.example.com -> path/to/main.html

http://www.example.com -> 主页面
http://www.example.com/#/ -> 主页面
http://www.example.com/#/page1 -> page1 页面
http://www.example.com/#/page2 -> page2 页面
http://www.example.com/#/page3 -> page3 页面

这样做的好处是后端只需要给一个 url 就可以了,因为路由完全是由前端实现的。

Browser Router(浏览器路由)

通过浏览器链接定义路由。这个时候,每次路由就都像正常的浏览器链接跳转一样。

这种路由需要后端配合,就是把所有需要路由的 url 都指定同一个 html 文件,由前端来根据 url 判断怎样渲染页面。

http://www.example.com/page1 -> path/to/main.html
http://www.example.com/page2 -> path/to/main.html
http://www.example.com/page3 -> path/to/main.html

这样做的好处是对搜索引擎友好,对浏览器的表现就像正常的 url 一样。

什么时候需要“服务器端渲染或 node 中间层

在前后端分离之后,后端语言的模板功能被弱化,整个页面的渲染基本上都由前端 js 动态渲染,但这样对于一些应用来说是有缺陷的。比如需要 SEO 的,需要打开页面不用等待就能看到页面的,这尤其对于电商类应用是必需的。解决这个问题有两个思路:

服务器端渲染

服务器端渲染,由框架与构建工具配合,并依据一定的项目结构和编码方式,共同运行。现有比较好解决方案:

对于 react, gatsby 也是一个不错的解决方案。服务器端渲染,社区还在不停的探索中,期待未来的新体验。

node 中间层

alt text

为什么选择node做中间层?

alt text

案例分析:淘宝首页优化
需求:静态资料展示,方便运营管理,更好的承载密集且庞大的流量
解决方案:页面缓存与定时刷新,返回缓存资料,NodeJS产出静态页面到CDN,定时刷新

alt text

案例分析:淘宝详情页优化
需求:单日四亿PV,页面数据来自各个不同接口,为了不影响体验,先产生页面框架后,在发起多个异步请求取数据更新页面,这些多出来的请求带来的影响不小,尤其在无线端
解决方案:在NodeJS端使用 Bigpiper 技术,合并请求,降低负担,分批输出,不影响体验

选择node做中间层好处多多,其中包括

Responses