GraphQLGraphQL EU 聚会关键见解
2023 年 8 月 1 日 由 Jamie Barton 撰写
正如谚语所说，团结就是力量。在柏林举行的首届 GraphQL EU “非正式会议” 就是对这一信念的证明。这场非凡的活动是我们在充满活力的生态系统中，众多公司和提供商之间紧密合作的结果。这些关键参与者之间的合作，在 GraphQL 基金会的辛勤努力的支持下，真正突出了我们社区的力量以及我们培养的团结精神。
来自各方的这种奉献精神，加强了我们对发展和壮大全球 GraphQL 社区的承诺。我们明白，一个强大的社区并非仅仅建立在大型活动的基础上，而是通过本地聚会和小型聚会，让爱好者和专家能够在更私密的层面上交流知识和想法。
为此，我们鼓励并很高兴支持渴望组织 GraphQL 聚会的本地贡献者。最近在阿姆斯特丹举行的聚会就是一个成功的本地活动的典范，它吸引了来自各行各业的参与者，他们分享了各自的 GraphQL 之旅，相互学习，并扩展了人脉。现在，在 GraphQL 基金会的支持下，任何有热情和激情将 GraphQL 社区聚集到本地的人，都可以得到我们的全力支持。
GraphQL EU#
“非正式会议” 格式鼓励开放式对话；它为所有参与者提供了一个表达他们想法的平台，促进了关于他们日常使用 GraphQL 的经验（包括胜利和挑战）的丰富讨论。
在大家聚齐并用咖啡和羊角面包（当时吃咖喱香肠还太早）振奋精神后，我们便前往主厅。
当天#
当天首先由所有赞助商进行简短的介绍 - Mirumee 软件、The Guild 软件、Stellate、Saleor 商业、Hasura、Escape。这些演讲远非标准的赞助商演讲，每位演讲者都分享了鼓舞人心的经历，这些经历后来引发了一整天充满吸引力的讨论。
赞助商演讲结束后，Van Riper出色地概述了后续行动计划，确保我们按计划时间表进行！
每位参与者都收到了一张卡片，用来记下他们的讨论主题，然后在舞台上获得 20 秒的时间来展示它。一旦我们弄清楚了胶带的正确使用方法，这些卡片就被贴在了白板上。这个互动活动基本上为当天剩余活动的结构奠定了基础。
第一轮#
选择一个主题并深入研究的时刻到了！我们被分配了大约一个小时的时间加入大厅的一个区域，进行深入的主题讨论。
鉴于白板上展示了众多主题，仅仅选择一个主题就颇具挑战性。
我选择参加 R1/D 位置的对话，它涵盖了三个相关主题
- 增强 GraphQL 开发者体验
- 简化 GraphQL 服务器（使用网关）
- 识别 GraphQL 开发者工具中缺失的元素
尽管讨论遵守了设定的时间限制，但它无疑包含了大量内容。
从这次对话中得出的主要结论是，迫切需要额外的标准，或者更确切地说，是关于 GraphQL 在服务器端和客户端实现的详细规范。由于缺乏标准化，开发人员经常发现自己需要在不同的语言中重复应用相同的逻辑。这通常会导致使用一种语言作为另一种语言的基础。
但是，如果与原始版本存在偏差，可能会对开发者体验产生负面影响，特别是对于那些在不同堆栈中使用多种语言的开发者而言。
创建规范并不需要是一个复杂的过程，也不需要任何人的批准才能发挥作用。几年前，Jayden Seric 引入了 GraphQL 多部分请求规范。任何正在实现多部分上传的人都会感谢这种单一规范提供的指导和见解，使开发人员能够专注于构建和交付应用程序的任务。
在第一轮的中场休息期间，我有机会观察 Uri Goldshtein 指导 Beyond GraphQL 小组。这场引人入胜的对话探讨了如何将 GraphQL 的概念与其他工具和标准（包括 OpenAPI 和 gRPC）集成。该小组还思考了现有的分歧以及弥合这些规范的潜在方法，旨在创建一个更加统一的景观，以便为工作选择合适的工具。
在 Uri 娴熟的调解下，讨论出现了令人兴奋的转变，他们探究了通过自动化使用 GraphQL 重用现有 API 的可能性。许多组织和工具，如 GraphQL Mesh、Grafbase、SOFA、Hasura 和 Wundergraph，已经在探索这些领域。他们邀请并感谢任何有兴趣通过开源项目为这个不断发展的领域做出贡献的人参与进来。
Uri 在总结发言中强调：“GraphQL 生态系统内部的讨论已经到了超越‘GraphQL vs. REST’辩论的时候了。相反，我们应该专注于如何应用 GraphQL 的强大功能来丰富其他现有的 API。”
第二轮#
选择下一个要参加的讨论证明是一项相当困难的任务，我盯着一个话题卡片板的时间比我想承认的要长。我在这几个话题之间犹豫不决：
- Relay
- 实践中的联邦 / 结合和扩展 GraphQL API
鉴于我日常工作中涉及指导和协助开发人员在使用 Grafbase 扩展 GraphQL API 方面取得卓越成就，我强烈倾向于这个话题。然而，我的直觉，加上对 Relay 明显增长的支持，最终引导了我的决定。
听到 Denis Badurina、Marion Schleifer、Stephan Schneider 以及其他人分享他们使用 Relay 的经验，真是大开眼界。
我坦率地向小组承认，自从我上次接触 Relay（坦白地说，那次并不完全成功）以来已经好几年了，但我渴望了解当前的使用模式，并分享我在 GraphQL 之旅中遇到的关于为什么开发人员通常不会选择 Relay 作为首选的一些叙述。
随着会议接近尾声，很明显，Relay 不是开发人员首选的原因有一些共同点：
- 感知到的陡峭学习曲线，主要源于围绕组件和数据依赖关系的心理模型转变。
- 设置编译器配置通常是一项繁琐的任务。
有趣的是，那些确实使用 Relay 的开发人员确实非常喜欢它！
第三轮#
随着一天接近尾声，是时候选择一个可能在晚上的招待酒会上引发讨论的话题了。我必须说，我确实选择了这样一个话题！
R3/C 的主题围绕着GraphQL 在 TRPC 和 RSC 时代的角色。我赞扬 Bogdan 大胆地提出了这样一个有争议的话题。但话说回来，我们是在一个 GraphQL 活动中，所以反应不会像在推特上出现这个话题时那样激烈。
所有参与者都有机会表达自己的意见，并解释为什么这个话题引起了如此多的争议。 Uri Goldshtein 介绍了社区中一些令人印象深刻的开源项目，特别是 Garph/GQty，它们旨在缩小差距，简化生成类型以实现端到端类型安全的流程。
React 的无处不在不是秘密。它的采用正在全面激增，这一趋势因 Next.js 在生态系统中产生的重大影响而进一步放大。
众所周知，Next.js 和 RSC 的兴起引发了许多担忧和问题，并遇到了一些挑战，因为它通过其对 **React 服务器组件** 的运行时实现推动着社区前进。我相信 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 服务器组件 (RSC)，尤其是与 Next.js 结合使用，并没有为 GraphQL 提供太多范围，这是可以接受的。
- 对于服务器端渲染的应用程序，GraphQL 仍然是一个可行的选择。作为一个简单的函数或网络调用，它可以比安装多个 SDK 更有效地促进与多个 API 的集成。
GraphQL 的下一步是什么？#
尽管这次活动意义重大，但我们将在 9 月 19 日至 21 日在旧金山举行的官方 GraphQL Conf 上超越它。如果你认为这次活动很有见地，我保证即将到来的会议将改变游戏规则！
不要错过，快来抢票吧！期待在大会上见到许多熟悉的面孔，也期待结识新朋友。
参与进来#
虽然以上反思概括了我的旅程，但我鼓励您将您独特的经历贡献到我们的集体叙事中。 加入我们的 Discord，用您的见解丰富 GraphQL 社区。
在旧金山见！