與 Eve Porcello 一起粉碎播客第 31 集：什麼是 GraphQL？

在本集中，我們將討論 GraphQL。 它是什麼，如何解決一些常見的 API 問題？ 我與專家 Eve Porcello 進行了交談以找出答案。

顯示註釋

• 夏娃在推特上
• Eve 的公司 Moon Highway
• 向 O'Reilly 學習 GraphQL
• 通過 GraphQL 荒野探索您的道路 - Eve 的 GraphQL 研討會將於 2021 年初啟動

每週更新

• 如何在 Next.js 網站中使用存儲在 Sanity 中的 MDX
  由傑森·倫斯托夫撰寫
• 使用 Google 的 Dialogflow 構建啟用會話 NLP 的聊天機器人
  由 Nwani Victory 撰寫
• 用戶體驗研究中的倫理考慮：培訓和審查的必要性
  由維克多·約科撰寫
• 讓網站更容易交談
  弗雷德里克·奧布萊恩 (Frederick O'Brien) 撰寫
• 當你有一個複雜的解決方案時如何設計一個簡單的 UI
  作者：蘇珊娜·斯卡卡

成績單

Drew McLellan：她是一名軟件工程師、講師、作家，以及培訓和課程開發公司 Moon Highway 的聯合創始人。 她的職業生涯開始於編寫技術規範並為 Web 項目創建 UX 設計。 自 2012 年創辦 Moon Highway 以來，她為 egghead.io 和 LinkedIn Learning 創建了視頻內容，並與人合著了為 O'Reilly 的媒體學習 React 和學習 GraphQL 的書籍。

Drew：她也是會議的常客，曾在 React Rally、GraphQL Summit 和 OSCON 等會議上發表演講。 所以我們知道她是 GraphQL 方面的專家，但你知道她曾經教過一隻北極熊下棋嗎？ 我的好朋友們，請歡迎 Eve Porcello。

德魯：嗨，伊芙，你好嗎？

伊芙·波切洛：我太棒了。

Drew：正如我在那裡提到的，你在 JavaScript 和 React 等方面非常擅長教育，但我今天想和你談談你的其他專業領域之一，GraphQL。 我們中的許多人都會以某種身份聽說過 GraphQL，但可能不完全確定它是什麼，或者它做了什麼，特別是它在 Web 堆棧中解決了什麼樣的問題。

Drew：那麼，如果你願意，如果我是一名前端開發人員，那麼請為我們做好準備，GraphQL 在生態系統中的位置以及它為我執行的功能是什麼？

伊芙：是的。 GraphQL 適合前端和後端。 它介於兩者之間，為前端開發人員和後端開發人員帶來了很多好處。

Eve：如果您是前端開發人員，您可以定義所有前端數據需求。 因此，例如，如果您有一個很大的 React 組件列表，您可以編寫一個查詢。 這將定義為該頁面填充數據所需的所有字段。

Eve：現在有了後端，它真的是自己的了，因為我們可以從很多不同的來源收集很多數據。 所以我們在 REST API、數據庫和所有這些不同的地方都有數據。 GraphQL 為我們提供了這個漂亮的小編排層，可以真正理解我們所有數據所在的混亂情況。 所以它對堆棧中的每個人都非常有用。

Drew：所以它基本上是一種基於 API 的技術，不是嗎？ 它位於前端和後端之間並提供某種 API，對嗎？

Eve：是的，完全正確。 確切地。

Drew：我認為，在過去十年中，API 的黃金標準一直是休息。 因此，如果您有一個客戶端應用程序並且您需要使用來自後端的數據填充它，您將構建一個 REST API 端點並查詢它。 那麼該模型在哪裡下降？ 我們什麼時候需要 GraphQL 來為我們解決這個問題？

Eve：嗯，GraphQL 真正幫助我們解決的問題，一種黃金問題，黃金解決方案，我猜，GraphQL 提供的是，使用 REST，我們過度獲取大量數據。 因此，如果我有 slash 用戶或 slash 產品，那將在我每次點擊路線時將所有數據返回給我。

Eve：使用 GraphQL，我們可以對我們想要的數據更加挑剔。 因此，如果我只需要來自具有一百個對象的四個字段，我將能夠真正查明這些字段，而不必將數據加載到您的設備中，或者我應該說的所有數據加載到您的設備中，因為這是很多額外的工作，尤其是對於您的手機。

Drew：我過去見過並使用過 REST API，它們有一個可選字段，您可以在其中傳遞您想要返回的數據列表，或者您可以通過額外的東西來增加返回的數據。 所以我想這是在識別這個問題，不是嗎？ 也就是說，您並不總是希望每次都返回相同的數據。 那麼 GraphQL 是否將允許前端指定後端將返回的數據形式化的方法形式化？

伊芙：是的，沒錯。 因此，您的查詢就變成了您如何詢問、如何過濾、如何從任何地方獲取任何類型的信息。

Eve：我還認為重要的是要注意我們不必為了真正成功地使用 GraphQL 而拆除所有的 REST API。 我見過很多最成功的 GraphQL 實現，它是圍繞 REST API 的包裝器。 GraphQL 查詢確實為您提供了一種思考所需數據的方法。 然後也許你的一些數據來自我們的用戶和產品，例如，一些數據來自 REST，一些來自數據庫。

Drew：我想熟悉的場景是，您的網站上可能有一個端點，它返回有關用戶的信息以顯示標題。 它可能會為您提供他們的用戶名和頭像。 然後你在每一頁上剔除它並填充數據，但是你會在你的應用程序的其他地方發現你需要顯示它們的全名。

Drew：所以你將它添加到端點，它開始返回它。 然後你做你的帳戶管理部分，你需要像他們的郵寄地址。 所以那個端點也會返回。

Drew：在你知道之前，那個端點正在返回一個很重的有效載荷，後端的成本很高，而且顯然要下載很多。

Drew：在每一頁都被剔除，只是為了顯示一個頭像。 所以我想這是隨著時間的推移而增長的那種問題，很容易陷入，特別是在大團隊中，GraphQL，它就在這個問題之上。 它知道如何解決這個問題，並且它是圍繞解決這個問題而設計的。

伊芙：沒錯。 是的，我認為 GraphQL Schema 的整個想法，我認為真的，它比 GraphQL 的查詢語言部分談論得少。 但我真的覺得 Schema 尤其為我們提供了這個很好的 API 類型系統。

Eve：所以團隊中的任何人、經理、前端開發人員、後端開發人員，任何真正處理數據的人都可以聚在一起，圍繞我們真正想要在這個 API 上提供的數據進行合併，然後每個人都知道那個來源事實上，他們可以在此基礎上構建自己的應用程序部分。

Eve：所以也有一些棘手的 Schema 管理問題。 但就從微服務回到單體應用而言，我們正在這樣做，但仍然可以從微服務中獲得我們喜歡的所有好處。

Drew：我是否正確理解設置 GraphQL 系統的典型方法是您基本上有一個路由，這是您將所有查詢發送到的端點，因此您不必……通常是其中之一最困難的事情是弄清楚要命名什麼，以及這個特定查詢應該在什麼路徑上。 是回頭客和產品，是砍用戶還是砍產品？

Drew：使用 GraphQL，您只有一個端點，您只需將查詢發送到該端點，您就會得到適當的響應。

伊芙：沒錯。 是的。 這是一個單一的端點。 我想，您仍然在處理命名問題，因為您正在命名模式中的所有內容。 但就我而言，我覺得很多公司都在微服務上下了大賭注，每個人都在想，我們有哪些端點？ 他們在哪？ 它們是如何記錄的？ 使用 GraphQL，我們有一個地方，一種字典來查找我們想要了解 API 工作原理的任何內容。

Drew：所以，我對其他查詢語言非常熟悉，比如 SQL 就是很多 Web 開發人員都知道的查詢語言的一個明顯例子。 並且其中的查詢採用幾乎像命令的形式。 這是一個文本字符串，不是嗎，從那個，在哪裡，隨便選擇這個。 GraphQL 的查詢採用什麼格式？

Eve：它仍然是一個技術字符串，但它沒有定義該邏輯的來源。 並且很多邏輯被移回服務器。 所以 GraphQL 服務器，GraphQL API 真正負責說，“從它所在的地方獲取這些數據，根據這些參數過濾它。”

Eve：但在查詢語言中，​​它是非常面向字段的。 因此，我們只需為要檢索的任何內容添加字段。 當然，我們也可以對這些查詢進行過濾。 但我認為關於這些信息的來源不太直接。 許多功能都內置在服務器中。

Drew：所以你可以在查詢中混合和匹配。 您可以發出一個請求，在一個請求中帶回許多不同類型的數據。 那正確嗎？

伊芙：是的，完全正確。 因此，您可以針對服務器允許的盡可能多的字段發送查詢，並帶回各種嵌套數據。 但這就是它的工作原理，我們在字段上連接不同的類型。 所以我想我們會回收我的用戶和產品創意，但用戶可能有一個產品字段，它返回產品列表。 所有這些也與其他類型相關聯。 因此，只要我們希望查詢進行深度嵌套，我們就可以。

Drew：這是否意味著在您的 Web 應用程序中為可能發生各種事情的典型視圖檢索數據，您只需向後端發出一個請求，然後一次性完成所有操作，而無需進行不同的操作查詢不同的端點，因為這只是一件事？

伊芙：是的。 這正是整個目標，只是一個查詢，定義您想要的每個字段，然後在一個響應中返回它。

Drew：查詢是基於 JSON 的，對嗎？

Eve：查詢本身是一個文本字符串，但它通常返回 JSON 數據。 因此，如果我有這些字段，那麼我的 JSON 響應將完全匹配，因此當您發送該查詢時，您將得到什麼非常清楚，因為數據響應看起來完全一樣。

Drew：看起來很多查詢幾乎都是針對裸對象，比如客戶或產品。 有沒有辦法在後端控制業務邏輯的情況下指定更複雜的查詢？ 假設我想獲得一個用戶的團隊列表，但僅限於該用戶是團隊管理員且團隊計劃尚未過期的情況，以及我們在日常 Web 應用程序開發中面臨的所有這些實際限制。 可以用 GraphQL 實現嗎？

伊芙：當然。 所以 GraphQL 真正令人興奮、強大的地方在於，您可以將大量邏輯移至服務器。 如果您有一個複雜的查詢，您想要獲取一些非常特定類型的用戶，您需要在 Schema 中做的就是說“獲取複雜的用戶”，然後在服務器上，會有一個函數你可以用任何你想要的語言編寫所有的邏輯。 JavaScript 是一種最流行的 GraphQL 實現語言，但您根本不必使用它。 所以 Python、Go、C++，無論你想用什麼，你都可以用它來構建一個 GraphQL 服務器。 但是，是的，您可以定義任意複雜的查詢。

Drew：我猜這使您能夠將大量業務邏輯封裝在新類型的對像中。 這公平嗎？ 您知道，您設置了一個複雜的用戶，然後您無需考慮複雜的用戶是什麼，但是您可以繼續使用該複雜的用戶並知道業務邏輯是在其上實現的。 那正確嗎？

伊芙：完全正確。 所以我認為這對前端人員來說非常好，因為他們可以開始基於此進行原型設計。 然後後端團隊可以去實現這些功能來完成這項工作。 然後對於該類型實際上是什麼以及他們是誰，以及“該類型的字段是什麼？”有一種共同的理解。 一切都可以由 GraphQL 堆棧中的任何位置處理。 這就是為什麼它不是真正的前端或後端技術。 兩者兼而有之，兩者都不是。

Drew：這聽起來像是對 API 以及前端和後端之間的關係進行了形式化，所以每個人都得到了一個可預測的標準化接口。

伊芙：沒錯。

Drew：我猜在前端和後端由不同團隊擁有的組織中，這並不少見，我想這種方法也可以進行更改，比如說，在前端，它可能需要不同的數據，而不需要在後端工作的人進行相應的更改。 如果您需要新數據，您仍然可以獲得這個幾乎無限可定制的 API，而無需進行任何工作來更改它。

Eve：是的，完全正確。

Drew：那麼 GraphQL 服務器是否負責格式化響應，或者您是否需要在服務器端邏輯中這樣做？

Eve：所以 GraphQL 服務器定義了兩件事。 它定義了存在於服務器上的 Schema 本身，然後定義了解析器函數。 這些函數可以從任何地方獲取數據。 因此，如果我有一個使用 GraphQL 包裝的 REST API，解析器將從該 API 中獲取數據，將數據轉換為所需的數據，然後在該函數中將其返回給客戶端。 您也可以在該服務器上使用任何類型的數據庫功能。 因此，如果您在一堆不同的地方有數據，這是一個非常好的凝聚點，可以將所有數據放入其中並設計所有邏輯，“這些數據來自哪裡？ 我們要如何改造它？”

Drew：客戶端說，“我想要一個複雜的用戶”，服務器在查詢中收到它，然後可以說，“好吧，我要查找複雜的用戶解析器。” 那正確嗎？

Eve：嗯嗯（肯定的）。

Drew：哪個是函數，然後你編寫你的邏輯，讓你的後端團隊，或者在那個函數中編寫邏輯的人，做任何必要的事情來返回一個複雜的用戶。

伊芙：是的，沒錯。

Drew：所以這可能是調用其他 API，可能是查詢數據庫，可能是在緩存中查找內容，或者幾乎任何東西。

伊芙：幾乎任何東西。 然後，只要函數的返回符合 Schema 的要求，匹配返回的字段、類型，那麼一切都會順利而和諧地工作。

Drew：我猜它默認情況下會在整個 API 中為您提供一致的響應格式。 你不必設計它的樣子。 你只會得到一致的結果。

伊芙：是的，沒錯。

Drew：我認為這真的是一場胜利，因為在大範圍的 API 端點之間保持一致性非常困難，尤其是在大型團隊中。 不同的人在做不同的事情。 除非你有相當嚴格的治理，否則它會很快變得非常複雜，不是嗎？

伊芙：是的，絕對的。 而且我認為 Schema 就是一個很好的小文檔來描述一切。 每當您嘗試向其發送查詢時，您都會自動獲得能夠看到該架構中的所有字段的好處，因為您可以發送自省查詢，並且有各種不錯的工具，例如 GraphQL 和 GraphQL Playground，可用於與 API 數據交互的小工具。

Eve：但是，如果你曾經玩過 Postman，比如 ping 一個 REST API，其中很多，文檔實際上並不存在，或者很難找到，或者類似的東西。 GraphQL 確實為您提供了很好的內聚層來描述可能屬於該 API 的所有內容。

Drew：實際上，服務器端是如何工作的？ 我的意思是，我猜你需要運行一個 GraphQL 服務作為你的基礎設施的一部分，但它採取什麼形式呢？ 它是在自己的端口上運行的整個服務器嗎？ 或者它就像一個庫，你集成到你現有的 Express 或 Apache 中，或者任何帶有解析到該服務的路由的庫？ 你如何實施它？

Eve：是的，它是一個真正的服務器。 所以最流行的 GraphQL 實現是 Node.js 服務器。 當 GraphQL 作為規範發佈時，該團隊在 JavaScript 中發布了這個參考實現，這是一種 Node 服務器，為所有其他已經出現的服務器提供指導。 但是，是的，您可以在它們自己的實例上運行這些服務器。 您可以將它們放在 Lambda 上。 所以有 Apollo Server Express，有 Apollo Server Lambda； 您可以使用各種不同類型的實現來實際運行這個東西。

Drew：所以您在服務器擁有的 Schema 概念之前簡要提到過。

伊芙：是的。

Drew：這使您能夠更嚴格地描述您的類型，而不僅僅是將名稱映射到解析器。 那裡涉及更多，是嗎？

伊芙：是的。 有完整的語言。 所以我參考了規範，我沒有描述它是什麼。 GraphQL 本身就是一個描述查詢語言和 Schema 定義語言的規範。 所以它有自己的語法。 它有自己定義這些類型的規則。

Eve：當您使用 Schema 定義語言時，您基本上使用了該語言的所有特性來思考，API 中包含哪些類型？ 它也是您定義查詢、突變、動詞、如操作、創建帳戶登錄等的地方。 甚至 GraphQL 訂閱，這是另一個很酷的東西，你可以在 Schema 中定義的實時 GraphQL。

Eve：所以是的，Schema 真的非常重要。 而且我認為它在我們的整個 Stack 應用程序中為我們提供了這種很好的類型強制，因為一旦你開始偏離這些字段和那些類型，你就會開始看到錯誤，在這種情況下，這很好，因為你'遵循模式的規則。

Drew：這和 TypeScript 之間有什麼交叉嗎？ 兩者之間是否存在某種協同作用？

伊芙：當然。 因此，如果您是一個經常談論 GraphQL 的人，有時人們會告訴您它很糟糕，並且當您可以這樣做時，他們會公開找到您，並談論 GraphQL 如何不好。 但是很多時候他們會跳過你從類型中得到的很酷的東西。 因此，就與 TypeScript 的協同作用而言，絕對可以使用 Schema 中的類型為前端應用程序自動生成類型。 所以這是一個巨大的勝利，因為您不僅可以在第一次生成它，從而為您提供與前端應用程序的良好互操作性，而且隨著事情的變化，您可以重新生成類型，然後構建以反映這些變化。 所以，是的，我認為隨著類型開始成為事實上的規則，這些東西非常適合。

Eve： ……要成為 JavaScript 中的一種事實上的規則，它們很好地結合在一起。

Drew：這似乎是 TypeScript 設計方式的一種持續主題……這不是 TypeScript，抱歉。 GraphQL 的設計有很多關於形式化前端和後端之間的交互。 它作為一種解決方案出現在剛剛創建一致性和形式化之間的解決方案中，到目前為止，對於很多人來說，這是一種相當混亂的休息體驗。 在編寫客戶端應用程序時，我們始終必須牢記的一件事是代碼需要接受檢查和可能的修改。 並且擁有一個客戶端可以請求數據的 API 可能很危險。 現在，如果您可以指定所需的字段，那可能會很危險。 在整個堆棧中，您會處理用戶的授權並確保圍繞您的數據執行的業務規則？

Eve：你會在服務器上處理所有這些。 因此，這可能以許多不同的方式發生。 您不必使用一次性策略，但您的解析器將處理您的授權。 所以這可能意味著包裝一個現有的非 REST API，比如像 Auth0 這樣的服務或者你自己構建的東西。 這可能意味著與 OAuth 交互，例如 GitHub、Facebook 或 Google 登錄，這些類型的事情涉及與解析器來回傳遞令牌。 但通常會直接構建到 Schema 中。 所以 Schema 會說，我不知道，我們將創建一個登錄突變。 然後我用我的憑據發送該突變，然後在服務器上驗證所有這些憑據。 所以客戶不用太擔心，也許會傳遞令牌之類的東西。 但其中大部分只是內置在服務器中。

Drew：所以本質上，與我們目前構建休息端點的方式相比，這並沒有真正改變。 休息作為一種技術，好吧，它也不真正處理授權，我們在處理它的服務器上有中間件和東西。 GraphQL 也是如此。 你只需處理它。 GraphQL 社區中是否有這樣做的約定？ 是否有共同的方法，或者人們選擇如何實施它？

伊芙：老實說，到處都是。 我想大多數時候你會看到人們構建到 Schema 中，我的意思是，代表這些類型和授權用戶與將這些類型構建到 Schema 本身中的普通用戶。 但是您也會看到很多人使用第三方解決方案。 我提到了Auth0。 很多人會將他們的授權轉移給更專注於它的公司，特別是小型公司、初創公司等。 但您也會看到更大的公司開始為此創建解決方案。 因此，AWS、Amazon 擁有 AppSync，這是他們的 GraphQL 風格，並且他們將作者卷直接內置到 AppSync 中。 這有點酷，只是能夠，我不知道，不必擔心所有這些東西，或者至少提供一個處理這些東西的界面。 所以很多這些生態系統工具都有，我認為授權在 GraphQL 中是一個很大的話題。 他們已經看到了某種需要、對身份驗證解決方案的需求以及在圖表上處理身份驗證的標準方法。

Drew：我想幾乎沒有一個不需要某種授權的實現。 所以，是的，這將是一個相當普遍的要求。 我們都在越來越多地構建組件化的應用程序，特別是當我們使用 React 和 View 以及你所擁有的東西時。 松耦合的原則給我們留下了很多組件，這些組件不一定知道在它們周圍的頁面上還運行著什麼。 這樣做是否存在危險，您最終可能會遇到大量組件查詢相同的數據並發出多個請求？ 或者它只是您的應用程序中需要解決的架構問題？ 有沒有一種成熟的解決方案來處理這個問題？

Eve：嗯，我認為是因為 GraphQL 在大多數情況下，不是 100% 的解決方案，但幾乎每個 GraphQL 查詢都是通過 HTTP 發送的。 因此，如果您想追踪這些多個請求發生的位置，對於在應用程序中使用休息數據的人來說，這可能是一個相當熟悉的問題。 所以有一些工具，比如 Paulo Client Dev Tools 和 Urkel Dev Tools，供前端開發人員使用，他們會問：“發生了什麼事？ 此頁面上有哪些查詢？” 這使您可以清楚地了解正在發生的事情。 有幾種思想流派。 我們是否為頁面的所有數據創建了一個巨大的查詢？ 或者我們是否創建更小的查詢來為應用程序的不同部分加載數據？ 正如您可能想像的那樣，它們都有自己的缺點，只是因為如果您有一個很大的查詢，您正在等待更多的字段。

Eve：如果您有較小的查詢，您需要的數據之間可能會發生衝突。 但我認為，不要太過分了，但我已經在那裡了。 因此，GraphQL 規範中出現了一種稱為 Deferred Directive 的東西，而 Deferred Directive 將有助於輔助加載內容。 因此，假設您在頁面頂部有一些內容，即您要首先加載的超級重要內容。 如果您將其添加到查詢中，然後任何後續字段都會獲得 deferred 指令。 它只是一個小裝飾器，你可以添加到一個字段中，然後它會說，“好吧，先加載重要數據，然後再等待並加載第二個數據。” 它給了你這個，它是一種流數據的外觀到你的前端，所以有感知的性能，有交互性。 人們會立即看到數據，而不是等待頁面加載每個字段，這可能是個問題。

德魯：是的。 我想這使您能夠構建頁面，其中所有內容......我們不喜歡過多談論視口，但它是首屏之上的所有內容，您可以優先考慮，加載然後再加載所有內容下。 所以，我們已經討論了很多關於查詢數據的內容。 API 的主要工作之一是將新的和修改過的數據發送回服務器以進行持久化。 您之前簡要提到了突變。 這就是 GraphQL 用於將數據寫回服務器的術語？

伊芙：沒錯。 因此，我們想要對數據進行的任何類型的更改，我們想要寫回服務器的任何內容，這些都是突變，這些都就像查詢一樣，它們被命名為存在於服務器上的操作。 所以你可以想想我們希望我們的用戶能夠做的所有事情是什麼？ 代表那些有突變的人。 然後再次在服務器上，編寫使這些東西工作的所有功能。

Drew：這和查詢數據一樣簡單嗎？ 調用突變同樣容易嗎？

伊芙：是的。 它是查詢語言的一部分。 它看起來幾乎相同。 唯一的區別是，我猜查詢包含過濾器。 所以突變在查詢本身中採用了看起來像過濾器的東西。 但這些負責實際更改數據。 一封電子郵件和密碼可能會隨突變一起發送，然後服務器會收集它，然後使用它來授權用戶。

Drew：所以，就像以前一樣，您正在後端創建一個解析器來處理這個問題並做任何需要做的事情。 寫入數據時常見的一種情況是您希望提交更改，然後重新查詢以獲取它的當前狀態。 GraphQL 是否有一個很好的工作流程？

Eve：它有點生活在突變本身中。 因此，很多時候在創建 Schema 時，您會創建變異操作。 我會堅持登錄，輸入電子郵件和密碼。 突變本身返回了一些東西。 所以它可以返回像布爾值這樣簡單的東西，這很順利，或者很糟糕，或者它可以返回一個實際的類型。 因此，您經常會看到登錄突變之類的突變，也許它會返回一個用戶。 因此，一旦用戶登錄，您就可以獲得有關用戶的所有信息。或者您可以創建一個自定義對像類型，為您提供該用戶以及用戶登錄的時間，以及返回對像中有關該事務的更多元數據. 再說一次，這完全取決於你自己的設計，但這種模式確實融入了 GraphQL。

Drew：這一切聽起來都很棒，但每一個技術選擇都需要權衡取捨。 使用 GraphQL 的缺點是什麼？ 是否有任何情況下它會是一個非常糟糕的選擇？

Eve：我認為 GraphQL 可能會遇到困難的地方是創建一個一對一的地圖——

Eve： ……奮鬥是創建表格數據的一對一地圖。 因此，假設您有，我不知道，認為具有各種不同字段的數據庫表，並且，我不知道，特定類型的數千個字段，諸如此類，該類型的數據可以很好地表示使用 GraphQL，但有時當您運行一個流程以在該數據上生成 Schema 時，在 Schema 中，您會遇到與數據庫中相同的問題，這可能是超出客戶端的數據過多實際上需要。 所以我認為那些地方，它們是潛在的問題。 我和那些根據他們的數據自動生成模式的人交談過，它變成了一百萬行長的模式或類似的東西，只有成千上萬行模式代碼。 這就是它變得有點棘手的地方，比如它作為人類可讀的文檔有多大用處？

伊芙：是的。 因此，在您與客戶打交道的任何情況下，就對每種不同類型的數據進行建模而言，它非常適合，如果您的數據源太大，它會變得有點棘手。

德魯：所以這聽起來像任何你要仔細策劃字段中的響應並更多地手工完成的地方，你可以獲得非常強大的結果。 但是，如果您因為剛剛擁有一個龐大的 Schema 而自動生成東西，那麼它可能會變得有點笨拙。

伊芙：是的。 我認為人們在傾聽我的意見並對此持不同意見，因為也有很好的工具。 但我認為 GraphQL 真正閃耀的地方在於將邏輯抽像到服務器的步驟，讓前端開發人員可以自由定義他們的組件或前端數據需求，並真正作為一個團隊管理 Schema。

Drew：查詢語言中是否有任何內置功能來處理結果的分頁，或者是否需要根據需要自定義實現？

伊芙：是的。 分頁，您將首先構建到模式中，因此您可以為此定義分頁。 社區中出現了很多指導方針。 GitHub GraphQL API 是一個很好的例子，看看你是否是 GraphQL 的新手，我一直在看這個。 他們基本上已經使用 GraphQL 為面向公眾的 API v4 重新創建了 API。 所以這是一個很好的地方，可以看看一家真正的大公司是如何大規模使用它的。 很多人都在運行大型 API，但他們不會向所有人公開。 所以分頁非常好地內置在該 API 中，您可以返回（我不知道）您曾經創建的前 50 個存儲庫，或者您也可以使用基於游標的分頁來根據數據中的想法返回記錄。 因此，基於光標的分頁和位置分頁，例如第一條記錄，最後一條記錄，這通常是人們處理它的方式，但有很多技術。

Drew：在使用 GraphQL 時我們應該知道哪些大問題？ 假設我要為我的組織部署新的 GraphQL 安裝，我們將使用 GraphQL 構建所有新的 API 端點。 我應該知道什麼？ 灌木叢裡有什麼東西嗎？

Eve：潛伏在灌木叢中，總是帶著技術，對吧？ 我認為 GraphQL 中沒有內置但可以毫不費力地實現的一件事是 API 安全性。 例如，你提到如果我有一個巨大的查詢，我們在授權的情況下討論了這個，但是打開一個 API 也很可怕，有人可以發送一個巨大的嵌套查詢，朋友的朋友，朋友的朋友，朋友的朋友, 順著鏈條向下。 然後你基本上允許人們用這些巨大的查詢對你進行 DDoS 攻擊。 So there's things that you can set up on the server to limit query depth and query complexity. You can put queries on a safe list. So maybe your front ends, you know what they all are and it's not a public API. So you only want to let certain queries come over the wire to you. So I would say before rolling that out, that is definitely a possible gotcha with the GraphQL.

Drew: You do a lot of instruction and training around GraphQL, and you've co-written the O'Reilly 'animal' book with Alex Banks called Learning GraphQL. But you've got something new that you're launching early in 2021, is that right?

Eve: That's right. So I have been collaborating with egghead.io to create a full stack GraphQL video course. We're going to build an API and front end for a summer camp, so everything is summer camp themed. And yeah, we're just going to get into how to work with Apollo server, Apollo client. We will talk about scaling GraphQL APIs with Apollo Federation. We'll talk about authorization strategies and all sorts of different things. So it's just kind of collecting the things that I've learned from teaching over the past, I don't know, three or four years GraphQL and putting it into one spot.

Drew: So it's a video course that… Is it all just self-directed, you can just work your way through at your own pace?

Eve: Yeah, exactly. So it's a big hefty course so you can work through it at your own pace. 絕對地。

Drew: Oh, that sounds really good. And it's graphqlworkshop.com, is that right?

Eve: Graphqlworkshop.com, exactly.

Drew: And I'm looking forward to seeing that released because I think that's something that I might need. So I've been learning all about GraphQL. What have you been learning about lately?

Eve: I've also been looking into Rust lately. So I've been building a lot of Rust Hello Worlds, and figuring out what that is. I don't know if I know what that is yet, but I have been having fun tinkering around with it.

Drew: If you dear listener, would like to hear more from Eve, you can find her on Twitter where she's @eveporcello, and you can find out about her work at moonhighway.com. Her GraphQL workshop, discover your path through the GraphQL wilderness, is coming out early in 2021 and can be found at graphqlworkshop.com. Thanks for joining us today, Eve. 你有什麼離別詞嗎？

Eve: Parting words, have fun with GraphQL, take the plunge, you'll enjoy it, and thanks so much for having me. 我很感激。