官宣之后，Express和Functiongraph也公布戀情了

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~