AWS Serverless RESTful API

AWS Serverless RESTful APIs


This site is Serverless.

近幾年在雲架構上討論熱度較高的 2 大主題分別是 容器化（Containerize）與 無伺服器（Serverless）架構。本篇文章會帶你瞭解什麼是 AWS 無伺服器架構，以及如何使用 Serverless Framework 這個框架，快速開發 RESTful APIs。

大綱

  1. 什麼是 XaaS？
  2. AWS 無伺服器架構
  3. Serverless Framework
    1. CRUDable Service
    2. 基礎設施即程式碼

什麼是 XaaS？

馬雲說過一句話：「過去的一百年，我們把人變成了機器，未來的一百年，我們將會把機器變成人。」

人算不如天算，天算就是雲計算。
人算不如天算，天算就是雲計算。

如果要用一句話來定義 XaaS（X as a Service）的話，那就是「萬物皆服務」。
舉凡 IaaS（基礎設施及服務）、PaaS（平台即服務）或 SaaS（軟體即服務）等⋯⋯，用一張圖來概括各個 XaaS 的關係：



身為程式設計師，我們就是那個負責寫服務來取代人類的存在。
所以能夠以最快速度開發出可驗證的服務原型，就成了開發者彼此之間的競爭條件之一，也是本篇文章的目的。

AWS 無伺服器架構

AWS 是目前雲技術的領頭羊，如果想要用 AWS 來開發 Serverless 的 RESTful APIs，主要會由 3 個核心服務所構成：
  1. AWS Lambda（Functions as a Service）
  2. Amazon API Gateway（REST API Endpoint as a Service）
  3. Amazon DynamoDB（NoSQL DB as a Service）

利用 3 個 XaaS 組成一個 BaaS（後端即服務）
利用 3 個 XaaS 組成一個 BaaS（後端即服務）

這裡不會贅述如何操作這些 AWS 服務，如果你已經熟悉這些服務，可以直接前往下一章的 Serverless Framework；如果還不知道它們是怎麼運作的，強烈建議先跑過一遍官方的幾篇教學與實作，理解這 3 個傢伙為什麼這麼酷，也才能理解為什麼接下來要介紹的 Serverless Framework 比它們更酷！
  1. 無伺服器運算和應用程式
  2. Build a Serverless Web Application

Serverless Framework

接下來進入本篇文章的重點，如果每次建立 REST API 都需要手動操作 Lambda、API Gateway 和 DynamoDB 這些服務的話就太麻煩了，所以這裡介紹一個第三方社群維護的框架：Serverless Framework。


Serverless Framework 提供了一整套專為「無伺服器架構」所設計的開發＆部署工具，除了 AWS 之外還支援了 Google Cloud Platform 和 Microsoft Azure 等雲服務平台，讓開發者只需專注在 Web、Mobile 和 IoT 應用的核心功能，而無需煩惱基礎設施的維護。
先來跑一遍官方的快速入門暖暖身，首先安裝 Serverless 的 CLI：
$ npm install serverless --global
注意：因為 Serverless CLI 會透過 AWS SDK 間接操作你的 AWS 帳戶，所以在開始之前，請先確認本機端已經配置完 AWS 的 credential，詳細設定方法可以參考官方文件的《Credentials》。
新增一個 Node.js 環境的專案 hello-service：
$ serverless create --template aws-nodejs --path hello-service
Serverless 會幫你建立了一個基本的 Lambda Function hello：
module.exports.hello = (event, context, callback) => {
  const response = {
    statusCode: 200,
    body: JSON.stringify({
      message: 'Go Serverless v1.0! Your function executed successfully!',
      input: event,
    }),
  };

  callback(null, response);
};
部署 Lambda Function 至 AWS：
$ serverless deploy --verbose
--verbose 顯示部署過程的細節。
如果每次都需要重新部署所有 Lambda Function 會很沒效率，Serverless 也可以只部署單個 Lambda Function：
$ serverless deploy function --function hello
--function 指定 Lambda Function 的名稱。
部署完成之後，使用 invoke 執行 Lambda Function：
$ serverless invoke --function hello --log
--log 顯示執行回傳的結果。
{
    "statusCode": 200,
    "body": "{\"message\":\"Go Serverless v1.0! Your function executed successfully!\",\"input\":{}}"
}
CLI 也可以使用 logs 和 --tail 來持續監控 Lambda Function 的執行結果：
$ serverless logs --function hello --tail
瞭解整個 Serverless 的運作方式之後，CLI 還有提供 remove 指令，讓你可以將整個專案從 AWS 帳戶移除，畢竟佔用這些資源是要計費的：
$ serverless remove

