課程目標
@掌握Koa基本用法? ? @理解Koa設(shè)計思路? ? @路由? ? @靜態(tài)文件服務(wù)? ?@模板引擎
koa 概述：koa是一個新的Web框架，致力于成為Web應(yīng)用和api開發(fā)領(lǐng)域中的一個更小，更富有表現(xiàn)力，更健壯的基石
koa是express的下一代基于node.js的web框架?
koa2完全使用Promise并配合async來實現(xiàn)異步
特點： 輕量 無捆綁? 中間件架構(gòu) 優(yōu)雅的api設(shè)計? ?增強錯誤處理
安裝： npm i koa -S
中間件機制、請求、響應(yīng)處理
中間件的作用是什么 ？
對于我們業(yè)務(wù)程序的描述有兩種需要，一種是順序的需要，同時也有一種非順序描述的需要，也可以說是一種橫向的業(yè)務(wù)描述的需要，比如鑒權(quán)，每次開始的時候需要處理，錯誤處理 每次到頭部的時候 包括統(tǒng)一加頭部，這些都可以認為是一種橫向業(yè)務(wù)描述的需要，這些統(tǒng)稱為AOP編程（面向切面編程）
中間件內(nèi)錯誤捕捉和全局內(nèi)錯誤捕捉
路由： npm i -S koa-router
在index.js中引入
靜態(tài)文件服務(wù)： npm i -S koa-static
模板引擎： npm i koa-hbs@next -S
引入并配置，app.js
創(chuàng)建views,views/partials,layout.hbs,index.hbs layout.hbs:
渲染，./routes/index.js
三種常見的鑒權(quán)方式 1 session / cookie 2 token 3 oAuth
1， session / cookie 方式
創(chuàng)建http.createServer服務(wù)，res.setHeader('Set-Cookie','cx=abc') 設(shè)置cookie, 啟動服務(wù)可以在application中看到cx abc的cookie信息 觀察一下network 在我在發(fā)送localhost的3000的請求的時候，它會response headers里發(fā) Set-Cookie:cx=abc cookie的原理是默認同域的情況下會發(fā)送cookie? Cookie: cx=abc? ,response回應(yīng)的時候如果瀏覽器收到讓你setCookie這樣兒一個header的時候，它就會設(shè)置這個cookie，如果下次再走這個請求的時候，它就會自動帶上這個cookie，作用就是建立一種前端的狀態(tài)的保存，回傳給他，這樣兒如果后端想在前端放置一個狀態(tài)的時候，我就可以有這樣一種方法，比如說我就可以設(shè)置很多信息了，比如前端的登錄態(tài)，使用這個cookie形成一種session機制。
下面我們看一下session:
說到session的話，我們怎么記錄登錄態(tài)或者說記錄用戶信息，假如每一個用戶有一個唯一的標識用 const sid = （Math.random() * 9999）.toFixed() ， 我們設(shè)置setHeader時可以這樣兒設(shè)置res.setHeader('Set-Cookie',`sid = ${sid}`)
同時我們可以在后端訪問的話，我們可以整一個鍵值對 const session = {} 設(shè)置 session[sid] = { name: 'wang' }
實現(xiàn)原理：1，服務(wù)器在接受客戶端首次訪問時在服務(wù)器創(chuàng)建session,然后保存session(我們可以保存在session中，也可以保存在redis中，推薦使用后者)，然后給這個session生成一個唯一的標識字符串，然后的響應(yīng)頭種下這個唯一標識字符串。
2，簽名，這一步通過秘鑰對sid進行簽名處理，避免客戶端修改sid(非必須步驟)
3，瀏覽器中收到請求響應(yīng)的時候會解析響應(yīng)頭，然后將sid保存在本地的cookie中，瀏覽器在下次http請求的請求頭中會帶上該域名下的cookie信息
4，服務(wù)器在接受客戶端請求時會去解析請求頭cookie中的sid,然后根據(jù)這個Sid去找服務(wù)器端保存的該客戶端的session,然后判斷該請求是否合法。
koa鑒權(quán)
當SESS_CONFIG的signed為true時，會對簽名的加密主體進行一次哈希，哈希其實就是一種摘要算法，原意是把一個不定長摘要出一個定長結(jié)果，并且它本身是一種摘要，具有雪崩效應(yīng)。
摘要：是一種不可逆的算法起到一種防篡改的作用，雪崩效應(yīng)：密文略有變化 ，明文就會發(fā)生巨大的變化，這種不可推算的效應(yīng)。
token驗證
1.客戶端使用用戶名和密碼請求登錄
2.服務(wù)端收到請求，去驗證用戶名與密碼
3.驗證成功后，服務(wù)端會簽發(fā)一個令牌(token) ,再把這個token發(fā)送給客戶端
4.客戶端收到token以后可以把它存儲起來，比如放在cookie里或者local storage里
5.客戶端每次向服務(wù)端請求資源的時候需要帶著服務(wù)端簽發(fā)的token
6.服務(wù)端收到請求然后去驗證客戶端的請深圳市里面帶著的Token 如果驗證成功，就向客戶端返回請求的數(shù)據(jù)
OAuth(開放授權(quán))
概念：三方登入主要基本于OAuth 2.0 OAuth協(xié)議為用戶資源的授權(quán)提供了一個案例的，開放而又簡易的標準，與以往的授權(quán)方式不同之處是OAUTH的授權(quán)不會使第三方觸及到用戶的賬號信息，如用戶名與密碼，即第三方無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的授權(quán)，因此OAUTH是安全的
OAUTH的登錄流程
補充材料：
當你想用異步程序描寫同步操作的時候就很麻煩了。https://github.com/su37josephxia/frontend-basic/blob/master/src/callback/index.js?（參考前端大班車）
EventLoop是什么 ： 事件循環(huán)被稱作循環(huán)的原因在于，它一直在查找新的事件并且執(zhí)行。一次循環(huán)的執(zhí)行稱之為 tick， 在這個循環(huán)里執(zhí)行的代碼稱作 task,event loop顧名思義就是事件循環(huán)，為什么要有事件循環(huán)呢？因為V8是單線程的，即同一時間只能干一件事情，但是呢文件的讀取，網(wǎng)絡(luò)的IO處理是很緩慢的，并且是不確定的,如果同步等待它們響應(yīng)，那么用戶就起飛了。于是我們就把這個事件加入到一個 事件隊列里(task),等到事件完成時，event loop再執(zhí)行一個事件隊列。
setTimeout / setImmediate / process.nextTick的區(qū)別 (https://blog.csdn.net/hkh_1012/article/details/53453138)
v8引擎單線程無法同時干兩件事
文件讀取 網(wǎng)絡(luò)IO緩慢具有不確定性
要通過異步回調(diào)的方式處理又稱為異步io
先同步再異步 異步放入隊列等同步完成后再執(zhí)行 每次循環(huán)叫一個tick(process.nextTick())
異步任務(wù)的區(qū)分
microtasks(微任務(wù))
唯一整個事件循環(huán)當中，僅存在一個，執(zhí)行為同步，同一個事件循環(huán)中的microtask按隊列順序，串行執(zhí)行完畢；?process.nextTick? /? promise / Object.observe? /? MutationObserver
tasks(宏任務(wù))
setTimeout? /? setInterval? /? setImmediate? /? I/O? /? UI渲染
先執(zhí)行微任務(wù) 再執(zhí)行宏任務(wù)
========================================================================
Restful API 及常見任務(wù)
