GraphQL 起源

時間退回到 2012年的一個下午, 美國加利福尼亞州, facebook 的工程師們發現他們才上架沒多久的移動端應用就收到了很多差評, 用戶反映app響應慢，耗電嚴重等，經過分析后發現, 應用在第一次啟動時, 會請求大量的后端api接口, 這其中包括用戶自己的信息, 好友發布的內容, 以及其他的熱點信息, 等等。太多的 rest api 請求, 這就是問題所在。

facebook 的工程師就開始思考如何才能解決這個問題, 在經過大量的技術討論之后, 他們想出了一個好方法, 和 rest api 對應的是一個個 endpoint, 能不能整合這些 endpoint 變成一個整體輸出到前端呢?

他們這樣做了, 并且很好用, 這項技術在 facebook 內部沉淀了三年, 在2015年, facebook 公開發布了 GraphQL。

到今天, 整個 GraphQL 生態系統、社區都已經非常成熟, 主流的開發語言按照 GraphQL 規范提供了實現, 并且有豐富的工具支持, Banana Cake Pop、GraphQL Playground 等。Github, Facebook 等公司都在生產環境使用了 GraphQL。

GraphQL 全稱是 Graph Query Language，是一種查詢語言, 像SQL, LINQ 都是常見的查詢語言, 靈活且強大的查詢功能是它的主要特點, 對于處理復雜的頁面展示, 功能頻繁變更, 這些都是 GraphQL 的強項, 為開發人員提供了極大的便利。

查詢能力

向后端 API 發送 GraphQL 查詢，它會準確的返回所需要的內容, 不多也不少！

聚合能力

在 rest api 上獲取多個資源時, 通常要進行多次url請求, 而使用 GraphQL 的查詢功能, 一次請求就可以獲取多個資源, 這正是 GraphQL 的數據聚合能力。

? GraphQL 的缺點?

當然 GraphQL 并不是完美的, 它也有一些缺點。

?查詢深度限制?因為 GraphQL 支持關聯查詢, 當你有一個樹結構時，你可能要考慮限制查詢深度, 防止過度遞歸帶來的問題。
?文件上傳?上傳文件對于 GraphQL 確實是個大難題, 規范中并沒有提到這個, 一種方式是一些 GraphQL 的庫自己實現了上傳功能，另一個方法就是用單獨的程序使用Http的方式提供上傳功能。
?緩存?和 rest api 相比, 由于 GraphQL 的查詢功能很靈活, 動態查詢, 不是固定的資源, 所以它的緩存不太好做。

GraphQL for .NET

??

如果要在.NET 平臺上使用 GraphQL, 下面是最流行的兩個庫, 你可以嘗試使用它

?graphql-dotnet
https://github.com/graphql-dotnet/graphql-dotnet
stars: 5k commits: 1600+ contributors: 140+

?hot chocolate
https://github.com/ChilliCream/hotchocolate?stars: 3k commits: 2200+ contributors: 140+

我個人比較喜歡用 hot chocolate, 上手簡單, 工具也很多, 而且有意思的都是以甜品命名的, 熱可可（GraphQL Server, 草莓奶昔（GraphQL Client）, 綠色甜甜圈（DataLoader）, 香蕉蛋糕（GraphQL IDE）。

總結

GraphQL 起初是為移動應用構建的, 和 rest api 不一樣的是, 它有出色的數據聚合能力和查詢能力, 在處理復雜的頁面以及需求快速迭代的場景時, 不過是探囊取物。?

總結

以上是生活随笔為你收集整理的GraphQL 到底有什么魔力？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。