[TOC]
> 前端 Front-end 和后端 Back-end 是描述進程開始和結束的通用詞匯。前端作用于采集輸入信息，后端進行處理。
這種說法給人一種很模糊的感覺，但是他說得又很對，它負責視覺展示。在 MVC 結構或者 MVP 中，負責視覺顯示的部分只有 View 層，而今天大多數所謂的 View 層已經超越了 View 層。前端是一個很神奇的概念，但是而今的前端已經發生了很大的變化。你引入了 Backbone、Angluar，你的架構變成了 MVP、MVVM。盡管發生了一些架構上的變化，但是項目的開發并沒有因此而發生變化。這其中涉及到了一些職責的問題，如果某一個層級中有太多的職責，那么它是不是加重了一些人的負擔？
后臺在過去的歲月里起著很重要的作用，當然在未來也是。就最幾年的解耦趨勢來看，它在變得更小，變成一系列的服務。并向前臺提供很多 RESTful API，看上去有點像提供一些輔助性的工作。
因此在這一章里，我們將講述詳細介紹：
1. 后臺語言與選型
2. 前端框架與選型
3. 前端一致化，后臺服務化的趨勢
4. 前后端通訊
## 后臺語言選擇
如何選擇一門好的后臺語言似乎是大家都很感興趣的問題？大概只是因為他們想要在一開始的時候去學一門很實用的語言——至少會經常用到，而不是學好就被遺棄了。或者它不會因為一門新的語言的出現而消亡。
### JavaScript
在現在看來，JavaScript 似乎是一個性價比非常高的語言。只要是 Web 就會有前端，只要有前端就需要有 JavaScript。與此同時 Node.js 在后臺中的地位已經愈發重要了。
對于 JavaScript 來說，它可以做很多類型的應用。這些應用都是基于瀏覽器來運行的，有：
* Electron + Node.js + JavaScript 做桌面應用
* Ionic + JavaScript 做移動應用
* Node.js + JavaScript 網站前后臺
* JavaScript + Tessl 做硬件
So，這是一門很有應用前景的語言。
### Python
Python 誕生得比較早，其語言特性——做事情只有一件方法，也決定了這門語言很簡單。在 ThoughtWorks University 的學習過程中，接觸了一些外國小伙伴，這是大多數人學習的第一門語言。
Python 在我看來和 JavaScript 是相當劃算的語言，除了它不能在前端運行，帶來了一點劣勢。Python 是一門簡潔的語言，而且有大量的數學、科學工具，這意味著在不遠的將來它會發揮更大的作用。我喜歡在我的各種小項目上用 Python，如果不是因為我對前端及數據可視化更感興趣，那么Python 就是我的第一語言了。
### Java
除此呢，我相信 Java 在目前來說也是一個不錯的選擇。
在學校的時候，一點兒也不喜歡 Java。后來才發現，我從 Java 上學到的東西比其他語言上學得還多。如果 Oracle 不毀壞 Java，那么他會繼續存活很久。我可以用 JavaScript 造出各種我想要的東西，但是通常我無法保證他們是優雅的實現。過去人們在 Java 上花費了很多的時間，或在架構上，或在語言上，或在模式上。由于這些投入，都給了人們很多的啟發。這些都可以用于新的語言，新的設計，畢竟沒有什么技術是獨立于舊的技術產生出來的。
### PHP
PHP 呢，據說是這個『世界上最好的語言』，我服務器上運行著幾個不同的 WordPress 實例。對于這門語言，我還是相當放心的。并且這門語言由于上手簡單，同時國內有大量的程序員已經掌握好了這門語言。不得不提及的是 WordPress 已經占領了 CMS 市場超過一半的份額，并且它也占領了全球網站的四分之一。還有 Facebook，這個世界上最大的 PHP 站點也在使用這門語言。
### 其他
個人感覺 Go 也不錯，雖然沒怎么用，但是性能應該是相當可以的。
Ruby、Scala，對于寫代碼的人來說，這是非常不錯的語言。但是如果是團隊合作時，就有待商榷。
## MVC
人們在不斷地反思這其中復雜的過程，整理了一些好的架構模式，其中不得不提到的是我司 Martin Fowler 的《企業應用架構模式》。該書中文譯版出版的時候是2004年，那時對于系統的分層是
| 層次 | 職責 |
| --- | --- |
| 表現層 | 提供服務、顯示信息、用戶請求、HTTP請求和命令行調用。 |
| 領域層 | 邏輯處理，系統中真正的核心。 |
| 數據層 | 與數據庫、消息系統、事物管理器和其他軟件包通訊。 |
化身于當時最流行的 Spring，就是 MVC。人們有了 iBatis 這樣的數據持久層框架，即 ORM，對象關系映射。于是，你的 package 就會有這樣的幾個文件夾：
~~~
|____mappers
|____model
|____service
|____utils
|____controller
~~~
在 mappers 這一層，我們所做的莫過于如下所示的數據庫相關查詢：
~~~
@Insert(
"INSERT INTO users(username, password, enabled) " +
"VALUES (#{userName}, #{passwordHash}, #{enabled})"
)
@Options(keyProperty = "id", keyColumn = "id", useGeneratedKeys = true)
void insert(User user);
~~~
model 文件夾和 mappers 文件夾都是數據層的一部分，只是兩者間的職責不同，如：
~~~
public String getUserName() {
return userName;
}
public void setUserName(String userName) {
this.userName = userName;
}
~~~
而他們最后都需要在 Controller，又或者稱為 ModelAndView 中處理：
~~~
@RequestMapping(value = {"/disableUser"}, method = RequestMethod.POST)
public ModelAndView processUserDisable(HttpServletRequest request, ModelMap model) {
String userName = request.getParameter("userName");
User user = userService.getByUsername(userName);
userService.disable(user);
Map<String,User> map = new HashMap<String,User>();
Map <User,String> usersWithRoles= userService.getAllUsersWithRole();
model.put("usersWithRoles",usersWithRoles);
return new ModelAndView("redirect:users",map);
}
~~~
在多數時候，Controller 不應該直接與數據層的一部分，而將業務邏輯放在 Controller 層又是一種錯誤，這時就有了 Service 層，如下圖：
Service MVC
Domain（業務）是一個相當復雜的層級，這里是業務的核心。一個合理的 Controller 只應該做自己應該做的事，它不應該處理業務相關的代碼：
我們在 Controller 層應該做的事是：
1. 處理請求的參數
2. 渲染和重定向
3. 選擇 Model 和 Service
4. 處理 Session 和 Cookies
業務是善變的，昨天我們可能還在和對手競爭誰先推出新功能，但是今天可能已經合并了。我們很難預見業務變化，但是我們應該能預見 Controller 是不容易變化的。在一些設計里面，這種模式就是 Command 模式。
### Model
> 模型用于封裝與應用程序的業務邏輯相關的數據以及對數據的處理方法。
它是介于數據與控制器之間的層級，擁有對數據直接訪問的權力——增刪改查(CRUD)。Web 應用中，數據通常是由數據庫來存儲，有時也會用搜索引擎來存儲
因此在實現這個層級與數據庫交付時，可以使用 SQL 語句，也可以使用 ORM 框架。
SQL(Structured Query Language，即結構化查詢語言)， 語句是數據庫的查詢語言
ORM(Object Relational Mapping)，即對象關系映射，主要是將數據庫中的關系數據映射稱為程序中的對象。
### View
View 層在 Web 應用中，一般是使用模板引擎裝載對應 HTML。如下所示的是一段 JSP 代碼：
~~~
<html>
<head><title>First JSP</title></head>
<body>
<%
double num = Math.random();
if (num > 0.95) {
%>
<h2>You'll have a luck day!</h2><p>(<%= num %>)</p>
<%
} else {
%>
<h2>Well, life goes on ... </h2><p>(<%= num %>)</p>
<%
}
%>
<a href="<%= request.getRequestURI() %>"><h3>Try Again</h3></a>
</body>
</html>
~~~
上面的 JSP 代碼在經過程序解析、處理后，會變成相對應的 HTML。而我們可以發現在這里的 View 層不僅僅只有模板的作用，我們會發現這里的 View 層還計劃了部分的邏輯。我們可以在后面細細看這些問題，對于前端的 View 層來說，他可能是這樣的：
~~~
<div class="information pure-g">
{{#.}}
<div class="pure-u-1 ">
<div class="l-box">
<h3 class="information-head"><a href="#/blog/{{slug}}" alt="{{title}}">{{title}}</a></h3>
<p>
發布時間:<span>{{created}}</span>
<p>
{{{content}}}
</p>
</p>
</div>
</div>
{{/.}}
</div>
~~~
在這里的 View 層只是單純的一個顯示作用，這也是我們推薦的做法。業務邏輯應該盡可能的放置于業務層。
### Controller
> 控制器層起到不同層面間的組織作用，用于控制應用程序的流程。
### 更多
在前后端解耦合的系統中，通常系統的架構模式就變成了 MVP，又或者是 MVVM。
MVC、MVVM、MVP 對比
三者間很大的不同在于層級間的通訊模型、使用場景。
#### MVP
> MVP 是從經典的模式 MVC 演變而來，它們的基本思想有相通的地方：Controller/Presenter 負責邏輯的處理，Model 提供數據，View 負責顯示。
#### MVVM
MVVM 是 Model-View-ViewModel 的簡寫。相比于MVC悠久的歷史來說，MVVM 是一個相當新的架構，它最早于2005年被由的 WPF 和Silverlight 的架構師 John Gossman 提出，并且應用在微軟的軟件開發中。而 MVC 已經被提出了二十多年了，可見兩者出現的年代差別有多大。
MVVM 在使用當中，通常還會利用雙向綁定技術，使得 Model 變化時，ViewModel 會自動更新，而 ViewModel 變化時，View 也會自動變化。所以，MVVM 模式有些時候又被稱作：model-view-binder 模式。
## 后臺即服務
> BaaS（Backend as a Service）是一種新型的云服務，旨在為移動和 Web 應用提供后端云服務，包括云端數據/文件存儲、賬戶管理、消息推送、社交媒體整合等。
產生這種服務的主要原因之一是因為移動應用的流行。在移動應用中，我們實際上只需要一個 API 接口來連接數據庫，并作一些相應的業務邏輯處理。對于不同的應用產商來說，他們打造 API 的方式可能稍有不同，然而他們都只是將后臺作為一個服務。
在一些更特殊的例子里，即有網頁版和移動應用端，他們也開始使用同一個 API。前端作為一個單頁面的應用，或者有后臺渲染的應用。其架構如下圖所示：
Backend As A Service
### API 演進史
在早期的工作中，我們會發現我們會將大量的業務邏輯放置到 View 層——如迭代出某個結果。
而在今天，當我們有大量的邏輯一致時，我們怎么辦，重復實現三次？
如下所示是筆者之前重構的系統的一個架構縮略圖：
重復邏輯的系統架構
上面系統產生的主要原因是：技術本身的演進所造成的，并非是系統在一開始沒有考慮到這個問題。
API 演進史
從早期到現在的互聯網公司都有這樣的問題，也會有同樣的過程：
第一階段： 因為創始人對于某個領域的看好，他們就創建了這樣的一個桌面網站。這個時間點，大概可以在2000年左右。
第二階段： 前“智能手機”出現了，人們需要開發移動版本的網站來適用用戶的需要。這時由于當時的開發環境，以及技術條件所限，當時的網站只會是桌面模板的簡化。這時還沒有普及 Ajax 請求、SPA 這些事物。
第三階段： 手機應用的制作開始流行起來了。由于需要制作手機應用，人們就需要在網站上創建 API。由于當時的業務或者項目需求，這個 API 是直接耦合在系統中的。
第四階段： 由于手機性能的不斷提高，并且移動網絡速度不斷提升，人們便開始在手機上制作單頁面應用。
由于他們使用的是相同業務邏輯、代碼邏輯相同而**技術棧不同**的代碼，當有一個新的需求出現時，他們需要重復多次實現，如下圖所示：
重復業務邏輯的系統架構
隨后——也就是今天，各種新的解決方案出現了，如 React、混合應用、原生 + Web 的混合式應用、他們的目的就是解決上述的問題。不過，這些解決方案只是為了解決在前端中可能出現的問題，詳細的內容可以見《前端演進史》。
而人們也借此機會在統一后臺——因為我們可以借助于混合應用或混合式應用（即原生 + 內嵌 WebView，可以同時解決性能和跨平臺問題）統一移動端，借助于響應式設計的理念可以統一桌面、平板和手機端。
因此，我們需要的就只是這樣的一個 API：
One API
### 后臺即服務
現在，讓我們來看看一個采用后臺即服務的網站架構會是怎樣的？
## 數據持久化
信息源于數據，我們在網站上看到的內容都應該是屬于信息的范疇。這些信息是應用從數據庫中根據業務需求查找、過濾出來的數據。
數據通常以文件的形式存儲，畢竟文件是存儲信息的基本單位。只是由于業務本身對于 Create、Update、Query、Index 等有不同的組合需求就引發了不同的數據存儲軟件。
如上章所說，View 層直接從 Model 層取數據，無遺也會暴露數據的模型。作為一個前端開發人員，我們對數據的操作有三種類型：
1. 數據庫。由于 Node.js 在最近幾年里發展迅猛，越來越多的開發者選擇使用 Node.js 作為后臺語言。這與傳統的 Model 層并無多大不同，要么直接操作數據庫，要么間接操作數據庫。即使在 NoSQL 數據庫中也是如此。
2. 搜索引擎。對于以查詢為主的領域來說，搜索引擎是一個更好的選擇，而搜索引擎又不好直接向 View 層暴露接口。這和招聘信息一樣，都在暴露公司的技術棧。
3. RESTful。RESTful 相當于是 CRUD 的衍生，只是傳輸介質變了。
4. LocalStorage。LocalStorage 算是另外一種方式的 CRUD。
說了這么多都是廢話，他們都是可以用類 CRUD 的方式操作。
### 文件存儲
通常來說，以這種方式存儲最常見的方式是 log(日志)，如 Nginx 的 access.log。像這樣的文件就需要一些專業的軟件，如 GoAccess、又或者是 Hadoop、Spark 來做對應的事。
在數據庫出現之前，人們都是使用文件來存儲數據的。數據以文件為單位存儲在硬盤上，并且這些文件不容易一起管理、修改等等。如下圖所示的是我早期存儲文件的一種方式：
~~~
├── 3.12
│?? ├── cover.png
│?? └── favicon.ico
└── 3.13
└── template.tex
~~~
每天我們都會修改、查看大量的不同類型的文件。而由于工作繁忙，我們可能沒有辦法一一地去分類這些文件。有時選擇的便是，優先先按日期把文件一劃分，接著再在隨后的日子里歸檔。而這種存儲方式大量的依賴于人來索引的工作，在很多時候往往顯得不是很靠譜。并且當我們將數據存儲進去后，往往很難進行修改。大量的 Log 文件就需要專門的工作來分析和使用，依賴于人來解析這些日志往往顯得不是很靠譜。這時我們就需要一些重量級的工具，如用 Logstash、ElasticSearch、Kibana 來處理 Nginx 訪問日志。
而對于那些非專業人員來說，使用 Excel 這樣的工具往往顯得比較方便。他們不需要去操作數據庫，也不需要專業的知識來處理這些知識。只是從某種意義上來說，Excel 應該歸屬于數據庫的范疇。
### 數據庫
當我們開始一個 Web 應用的時候，如創建一個用戶管理系統的時候，我們就需要不斷由于經常對文件進行查詢、修改、插入和刪除等操作。不僅僅如此，我們還需要定義數據之前的關系，如這個用戶對應這個密碼。在一些更復雜的情況下，我們還需要尋找中這些用戶對應的一些操作數據等等。如果我們還是這些工作交給文件來處理，那么我們便是在向自己挖坑。
> 數據庫，簡單來說可視為電子化的文件柜——存儲電子文件的處所，用戶可以對文件中的數據運行新增、截取、更新、刪除等操作。
在操作庫的時候，我們會使用到一名為 SQL（英語：Structural Query Language，中文： 結構化查詢語言）的領域特定語言來對數據進行操作。
> SQL 是高級的非過程化編程語言，它允許用戶在高層數據結構上工作。它不要求用戶指定對數據的存放方法，也不需要用戶了解其具體的數據存放方式。
數據庫里存儲著大量的數據，在我們對系統建模的時候，也在決定系統的基礎模型。
#### ORM
在傳統 SQL 數據庫中，我們可能會依賴于 ORM，也可能會自己寫 SQL。在使用 ORM 框架時，我們需要先定義 Model，如下是 Node.js 的 ORM 框架 Sequelize 的一個示例：
~~~
var User = sequelize.define('user', {
firstName: {
type: Sequelize.STRING,
field: 'first_name'
},
lastName: {
type: Sequelize.STRING
}
}, {
freezeTableName: true
});
User.sync({force: true}).then(function () {
// Table created
return User.create({
firstName: 'John',
lastName: 'Hancock'
});
});
~~~
上面定義的 Model，在程序初始化的時候將會創建相應的數據庫字段。并且會創建一個 firstName 為 ‘John’，lastName 為 ‘Hancock’ 的用戶。而這個過程中，我們并不需要操作數據庫。
像如 MongoDB 這類的數據庫，也是存在數據模型，但說的卻是嵌入子文檔。在業務量大的情況下，數據庫在考驗公司的技術能力，想想便覺得 Amazon RDS 挺好的。
### 搜索引擎
盡管百科上對于搜索引擎的定義是這樣的：
> 搜索引擎指自動從因特網搜集信息，經過一定整理以后，提供給用戶進行查詢的系統。
但是這樣說往得不是非常準確。因為有相當多的網站采用了搜索引擎作為基礎的存儲服務架構，而且他們并非自動從互聯網上搜索信息。搜索引擎應該分成三個部分來組成：
1. 索引服務
2. 搜索服務
3. 索引數據
索引服務便是用于將數據存儲到索引數據中，而搜索服務正是搜索引擎存在的意義。對于查詢條件復雜的網站來說，采用搜索引擎就意味著減少了非常多的繁瑣數據處理事務。在一些架構中，人們用數據庫存儲數據，并使用工具來將數據注入到搜索引擎中。
從架構上來說，使用搜索引擎的優點是：分離存儲、查詢部分。從開發上來說，它可以讓我們更關注于業務本身的價值，而不是去實現這樣一個搜索邏輯。
如下圖所示的 Lucene 應用的架構：
Lucene 應用架構
可以從圖中看到系統明顯被劃分成兩部分：
1. Index Documents。索引文檔部分，將用于存儲數據到文件系統中。
2. Search Index。搜索部分，用于查詢相應的數據。
## 前端框架選擇
選擇前端框架似乎是一件很難的事，然而這件事情并不是看上去那么難。只是有時候你只想追隨潮流，或者因為你在技術選型受到一些影響。但是總的來說，選擇一個框架并不是一件很難的事。同時也不是一件非常重要的事，因為框架本身是相通的。如果我們不盡量去解耦系統，那么選擇什么框架也都是一樣的。
### Angular
AngularJS 對于后端人員寫前端代碼來說，是一個非常不錯的選擇。Angular 框架采用并擴展了傳統 HTML，通過雙向的數據綁定來適應動態內容，雙向的數據綁定允許模型和視圖之間的自動同步。
并且類似于 Ionic 這樣的混合框架，也將 Ionic 帶到了移動應用的領域。
### React
React 似乎很受市場歡迎，各種各樣的新知識——虛擬 DOM、JSX、Component 等等。React 只是我們在上面章節里說到的 View 層，而這個 View 層需要輔以其他框架才能完成更多的工作。
并且 React 還有一個不錯的殺手锏——React Native，雖然這個框架還在有條不紊地挖坑中，但是這真的是太爽了。以后我們只需要一次開發就可以多處運行了，再也沒有比這更爽的事情發生了。
### Vue
Vue.js 是一個輕量級的前端框架。它是一個更加靈活開放的解決方案。它允許你以希望的方式組織應用程序，你可以將它嵌入一個現有頁面而不一定要做成一個龐大的單頁應用。
### jQuery 系
jQuery 還是一個不錯的選擇，不僅僅對于學習來說，而且對于工作來說也是如此。如果你們不是新起一個項目或者重構舊的項目，那么必然你是沒有多少機會去超越 DOM。而如果這時候嘗試去這樣做會付出一定的代價，如我在前端演進史所說的那樣——晚點做出選擇，可能會好一點。
因為誰說 jQuery 不會去解放 DOM，React 帶來的一些新的思想可能就比不上它的缺點。除此，jQuery 耕織幾年的生態系統也是不可忽略。
#### Backbone + Zepto + Mustache
這是前幾年（今年2016）的一個技術方向，今天似乎已經不太常見了。在這種模式下，人們使用 Backbone 來做一些路由、模型、視圖、集合方面的工作，而由 jQuery 的兼容者 Zepto 來負責對 DOM 的處理，而 Mustache 在這里則充當模板系統的工作。
## 前臺與后臺交互
在我們把后臺服務化后，前端跨平臺化之前，我們還需要了解前臺和后臺之間怎么通訊。從現有的一些技術上來看，Ajax 和 WebSocket 是比較受歡迎的。
### Ajax
AJAX 即 “Asynchronous JavaScript And XML”（異步 JavaScript 和 XML），是指一種創建交互式網頁應用的網頁開發技術。這個功能在之前的很多年來一直被 Web 開發者所忽視，直到 Gmail、Google Suggest 和 Google Maps 的出現，才使人們開始意識到其重要性。通過在后臺與服務器進行少量數據交換，AJAX 可以使網頁實現異步更新。這意味著可以在不重新加載整個網頁的情況下，對網頁的某部分進行更新。傳統的網頁如果需要更新內容，必須重載整個網頁頁面。
Ajax 請求
說起 Ajax，我們就需要用 JavaScript 向服務器發送一個 HTTP 請求。這個過程要從 XMLHttpRequest 開始說起，它是一個 JavaScript 對象。它最初由微軟設計，隨后被 Mozilla、Apple 和 Google 采納。如今，該對象已經被 W3C 組織標準化。
如下的所示的是一個 Ajax 請求的示例代碼：
~~~
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if (xhr.readyState == XMLHttpRequest.DONE) {
alert(xhr.responseText);
}
}
xhr.open('GET', 'http://example.com', true);
xhr.send(null);
~~~
我們只需要簡單的創建一個請求對象實例，打開一個 URL，然后發送這個請求。當傳輸完畢后，結果的 HTTP 狀態以及返回的響應內容也可以從請求對象中獲取。
而這個返回的內容可以是多種格式，如 XML 和 JSON，但是從近年的趨勢來看，XML 基本上已經很少看到了。這里我們以 JSON 為主，來簡單地介紹一下返回數據的解析。
### JSON
> JSON(JavaScript Object Notation) 是一種輕量級的數據交換格式。它基于 ECMAScript 的一個子集。 JSON采用完全獨立于語言的文本格式，但是也使用了類似于 C 語言家族的習慣（包括 C、C++、C#、Java、JavaScript、Perl、Python等）。這些特性使 JSON 成為理想的數據交換語言。易于人閱讀和編寫，同時也易于機器解析和生成(一般用于提升網絡傳輸速率)。
#### XML VS JSON
JSON 格式的數據具有以下的一些特點：
* 容易閱讀
* 解析速度更快
* 占用空間更少
如下所示的是一個簡單的對比過程：
~~~
myJSON = {"age" : 12, "name" : "Danielle"}
~~~
如果我們要取出上面數值中的age，那么我們只需要這樣做：
~~~
anObject = JSON.parse(myJSON);
anObject.age === 12 // True
~~~
同樣的，對于 XML 來說，我們有下面的格式:
~~~
<person>
<age>12</age>
<name>Danielle</name>
</person>
~~~
而如果我們要取出上面數據中的age的值，他將是這樣的：
~~~
myObject = parseThatXMLPlease();
thePeople = myObject.getChildren("person");
thePerson = thePeople[0];
thePerson.getChildren("age")[0].value() == "12" // True
~~~
對比一下，我們可以發現XML的數據不僅僅解析上比較麻煩，而且還繁瑣。
#### JSON WEB Tokens
> JSON Web Token (JWT) 是一種基于 token 的認證方案。
在人們大規模地開始 Web 應用的時候，我們在授權的時候遇到了一些問題，而這些問題不是 Cookie 所能解決的。Cookie 存在一些明顯的問題：不能支持跨域、并且不是無狀態的、不能使用CDN、與系統耦合等等。除了解決上面的問題，它還可以提高性能等等。基于 Session 的授權機制需要服務端來保存這個狀態，而使用 JWT 則可以跳過這個問題，并且使我們設計出來的 API 滿足 RESTful 規范。即，我們 API 的狀態應該是沒有狀態的。因此人們提出了 JWT 來解決這一系列的問題。
通過 JWT 我們可以更方便地寫出適用于前端應用的認證方案，如登陸、注冊這些功能。當我們使用 JWT 來實現我們的注冊、登陸功能時，我們在登陸的時候將向我們的服務器發送我們的用戶名和密碼，服務器驗證后將生成對應的 Token。在下次我們進行頁面操作的時候，如訪問 /Dashboard 時，發出的 HTTP 請求的 Header 中會包含這個 Token。服務器在接收到請求后，將對這個 Token 進行驗證并判斷這個 Token 是否已經過期了。
JWT 流程
需要注意的一點是：在使用 JWT 的時候也需要注意安全問題，在允許的情況下應該使用 HTTPS 協議。
### WebSocket
在一些網站上為了實現推送技術，都采用了輪詢的技術。即在特定的的時間間隔里，由瀏覽器對服務器發出 HTTP 請求，然后瀏覽器便可以從服務器獲取最新的消息。如下圖所示的是 Google Chrome 申請開發者賬號時發出的對應的請求：
Chrome Ajax 輪詢
從上圖中我們可以看到，Chrome 的前臺正在不斷地向后臺查詢 API 的結果。由于瀏覽器需要不斷的向服務器發出請求，而 HTTP 的 Header 是非常長的，即使是一個很小的數據也會占用大量的帶寬和服務器資源。為了解決這個問題，HTML5 推出了一種在單個 TCP 連接上進行全雙工通訊的協議WebSocket。
WebSocket 可以讓客戶端和服務器之間存在持久的連接，而且雙方都可以隨時開始發送數據。
