本篇内容主要介紹FaaS場景下的SSR架構，也就是在FaaS場景下怎麼開發服務端渲染頁面。服務端渲染是指前後端同構的服務端渲染，即React SSR。
在介紹SSR架構之前，首先簡單介紹一下Serverless。
首先是NodeJS的定位。在很多公司NodeJS都在充當BFF層的角色，甚至NodeJS隻出現在本地開發，僅僅做一些開發工具和建構工具的角色。最主要的原因，可能是因為前端工程師在運維方面的知識比較稀缺，就導緻了可能很多公司不敢NodeJS，不敢讓前端工程師做服務端。
但是随着Serverless概念的出現，上面提到的問題就很好解決了。Serverless不需要關注運維，隻需要關注自身業務邏輯的開發，因為運維的工作在雲開發平台都已經解決了，這對前端工程師來說是收益最大的。
從BFF到SFF層本質上開發模式并沒有改變，但是卻大大提升了開發效率。上圖列舉了在SFF場景下，經常做的5給方面工作：
第一個， API接口；
第二個，API Proxy；
第三個，Render渲染層。渲染層可以分為用戶端渲染和服務端渲染；
第四個，SSR+API，就是如何開發服務端渲染應用，下面會着重介紹在FaaS應用裡，如何同時開發服務端生産應用和API接口；
第五個，Gateway網關層。
SSR架構前身
SSR架構是由Egg+React+SSR演變來的。這個項目已經開源一年多了，目前大概有1200個star了。阿裡内部已經有七八個部門用于線上應用的開發了，阿裡外部也有很多公司正在使用這個項目來開發線上應用。大家對應用開發的整體回報是，比一些業界類似的架構好很多。
FaaS場景下的SSR架構
這個架構針對FaaS場景做了很多優化和制定了一些規範。盡量保證在雲開發和本地的開發體驗保持一緻。
實操示範SSR架構的使用
首先登陸雲開發平台http://workbench.aliyun.com，然後建立應用。在建立的時候的時候，選擇WEB和FaaS場景下的SSR架構。建立完成安裝依賴，tips是可以用cnpm而不是用npm來安裝依賴，cnpm安裝依賴要快很多。
如下圖可以看到yml檔案，可以看到和API接口看起來差不多。
上圖所示新增的 render字段的意思是，當檢測到函數裡有這個字段，這個函數要傳回htmlStr界面的，而不是傳回API服務。index handler的作用很簡單，就是從 ssr-core中emloy的render方法，然後再把傳回的結果到htmlStr。
本地開發也是通過Snpm start 來啟動服務，可以直接使用SSR架構。啟動後進行建構，同時啟動FaaS服務，最後會傳回一個位址，這個位址可以直接在浏覽器打開來預覽目前的應用。
從頁面的源碼可以看出它包含了一個完整的HTR結構，也就是說這個頁面是由服務端而不是用戶端渲染産生的，點選重新整理也不會産生因用戶端渲染而産生的白屏。
由根路由切換到詳情頁，這個切換過程僅限于前端的切換，不會向服務端送出請求。是以詳情頁的資料其實是由前端發起HTTP請求擷取的，這個請求也會寫在FaaS服務裡的。包括退回到首頁的操作也是前端路由的切換邏輯，隻有重新整理才是真正通路到伺服器。
如下圖在f.yml檔案中， api-index和api-detail底下是定義的兩個API的接口服務。打開web目錄，就是前端元件存放的目錄。打開Pages檔案夾，這個就是首頁元件對應的路由，這裡有一個fetch檔案，它定義了資料是怎麼擷取的。這裡區分了服務端和用戶端兩個場景的資料擷取。再看API index函數，它是傳回一個Json資料結構。如果是在服務端的話，非常簡單，可以直接通過ctx.apService拿到自己寫的一個Service服務直接調用，然後就可以傳回正确結果。
SSR架構還支援用戶端和服務端的一鍵切換的能力。以下圖為例，它是服務端渲染，在 url參數後面加csr=1，就可以迅速的切換為用戶端渲染，切換之後頁面的源碼就變成空的了。
回到控制台頁面繼續釋出，釋出之前要先build，把前端檔案進行打包，打包成生産環境需要用到的檔案大小。
如果使用Cloud ID釋出，可以直接通過左邊第一個tag；如果是本地釋出，可以直接通過一個指令來釋出。
釋出時選擇日常環境釋出。建構之後會放在build目錄下，然後根據函數作為檔案夾的區分。比如，目前渲染層函數叫index，建構出來的結果都放在build index函數檔案夾下，分為client和server兩個檔案夾。
Client檔案夾之前的課程已經詳細介紹過了，這裡就不多贅述。看下server檔案夾，因為是服務端渲染是以多出來一個server檔案夾，比如Page.server.js就是在服務端使用到的檔案。
Serverless場景和傳統的NodeJS應用的釋出場景有什麼差別呢？傳統NodeJS應用釋出場景，很多成熟的公司釋出建構大部分是在CI平台上進行的，比如說本地把代碼譜寫到倉庫之後自動出發這個建構邏輯；但是在雲平台釋出場景，代碼打包是在本地進行的，意思是點了部署後，首先它是會把本地的代碼都達成一個code.zip壓縮包，然後再把壓縮包上傳，同時對包的大小也是限制的。值得注意的一點，它也會把node-modules的檔案夾一起打包進去。
是以如果開發應用運作在Serverless場景，就需要很清楚哪些依賴是在生産方面用的，哪些依賴是在開發方面用的。如果不注意，打的包就會很容易特别大，超出平台限制。
部署成功後會傳回一個位址，可以通過這個位址打開預覽或申請新域名指到這個位址使用。
總結而言，本地開發隻需要關注start指令，執行ssr start；build就是執行ssr build 指令。如果是本地開發，也可以直接通過ssr deploy一鍵釋出到雲端。
ssr-spec規範
這部分主要介紹在怎樣的規範下，才能在Serverless場景下開發出一個渲染層的頁面。
（實操示範講解）
如下圖，架構在github的位址。
在這個位址可以看到SSR的規範。
這個規範主要是基于單頁應用和多頁應用兩個不同類型的應用制定不同的規範，分為SPA和MPA。當下非常常見應用是SPA類型的。
首先就src目錄放一些FaaS服務端相關的代碼。這裡要做的就是在檔案夾下新增一個web目錄， web目錄裡放一些前端相關的東西，比如前端元件。
這雖然是為FaaS場景打造的，但是與服務端無關。在web目錄下，上圖所示的檔案夾結構也可以參考。檔案夾裡的路由用的是約定式，不需要去手動編寫路由配置表。
舉個例子，pages檔案夾會放頁面的登入，有的也會将根元件放在這裡，如果pages有index檔案夾，就會把index檔案夾映射預設為根路由。
fetch.ts檔案，在這個檔案主要做一些資料擷取方面的邏輯，比如頁面需要在服務端調用哪個接口或者調哪個服務擷取資料，然後在檔案導出的函數裡把它傳回出來就可以了。
index.less是樣式檔案。
render.tsx，定義了它是怎麼渲染的，其實就是render方法。
components檔案夾存放了一些公共元件
pages檔案夾，如果頁面登入有對應的元件就會放在這裡；詳情頁可以放在detail檔案夾中。
Layout檔案夾，采用的是html結構。如果目前開發的是單頁面應用，隻需要一個layout就夠了；如果是為不同的路由做不同邏輯區分，可以在下圖代碼處拿到context，然後根據請求不同做不同邏輯處理。
yml檔案的編寫規範
yml檔案編寫規範，函數裡增加了render字段，也就是說，如果檢測到這個函數有rander字段，就說明這個函數會有渲染服務。
比如render有個mode，mode預設是以ssr模式來渲染的，如果把ssr寫成csr就會把它降級為用戶端。舉個例子，頁面可能會有些極端情況，當發生時頁面在服務上會報錯，這時候可以通過改yml檔案來為用戶端渲染。開發接口服務，隻需要handler和events是這兩個字段就可以了。
釋出這裡對接的是Midway FaaS的釋出功能，如果在雲平台的話，直接點 tab按鍵就可以釋出。
MPA的頁面規範
開發多頁面應用，跟單頁面應用總體上比較類似，差別是多頁面應用有不同的layout，每個pages檔案夾下面都是一個獨立的頁面和應用。如果不給每個檔案夾添加獨立layout，那麼就是用預設的layout。
建構出來的build目錄也會根據yml檔案，基于多頁和多函數建構出對應數量的檔案夾。如下圖所示，yml檔案如果有多個函數，每個函數都定義了一個render字段的話，這就需要開發一個MPA多頁面應用。
使用MPA多頁面應用很簡單，隻需要按照上文介紹的規範，添加一個web目錄，然後從ssr-core子產品裡倒入render方法，再把請求的.ctx傳進去，就會自動渲染元件，再把渲染好的結果傳回。
模式切換
降級也有多種方式。
為了更加靈活，如下圖，支援config.js。如果想改預設的配置或端口等，都有對應的配置可以更改。這個架構內建了很多流行的前端UI架構，不需要再為內建架構做額外配置了。