如何使GraphQl和DynamoDB一起效果很好

無服務器體系結構，GraphQL API和DynamoDB數據庫形成了網站開發的強大組合。雖然無服務器和GraphQl廣泛流行，但DynamoDB通常被誤解或避免，有時被錯誤地被視為在大規模尺度上僅有益。

最初，我分享了這種誤解，更喜歡我的無服務器項目的SQL數據庫。但是，在獲得DynamoDB的經驗之後，我發現了各種項目規模的優勢。為了說明，讓我們從頭開始構建樣本API，繞過複雜的ORMS或GraphQl框架以揭示基礎機制。這種動手方法可能會改變您對DynamoDB價值的看法。

解決共同的問題

DynamoDB採用的主要障礙是其陡峭的學習曲線，儘管其功能很少有爭議。儘管學習曲線很重要，但SQL數據庫並不是無服務器應用程序的理想選擇。在無服務器環境中部署和管理SQL數據庫連接的挑戰是重大的。 DynamoDB本質上是無服務器友好的，可以通過減輕未來擴展的複雜性來提供長期優勢。最初對學習DynamoDB的投資最終可以節省大量的未來頭痛。

配對GraphQL與DynamoDB的適合性更為複雜。現有的GraphQL文檔，教程和示例中的大部分都假設了關係數據庫。即使是DynamoDB專家，也是“ DynamoDB書”的作者Alex Debrie，也建議您使用這種組合，這主要是由於將GraphQL解析器作為順序的，獨立的數據庫調用的常見實踐，導致過多的讀取。

另一個潛在的問題是DynamoDB偏愛預定義的訪問模式。 GraphQl的強度在於它比休息更容易處理任意查詢的能力。對於用戶可以製作不可預測的查詢的公共API，這變得更加問題。但是，GraphQL經常用於私有API，其中對客戶端和服務器的控制允許管理和控制查詢模式。如果沒有仔細的設計，GraphQl查詢就可以輕鬆地超載任何數據庫。

一個簡單的數據模型

此示例API將與團隊，用戶和認證的組織建模。這些關係在下面的實體關係圖中描述。每個團隊都有多個用戶，每個用戶都可以擁有多個認證。

關係數據庫表示

儘管我們的目標是DynamoDB模型，但SQL數據庫表示形式將類似於以下圖：（圖將在這裡，顯示表格和關係）

為了處理用戶與認證之間的多對多關係，引入了一個名為“憑據”的中介表。到期日期是此表中的唯一屬性。為簡單起見，省略了其他屬性。

訪問模式

有效的DynamoDB數據建模取決於了解訪問模式。關係數據庫以標準化數據開頭，並使用加入進行數據檢索。 DynamoDB缺乏連接；因此，數據模型必須與預期的訪問方法一致。這是一個迭代過程。優先考慮頻繁的訪問模式。許多人將直接映射到GraphQl查詢，而其他則可以內部用於身份驗證或授權。頻繁的操作（例如，每周行政檢查）不需要優化的設計；效率低下的方法（如表掃描）就足夠了。

高頻訪問：

• 用戶通過ID或名稱
• 由ID或名稱的團隊
• 用ID或名稱認證

頻繁訪問：

• 團隊中的所有用戶（按團隊ID）
• 用戶的所有認證
• 所有團隊
• 所有認證

不經常訪問：

• 團隊中用戶的所有認證
• 所有擁有特定認證的用戶
• 所有團隊中獲得認證的用戶

DynamoDB單台設計

DynamoDB缺乏連接需要根據主要鍵或預定義索引進行查詢。數據庫不強制執行模式，允許單個表中的各種項目類型。最好的做法是將所有項目存儲在單個表中，以有效地共同確定的數據訪問。下面的模式反映了這種方法，與前面確定的訪問模式保持一致。 （架構詳細信息將在這裡，顯示主鍵，排序鍵和索引）

主要鍵是分區密鑰（PK）和Sort Key（SK）的複合材料。檢索項目需要指定分區密鑰以及單一鍵值或範圍。索引（GSI1PK，GSI1SK等）用於靈活訪問不同項目類型。 “＃”符號充當了空鍵的佔位符。

