GraphQL神話和誤解

消除對GraphQL的困惑

> Image by TeeFarm from Pixabay

因此，請告訴我為什麼我要與團隊中的一名工程師就GraphQL的好處進行辯論，而他試圖通過說："您只喜歡它是因為它對前端開發人員是有好處的"。

老實說，我有點不高興，因為我認為這是我職業生涯中的幾次，其中一位只知道服務器端開發的工程師因為我喜歡構建用戶界面而拒絕了我的意見。

經過一番思考，我意識到他是對的。 GraphQL對客戶端確實非常有用。 對於服務器端來說也很棒，但這不是我們討論的重點。

當比較GraphQL和REST時，可以觀察到的是典型的REST服務針對服務器進行了優化，而GraphQL服務針對客戶端和服務器端開發進行了優化。

顧名思義，GraphQL服務旨在使客戶滿意和高效。

這不是我第一次進行這樣的討論，所以我想繼續討論我在GraphQL傳福音之旅中遇到的一些關於GraphQL的誤解。

1.您正在公開整個數據庫

"但是William，藉助GraphQL，您正在將整個數據庫公開給客戶以執行他們想要的任何事情。"

您沒有公開整個數據庫。 我曾與諷刺地描述GraphQL來公開整個數據庫並允許客戶從數據庫中查詢所需內容的人們進行過交談。

通常將其描述為一個缺點，使GraphQL基本上是您前端的數據庫連接器。 此定義存在一些問題。

您可以在沒有數據庫的情況下使用GraphQL服務

正如GraphQL服務不必基於Graph數據庫一樣，您可以擁有不帶數據庫的GraphQL服務。 它可以用於執行計算和處理的服務或代理其他服務。

您設計自己的模式

由於您設計自己的GraphQL模式，因此該服務僅會公開您希望通過模式訪問的內容。

您可以限制用戶查詢的複雜性

由於GraphQL查詢可以嵌套和批處理，因此可以使用一些工具對查詢的複雜性施加一些限制。

例如，諸如GraphQL查詢複雜度之類的工具可通過限制查詢的複雜度並防止嵌套過多的查詢來幫助防止不良行為者。

2. GraphQL不安全

GraphQL服務與您提供的服務一樣安全。 需要了解的一件事是GraphQL只是應用程序的一部分； 查詢層。

這是GraphQL的創建者在與Airbnb等其他公司交談以瞭解GraphQL如何在野外使用時重申的一件事。

到Facebook開始使用GraphQL時，他們已經擁有了GraphQL可以容納的完善的安全性和數據獲取層，因此他們沒有發現需要在GraphQL規範中強調這些內容。

他們認為在Facebook擁有的所有層和工具都是顯而易見的，並可供其他開發人員和公司使用。 這使得社區很難就如何在GraphQL應用程序上處理身份驗證和授權達成共識。

好消息是，我們在REST服務中熱愛的許多安全方法和應用程序也可以類似的方式用於保護GraphQL服務。

這是實現安全性的幾種方法（有些與我們已經為REST服務所做的非常相似）

· JSON Web令牌：只需將它們傳遞給標頭即可，就像使用REST服務一樣。

· API密鑰：您可以實現自己的API密鑰系統或通過API網關代理服務以保護應用程序。 Yelp的公共GraphQL API就是一個很好的例子。

· GraphQL指令：可以將GraphQL指令用作攔截器，以解決對圖的各個部分強制執行訪問權限的問題。 通過實現auth指令，Apollo GraphQL就是一個很好的例子。

有關使用指令強制執行訪問權限的更多信息：

在上面的示例中（從Apollo GraphQL的文檔複製而來），您可以看到訪問使用@auth指令由用戶角色控制。 禁用字段只能由ADMIN級別的用戶訪問，而canPost字段只能由具有REVIEWER級別角色的用戶訪問。

3. GraphQL僅適用於移動和Web應用程序

"如果您沒有多個移動和Web客戶端，則沒有理由使用GraphQL。"

GraphQL最初是隨著Facebook進入移動世界而誕生的。 它在前端和全棧環境中得到了廣泛的採用，這使得一些企業架構師可以輕鬆地將其視為前端世界中的假冒趨勢。

沒有什麼可以限制您使用GraphQL進行服務器到服務器的連接。

由於GraphQL服務的豐富開發經驗，一些出色的開發人員已經為現有解決方案構建了GraphQL實現。

這裡有一些例子。

· GraphQL-Kafka-Subscriptions：這是一個庫，使您可以使用GraphQL訂閱查詢主題並將其發佈到Kafka。

· GraphQL-Redis-Subscriptions：訂閱Redis消息代理的接口。

· 重新加入者：來自gRPC微服務的統一GraphQL模式。

4. HTTP / 2將殺死GraphQL

哦耶。 這是一個很大的。 GraphQL的主要賣點之一是它使客戶端能夠在一個HTTP請求中批量和獲取多個資源。 這很吸引人，因為發出HTTP請求非常昂貴。

使用HTTP / 2，可以大大降低建立HTTP連接的成本，因此該賣點的吸引力降低了。

那麼，這是否意味著一旦每個人都開始使用HTTP / 2，GraphQL將變得毫無意義。 我不這麼認為。 即使能夠批量查詢並不是人們使用和喜歡GraphQL的唯一原因。

GraphQL的整個開發人員體驗都很棒。 具有類型化模式和標準語言來查詢API的功能也是開發人員喜歡GraphQL的原因。 如果您想深入瞭解這篇文章，請查看這篇寫得很好的文章。

GraphQL在HTTP2世界中仍然有意義嗎？

GraphQL提供的功能遠不止往返。

我認為，從長遠來看，HTTP / 2實際上將幫助提高GraphQL的功能和效率，而不是消滅它。

結論

GraphQL絕對不是完美的，但我認為在改善開發人員體驗以及我們如何構建產品方面，它可以提供很多幫助。

感謝您閱讀本文，並讓我知道您是否對此有任何想法或遺漏。 保持安全並洗手！

(本文翻譯自William Kwao的文章《GraphQL Myths and Misconceptions》，參考：https://medium.com/better-programming/graphql-myths-and-misconceptions-40d2d6db9b3b)