浅谈先后端路由与先后端渲染

时间 2019-11-17

标签浅谈后端路由渲染栏目系统网络繁體版

原文原文链接

原文首发于个人博客javascript

最近常常会遇到有人问诸如相似下面的问题：php

为啥我写的Vue应用在开发阶段都没问题，部署到服务端以后访问不了除了/的页面呢
为啥我写的SPA页面的路由用hash模式都没问题，改为history模式就问题百出呢
啥是前端路由啥是后端路由，要怎么配后端才能支持个人前端路由呢

这个问题是不少初学者会问的问题，因而结合我本身的学习经历也来简单的讲解一下这两者的区别与联系，但愿能对大家有所帮助。html

老手能够绕道，去看些更有用的文章吧~前端

什么是路由

理解Web路由这篇文章讲得特别好了。vue

在Web开发过程当中，常常会遇到『路由』的概念。那么，到底什么是路由？简单来讲，路由就是URL到函数的映射。java

访问的URL会映射到相应的函数里（这个函数是广义的，能够是前端的函数也能够是后端的函数），而后由相应的函数来决定返回给这个URL什么东西。路由就是在作一个匹配的工做。node

从后端路由讲起

在web开发早期的「刀耕火种」年代里，一直是后端路由占据主导地位。无论是php，仍是jsp、asp，用户能经过URL访问到的页面，大可能是经过后端路由匹配以后再返回给浏览器的。经典面试题，「你从浏览器地址栏里输入www.baidu.com到你看到网页这个过程当中经历了什么」其实讲的也是这个道理。react

在web后端，无论是什么语言的后端框架，都会有一个专门开辟出来的路由模块或者路由区域，用来匹配用户给出的URL地址，以及一些表单提交、ajax请求的地址。一般遇到没法匹配的路由，后端将会返回一个404状态码。这也是咱们常说的404 NOT FOUND的由来。webpack

URL与Methods

若是你关注RESTful API，那么将会很熟悉下面四种发起请求的类型：GET，POST，PUT，DELETE。git

它们分别对应四种基本操做：GET用来获取资源，POST用来新建资源（也能够用于更新资源），PUT用来更新资源，DELETE用来删除资源。 ——来自阮一峰《理解RESTful架构》

虽然上面说的是RESTful API，可是实际上咱们在地址栏输入一个URL，并回车的时候，是以GET请求发出去的。这也体现了，URL地址和请求的method也应该是一一对应。下面给出一个例子：

router.post('/user/:id', addUser)
复制代码

假如个人后端路由配置里只有这一句路由。那么我经过浏览器里访问：http://xxx.com/user/123的话是没法访问到的，也会返回一个404。由于后端只配了一个post方法的路由。若是要接受这个请求，那么必须有以下的路由：

router.get('/user/:id', getUser) // 配置get路由
router.post('/user/:id', addUser)
复制代码

后端路由与服务端渲染

前面说了，「刀耕火种」的年代里，网页一般是经过后端路由直出给客户端浏览器的。也就是网页的html通常是在后端服务器里经过模板引擎渲染好再交给前端的。至于一些其余的效果，是经过预先写在页面里的jQuery、Bootstrap等常见的前端框架去负责的。

若是你说有些网站已是经过ajax去实现的页面，好比gmail，好比qq邮箱。那么你要注意到哪怕是这些页面，它们页面的「龙骨」也并不是是所有经过ajax去实现的，依然仍是后端直出——这也就是咱们如今又老生常谈的服务端渲染。

服务端渲染的好处有不少，好比对于SEO友好，一些对安全性要求高的页面采用服务端渲染是更保险的。而在当时尚未node.js的年代，为了良好地构建前端页面，都是经过服务端语言对应的模板引擎来实现动态网页、页面结构的组织、组件的复用。好比Laravel的blade，用在Django上的jinja2，用在Struts的jsp等等。实际上到现在，一门后端语言想要能实现本身的web功能，都须要有本身对应的模板引擎。

