GraphQLGraphQL EU 聚會的主要見解
2023/8/1 by Jamie Barton
俗話說，團結就是力量。在柏林舉辦的 GraphQL EU「非會議」，證明了這項信念。這場非凡的活動是我們充滿活力的生態系統中，各家公司和供應商之間廣泛合作的成果。這些主要參與者之間的合作夥伴關係，在 GraphQL 基金會 的不懈努力下，真正突顯了我們社群的力量和我們所培養的團結。
來自各方的奉獻精神，強化了我們對發展和壯大全球 GraphQL 社群的承諾。我們了解到，一個強健的社群並非僅建立於盛大的活動，而是透過在地的聚會和小型聚會，讓愛好者和專家在更親密的層面上交流知識和想法。
為此，我們鼓勵並熱衷於支持渴望組織 GraphQL 聚會的在地貢獻者。一個成功的在地活動的閃亮範例是最近在阿姆斯特丹舉行的聚會，參與者熱烈分享他們的 GraphQL 旅程，彼此學習，並擴展他們的網路。現在，在 GraphQL 基金會的支持下，任何懷抱熱情和熱忱，想在在地層級凝聚 GraphQL 社群的人，都能獲得我們的全力支持。
GraphQL EU#
「非會議」形式鼓勵開放對話；它提供一個平台讓所有參與者表達他們的想法，促進關於他們在 GraphQL 中的日常經驗的豐富討論，包括勝利和挑戰。
在大家聚集並用咖啡和可頌提神後（吃咖哩香腸還太早），我們開始在主廳集合。
當天#
當天以所有贊助商的簡短簡報開始 - Mirumee Software、The Guild Software、Stellate、Saleor Commerce、Hasura、Escape。每位講者傳達的不是標準的贊助商演講，而是一種鼓舞人心的體驗，後來激發了一整天充滿吸引人的討論。
在贊助商簡報結束後，Van Riper出色地概述了後續的行動計畫，確保我們遵守分配的時間表！
每位參與者都收到一張卡片來記下他們的討論主題，然後在台上有一個 20 秒的時間來展示它。一旦我們解碼了膠帶的正確用法，這些卡片就被貼在白板上。這種互動活動基本上奠定了當天剩餘活動的結構。
第一輪#
現在是選擇一個主題並深入探討的時候了！我們分配了大約一小時的時間加入大廳的一部分進行深入的主題討論。
由於在各種白板上呈現了大量的科目，因此僅選擇一個就構成了相當大的挑戰。
我選擇參與在位置R1/D的對話，其中包含三個相關的主題
- 提升 GraphQL 開發人員體驗
- 簡化 GraphQL 伺服器（透過閘道器）
- 找出 GraphQL 開發人員工具中缺少的元素
儘管討論遵守設定的時間限制，但無疑包含豐富的資料。
從這次對話中得出的主要結論是迫切需要更多標準，甚至更好的詳細規格，用於伺服器和用戶端上的 GraphQL 實作。由於缺乏標準化，開發人員經常發現自己在不同的語言中重新套用相同的邏輯。這通常導致使用一種語言作為下一種語言的基礎。
但是，如果偏離原始語言，可能會對開發人員體驗產生負面影響，特別是對於跨不同堆疊使用多種語言的人員。
建立規格不必是一個複雜的過程，也不需要任何人的制裁才能受益。幾年前，Jayden Seric 介紹了 GraphQL 多部分請求規格。任何正在實作多部分上傳的人員都會欣賞此類單一規格提供的指導和見解，讓開發人員可以專注於建置和傳遞其應用程式的任務。
在第一輪的中場休息時間，我有機會觀察 Uri Goldshtein 指導 Beyond GraphQL 小組。這場引人入勝的對話探討了如何將 GraphQL 的概念與其他工具和標準整合，包括 OpenAPI 和 gRPC。該小組還思考了現有的分歧以及橋接這些規格的潛在方法，目標是建立一個更統一的環境，可以在其中選擇適當的工具來執行工作。
在 Uri 巧妙的主持下，討論出現令人興奮的轉折，因為他們探討了使用自動化手段重新利用現有 API 的 GraphQL 潛力。許多組織和工具，例如 GraphQL Mesh、Grafbase、SOFA、Hasura 和 Wundergraph，已經在探索這些領域。他們歡迎並感謝任何有興趣透過開源專案為這個不斷演進的領域做出貢獻的人員參與。
在結論中，Uri 強調：「現在是時候讓 GraphQL 生態系統中的討論超越『GraphQL 與 REST』的爭論。相反地，我們應該專注於如何應用 GraphQL 的強大功能來豐富其他現有 API。」
第二輪#
選擇要參加的下一個討論被證明是一項相當困難的任務，我盯著主題卡板的時間比我願意承認的還要長。我在以下主題之間猶豫不決
- Relay
- 實務中的聯合/組合和擴充 GraphQL API
由於我日常的工作角色涉及指導和協助開發人員使用 Grafbase 來擴充 GraphQL API，因此我強烈傾向於這個主題。然而，我的直覺加上對 Relay 明顯增長的支援，最終引導了我的決定。
聽取 Denis Badurina、Marion Schleifer、Stephan Schneider 等人分享他們使用 Relay 的經驗，令人大開眼界。
我公開向小組承認，自上次接觸 Relay（坦白說，那次接觸並不完全成功）以來已經過了幾年，但我渴望了解目前的用法模式，並分享我在 GraphQL 歷程中遇到的部分敘述，說明為什麼開發人員通常不會選擇 Relay 作為他們的首選。
隨著會議接近尾聲，顯然有一些常見的原因導致 Relay 沒有成為開發人員的首選
- 一個感知到的陡峭學習曲線，主要是源於圍繞組件和資料依賴性的心智模型轉變。
- 設定編譯器組態經常是一項繁瑣的任務。
有趣的是，那些確實使用 Relay 的開發人員確實非常喜歡它！
第 3 輪#
隨著一天接近尾聲，是時候選擇一個有可能在晚間接待飲料期間引發對話的主題了。我必須說，我肯定選擇了這樣的題目！
在 R3/C 的主題圍繞著 TRPC 和 RSC 時代的 GraphQL 角色。我讚揚 Bogdan 提出如此有爭議性的話題的膽量。但話說回來，我們是在一個 GraphQL 活動中，所以反應不會像在推文中出現這個話題時那樣激烈。
所有參與者都有機會表達他們的意見，並解釋為什麼這個話題引起了如此多的爭議。 Uri Goldshtein 介紹了社群中一些令人印象深刻的開源專案，特別是 Garph/GQty，它們旨在縮小差距並簡化為端到端類型安全性產生類型的程序。
React 的無所不在不是什麼秘密。它的採用率正在全面激增，這一趨勢進一步被 Next.js 在生態系統中發揮的重大影響所放大。
眾所周知，Next.js 和 RSC 的崛起引起了許多疑慮和問題，並在社群推動其執行時期實作「React Server Components」時遇到了一些挑戰。我相信 GraphQL 也處於十字路口，試圖在這個不斷演進的 React 生態系統中找出其理想的定位。
然而，至關重要的是要記住，儘管 React 和 Next.js 是普遍的選擇，但還有許多其他語言和架構可以利用 GraphQL。作為一個社群，我們有時會忽略這些替代方案。
如果您尚未使用 Houdini GraphQL 和 Svelte，那麼您將會大飽口福。Houdini 提供了一個令人耳目一新的方法來建構由 GraphQL 驅動的類型安全 Web 應用程式。
總體而言，GraphQL 似乎持續擴展，但其應用程式正在轉變。建構 Web 和行動應用程式的開發人員似乎正在轉向更簡單的路由機制，例如 Tanstack 和 React Router，並結合 Relay 進行客戶端資料載入和快取。
GraphQL EU 的主要見解#
儘管我無法參與每一場對話，但在迎賓派對，甚至迎賓派對之後，無疑討論了許多主題。
以下是當天我在「備忘錄」應用程式中記下的主要見解
- 儘管最初的複雜性和典範轉移，Relay 正越來越受到具有更多 GraphQL 經驗的人採用，特別是因為它能夠將片段與其各自的元件並置。
- 雖然 tRPC 很吸引人，但並非所有公司都能完全控制其技術堆疊，並依賴外部 GraphQL API。因此，更多開發人員正在利用閘道或聯合方法來整合這些 API。
- 確保 GraphQL API 沒有版本對於行動應用程式的順利運作至關重要，因為使用者經常會延遲更新他們的應用程式。
- 對於 SPA 或行動應用程式，在客戶端擷取資料較為理想，GraphQL 仍然提供較佳的體驗。React Server Components (RSC)，特別是與 Next.js 搭配使用，並未提供太多 GraphQL 的應用範圍，這是可以接受的。
- 對於伺服器渲染的應用程式，GraphQL 仍然是一個可行的選擇。它可以作為一個簡單的函式或網路呼叫，比必須安裝多個 SDK 更有效率地促進與多個 API 的整合。
GraphQL 的下一步是什麼？#
儘管這項活動意義重大，但我們已準備好透過 9 月 19 日至 21 日在舊金山舉行的官方 GraphQL Conf 超越它。如果您認為這項活動很有見解，我保證即將舉行的會議將會是改變遊戲規則的活動！
您不會想錯過，所以快點搶票吧！我期待在會議上看到許多熟悉的面孔並認識新朋友。
參與#
儘管上述的反思概括了我的旅程，但我鼓勵您將您獨特的經驗貢獻給我們的集體敘事。 在 Discord 上與我們聯繫，並透過您的見解豐富 GraphQL 社群。
舊金山見！