无伺服器計算是對傳統基於伺服器的架構遇到的挑戰的回應。在無伺服器計算中，開發者不再需要手動管理或擴展伺服器。取而代之的是，雲服務提供商處理基礎設施管理，使得團隊能夠專注於寫作和部署程式碼。
無伺服器解決方案根據需求自動擴展，並提供按用量付费的模式。這意味著您只會為您的應用程序實際使用的資源付款。這種方法顯著減少運營開支，提高靈活性並加快開發週期，使其成為現代應用開發的吸引人的選擇。
通過抽象化伺服器管理，無伺服器平台讓您能夠專注於商業邏輯和應用功能。這導致更快部署和更多創新。無伺服器架構也是基於事件的，這意味著它們可以自動响應用户需求而不需要手動參與。
目錄
在進入技術細節之前，我們將概述一些關鍵的背景概念。
重要概念理解
應用程式設計接口(API)
應用程式設計接口(API)讓不同的軟件應用程式能夠進行溝通和相互作用。它定義了應用程式可以使用來要求和交換信息的方法和數據格式，以實現不同系統之間的整合和數據共享。
HTTP方法
HTTP方法或請求方法是Web服務和API的關鍵组成部分。它們指明了在給定的請求URL上要对資源执行的期望動作。
在RESTful API中最常使用的方法有：
-
GET: 用於從服務器獲取數據
-
POST: 将包含在請求正文中的数据发送到服务器以创建或更新资源
-
PUT: 更新或替换现有资源，或在它不存在时创建新资源
-
DELETE: 从服务器上删除指定的数据。
亞馬遜API閘道器
Amazon API 閘道器是一個完全管理等級服務，讓開發者能夠輕鬆地創建、發布、維護、監控和保護 API 並進行擴展。它作為多個 API 的進入點，管理和控制客戶端（如網絡或移動應用程序）與後端服務之間的互動。
它還提供各種功能，包括請求路由、安全、認證、快取和速率限制，幫助簡化 API 的管理和部署。
Amazon DynamoDB
DynamoDB 是一個完全管理等級的非關係型數據庫服務，設計用於高可擴展性、低延遲和在不同區域複製數據。
DynamoDB將數據存儲在無模式格式中，允許靈活且快速地存儲和擷取結構化和半結構化數據。它通常用於在雲基礎環境中建造可擴展和反應快速的應用程序。
无伺服器 CRUD 應用程序
無伺服器 CRUD 應用程序指的是 創建、讀取、更新和刪除 數據的能力。但是，涉及的架構和組件與傳統的伺服器基礎應用程序不同。
創建 涉及其向 DynamoDB 表中添加新条目。讀取 操作從 DynamoDB 表中检索數據。更新 操作更新 DynamoDB 中的现有數據。而刪除 操作從 DynamoDB 中刪除數據。
無伺服器框架
无伺服器框架是一款開源工具，它簡化了在多個雲服務提供商（包括AWS）之間部署和管理無伺服器應用程序的過程。它通過允許開發者使用YAML文件以程式碼形式定義他們的基礎設施，將基礎設施的部署和管理複雜性抽象化。
該框架處理無伺服器函數、API和其他資源的部署、擴展和更新。
GitHub Actions
GitHub Actions是一款強大的CI/CD自動化工具，允許開發者直接從他們的GitHub倉庫自動化他們的軟件工作流。
使用GitHub Actions，您可以創建由诸如代碼推送、拉取請求或分支合併等事件觸發的自定義管道。這些工作流在倉庫內以YAML文件形式定義，可以執行如測試、建造和將應用程序部署到各種環境等任務。
Postman
Postman是一個流行的协作平台，它簡化了設計、測試和記錄API的過程。它為開發者提供了一個易於使用的界面，以創建和發送HTTP請求、測試API端點和自動化測試工作流。
好的，既然你已經熟悉了我們將使用的工具和技術，讓我們開始吧。
先決條件
-
已安裝Node.js和npm
-
AWS CLI已配置，可以访问您的AWS账户
-
Serverlesss Framework账户
-
無伺服器框架已在您的本地 CLI 全局安裝
我们的使用案例
Meet Alyx，一位最近一直在學習無伺服器架構的創業者。她閱讀過有关如何為Web應用程序建立後端的信息，這是一種更加現代的Web應用開發方法。
她想將至今所學的AWS無伺服器計算的基本知識應用於实践。她知道無伺服器並不等同於沒有伺服器參與——而是將伺服器的管理和配置抽象化。現在她只想專注於寫代碼和實現商業邏輯。
讓我們看看Alyx，一家生意興隆的咖啡店的擁有者，如何開始利用無伺服器架構為其Web應用程序的後端提供支持。
Alyx的咖啡天堂是一家线上咖啡店，提供各種咖啡 blends 和 treats 供銷售。最初，Alyx使用傳統的Web托管服務和操作來管理商店的訂單和庫存，她處理多個伺服器和資源。但是隨著她的咖啡店越來越受歡迎，她在高峰時間和季度促銷活動中開始面臨越来越多的訂單。
管理伺服器並確保應用程序能夠處理流量 surge 對Alyx來說成為了一個挑戰。她發現自己不斷擔心伺服器容量、可伸縮性和基礎設施的維護成本。
她還想介紹像個人化推薦和忠誠計劃等新功能，但考慮到她傳統系統的限制，這变成了一項艰巨的任務。
然後Alyx了解了無伺服器概念。她將無伺服器後端比作一位咖啡師，能夠實時自动泡製咖啡，而無需她擔心咖啡泡製的複雜細節。
對這個想法感到興奮的Alyx決定將她的咖啡店後端遷移到使用AWS Lambda、AWS API Gateway和Amazon DynamoDB的無伺服器平台。這個設定將让她更能專注於為顧客創造完美的咖啡 blends 和點心。
在無伺服器環境中，每個顧客的訂單成為一個觸發一系列無伺服器函數的事件。不同的AWS Lambda函數處理訂單並幕後處理所有商業邏輯。例如，它創建一個顧客的訂單並能夠取回該訂單。它還可以刪除某人的訂單或更新訂單狀態。
Alyx不再需要擔心管理服務器，因為無伺服器平台會根據传入的訂單請求自動擴展和縮放。此外，無伺服器的成本效益對Alyx來說是巨大的。透過按用量付費模式，她只為她的函數實際消費的計算時間付費，為她的成長企業提供了一套更經濟有效的解決方案。
但她不就此止步！她還想自動化一切，從部署基礎設施到每当有新變更時更新她的應用程序。透過使用無伺服器框架的基礎設施作為程式碼（IaC），她可以以程式碼定義所有基礎設施並輕鬆管理它。
此外，她為持续集成和交付（CI/CD）設定GitHub Actions，所以她所做的任何變更都會通過管線自動部署，無論是開發中的新功能還是為生產環境制定的熱修復。
教學目標
-
設定無伺服器框架環境
-
在YAML文件中定義API
-
開發AWS Lambda函式以處理CRUD操作
-
為Dev和Prod設定多階段部署
-
測試Dev和Prod管線
-
使用Postman測試和驗證Dev和Prod API
如何開始：複製Git倉庫
為要提高您對本教程的 understood並能更有效地跟進，請您從我的 GitHub 複製该项目庫。您可以 按這裡 進行操作。在我們前進的過程中，您可以自由地对文件進行必要的編輯。
複製庫之後，您會發現您的文件夾中有多個文件，如下面的圖像所示。我們將使用這些文件來建造我們的無服務器咖啡店API。
步驟1：設置無服務器框架環境
為自動部署 settings up the Serverless Framework environment，您需要通過 CLI 認證您的 Serverless Framework 帳號。
這需要創建一個訪問鑰匙，使管道能夠使用 Serverless Framework 安全地认证到您的帳號，而不會暴露您的憑證。通過登錄您的 Serverless 帳號並生成一個訪問鑰匙，管道可以從建造配置文件自動部署您的無服務器應用。
为此，請转到您的 Serverless 帳號並 導航至訪問Keys部分。點擊“+增加”，將其命名為 SERVERLESS_ACCESS_KEY，然後創建鑰匙。
一旦您創建了您的訪問鑰匙，請確保保安地複製和存放。您將使用這個鑰匙作為 GitHub 倉庫中的秘密變量，以認證和授權您的 CI/CD 管道。
在部署過程中，它將提供對您的Serverless Framework帳號的訪問權限。您稍後將將此鑰匙添加到您的GitHub倉庫的私密中，以便您的管道可以安全的使用它部署無服務器資源，而無需在您的代碼庫中暴露敏感信息。
現在，讓我們在severless.yaml文件中將AWS資源作為代碼定義。
步驟2：在Serverless YAML文件中定義API
在此文件中，您將使用Serverless Framework的YAML配置來定義Coffee Shop API的 cores infrastructure and functionality。
此文件定義了所使用的AWS服務，包括API Gateway、用於CRUD操作的Lambda函數，以及用於數據存儲的DynamoDB。
您還將配置IAM角色，使Lambda函數具有必要權限與DynamoDB服務互動。
API Gateway使用恰當的HTTP方法（POST、GET、PUT 和 DELETE）來處理進來的請求並觸發相應的Lambda函數。
讓我們來看一下代碼：
service: coffee-shop-api
frameworkVersion: '4'
provider:
name: aws
runtime: nodejs20.x
region: us-east-1
stage: ${opt:stage}
iam:
role:
statements:
- Effect: Allow
Action:
- dynamodb:PutItem
- dynamodb:GetItem
- dynamodb:Scan
- dynamodb:UpdateItem
- dynamodb:DeleteItem
Resource: arn:aws:dynamodb:${self:provider.region}:*:table/CoffeeOrders-${self:provider.stage}
functions:
createCoffee:
handler: createCoffee.handler
environment:
COFFEE_ORDERS_TABLE: CoffeeOrders-${self:provider.stage}
events:
- http:
path: coffee
method: post
getCoffee:
handler: getCoffee.handler
environment:
COFFEE_ORDERS_TABLE: CoffeeOrders-${self:provider.stage}
events:
- http:
path: coffee
method: get
updateCoffee:
handler: updateCoffee.handler
environment:
COFFEE_ORDERS_TABLE: CoffeeOrders-${self:provider.stage}
events:
- http:
path: coffee
method: put
deleteCoffee:
handler: deleteCoffee.handler
environment:
COFFEE_ORDERS_TABLE: CoffeeOrders-${self:provider.stage}
events:
- http:
path: coffee
method: delete
resources:
Resources:
CoffeeTable:
Type: AWS::DynamoDB::Table
Properties:
TableName: CoffeeOrders-${self:provider.stage}
AttributeDefinitions:
- AttributeName: OrderId
AttributeType: S
- AttributeName: CustomerName
AttributeType: S
KeySchema:
- AttributeName: OrderId
KeyType: HASH
- AttributeName: CustomerName
KeyType: RANGE
BillingMode: PAY_PER_REQUEST
serverless.yml 配置定義了Alyx的Coffee Shop API如何在AWS上的無服務器環境中運行。provider部分指定了應用程序將使用AWS作為雲服務提供商，並使用Node.js作為運行環境。
地區已設定為 us-east-1，而 stage 變數容許在不同環境（如開發和生產）之间進行动态部署。这意味着同一套代碼可以部署到不同的環境中，資源会根据环境命名以避免冲突。
在 iam 节段中，授予 Lambda 函数与 DynamoDB 表互动的权限。${self:provider.stage} 语法动态命名 DynamoDB 表，以便每个环境都有其自己的独立資源，如 CoffeeOrders-dev（开发环境）和 CoffeeOrders-prod（生产环境）。这种动态命名有助于无需手动为每个环境配置单独的表来管理多个环境。
在 functions 节段中定义了四个核心 Lambda 函数，createCoffee、getCoffee、updateCoffee 和 deleteCoffee。这些函数负责处理咖啡店 API 的 CRUD 操作。
每个函数都与 API 网关中的特定 HTTP 方法连接，如 POST、GET、PUT 和 DELETE。这些函数与基于当前阶段动态命名的 DynamoDB 表互动。
最后的 resources 节段定义了 DynamoDB 表本身。它设置了具有 OrderId 和 CustomerName 属性的表，这两个属性用作主键。该表配置为使用按请求付费的计费模式，这对于 Alyx 不断增长的业务来说具有成本效益。
透過使用Serverless Framework来自動部署這些資源，Alyx可以輕鬆地管理她的基礎設施，從而解放她手動配置和扩展資源的負擔。
步驟3：為CRUD操作開發Lambda函式
在這個步驟中，我們通過使用JavaScript創建Lambda函式來實現Alyx的咖啡店API的核心邏輯，這些函式執行必要的CRUD操作createCoffee、getCoffee、updateCoffee和deleteCoffee。
這些函式使用AWS SDK與AWS服務進行互動，特別是DynamoDB。每個函式將負責處理特定的API請求，例如創建訂單、擷取訂單、更新訂單狀態，以及刪除訂單。
創建咖啡Lambda函式
這個函式用於創建訂單：
const AWS = require('aws-sdk');
const dynamoDb = new AWS.DynamoDB.DocumentClient();
const { v4: uuidv4 } = require('uuid');
module.exports.handler = async (event) => {
const requestBody = JSON.parse(event.body);
const customerName = requestBody.customer_name;
const coffeeBlend = requestBody.coffee_blend;
const orderId = uuidv4();
const params = {
TableName: process.env.COFFEE_ORDERS_TABLE,
Item: {
OrderId: orderId,
CustomerName: customerName,
CoffeeBlend: coffeeBlend,
OrderStatus: 'Pending'
}
};
try {
await dynamoDb.put(params).promise();
return {
statusCode: 200,
body: JSON.stringify({ message: 'Order created successfully!', OrderId: orderId })
};
} catch (error) {
return {
statusCode: 500,
body: JSON.stringify({ error: `Could not create order: ${error.message}` })
};
}
};
此Lambda函式負責在DynamoDB表中創建新的咖啡訂單。首先我們導入AWS SDK並初始化一個DynamoDB.DocumentClient以與DynamoDB互動。還導入了uuid庫以生成唯一的訂單ID。
在handler函式內，我們解析传入的請求體以 extracts customer information，例如客戶的名字和偏好的咖啡 blends。使用uuidv4()生成的唯一orderId，並將這些數據準備好插入DynamoDB。
The params object defines the table where the data will be stored, with TableName dynamically set to the value of the environment variable COFFEE_ORDERS_TABLE. The new order includes fields such as OrderId, CustomerName, CoffeeBlend, and an initial status of Pending.
In the try block, the code attempts to add the order to the DynamoDB table using the put() method. If successful, the function returns a status code of 200 with a success message and the OrderId. If there’s an error, the code catches it and returns a 500 status code along with an error message.
Get Coffee Lambda function
This function retrieves all coffee items:
const AWS = require('aws-sdk');
const dynamoDb = new AWS.DynamoDB.DocumentClient();
module.exports.handler = async () => {
const params = {
TableName: process.env.COFFEE_ORDERS_TABLE
};
try {
const result = await dynamoDb.scan(params).promise();
return {
statusCode: 200,
body: JSON.stringify(result.Items)
};
} catch (error) {
return {
statusCode: 500,
body: JSON.stringify({ error: `Could not retrieve orders: ${error.message}` })
};
}
};
This Lambda function is responsible for retrieving all coffee orders from a DynamoDB table and exemplifies a serverless approach to retrieving data from DynamoDB in a scalable manner.
We again use the AWS SDK to initialize a DynamoDB.DocumentClient instance to interact with DynamoDB. The handler function constructs the params object, specifying the TableName, which is dynamically set using the COFFEE_ORDERS_TABLE environment variable.
“`
“`plaintext
scan() 方法從表中检索所有項目。如果操作成功，該函數返回一個狀態代碼 200 以及以 JSON 格式取得的項目。在出現錯誤的情況下，將返回一個 500 狀態代碼以及一個錯誤訊息。
更新咖啡 Lambda 函數
此函數通過其 ID 更新咖啡項目：
const AWS = require('aws-sdk');
const dynamoDb = new AWS.DynamoDB.DocumentClient();
module.exports.handler = async (event) => {
const requestBody = JSON.parse(event.body);
const { order_id, new_status, customer_name } = requestBody;
const params = {
TableName: process.env.COFFEE_ORDERS_TABLE,
Key: {
OrderId: order_id,
CustomerName: customer_name
},
UpdateExpression: 'SET OrderStatus = :status',
ExpressionAttributeValues: {
':status': new_status
}
};
try {
await dynamoDb.update(params).promise();
return {
statusCode: 200,
body: JSON.stringify({ message: 'Order status updated successfully!', OrderId: order_id })
};
} catch (error) {
return {
statusCode: 500,
body: JSON.stringify({ error: `Could not update order: ${error.message}` })
};
}
};
此 Lambda 函數處理在 DynamoDB 表中更新特定咖啡訂單的狀態。
handler 函數從請求體中提取 order_id、new_status 和 customer_name。它然後構建 params 物件以指定表名和訂單的主鍵（使用 OrderId 和 CustomerName）。UpdateExpression 設定訂單的新狀態。
在 try 區塊中，代碼嘗試使用 update() 方法在 DynamoDB 中更新訂單。當然，如果成功，函數將返回一個狀態代碼 200 以及一個成功訊息。如果發生錯誤，它會捕捉到錯誤並返回一個 500 狀態代碼以及一個錯誤訊息。
刪除咖啡 Lambda 函數
此函數通過其 ID 刪除咖啡項目：
const AWS = require('aws-sdk');
const dynamoDb = new AWS.DynamoDB.DocumentClient();
module.exports.handler = async (event) => {
const requestBody = JSON.parse(event.body);
const { order_id, customer_name } = requestBody;
const params = {
TableName: process.env.COFFEE_ORDERS_TABLE,
Key: {
OrderId: order_id,
CustomerName: customer_name
}
};
try {
await dynamoDb.delete(params).promise();
return {
statusCode: 200,
body: JSON.stringify({ message: 'Order deleted successfully!', OrderId: order_id })
};
} catch (error) {
return {
statusCode: 500,
body: JSON.stringify({ error: `Could not delete order: ${error.message}` })
};
}
};
Lamda 函數會從 DynamoDB 表中刪除特定的咖啡訂單。在處理函數中，程式碼會解析請求內容以抽取 order_id 和 customer_name。這些值用作识别表中被刪除項目的主鍵。params 物件指定了要刪除的項目的表名和鍵。
在 try 區塊中，程式碼嘗試使用 delete() 方法從 DynamoDB 刪除訂單。如果成功，它會再次返回一個 200 狀態代碼和成功消息，表示訂單已被刪除。如果發生錯誤，程式碼會捕獲它並返回一個 500 狀態代碼和錯誤消息。
現在我們已經解釋了每個 Lamda 函數，讓我們來設置一個多階段 CI/CD 管道。
步驟 4:為開發和生產環境設定多階段 CI/CD 管道部署
要在 GitHub 倉庫中設定 AWS 秘密，首先移至倉庫的設定。在頂部右側選擇 Settings，然後轉到左下角選擇 Secrets and variables.
接下來，點擊 Actions，如下面的圖所示：
從那裡，選擇 New repository secret 來建立秘密。
為您的管道需要建立三個秘密，即 AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY 和 SERVERLESS_ACCESS_KEY。
使用您的AWS帳號訪問密钥凭证為前兩個變量，然後使用先前保存的serverless訪問密钥創建SERVERLESS_ACCESS_KEY。這些密钥將安全地認證您的CI/CD管道，如图下所示。
請確保您的宿主分支命名為“main”，因為這將作為生產分支。接下來，為開發工作創建一個稱為“dev”的新分支。
您也可以為特定功能創建分支，例如“dev/feature”，以進行更細粒度的開發。GitHub Actions將使用這些分支自動部署更改，dev代表開發環境，而main代表生產。
這種分支策略让您有效地管理CI/CD管道，並在dev或prod環境中合并新的代人更改時進行部署。
如何使用GitHub Actions部署YAML文件
為了自動化Coffee Shop API的部署過程，您將使用與您的GitHub庫集成的GitHub Actions。
此部署管道在將代碼推送到主要或開發分支時觸發。通過配置環境特定的部署，您將確保更新到開發分支部署到開發環境，而主要分支的更改則觸發生產部署。
現在，讓我們查看代碼：
name: deploy-coffee-shop-api
on:
push:
branches:
- main
- dev
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: '20.x'
- name: Install dependencies
run: |
cd coffee-shop-api
npm install
- name: Install Serverless Framework
run: npm install -g serverless
- name: Deploy to AWS (Dev)
if: github.ref == 'refs/heads/dev'
run: |
cd coffee-shop-api
npx serverless deploy --stage dev
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
SERVERLESS_ACCESS_KEY: ${{secrets.SERVERLESS_ACCESS_KEY}}
- name: Deploy to AWS (Prod)
if: github.ref == 'refs/heads/main'
run: |
cd coffee-shop-api
npx serverless deploy --stage prod
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
SERVERLESS_ACCESS_KEY: ${{secrets.SERVERLESS_ACCESS_KEY}}
GitHub Actions 的 YAML 配置是自動化將 Coffee Shop API 部署到 AWS 的過程，並使用 Serverless Framework。當主要或開發分支上有任何推送時，工作流程會被觸發。
它開始於检出倉庫的代碼，然後設定 Node.js 版本 20.x，以符合 Lambda 函數使用的運行時。然後，它通過運行 npm install 前往 coffee-shop-api 目錄來安裝項目依賴。
工作流程還會全局安裝 Serverless Framework，允許使用 serverless CLI 進行部署。根據更新的分支，工作流程會條件性部署到適當的环境。
如果更改被推送到了開發分支，它將部署到開發階段。如果它們被推送到主要分支，它將部署到生產階段。部署命令 npx serverless deploy --stage dev 或 npx serverless deploy --stage prod 將在 coffee-shop-api 目錄內執行。
為了安全部署，工作流程通過 GitHub Secrets 存儲的環境變量訪問 AWS 憑据和 Serverless 訪問密钥。這讓 CI/CD 管道能夠不暴露倉庫中的敏感信息，就能通過 AWS 和 Serverless Framework 進行認證。
現在，我們可以繼續測試管道。
步驟 5: 測試開發和生產管道
首先，你需要確認主分支（prod）的名稱是“main”。然後，創建一個名叫“dev”的開發分支。一旦你在開發分支上作出了有效的更改，就要將這些更改提交，以觸發GitHub Actions管道。這會自動將更新資源部署到開發環境中。在開發環境中確認一切正常後，你可以將開發分支合併到主分支。
合併到主分支也会自動觸發生產環境的部署管道。這樣，所有必要的更新都被應用，並且生產資源順暢地部署。
你可以通過訪問GitHub倉庫的Actions標籤來監控部署過程和查看每次GitHub Actions運行的詳細日志。
日志提供了管道的每一步的可见性，幫助你確認一切都在按照預期運行。
你可以選擇任何建立的運行來查看開發和生產環境部署的詳細日志，以便跟蹤進度和確保一切都在顺暢地運行。
在GitHub Actions中導航到特定的建立運行，如下图所示。那裡，你可以查看開發或生產管道的執行詳細信息和結果。
確保徹底測試開發和生產環境，以確認管道成功執行。
步驟6：使用Postman測試和驗證prod和dev API。
現在API和資源已經部署並配置好了，我們需要找到由AWS生成的唯一API端點（URL），以開始進行功能測試的請求。
只需將這些URL粘貼到網頁瀏覽器中，即可測試API的功能。 API的URL可以在CI / CD構建的輸出結果中找到。
要檢索它們，請導航到GitHub Actions日誌，選擇最近環境中成功的構建，然後點擊部署以檢查生成的API端點的部署詳細信息。
在GitHub Actions日誌中，點擊所選環境（Prod或Dev）的部署到AWS階段。一旦進入該頁面，您將找到生成的API URL。
複製並保存此URL，因為在測試API功能時將需要使用它。該URL是驗證已部署的API是否按預期工作的入口。
現在複製其中一個生成的API URL，並將其粘貼到瀏覽器中。您將看到響應中顯示的空數組或列表。這實際上證實了API的正常運行，並成功從DynamoDB表中檢索數據。
即使列表是空的，它也表示API可以連接到數據庫並返回信息。
為了驗證您的API在兩種環境下都可用，請重複執行另一個API環境（Prod和Dev）的步驟。
為進行更全面的測試，我們將使用Postman來測試所有API方法：創建、讀取、更新和刪除，並為開發和生產環境執行這些測試。
要用GET方法進行測試，請使用Postman將GET請求發送到API端點。您將收到與下图相同的回应，即空咖啡訂單列表。這Confirms API的取數能力，如下图所示。
要實際創建訂單，讓我們來測試POST方法。再次使用Postman，將POST請求發送到API端點，並在請求體中提供客戶名稱和咖啡 blends，如下所示：
{
"customer_name": "REXTECH",
"coffee_blend": "Black"
}
回应將是一個带有放置訂單的唯一OrderId的成功消息。
通過查看特定環境的DynamoDB表中的項目，驗證新訂單是否已保存到DynamoDB表中：
要測試PUT方法，請通過提供先前的訂單ID和新的訂單狀態在請求體中制作用於API端點的PUT請求，如下所示：
{
"order_id": "42a81c27-1421-4025-9bef-72b14e723c34",
"new_status": "Ready",
"customer_name": "REXTECH"
}
回應將是一個带有放置訂單的OrderId的成功訂單更新消息。
您也可以從DynamoDB表項目中驗證訂單狀態是否已從更新。
要測試DELETE方法，使用Postman，制作用於API端點的DELETE請求，提供先前的訂單ID和客戶名稱，如下所示：
{
"order_id": "42a81c27-1421-4025-9bef-72b14e723c34",
"customer_name": "REXTECH"
}
已成功刪除訂單的訊息將包含已下訂單的訂單 ID。
再次確認，您可以在 DynamoDB 表中驗證訂單已被刪除。
結論
就是這樣——恭喜！您已成功完成所有步驟。我們已建立一個無伺服器的 REST API，支持 CRUD (Create, Read, Update, Delete) 功能，使用 API Gateway、Lambda、DynamoDB、Serverless Framework 和 Node.js，並通過 Github Actions 自動化部署已批准的代碼更改。
如果您已經到這一步，感謝您的閱讀！ 希望這對您有價值。
Ifeanyi Otuonye 是一名擁有 6 項 AWS 認證的雲端工程師，擅長 DevOps、技術寫作和作為技術講師的教學專業。他因渴望學習和發展而受到激勵，並在協作環境中茁壯成長。在轉向雲端之前，他曾擔任職業田徑運動員六年。
在 2022 年初，他策略性地開始自學並參加為期六個月的加速雲端課程，以成為雲端/DevOps 工程師。
2023 年 5 月，他實現了該目標，獲得了他的第一個雲端工程職位，並現在設立了另一個個人使命，旨在賦能其他人走向雲端的旅程。
Source:
https://www.freecodecamp.org/news/how-to-build-a-serverless-crud-rest-api/