node.js诞生以后，前端拥有本身的后端渲染的模板引擎也成为了现实。常见的好比pug、ejs、nunjucks等。这些模板引擎搭配Express、Koa等后端框架也在一开始风靡一时。

不过在这个过程当中，随着web应用的开发愈来愈复杂，单纯服务端渲染的问题开始慢慢的暴露出来了——耦合性太强了，jQuery时代的页面很差维护，页面切换白屏严重等等。耦合性问题虽然能经过良好的代码结构、规范来解决，不过jQuery时代的页面很差维护这是有目共睹的，全局变量满天飞，代码入侵性过高。后续的维护一般是在给前面的代码打补丁。而页面切换的白屏问题虽然能够经过ajax、或者iframe等来解决，可是在实现上就麻烦了——进一步增长了可维护的难度。

因而，咱们开始进入了前端路由的时代。

过渡到前端路由

前端路由——顾名思义，页面跳转的URL规则匹配由前端来控制。而前端路由主要是有两种显示方式：

带有hash的前端路由，优势是兼容性高。缺点是URL带有#号很差看
不带hash的前端路由，优势是URL不带#号，好看。缺点是既须要浏览器支持也须要后端服务器支持

前端路由应用最普遍的例子就是当今的SPA的web项目。无论是Vue、React仍是Angular的页面工程，都离不开相应配套的router工具。前端路由带来的最明显的好处就是，地址栏URL的跳转不会白屏了——这也得益于前端渲染带来的好处。

前端路由与前端渲染

讲前端路由就不能不说前端渲染。我以Vue项目为例。若是你是用官方的vue-cli搭配webpack模板构建的项目，你有没有想过你的浏览器拿到的html是什么样的？是你页面长的那样有button有form的样子么？我想不是的。在生产模式下，你看看构建出来的index.html长什么样：

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Vue</title>
</head>
<body>
  <div id="app"></div>
  <script type="text/javascript" src="xxxx.xxx.js"></script>
  <script type="text/javascript" src="yyyy.yyy.js"></script>
  <script type="text/javascript" src="zzzz.zzz.js"></script>
</body>
</html>
复制代码

一般长上面这个样子。能够看到，这个其实就是你的浏览器从服务端拿到的html。这里面空荡荡的只有一个<div id="app"></div>这个入口的div以及下面配套的一系列js文件。因此你看到的页面实际上是经过那些js渲染出来的。这也是咱们常说的前端渲染。

前端渲染把渲染的任务交给了浏览器，经过客户端的算力来解决页面的构建，这个很大程度上缓解了服务端的压力。并且配合前端路由，无缝的页面切换体验天然是对用户友好的。不过带来的坏处就是对SEO不友好，毕竟搜索引擎的爬虫只能爬到上面那样的html，对浏览器的版本也会有相应的要求。

须要明确的是，只要在浏览器地址栏输入URL再回车，是必定会去后端服务器请求一次的。而若是是在页面里经过点击按钮等操做，利用router库的api来进行的URL更新是不会去后端服务器请求的。

Hash模式

hash模式利用的是浏览器不会对#号后面的路径对服务端发起路由请求。也即在浏览器里输入以下这两个地址：http://localhost/#/user/1和http://localhost/其实到服务端都是去请求http://localhost这个页面的内容。

而前端的router库经过捕捉#号后面的参数、地址，来告诉前端库（好比Vue）渲染对应的页面。这样，无论是咱们在浏览器的地址栏输入，或者是页面里经过router的api进行的跳转，都是同样的跳转逻辑。因此这个模式是不须要后端配置其余逻辑的，只要给前端返回http://localhost对应的html，剩下具体是哪一个页面，就由前端路由去判断即可。

History模式

