Amo Wu's Blog

AWS Serverless RESTful APIs 近幾年在雲架構上討論熱度較高的 2 大主題分別是 容器化 （Containerize）與 無伺服器 （Serverless）架構。本篇文章會帶你瞭解什麼是 AWS 無伺服器架構，以及如何使用 Serverless Framework 這個框架，快速開發 RESTful APIs。 大綱 什麼是 XaaS？ AWS 無伺服器架構 Serverless Framework CRUDable Service 基礎設施即程式碼 什麼是 XaaS？ 馬雲說過一句話：「過去的一百年，我們把人變成了機器，未來的一百年，我們將會把機器變成人。」 人算不如天算，天算就是雲計算。 如果要用一句話來定義 XaaS（X as a Service）的話，那就是「 萬物皆服務 」。 舉凡 IaaS（基礎設施及服務）、PaaS（平台即服務）或 SaaS（軟體即服務）等⋯⋯，用一張圖來概括各個 XaaS 的關係： 坐在服務窗口後面的人最後都會變成 API。（via @legendtang ） — ruanyf (@ruanyf) 2016年8月26日 身為程式設計師，我們就是那個負責寫服務來取代人類的存在 。 所以能夠以最快速度開發出可驗證的服務原型，就成了開發者彼此之間的競爭條件之一，也是本篇文章的目的。 AWS 無伺服器架構 AWS 是目前雲技術的領頭羊，如果想要用 AWS 來開發 Serverless 的 RESTful APIs，主要會由 3 個核心服務所構成： AWS Lambda（Functions as a Service） Amazon API Gateway（REST API Endpoint as a Service） Amazon DynamoDB（NoSQL DB as a Service） 利用 3 個 XaaS 組成一個 BaaS（後端即服務） 這裡不會贅述如何操作這些 AWS 服務，如果你已經熟悉這些服務，可以直接前往下一章的 Serverless Framework；如果還不知道它們是怎麼運作的，強烈建議先跑過一遍官方的幾篇教學與實作，理解這 3 個傢伙為什麼這麼酷，也才能理解為什麼接下...

如果你是使用 Angular、React 或是 Vue 來開發 SPA（單頁面應用），並且放在 Amazon S3 Static Website Hosting 上的話，那麼你會碰到 URL routing 的問題。 一般 react-router 或 vue-router 都預設使用 hash 的方式來處理 SPA 的路由： http://domain.com/#!/paths 如果你不喜歡 #!/ 的顯示方式，可以使用 HTML5 的 History API ，這樣就能像一般網站那樣顯示 URL： http://domain.com/paths 但是使用 HTML5 History API 時，通常必須搭配 server 端正確的 路由配置 才能防止出現 404 Not Found 的情形。 遺憾的是，在 Amazon S3 Static Website Hosting 上，你無法更動 Apache 或 Nginx 的配置，所以需要靠其它方式來解決問題。 使用 S3 的 Redirection Rules 使用 CloudFront 的 Custom Error Response 使用 S3 的 Redirection Rules Amazon S3 Static Website Hosting 提供了 Edit Redirection Rules 的選項，我們可以輕鬆使用這段程式碼將所有 domain.com/#!/paths 所產生的 404，全部重新導向至根路徑： <RoutingRules> <RoutingRule> <Condition> <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals> </Condition> <Redirect> <HostName>你的網域（例：domain.com）</HostName> <ReplaceKeyPrefixWith>#!/</ReplaceKeyPrefixWith> </Redirec...