CRUDable Service

瞭解 Serverless Framework 如何輕易地部署 Lambda Function 之後，我們來看看 Serverless Framework 如何開發一套完整、可以 CRUD 資料庫的 REST API 服務。
下載 Serverless 社群寫好的 To-do CRUD 範例：
$ serverless install --url https://github.com/pmuens/serverless-crud
注意：因為這個範例有用到其它第三方的 npm packages，所以部署前記得先 npm install 安裝。
部署 To-do service 至 AWS：
$ serverless deploy --verbose
部署完成之後，CLI 會顯示你的 API Gateway endpoints：
...

endpoints:
  POST - https://18055egsjj.execute-api.us-east-1.amazonaws.com/dev/todos
  GET - https://18055egsjj.execute-api.us-east-1.amazonaws.com/dev/todos
  GET - https://18055egsjj.execute-api.us-east-1.amazonaws.com/dev/todos/{id}
  PUT - https://18055egsjj.execute-api.us-east-1.amazonaws.com/dev/todos/{id}
  DELETE - https://18055egsjj.execute-api.us-east-1.amazonaws.com/dev/todos/{id}

...

Read All To-dos

使用 cURL 或 HTTPie 之類的 HTTP client 來測試結果，首先是取得所有 to-dos：
$ http GET https://18055egsjj.execute-api.us-east-1.amazonaws.com/dev/todos
沒意外的話，會回傳空的 To-do 陣列：
HTTP 200 OK

[]
打開程式碼，Read all to-dos 的 Lambda Function 很簡單，透過 AWS SDK 的 DynamoDB scan API 來取得所有 todos table 的 items：
// todos-read-all.js

const AWS = require('aws-sdk');
const dynamoDb = new AWS.DynamoDB.DocumentClient();

module.exports = (event, callback) => {
  const params = {
    TableName: 'todos',
  };

  return dynamoDb.scan(params, (error, data) => {
    if (error) {
      callback(error);
    }
    callback(error, data.Items);
  });
};

Create To-do

接著我們試著新增一筆 to-do：
$ http POST https://<省略>/todos body="Hodor"
新增成功並回傳一筆包含 id、body 和 updateAt 欄位的 to-do item：
HTTP 200 OK

{
    "body": "Hodor",
    "id": "1b691310-a0e7-11e7-b1c4-1d790783726f",
    "updatedAt": 1506230011585
}
Create 的 Lambda Function 也很好懂，透過 UUID 以及 DynamoDB 的 put API 新增一筆 to-do item：
// todos-create.js

...
const uuid = require('uuid');

module.exports = (event, callback) => {
  const data = JSON.parse(event.body);

  data.id = uuid.v1();
  data.updatedAt = new Date().getTime();

  const params = {
    TableName: 'todos',
    Item: data
  };

  return dynamoDb.put(params, (error, data) => {
    if (error) {
      callback(error);
    }
    callback(error, params.Item);
  });
};

Read One To-do

接著我們試著讀取剛才新增的 id 為 1b691310-a0e7-11e7-b1c4-1d790783726f 的 to-do：
$ http GET https://<省略>/todos/1b691310-a0e7-11e7-b1c4-1d790783726f

HTTP 200 OK

{
    "body": "Hodor",
    "id": "1b691310-a0e7-11e7-b1c4-1d790783726f",
    "updatedAt": 1506230011585
}
這裡要注意，DynamoDB 讀取所有 items 所使用 API 是 scan，讀取單筆 item 的 API 是 get：
// todos-read-one.js

...

module.exports = (event, callback) => {
  const params = {
    TableName: 'todos',
    Key: {
      // 透過 event.pathParameters 來取得 URL 的 todo item id
      id: event.pathParameters.id
    }
  };

  return dynamoDb.get(params, (error, data) => {
    if (error) {
      callback(error);
    }
    callback(error, data.Item);
  });
};

Update To-do

更新已經存在的單筆 to-do：
$ http PUT https://<省略>/todos/1b691310-a0e7-11e7-b1c4-1d790783726f body="Hold The Door"

HTTP 200 OK

{
    "body": "Hold The Door",
    "id": "1b691310-a0e7-11e7-b1c4-1d790783726f",
    "updatedAt": 1506230311609
}
更新 DynamoDB item 的程式碼基本上與新增的方式差不多：
// todos-update.js

