黑皮考町

本篇文章簡單的介紹, 如何使用OneDrive API來取得特定的檔案(使用POSTMAN) 基本上, 使用OneDrive API取得使用者任何資料都需要一個認證過程來取得資料擁有者的授權, 而要完成這個授權的流程 首先, 需要在微軟的網站上註冊你的應用程式 https://apps.dev.microsoft.com/#/appList 註冊完之後我們會獲得 Application ID :  1ba84ab3-12fe-4c1e-86f2-0c5636c389ca Key : kHOUAH^&H= 再來, 加入Redirect URL 1. 選擇Add Platform 2. 選擇Web Application 然後加入https://www.getpostman.com/oauth2/callback 如下 取得授權(打開POSTMAN) 1. 認證方式選擇Oauth 2.0 2. 打開Get New Access Token的對話框 輸入相關資料 Auth Url: https://login.microsoftonline.com/common/oauth2/v2.0/authorize Access Token Url: https://login.microsoftonline.com/common/oauth2/v2.0/token Client ID: 你的Application ID Client Secret: 你的Application Key Scope: files.readwrite offline_access Grant Type: Authorization Code (此方式會額外得到一組refresh token, 將來若access token 過期, 可以用它來索取新的access token) 授權結束之後會取得一組access token, 對於OneDrive的後端來說, 夾帶這個token的API請求就是合法的請求, 因此可以有條件地存取資源 開始存取資源(搜尋檔案) GET https://graph.microsoft.com/v1.0/me/dri...

什麼是Simple Email Service(SES) SES 是AWS上的Mail Service, 可以用來收發電子郵件 Persistence SES會將收到的信件儲存在S3 觸發事件 可以用來觸發 SNS, 以及Lambda function

SQS 跟 SNS 的差別在哪? 這裡簡單的整理一下, SQS 是Pull Based的架構, 消費者要自己去佇列中抓訊息下來 SNS 是Push Based的架構, 訊息會自動推撥給訂閱者 使用情境 SQS 用在將應用程式解偶降低相依性 SNS Fanout, 用在同時將訊息散發到其他不同的服務上 使用例子 SQS 線上機票查詢服務(skyscanner), 假設架構如下 我們可以把服務使用者的EC2 instance與負責撈資料的EC2 instance解偶, 好處是, 即使撈資料的EC2掛了, 也不會弄丟使用者的查詢請求, 因為沒處理完的訊息會持續地保留在佇列中等待被處理 SNS 線上影像處理服務, 當使用者上傳照片到S3, 可以透過SNS同時散發這訊息給: (一)處理影像的Lambda, 以及(二)寄發感謝函給使用者的服務, 藉此平行地執行相應的動作 儲存方式 SQS 可以保留訊息到最長14天 SNS 不能保留訊息, 若推撥時訂閱者不在, 訊息會遺失 消費者 SQS的消費者通常都作相似的工作 SNS的消費者(訂閱者)有很大的可能是處理不一樣的工作 https://stackoverflow.com/questions/13681213/what-is-the-difference-between-amazon-sns-and-amazon-sqs

Simple Notification Service Simple Notification Service(簡稱SNS) 允許我們從雲上推撥訊息到任何其他行動裝置或是服務上 Mobile Directly Push 基本上, 要實作訊息推撥的服務, 我們必須串接裝置平台上的Push Notification Service, 但是不同平台有各自的Push Notification Service, 如果目的端橫跨多平台(比如Apple, Google Android, Windows), 這對開發人員來說會是個很大的工程 使用SNS的Mobile Directly Push就不必煩惱這種問題, 因為他都幫我們整合好了, 所以可以簡單地實現跨平台推撥訊息的服務 Push-subscribe  定義好Topic之後, 只要將訊息傳到指定的Topic, 任何訂閱這個Topic的行動裝置或服務都會收到推撥通知 訂閱的對象 除了行動裝置之外, Email, SMS, Lambda, SQS, HTTP Endpoint也可以訂閱SNS上的Topic 優點 1. 主動推撥, 不需要特別發請求去詢問有沒有訊息 2. 推撥訊息時, 無需特別考慮目的端使用何種通訊協定 3. 允許同一則訊息同時在不同的通訊協定上傳送 https://docs.aws.amazon.com/sns/latest/dg/SNSMobilePush.html https://blog.idanbean.io/2016/03/02/aws-sns-with-apns/

