通過使用GraphQL保護您的外部API並減少攻擊面
我最近參與的眾多專案之一是從頭開始構建一個新的應用程式。 這是一個大型企業業務應用程式,將有許多前端使用者。 所需的邏輯和功能量將以該體系結構中的大約50個微服務結束,一些微服務本地部署到雲中,而某些則需要託管在OpenShift叢集的本地中,這將成為我們與舊資料系統的連線。
該公司之前從未構建過如此多的微服務,也從未將它們引入雲中。 難題之一已成為如何協調服務網格以確保前端的更改不會破壞應用程式,或者對後端服務的更改不會破壞前端。
我推薦的解決方案:將GraphQL用作企業API閘道器。
簡化部署流程所有這些API的眾多問題之一是,對其中任何一個進行更改都可能最終破壞另一個API。 儘管"微服務"應該自力更生,但實際上這仍然意味著響應中缺少資料。
當我們有兩個部署了不同服務的平臺時,這變得更加複雜。 人們將使用不同的CI / CD管道來實現本地OpenShift與雲原生Lambda服務。
在GraphQL之前提供我們所有的服務,簡化了對這些平臺進行協調的需求。 你怎麼問 好吧,現在我的前端應用程式將只能與一個端點通訊。 它是用於查詢和釋出資料的無版本架構,因此我不需要對前端進行更改,因為後端上的某些內容已發生更改。 GraphQL端點保持不變,即使後端發生變化也可以繼續執行。
> Example CI/CD pipeline for Lambda (Source)
簡化安全性該體系結構提出的另一個主題是如何保護我們的所有服務? 我們是否建立了在使用其他服務之前必須先呼叫確保安全的令牌服務? 我們是否為每個服務新增邏輯以確保令牌位於標頭中並在各處驗證?
再次,我的答案是否定的! 使用API閘道器來管理所有服務可以使您將安全檢查/驗證向上移動一層。 這使開發人員可以專注於開發具有業務價值的事物的功能。 它還減少了遍及所有地方重複的膨脹和多餘程式碼。
我們可以使用GraphQL實施幾件事來提高安全性:
深度限制
import depthLimit from 'graphql-depth-limit'import express from 'express'import graphqlHTTP from 'express-graphql'import schema from './schema'const app = express()app.use('/graphql', graphqlHTTP((req, res) => ({ schema, validationRules: [ depthLimit(10) ]})))
限速
使用此GraphQL Rate Limit外掛,您可以通過三種不同方式(自定義指令graphql-shield或基本速率限制器功能)為查詢和突變指定限制。
該外掛可讓您設定時間視窗和限制。 在高度脆弱的變異和查詢上設定一個較大的時間視窗,例如登入以及對脆弱程度較低的查詢設定較短的限制,將有助於您為合法使用者保持良好的體驗,併為攻擊者帶來噩夢。
查詢費用限制
> Source: https://docs.microsoft.com/en-us/azure/devops/migrate/media/phase-rollout-with-rings/phase-rollout-with-rings-pipeline.png?view=azure-devops
沒有GraphQL,我將必須非常小心如何版本和更新API。 我可以執行多個版本的API,例如/ v1和/ v2,但是我必須確保上游API和前端應用程式對/ v2進行了更新才能退出/ v1。 另外,我將必須在同一程式碼庫或容器中同時支援這兩種方法,從而使其更易碎,並且容易受到重大更改的影響。 使用該GraphQL服務作為代理,我可以推出一個/ v2容器並使兩者並排執行。 我可以更改GraphQL解析器以指向/ v2,而無需更改程式碼的前端行。 這使部署新功能非常容易!
我還可以為任何服務選擇任何部署策略,例如:
· 藍綠髮布
· 金絲雀釋出
· 功能標記
> Example Blue/Green Deployment (source)
摘要目前,開發新的應用程式體系結構的首選是檢視微服務模式。 所有這些小型服務一起工作,並在API閘道器後面公開,以便我的前端SPA應用程式可以使用它們向終端使用者顯示資訊。
GraphQL可以減少攻擊面,並簡化應用程式開發以及服務的實際部署。
(本文翻譯自Tj Blogumas的文章《GraphQL is the New API Gateway》,參考:https://levelup.gitconnected.com/graphql-is-the-new-api-gateway-383edeed4bcd)