...

module.exports = (event, callback) => {
  const data = JSON.parse(event.body);

  data.id = event.pathParameters.id;
  data.updatedAt = new Date().getTime();

  const params = {
    TableName : 'todos',
    Item: data
  };

  return dynamoDb.put(params, (error, data) => {
    if (error) {
      callback(error);
    }
    callback(error, params.Item);
  });
};

Delete To-do

最後剩下刪除已存在的單筆 to-do：
$ http DELETE https://<省略>/todos/1b691310-a0e7-11e7-b1c4-1d790783726f

HTTP 200 OK

{
    "id": "1b691310-a0e7-11e7-b1c4-1d790783726f"
}
刪除的 Lambda Function 程式碼：
// todos-delete.js

...

module.exports = (event, callback) => {
  const params = {
    TableName : 'todos',
    Key: {
      id: event.pathParameters.id
    }
  };

  return dynamoDb.delete(params, (error, data) => {
    if (error) {
      callback(error);
    }
    callback(error, params.Key);
  });
};

基礎設施即程式碼

跑完上面的 to-do services 之後有沒有感到很神奇呢？竟然一個 serverless deploy 指令，就可以把原本需要手動配置的所有 AWS 基礎服務都自動建立好了，這是因為 Serverless Framework 用到了 AWS CloudFormation 這個服務。


我們先打開 serverless.yml 這個檔案來看看 Lambda Function 和 API Gateway 的配置：
functions:
  create:
    ...
  readAll:
    ...
  readOne:
    handler: handler.readOne
    events:
      - http:
          path: todos/{id}
          method: get
          ...
  update:
    ...
  delete:
    ...
DynamoDB 的設定：
resources:
  Resources:
    TodosDynamoDbTable:
      ...
      Properties:
        AttributeDefinitions:
          -
            AttributeName: id
            AttributeType: S
        KeySchema:
          -
            AttributeName: id
        ...
        TableName: 'todos'
這就是 Infrastructure as a Code（基礎設施即程式碼）的威力，它的好處：
  • 隨地配置：直接使用程式碼控制你的基礎設施資源，忘記那些繁瑣的操作流程
  • 易於維護：因為程式碼可以上版本控制，所以可以多人共同維護一份基礎設施
  • 持續交付：因為可以進版本控制，所以更容易整合進 CI/CD 的自動化流程

結論

  1. XaaS（萬物皆服務）是未來的趨勢，而服務的本質就是 API，誰能夠越快地開發出原型、越有機會成功
  2. 如果要用 AWS 的無伺服器架構來開發 REST API，核心服務分別是 Lambda、API Gateway 和 DynamoDB
  3. Serverless Framework 利用「基礎設施即程式碼」的概念，讓開發者可以更迅速地在 AWS 上建立一套可維護的 CRUD RESTful API Services

參考文章

留言

張貼留言

這個網誌中的熱門文章

全遠端工作

圖片
每周分享第 21 期 全遠端工作 原文標題：All Remote 原文網址：https://about.gitlab.com/company/culture/all-remote/ 原文作者：GitLab GitLab 是一間實行 全遠端 （All Remote）的公司， 團隊成員 遍布全球 50 多個國家。 這裡 有介紹一些 GitLab 的工作原理。 遠端宣言 全遠端工作提倡： 從世界各地招聘和工作，而不是從都市地帶 彈性工時，勝過固定工時 寫下和記錄知識，勝過口頭傳授 寫下流程，勝過在職培訓 公開分享資訊，勝過僅知原則（need-to-know access，僅給予完成一件任務所需要知道的事項即可） 開放所有文件供任何人編輯，勝過自上而下的文件控制 非同步通訊，勝過同步通訊 工作的成果，勝過投入的工時 正式的溝通管道，勝過非正式的溝通管道 正式溝通 vs 非正式溝通（ 來源 ） 為什麼需要遠端？ 遠端不是一個需要克服的挑戰。這是一個明顯的商業優勢。 — Victor, Product Manager, GitLab 從節省辦公空間的成本到員工的日常生活更加彈性，全遠端工作為組織及其員工提供了許多好處。但我們也體認到，並非所有人都適合成為一家全遠端的公司。 以下是一些優點和缺點。 優點 對於員工 日常生活更加彈性（小孩、父母、朋友、雜務、運動、快遞） 不會浪費時間、精力和金錢在通勤上（捷運和公車、油價、維修保養、收費站等） 減少接觸同事的病菌 減少被打斷的狀態，提高 生產力 能夠在不請假的情況下遊歷各地（家庭、娛樂等） 自由移動 有些人發現遠端更容易與難搞的同事溝通 減少入職可能會有的社交壓力 在家吃飯（有時）更好、更便宜 某些國家的稅收可能更便宜 不用煩惱今天穿什麼 從家庭時間到旅行計劃，有很多關於遠端工作是如何影響全球 GitLab 團隊成員生活的 例子和...
閱讀完整內容

