官宣以後-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 一些最 「致命」 的短板：

一、Websockets 沒法在 FunctionGraph 中使用。這是由於在 Functiongraph 中，若應用沒有任何的訪問，那麼你的服務器在客觀上也是不存在的。

二、上傳文件到文件系統一樣是沒法工做的，除非你的上傳目錄是 /tmp 文件夾。這是由於 FunctionGraph 對文件系統是隻讀的，即便你將文件上傳到了 /tmp 文件夾，它們也只會在 function 處於 「工做態」 時存在。爲確保你應用中的上傳功能運轉正常，你應當把文件上傳並保存到 OBS 上。

三、執行限制也將影響你的 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~