時間退回到 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-dotnethttps://github.com/graphql-dotnet/graphql-dotnetstars: 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 不一樣的是, 它有出色的資料聚合能力和查詢能力, 在處理複雜的頁面以及需求快速迭代的場景時, 不過是探囊取物。
更多內容，關注公眾號【全球技術精選】