不带#号的路由，也就是咱们一般能见到的URL形式。router库要实现这个功能通常都是经过HTML5提供的history这个api。好比history.pushState()能够向浏览器地址栏push一个URL，而这个URL是不会向后端发起请求的！经过这个特性，便能很方便地实现漂亮的URL。不过须要注意的是，这个api对于IE9及其如下版本浏览器是不支持的，IE10开始支持，因此对于浏览器版本是有要求的。vue-router会检测浏览器版本，当没法启用history模式的时候会自动降级为hash模式。

上面说了，你在页面里的跳转，一般是经过router的api去进行的跳转，router的api调用的一般是history.pushState()这个api，因此跟后端没什么关系。可是一旦你从浏览器地址栏里输入一个地址，好比http://localhost/user/1,这个URL是会向后端发起一个get请求的。后端路由表里若是没有配置相应的路由，那么天然就会返回一个404了！这也就是不少朋友在生产模式遇到404页面的缘由。

那么不少人会问了，那为何我在开发模式下没问题呢？那是由于vue-cli在开发模式下帮你启动的那个express开发服务器帮你作了这方面的配置。理论上在开发模式下原本也是须要配置服务端的，只不过vue-cli都帮你配置好了，因此你就不用手动配置了。

那么该如何配置呢？其实在生产模式下配置也很简单，参考vue-router给出的配置例子。一个原则就是，在全部后端路由规则的最后，配置一个规则，若是前面其余路由规则都不匹配的状况下，就执行这个规则——把构建好的那个index.html返回给前端。这样就解决了后端路由抛出的404的问题了，由于只要你输入了http://localhost/user/1这地址，那么因为后端其余路由都不匹配，那么就会返回给浏览器index.html。

浏览器拿到这个html以后，router库就开始工做，开始获取地址栏的URL信息，而后再告诉前端库（好比Vue）渲染对应的页面。到这一步就跟hash模式是相似的了。

固然，因为后端没法抛出404的页面错误，404的URL规则天然是交给前端路由来决定了。你能够本身在前端路由里决定什么URL都不匹配的404页面应该显示什么。

前端路由与服务端渲染

虽然前端渲染有诸多好处，不过SEO的问题，仍是比较突出的。因此react、vue等框架在后来也在服务端渲染上作着本身的努力。基于前端库的服务端渲染跟之前基于后端语言的服务端渲染又有所不一样。前端框架的服务端渲染大多依然采用的是前端路由，而且因为引入了状态统1、vnode等等概念，它们的服务端渲染对服务器的性能要求比php等语言基于的字符串填充的模板引擎渲染对于服务器的性能要求高得多。因此在这方面不只是框架自己在不断改进算法、优化，服务端的性能也必需要有所提高。当初掘金换成SSR的时候也遇到了对应的性能问题，就是这个缘由。

固然在两者之间，也出现了预渲染的概念。也即先在服务端构建出一部分静态的html文件，用于直出浏览器。而后剩下的页面再经过经常使用的前端渲染来实现。一般咱们能够把首页采用预渲染的方式。这个的好处是明显的，兼顾了SEO和服务器的性能要求。不过它没法作到全站SEO，生产构建阶段耗时也会有所提升，这也是遗憾所在。

关于预渲染，能够考虑使用prerender-spa-plugin这个webapck的插件，它的3.x版本开始使用puppeteer来构建html文件了。

先后端分离

得益于前端路由和现代前端框架的完整的先后端渲染能力，跟页面渲染、组织、组件相关的东西，后端终于能够不用再参与了。

先后端分离的开发模式也逐渐开始普及。前端开始更加注重页面开发的工程化、自动化，然后端则更专一于api的提供和数据库的保障。代码层面上耦合度也进一步下降，分工也更加明确。咱们也摆脱了当初「刀耕火种」的web开发年代。撒花~

总结

但愿经过此文可以让你对于先后端路由和先后端渲染有所了解。在实际开发的过程当中，也不该该仅仅关注于本身所在的领域，相关的领域也要有所涉猎，这样才能面对问题游刃有余。

注：文中的图我使用OmniGraffle制做。转载请注明做者！