Simple Queue service(SQS) 在設計系統時, 若不希望元件之間相依程度過高的話, 通常會在元件之間加一層message queue來解偶 在雲上, AWS提供的Simple Queue Service 簡稱SQS, 讓我們可以把雲上各個相依的服務元件解偶, 進而提升整體系統的延展性 Key Feature Pull Based 不會自動推撥訊息, consumer 需要不斷地去詢問有沒有可執行的任務在佇列中 (2018年六月之後的SQS可以透過事件來驅動Lambda) 訊息大小 目前支援最大256kb 訊息的保存期限 最短1分鐘到最長14天, 訊息一旦過保就會被刪除 訊息的存取時間 預設每則訊息可以被獨佔30秒, 因為當訊息被截取之後, 會變成隱蔽狀態, 可是一旦超過這個存取時間之後, 狀態會恢復, 重新開放給任何其他的consumer去獨佔, 當然我們也可以延長獨佔的時間到最長12小時 存取的範例程式碼 var params = { AttributeNames: [ "SentTimestamp" ], MaxNumberOfMessages: 1 , MessageAttributeNames: [ "All" ], QueueUrl: queueURL, VisibilityTimeout: 2 , //訊息的存取時間 WaitTimeSeconds: 0 //等待回復的時間, 設為0表示Short polling }; sqs.receiveMessage(params, (err,data)=>{ if (err){ console.log(err); } else { console.log( "Received Data:" ,data); } }) 任務完成後必須要手動清掉佇列中的訊息, 否則當存取時間超過之後, 訊息會重新開放給其他的consumer, ...

前言 當我們開發完一個WEB專案之後, 接下來要做的就是測試跟部屬, 通常在部屬的時候, 往往都是找一台機器開始灌OS, 切partition, ...OS灌完之後還要再安裝Application Server, 像Tomcat, IIS 等等 然後設定環境, 如網路,憑證,備份,,等等 最後才開始部屬WEB application, 可是到這個時候, 差不多也浪費掉了一兩天的時間 Elastic Beanstalk(簡稱EBS)是Amazon提供的PAAS服務, 開發人員不需要考慮如何配置以及維護環境, 甚至也不需要煩惱scaling的問題, 只要專心寫程式, 然後上傳到EBS上, 所有跟環境有關的工作EBS都會幫你完成 EBS會幫我們做Heath check, 程式有問題時馬上就會知道, 如果流量增加, EBS也可以幫我們做load balancing, 除此之外, 版本管控的功能也可以讓我們隨時方便的做Roll back Deployment policy EBS 提供四種部屬方式 All at once 直接部屬到所有的instance上, 在部屬期間服務會被停止, 部屬失敗的話需要額外再做Roll back Rolling 選擇這個方式, EBS會一個接著一個將程式部屬到每個instance上, 對外服務不會被停止但整體的performance會下降, 對於很吃performance的WEB APP來說並不適用, 部屬失敗時也需要額外的動作去做Roll back Rolling with additional batch policy 會額外再多建立新的instance去做部屬, 然後再一個接一個部屬下去, 好處是部屬時不會造成performance下降, 部屬失敗時也需要額外的動作去做Roll back Immutable 所有的instance會先部屬在分身上面, 當部屬成功後分身會取代本尊成為服務的提供者, 而先前的instance會被刪除(非常適合Missions critical production), 部屬失敗時影響最小, 只要砍掉分身就好 Config EBS允許我們使用特定的config檔案去客製化EBS上的環境, 例如安裝那些套件, 建立那些特定的...

API Gateway API Gateway有點像是水龍頭的概念, 每個水龍頭後面可能各自連接著不同的水源, 用的人不需要知道後面管線怎麼牽的, 如果想要山泉水就去轉開山泉水的水龍頭, 如果想要自來水就去轉開自來水的水龍頭 我們可以在API Gateway上定義RESTful API, 被後再介接Lambda或是其他的web service, 使API Gateway 成為這些網路資源統一對外的出口 Cache 如果想要增加Performance, 我們可以額外付費去啟用快取的功能, 對於相同的請求, 就可以從塊取拿答案直接回覆 (步驟 Stages > Your_stage > Settings ) Throttle 我們可以限制API的呼叫次數, 以避免被有心人士惡意攻擊 (步驟Stages > Your_Stage > Settings) Cross Origin Resource Sharing(CORS) 在Same-origin Policy的機制下, 為了避免Cross-site Script(XSS)攻擊, 大部分的瀏覽器只允許存取與頁面相同Domain下的資源 CORS 可以讓瀏覽器放寬這個限制執行跨域請求