您可能不需要 GraphQL！當您從一家 GraphQL 公司的聯合創始人那裡讀到這句話時，您可能會感到驚訝。
為什麼您可能不需要 GraphQL
2015 年（將近十年前！），Facebook 釋出 GraphQL 後不久，GraphQL 就被炒得沸沸揚揚，因為它可以構建型別安全的 API，而且比其他任何 API 都具有更好的開發人員體驗。各種各樣的人都採用了它，包括
- 擁有小型團隊的早期創業公司
- 打造 MVP 的獨立駭客
- 構建無使用者介面產品的公司
- 進行服務間通訊的微服務團隊
- 甚至是作為查詢語言的資料庫引擎團隊
但 GraphQL 並不是為這些用例而設計的。
Facebook 發明 GraphQL 的初衷是將其作為眾多面向終端使用者的客戶端與眾多資料來源之間的核心中介層。他們開發了一種新語言（因此也開發了工具鏈），使其能夠跨不同語言編寫的微服務工作。
這使得它成為解決 "我希望客戶端資料訪問是型別安全的 "這一問題的重型解決方案。不可避免的是，針對這些用例出現了更好的解決方案（如 tRPC），其採用率超過了 GraphQL。而且，隨著 React 伺服器元件的出現，這些用例中的許多又將得到進一步簡化。
那麼，誰需要 GraphQL 呢？
回答 "誰需要 GraphQL？"的困難在於 GraphQL 可以解決許多不同的問題。當你與兩個使用 GraphQL 的人交談時，你不可避免地會得到兩種不同的答案，即他們為什麼使用 GraphQL？
不僅如此，GraphQL 並不能明顯地解決所有這些不同的問題；當你使用 GraphQL 時，許多問題就會......消失。這就很難讓人意識到 GraphQL 解決了這些問題，因為你 "必須親身經歷過"，才能發現哪些問題悄然消失了。
我知道：作為經營 GraphQL 公司工作的一部分，我在過去三年中與數百家公司的數千名工程師討論了他們的 API，尤其是使用 GraphQL 構建的 API。
讓我總結一下他們告訴我 GraphQL 為他們解決了哪些問題，以及 GraphQL 是如何做到的。
GraphQL 解決的問題
1.移動應用程式在 API 更改後會定期中斷
GraphQL 只返回客戶端明確請求的欄位，因此可以透過新增新型別或欄位來增加新功能，而這對現有客戶端來說絕不會造成中斷。
此外，您還可以監控哪些客戶正在使用哪些欄位，因為他們必須準確指定他們需要的資料。
2.請求瀑布和/或過度抓取導致載入時間緩慢
使用 GraphQL，客戶端只需傳送一個請求，就能獲得渲染整個頁面/檢視所需的所有資料，伺服器會解析所有資料，並在一個響應中傳送回來，而不會出現 BFF 帶來的重複。(客戶端甚至可以使用 @defer 和 @stream 指令要求伺服器首先流式傳輸摺疊資料）。
3.由於存在數百個重複的一次性端點，維護和端點發現非常困難
GraphQL 集中了每個實體/資源的資料訪問。當底層微服務或資料庫更改其資料管理方式時，只需將更改應用到 API 層中的單箇中心位置，而無需更新許多端點或 BFF。
更進一步，GraphQL 使客戶能夠透過片段在元件級別上指定他們的資料需求。(例如，UserAvatar 元件可以抽象地指定它需要 UserType.avatarUrl）因此，即使在客戶端，變更也必須只應用於與變更相關的特定元件！
4.安全和效能是一場 "打地鼠 "遊戲
GraphQL 是客戶端的中心資料訪問層，因此您可以根據需要在儘可能精細的級別上執行安全和效能 SLA。與 REST API 的每個端點類似，您可以在 GraphQL 中對每個操作執行限制，但也可以更精細地對每個型別甚至每個欄位進行限制。
如果您的公司遇到上述問題中的一個（或多個！），請考慮將 GraphQL 新增到您的堆疊中。
如果您現在還沒有遇到這些問題，您可能會問："我什麼時候會遇到這些問題？答案是很難預測，因為這取決於您的具體用例。有些公司在擁有 50 名工程師和數百萬使用者的情況下，並沒有遇到這些問題。還有一些公司在構建 MVP 時遇到了多個問題。
根據我的經驗提供一些指導：最遲當你有 100 多名工程師時，你很可能會遇到上述問題中的至少一個。
這就是為什麼我的推文的大多數回覆者都是對的：他們可能並不需要 GraphQL。
但有一點是肯定的：只要你遇到這些問題中的任何一個，GraphQL 都會為你解決。