2017-02-26 68 views
16

您認爲在AWS API網關中使用具有和不具有代理功能的Lambda集成的優點和缺點(更具體地說,使用無服務器框架時)如何?這是我覺得到現在爲止:Lambda集成與Lambda代理:優缺點

LAMBDA集成代理

  • :人們可以快速原型和代碼,而不必擔心所有需要的配置細節(和重塑幾個輪子像通用模板映射等)。
  • Pro:它很容易返回任何狀態碼和自定義標題,同時還有一種通用的方式來讀取請求的主體,標題,參數。
  • Con:一切都在代碼中完成,所以自動生成文檔有點困難。代碼中依賴項(標題,模型,返回的狀態代碼)「隱藏」。

LAMBDA集成,而不代理

  • 精讀:涉及很多工作更來進行設置,這樣的配置可能在不同的資源進行復制。
  • Pro:它允許解耦lambda接收和返回的內容,以及它如何映射到不同的HTTP狀態碼,標題和有效載荷。
  • Pro:非常有用,因爲它規定了它返回的內容,以及它在標題和有效載荷方面的要求。
  • 專業版:從長遠來看,設置所有內容時的辛勤工作很有用,因爲可以將所有內容導出到Swagger,因此其他人可以使用它爲其生成不同的SDK。

您的想法是什麼?您通常使用Lambda Proxy還是普通的Lambda集成?你喜歡什麼,爲什麼?

編輯:到目前爲止,我傾向於總是選擇不使用代理服務器的功能,由於所提及的原因(解耦,並說明依賴-headers,狀態碼,etc-前期)。

+3

不太確定我同意你的優點和缺點,我覺得這個問題很有趣,我想看看其他人的想法,但基於觀點的問題不是什麼stackoverflow是。 –

回答

2

沒有代理。

我在生產中有幾個SLS部署,有些產生收入一些作爲內部工具。我專門使用沒有代理。我不想依賴於我的應用程序的AWS結構,所以如果我們不再成爲朋友,我可以遷移而不會有太多的痛苦。

至於代理人的優點,我會認爲他們是缺點,因爲它感覺你也有,而且是專業人士。在「讓我們超級快速移動」之前,我已經看到了這一切。是的,我們需要敏捷並迅速行動,但不以犧牲思維爲代價。我始終與我的工程師們共同完成這項任務,其中一件事情就是在文檔/設計方面低下一切,一起說「對規劃的要求只是代碼」。無論你上市速度有多快,這就是你如何擺脫自己的問題。如果沒有代理服務器(並且對項目結構進行了一些早期規劃,也許有一些DDD思想很好),如果世界變得炙手可熱,那麼它很容易從AWS遷移出去。

除此之外,我發現使用AWS的東西很難獲得新的機器人。一旦你知道它的所有肉汁,但開發人員是開發人員,而不是基礎設施工程師(我們這些人誰都是驚人的罕見)。抽象的離開幫助人們在開始拉博索爾的艱難旅程時具有生產力。我寧願使用編碼器代碼,也不需要每隔20分鐘就打擾一下CFN。