數據庫架構實現（代碼段）

數據庫模式在應用程序中執行。 DynamoDB的API功能強大，但複雜。許多開發人員使用ORM來簡化。在這裡，我們將使用助手功能直接訪問數據庫來定義團隊項目架構。 （db_map的代碼段，包括團隊的get，put和解析功能，將在這裡）

要添加一個新團隊，您會致電： DB_MAP.TEAM.put({teamId:"t_01",teamName:"North Team"})

這將生成數據庫API的索引和鍵值。 parse方法將數據庫項轉換回應用程序模型。

GraphQL模式（代碼段）

（類型團隊，用戶，認證，憑據和查詢的類型類型定義定義將在這裡。）

將GraphQL和DynamoDB與解析器連接

解析器執行GraphQl查詢。解析器對於構建我們的API至關重要。 GraphQL模式中的每個查詢都有一個相應的根解析器（此處僅顯示團隊解析器）。這些解析器返回承諾或包含部分查詢結果的對象。

如果查詢返回Team類型，則執行將繼續使用Team類型解析器。該解析器具有每個Team屬性的功能。如果丟失了解析器（例如，對於id ），則檢查根解析器是否提供了值。

查詢採用四個參數： root （parent對象）， args （查詢參數）， context （應用程序數據，包括數據庫參考）和info （查詢詳細信息，在此處未使用）。

下面的解析器使用ctx.db.singletable可訪問DynamoDB表。 get和query方法直接與數據庫進行交互，並且DB_MAP.TEAM...使用輔助函數轉換架構。 parse方法將數據轉換為GraphQL架構格式。 （ResolverMap的代碼段，包括用於查詢的解析器，QUERY.TEAMBYNAME，QUERY.ALLTEAMS，team.name，team.Members.Members，user.name，user.credentials將在這裡）

讓我們跟踪以下查詢的執行：團隊根解析器按ID讀取團隊，返回ID和名稱。 Team類型解析器然後檢索所有團隊成員。 User類型解析器為每個用戶獲取憑據和認證。每個成員和五個憑證都有七個數據庫讀取。儘管與SQL數據庫（可能是四個呼叫）相比，這似乎看起來過高，但根據各種因素，七個DynamoDB讀取可能更快，更便宜。

查詢{team（ID：“ T_01”）{
  ID
  姓名
  成員{
    ID
    姓名
    證書{
      ID
      認證{
        ID
        姓名
      }
    }
  }
}}}

過度提取和n 1問題

優化GraphQL API涉及許多權衡。在DynamoDB和SQL之間進行選擇時，有兩個關鍵的考慮因素是過度提取的，而N 1問題。這些通常是對立的力量。當解析器要求更多的數據時，就會發生過度提取。當根部或類型的解析器（例如， Team解析器中的members ）試圖在單個數據庫調用中檢索過多的數據時，就會發生這種情況。如果查詢沒有請求name屬性，請檢索它是浪費的。

N 1問題恰恰相反。將所有讀取到最低級別的解析器都意味著更高級別的數據庫請求。代替了一個五個成員的電話，而是進行了五個單獨的讀數。這可能會導致更多讀取。實際上，諸如DataLoader批處理這些請求之類的工具減少了數據庫調用的數量。這些較小的原子要求對於有效的批處理至關重要。

對於SQL，通常最好的帶有數據加載器的小型低水平解析器是最好的。對於DynamoDB，與單台設計對齊的“更智能”的高級解析器更有效。在這種情況下，過度取得的邪惡通常是較小的邪惡。

部署（摘要）

可以使用Architect快速部署此示例，這是用於在AWS上構建無服務器應用程序的開源工具。 GitHub存儲庫提供代碼。克隆和運行npm install後，可以在本地啟動應用程序（包括本地數據庫）。在AWS（包括DynamoDB）上的生產部署也很簡單。

以上是如何使GraphQl和DynamoDB一起效果很好的詳細內容。更多資訊請關注PHP中文網其他相關文章！