在目前的公司裡，後端 API 是使用 GraphQL 來設計的，因此我開始學習這項技術，並決定記錄這段學習的歷程和心得。在這系列文章中，我會介紹 GraphQL 的技術細節、設計理念，並分享一些實際使用的經驗和踩雷心得。
GraphQL 簡介
GraphQL 是一種專為 API 設計的資料查詢和修改語言，讓前端能夠以更直覺且彈性的語法來獲取或修改資料。這項技術由 Facebook 在 2012 年開始使用，主要為了支援跨裝置的 News Feed 功能開發。2015 年，Facebook 將其公開，讓更多人能夠享受其便利。
大致上，GraphQL 的運作方式有點像 SQL，使用者可以透過定義好的語法來取得所需的資料（類似 SELECT），或修改資料（類似 CREATE、UPDATE）。但 GraphQL 主要用於應用服務之間的溝通，尤其是前後端之間的交互，是一種新型態的 RESTful API，但具備更多強大功能。
為什麼選擇 GraphQL？
近年來，GraphQL 受到許多知名企業如 Github、Shopify、Coursera 和 Twitter 的青睞，我認為這主要有三個原因:
- 行動裝置普及：
資料傳遞速度影響效能，不同平台所需的資料數量和格式各異。 - Domain Knowledge & Business Logic
越來越複雜 Schema 設計日趨複雜，前後端溝通難度增加，Legacy API 難以處理。 - Microservice 崛起
需要一個統一的介面來整合不同服務，而 GraphQL 正好解決了這些問題。
GraphQL 的優缺點
優點：
- 精準資料取得：
宣告式資料索取，資料取得彈性高，大幅減少 request 次數。 - 程式即文檔：
前後端溝通成本降低，文檔生成幾乎無需額外成本。 - 前端控制權提升：
前端可以自行決定資料的格式和方式，開發速度加快。 - 高度自由的實作方式：
不預設綁定任何程式語言或資料庫，支持 Schema stitching。 - 強型別：
型別錯誤會被立即擋下，支援自定義型別。 - 一次性請求：
一次請求即可取得多個資料，減少 request 次數。
缺點：
- 過於自由、規範少：
實作規範不一，可能導致設計過於複雜的 Schema。 - 學習成本:
GraphQL 雖然不難，但應用到整個架構需要時間和精力。 - 仍在發展中：
需要密切注意技術更新，避免突如其來的 breaking change。 - Server Side Caching 實作困難
GraphQL 難以保證每次 request 的模樣， caching 比較難以實作。
小結
GraphQL的實務應用日益增多，許多公司正在探索如何更有效地利用這一技術。同時，開源社群，特別是Apollo，也在不斷地推動GraphQL的發展和改進。隨著技術的成熟，GraphQL可能會成為未來數據交互的標準。
總結來說，GraphQL代表了一種對於API設計的重大創新，它提供了一種更靈活、更高效的數據查詢方式。隨著技術的不斷發展和應用的擴展，GraphQL有望成為推動現代應用開發的重要力量。
Github有公開 GraphQL API，有興趣的可以到這邊玩玩 Playground。