翻譯自原文 Error handling in AWS API Gateway with Lambda 這篇文章會介紹如何設置 AWS API Gateway 正確處理 Lambda 返回的 HTTP 錯誤狀態碼。 更新：2016.03.12 claudia 可以自動化解決這個問題，詳細可以參考 這篇 文章。 本文假設讀者已經知道如何利用 AWS API Gateway 和 Lambda 建立 REST API，詳細可參考 Create API Gateway API for Lambda Functions 。 假設你的 Lambda function 錯誤處理如下： console.log('I am a AWS Lambda function'); exports.handler = function(event, context) { // 一般使用 context.fail 來返回 Lambda function 錯誤 context.fail(JSON.stringify({status:'fail', reason:'some reason', foo:'bar'})); }; 但是 API Gateway 返回的結果會是 HTTP 200 ： HTTP/1.1 200 OK ... { "errorMessage": "{\"status\":\"fail\",\"reason\":\"some reason\",\"foo\":\"bar\"}" } 我們希望的結果是： HTTP Status 400 Bad request 只顯示 errorMessage 的 JSON 值 1. 新增 HTTP Status 400 Method Response 前往 API Gateway Console 進入 Method Execution 進入 Method Response 點選 Add Response 輸入 HTTP Status 400 點選...

本文介紹如何使用 AWS Lambda & AWS API Gateway 搭建一個不需要伺服器的環境，提供 Slack Slash Commands 查詢豆瓣電影。 2016-01-24 Update： New – Slack Integration Blueprints for AWS Lambda 在 Slack 輸入 /movie 絕地救援，會顯示相關的電影資料。 這篇文章使用到的技術： Slack Slash Commands AWS Lambda AWS API Gateway 豆瓣電影 API 閱讀這篇文章需要具備什麼能力： Node.js 的基本能力 Amazon Web Services 的基本操作 接下來我會逐步講解這些東西： Slack Slash Commands 的運作機制 建立一個簡單的 AWS Lambda function 建立一個簡單的 AWS API Gateway 執行 Lambda function 使用 Lambda 呼叫豆瓣電影 API 測試 AWS API Gateway 將 API Gateway endpoint 加入至 Slack Slash Command Slack Slash Commands 的運作機制 當你在 Slack channel 輸入 /movie 權力的遊戲 ，Slack 會發出一個 content-type Header 設為 application/x-www-form-urlencoded 的 HTTP POST 請求，格式如下： token=YOUR_SLASH_COMMAND_TOKEN team_id=YOUR_TEAM_ID team_domain=YOUR_TEAM_DOMAIN channel_id=YOUR_CHANNEL_ID channel_name=YOUR_CHANNEL_NAME user_id=YOUR_USER_ID user_name=YOUR_USER_NAME command=/movie text=權力的遊戲 response_url=YOUR_HOOK_URL 然後 Slack 需要收到的 JSON 回應格式如下（詳見 Attachments）： { ...

這篇文章將一步一步介紹如何使用 Docker、GitHub Flow、CircleCI、AWS Elastic Beanstalk 與 Slack 來完成 持續整合 與 持續交付 的開發流程。 前言 什麼是持續整合＆持續交付？ 持續整合＆持續交付（Continuous Integration & Continous Delivery），簡稱 CI & CD，具體介紹可以參考「 山姆鍋對持續整合、持續部署、持續交付的定義 」這篇文章。 簡單來說就是盡量減少手動人力，將一些日常工作交給自動化工具。例如：環境建置、單元測試、日誌紀錄、產品部署。 我使用了哪些工具？ Git - 版本管理 GitHub - 程式碼託管、審查 CircleCI - 自動化建置、測試、部署 Docker - 可攜式、輕量級的執行環境 AWS Elastic Beanstalk - 雲端平台 Slack - 團隊溝通、日誌、通知 看完這篇你可以學到什麼？ 瞭解 GiHub 的工作流程（ GitHub Flow ），利用 Pull Request 以及 分支 來完成 代碼審查 （Code Review）與 環境配置 ，例如：開發版（development）、測試版（testing/QA）、上線產品（staging/production）。 使用 Docker，統一開發者、測試人員、以及產品的執行環境。 使用 EB CLI 將應用程式部署到 AWS Elastic Beanstalk 平台上。 使用 CircleCI 將以上工作全部自動化。偵測 GitHub 分支上的程式碼，若有更新則觸發：建置 Docker 環境、單元測試、然後自動部署新版本到 AWS EB。 使用 Slack，讓團隊成員能夠即時接收 GitHub 與 CircleCI 每一項動作的通知。 內容大綱 Node.js 在本地端執行 Node.js 在本地端測試 Node.js GitHub CircleCI 在 CircleCI 測試 Node.js Code Review with GitHub Flow Docker 在 Docker 執行 Node.js 在 CircleCI 測試 Docker ...