将传统的三次串行http请求简化成一次http请求新萄京娱乐手机版

当前位置:新萄京娱乐手机版 > 新萄京娱乐手机版 > 将传统的三次串行http请求简化成一次http请求新萄京娱乐手机版
作者: 新萄京娱乐手机版|来源: http://www.shkimoto.com|栏目:新萄京娱乐手机版

文章关键词:新萄京娱乐手机版,同构

  最近花了点时间研究React同构实践,赶上过年回家,心也散了,两个月没写文章。

  同构也算是前端的一个应用模式,目的是为了加速首屏显示时间和seo优化,很多公司都将同构作为前端优化的一个优化点来做,同时Raect16版本中也添加了很多对同构的支持,可以看出FB也是默认支持这一场景使用的。

  一套代码既可以在服务端运行又可以在客户端运行,这就是同构应用。简而言之, 就是服务端直出和客户端渲染的组合, 能够充分结合两者的优势,并有效避免两者的不足。

  概括地说,同构就是服务端(Node)替客户端请求接口,获取到数据后,将有数据和结构的页面渲染好之后返回给客户端,新萄京娱乐手机版这样避免了客户端页面首次渲染,同时服务端RPC比客户端请求要快。

  性能: 通过Node直出, 将传统的三次串行http请求简化成一次http请求,降低首屏渲染时间

  SEO: 服务端渲染对搜索引擎的爬取有着天然的优势,虽然阿里电商体系对SEO需求并不强,但随着国际化的推进, 越来越多的国际业务加入阿里大家庭,很多的业务依赖Google等搜索引擎的流量导入,比如Lazada.

  SPA:服务端替客户端请求数据,完成第一次render,将render完成之后的html页面返回给客户端,相对于客户端渲染,客户端第一次获取的html是个有数据有结构的html,结合样式文件下载客户端可以较快的看到首屏内容。

  SSR:服务端Node也可以运行React解析出页面内容,并且要比客户端更快;客户端通常要在render一次之后请求数据,数据返回之后再render一次,服务端渲染可以解决客户端重复渲染问题。

  React中有一个renderToString方法,该方法将解析好的jsx片段以html字符串形式输出,就是为了同构而诞生。

  实现方法有多种,我这里使用webpack-isomorphic-tools插件来实现,之后会做介绍。

  通常我们只做首页,或者关键页面的服务端渲染,相当于从首页进去是服务端渲染,但是从项目其他页面进入就跟正常的SPA一样。所以在服务端将要ssr的路由匹配出来,其他的路由仍交给SPA。

  通常来讲,我们从接口获取数据,都要将一些数据放到store中,便于其他页面共享。

  实际上SSR开发通常是在一个项目基础上改,而不是重新搭建一个项目,比较很多人拿它当做优化,而不是重构。

  通常来说我们一个项目按照SPA模式开发,针对特定页面做SSR的修改,修改之后的项目既可以SPA也可以SSR,只不过SPA模式时对应页面获取不到数据,因为获取数据的方法均被修改。

  不会减小,所谓同构,其实就是服务端借助客户端的JS去渲染页面,没有影响到客户端的JS,还是正常打包,客户端做代码分割也不会受影响。

  先插一嘴,现在有个叫Next框架,索性也试了下,真的很简便,快速搭建SSR项目,但是问题也很明显:

  所以没有选用该框架进行尝试,不过该框架凭借着简单易上手,未来还是很有市场的。

  上面第二个问题就提到了服务端如何处理静态资源,这里使用webpack-isomorphic-tools插件,该插件处理静态资源的。

  然后运行webpack,将文件打包之后,会生成一个webpack-assets.json文件,该文件就是存储静态资源的映射关系的json:

  这里选用Express框架作为服务器,原因就是简单,很多人也选用koa,都一样。

  核心在于路由部分:这里匹配所有路由(也可以是首页路由),使用fetch方法获取到了promises和store,然后再用render方法生成了html返回给客户端,这两个方法都是封装过的,

  在fetch文件中,我们将首页需要获取的数据通过isomorphic-fetch来获取,然后跟SPA一样,dispatch到store中,然后暴露出去。

  SSR返回的是首次渲染过后的html,首次渲染就是在render方法中实现的:

  这里显而易见,我们准备一段html模板,跟SPA那个html模板类似,将renderToString的片段塞进去,同时根据webpack-assets.json获取到打包好的js和css,塞进去;最后,将上面刚刚配置好的store注入进去。

  我们制作一个接口,使用setTimeout 500ms模拟网络开销,效果如下:

  所有页面SSR可以做,这样每个页面的首屏都会很快,同时js也会小很多。但是带来的问题服务器压力会很大,维护起来成本较高。而且服务端毕竟是模拟客户端环境渲染,一些地方还是不一样的比如没有Document,没有window对象,无法进行DOM操作等。所以推荐首页等重要页面进行SSR。

  确实有这个问题,理论上讲,RPC要比客户端请求快很多,这样可以节省很多时间;但是如果接口很慢会造成白屏时间过长,得不偿失。所以接口很慢的页面不建议做SSR,同时接口也应该有严格的规范控制接口返回时间。

  页面如果有很重的逻辑比如判断很多不同条件,做出很多相应处理;依次请求很多接口,或者一起请求大量数据等情况,这些逻辑处理都需要一同写进SSR中。

  使用Node服务器的话,还涉及到服务器的日常维护问题,日志收集,错误报警等问题,以及性能问题。要求前端(SA)有一定的Node服务器的维护经验,这时前端已经不是纯前端了。

  这个问题才是关键的问题。并不是所有项目都适合SSR,就好像不是所有项目都适合Redux一样。根据SSR特点适合场景:

网友评论

我的2016年度评论盘点
还没有评论,快来抢沙发吧!