Express APP
作爲一個Node.js開發者，相信大家都可能會使用Express框架，無論是構建後端服務，或是搭建一個前端的開發態服務器，Express都是一個很流行的選擇。構建Express是極爲容易的，添加一些路由規則和對應的處理函數，再選擇一些中間件，一個應用就誕生了。
一個使用傳統託管方法的簡單 Express.js App —— 響應單次請求的過程。
下列代碼展示了一個最簡單的 Express App：
'use strict'
const express = require('express')
const app = express()
app.get('/', (req, res) => res.send('Hello world!'))
module.exports = app
這就完成了一個 Express App。若使用瀏覽器訪問http://localhost:3000，你便可以在打開的網頁中看到“Hello world!” 信息。
應用部署
麻煩的問題來了：如何才能將你構建的 Express App 展示給你的朋友或者家人？如何才能讓每個人都能訪問到它？
應用部署是一個耗時且痛苦的過程，但現在我們就假定你已經很快、很好地完成了部署的工作。你的應用已經能被所有人訪問了，並且之後也運轉良好。就這樣直到一天，突然有一大批用戶涌入開始使用你的應用。你的服務器開始變得疲憊不堪，不過仍然還能工作。
一個使用傳統託管方法的簡單 Express.js App —— 處於較大負載下。
就這樣持續了一段時間後，它終於宕機了。
一個使用傳統託管方法的簡單 Express.js App —— 因爲過多用戶訪問導致應用掛掉
一大批用戶因爲應用無法訪問而變得不開心（無論他們是否爲此應用付費）。你對此感到絕望，並開始在 Google 上尋求解決方法。如果在雲上部署可以改善現狀嗎？
在雲上部署應該就可以解決應用規模伸縮的問題了，對吧？
此時你遇到了一個惱人的朋友，她又在給你談論 Serverless（無服務器）技術的種種。
Try serverless
讓你的 Express App Serverless 化
在過去的文章《5分鐘serverless實踐|構建無服務器圖圖片鑑黃Web應用》中，你已經知道了 Serverless API 是由 API Gateway 和 FunctionGraph 組成的。現在需要考慮的是如何讓你的 Express App Serveless 化。就像 Matt Damon 出演的電影《縮小人生》中描繪的橋段，Serverless 在未來也具有無限的潛力和可能性。
如何才能讓你的 Express App 無縫接入 FunctionGraph
讓我們向它請教一番！在集成到FunctionGraph之前，你的代碼需要稍微調整一下。你需要 export 你的 app，而不是調用 app.listen 去啓動它。你的 app.js 內容應該類似下列代碼：
'use strict'
const express = require('express')
const app = express()
app.get('/', (req, res) => res.send('Hello world!'))
module.exports = app
這樣修改後你可能無法在本地啓動 Express 服務器了，不過你可以通過額外添加 app.local.js 文件進行解決：
'use strict'
const app = require('./app')
const port = process.env.PORT || 3000
app.listen(port, () =>
console.log(`Server is listening on port ${port}.`)
)
之後像啓動本地服務器執行下面的命令就可以了：
node app.local.js
爲了讓應用的API能更好地使用API網關進行管理，你還需要確保你的所有API擁有一個共同的root_path。現在，進入FunctionGraph頁面創建一個函數，函數名爲api的root_path，將本地Express工程打包上傳，作爲函數的代碼。然後再爲函數創建一個入口文件，可以點擊在線編輯器上File -> New File Template -> Node.js Express Server快速創建，入口文件代碼如下：
const fgsExpress= require('fgs-express');
const app = require('./app'); // Your Express app entry
const server = fgsExpress.createServer(app);
exports.handler = (event, context, callback) => {
fgsExpress.proxy(server, event, context, callback);
}
fgs-express三方件會包裝你的app，轉發apig和app之間的請求。至此，你的Serverless化的Express APP就上線了，在瀏覽器中打開響應信息中返回的鏈接，若網頁展示出 “Hello world!” 那麼證明應用已經成功部署起來了！
Serverless Express App
優勢
將你的應用 Serverless 化後，你不再畏懼用戶羣體的進一步擴大，應用會始終保持爲可用狀態。這並不是言過其實，因爲在默認情況下 FunctionGraph 可通過彈性伸縮最高支持100個 function 併發執行。當 API Gateway 接收到請求後，新的 function 會在短時間內處於可用狀態。
在高負載下的 Serverless Express.js App
這並不是你接入 Serverless 後唯一的收益。在保證應用不會因爲高負載宕機的前提下，你同樣削減了不少應用的運行開銷。使用 FunctionGraph，你僅需按你應用的實際訪問量付費。同樣，FunctionGraph的免費試用計劃還將給予你每應用每月一百萬的免費流量（按訪問次數計算）。
你的 Serverless App 真是太替你省錢了
更炫酷的Demo
在真實的項目中，是否真的能夠快速集成？下面我們來實際操作一波，在Github上找一個實際的Express項目，讓它Serverless化，快速上線。
canfoo / react-taopiaopiao
這是一個基於Express和React構建的仿淘票票APP，其中包括對前、後端請求的處理，無需關注細節，我們將其Api的root_path設置爲express-demo，然後將項目壓縮成zip包，將其作爲代碼創建一個名爲express-demo的函數。創建完成後爲函數添加一個入口文件，並創建一個apig觸發器，即完成構建了。Apig觸發器中顯示的url即爲Express程序的Api訪問地址根路徑。
現在，讓我們拭目以待吧，將此url生成一個二維碼，掏出手機，讓大家在世界各地訪問你APP吧。
愛情需要磨合——缺陷
即使Servlerss Express APP聽起來超讚，也會有一些缺陷。
下面是 Serverless Express App 一些最 “致命” 的短板：
1、Websockets 無法在 FunctionGraph 中使用。這是因爲在 Functiongraph 中，若應用沒有任何的訪問，那麼你的服務器在客觀上也是不存在的。
2、上傳文件到文件系統同樣是無法工作的，除非你的上傳目錄是 /tmp 文件夾。這是因爲 FunctionGraph 對文件系統是隻讀的，即使你將文件上傳到了 /tmp 文件夾，它們也只會在 function 處於 “工作態” 時存在。爲確保你應用中的上傳功能運轉正常，你應當把文件上傳並保存到 OBS 上。
3、執行限制也將影響你的 Serverless Express App 功能。例如 FunctionGraph 最大執行時間不能超過 5 分鐘等。
這僅僅算是你的應用與 FunctionGraph 之間關於 Serverless 愛情故事的一個序章，期待儘快涌現更多的愛情故事！
生活需要愛——感謝
本文Express介紹部分大量借鑑以下文章：
(英文原文) Express.js and AWS Lambda — a serverless love story（作者：Slobodan Stojanović）
(譯文) Express.js 與 AWS Lambda——一場關於Serverless的浪漫愛情故事（譯者：劉嘉一）
掃碼免費體驗函數工作流FunctionGraph~