影響我一生的十大遊戲（一）

圖片
每周分享第 19 期 影響我一生的十大遊戲（一） 自 1989 年的平成元年算起，持續了約 30 年的「平成時代」已於今年 4 月畫下句點，5 月起由新年號「令和」正式接班。 日本遊戲媒體 週刊ファミ通 日前 公布 由讀者票選的「平成最佳遊戲」前三名經典作品。 來源： ファミ通.com 拿下第一名的是 1995 年在 SFC（俗稱： 超任 ）平台發售的《 超時空之鑰 》。本作受到 30 歲以上玩家（包括我）一致壓倒性支持，高票獲選。 來源： ヤフオク 《超時空之鑰》是由 SQUARE （當時尚未合併 SQUARE ENIX ）負責製作發行，《 七龍珠 》作者 鳥山明 、《 勇者鬥惡龍 》之父 堀井雄二 ，以及《 太空戰士 》之父 坂口博信 聯手打造的夢幻級 RPG。無論是劇情、美術、系統或音樂，放到今天來看仍是經典的不朽名作。 創新的時空旅行與多重結局成為不少玩家一生難忘的回憶（來源： ヤフオク ） 作為一路走過昭和、平成、令和時代的三朝元老級玩家，見證了這 30 年間五花八門的遊戲作品問世。最近看了 YouTube 頻道 攻壳 Gamker 的《 十大影響我的遊戲 》影片之後，也想來寫一系列「影響我一生的十大遊戲」文章。 第十位：熱血行進曲（FC） ...
閱讀完整內容

無限環境（ㄧ）Netlify Deploy Previews

圖片
大綱 什麼是「無限環境」？ 什麼是 Netlify Deploy Previews？ 快速入門指南 步驟一、建立 React 網站 步驟二、建立 GitHub repository 步驟三、註冊＆配置 Netlify ⭐️ 最終步驟、玩轉 Deploy Previews ⭐️ 總結 附錄 參考資料 什麼是「無限環境」？ 大家常用的 GitHub flow 其實有一個常常被忽略的重點 —— 合併前部署。 我自己在前端開發的 Code Review 上，常常碰到下列兩個問題： PR 合併、部署到 staging 或 production 環境之後，才發現程式碼有問題 為了避免第一個問題發生，就必須先 checkout PR 到 local 環境，然後經過一系列繁瑣的步驟跑起來，最後才能開始驗收和測試 為了解決上述問題，就需要引入無限環境的概念。 所謂的無限環境，就是自動將目前 PR 中的最新 commit，部署到一個臨時環境中，並返回該環境的 URL 網址。[1] 如果能實現這個條件，將為開發團隊帶來兩點好處： Reviewer 有任何懷疑時，便可以直接在預覽環境中驗證，而非憑空猜疑。 Reviewer 也可以放心大膽的驗證自己的懷疑，不需要在 local 開發環境耗時費力地切換。 接下來我會寫三篇「無限環境」系列的文章，介紹一些可以達成這個目的的工具。 這是第一篇文章，介紹如何透過 Netlify 的 Deploy Previews 服務，建立靜態網頁的無限環境。 什麼是 Netlify Deploy Previews？ Netlify 是一個類似 Heroku 的 All-in-one PaaS ，提供各種現代 web 專案會用到的自動化服務，例如：靜態網站部署、CDN、持續交付和一鍵配置 HTTPS 等。 其中 Deploy Previews 這項服務，可以將 GitHub repository 中的每個 pull request 部署到 唯一 的 URL，與 staging 和 production 環境的完全不同。你和你的團隊可以在合併到主分支、並且部署到正式環境之前，提前看到更改的外觀以及驗收功能是否正確。 快速入門指南 這篇文章會以時下最流行的 Create React App 為例，示範如何實現 React ...
閱讀完整內容