GraphQLGraphQL EU Gatheringからの重要な知見
8/1/2023執筆Jamie Barton
「団結は力なり」という格言が示すように、ベルリンで開催された初のGraphQL EU「アンカンファレンス」は、この信念の証です。この素晴らしいイベントは、活気あるエコシステム内のさまざまな企業やプロバイダー間の多大な協力の結果です。これらの主要なプレーヤー間のパートナーシップは、GraphQL財団のたゆまぬ努力に支えられ、私たちのコミュニティの強さと私たちが育む団結を真に強調しました。
あらゆる方面からのこのような献身は、グローバルなGraphQLコミュニティを成長させ、強化するという私たちのコミットメントを強化します。私たちは、強固なコミュニティは大規模なイベントだけでなく、熱心な参加者や専門家がより親密なレベルで知識やアイデアを交換できるローカルなミートアップや小規模な集まりを通して構築されることを理解しています。
そのために、私たちはGraphQLミートアップを企画することに意欲的なローカルな貢献者を奨励し、支援することに興奮しています。最近のアムステルダムでの集まりは、GraphQLの旅を共有し、互いに学び、ネットワークを広げる活気に満ちた参加者の混合が見られた、成功したローカルイベントの好例です。現在、GraphQL財団の支援により、ローカルレベルでGraphQLコミュニティをまとめたいという熱意と情熱を持つ人なら誰でも、私たちの全面的なサポートを受けることができます。
GraphQL EU#
「アンカンファレンス」形式はオープンな対話を奨励します。それは、すべての参加者が自分のアイデアを表現するためのプラットフォームを提供し、GraphQLでの日常的な経験（成功も課題も）に関する豊かな議論を促進します。
全員が集まり、コーヒーとクロワッサンで元気づけた後（カレーヴルストには少し早すぎましたが）、メインホールに集まりました。
1日#
この日は、すべてのスポンサー（Mirumee Software、The Guild Software、Stellate、Saleor Commerce、Hasura、Escape）からの簡単なプレゼンテーションから始まりました。標準的なスポンサーのスピーチとはかけ離れて、各スピーカーは、後で魅力的な議論で満たされる一日のきっかけとなる、刺激的な経験を伝えました。
スポンサーのプレゼンテーションが終わった後、Van Riperが、その後の行動計画の概要を説明する素晴らしい仕事をし、割り当てられた時間内に進むようにしました。!
各参加者には、議論のトピックを書き留めるためのカードが渡され、その後、それを発表するための20秒間のステージが与えられました。粘着テープの正しい使い方を解読したら、これらのカードはホワイトボードに貼り付けられました。このインタラクティブなアクティビティは、基本的に残りの日のイベントの構成を定めました。
ラウンド1#
トピックを選択して飛び込む時が来ました！！私たちは、集中的なトピックディスカッションのためにホールのセクションに参加するために、約1時間割り当てられました。
さまざまなホワイトボードに提示された多数の主題を考えると、1つだけを選択するのは非常に難しいことでした。
私は、3つの関連するトピックを含むR1/Dの場所での会話に参加することを選択しました。
- GraphQL開発者エクスペリエンスの強化
- GraphQLサーバーの簡素化（ゲートウェイを使用）
- GraphQL開発ツールでの欠落要素の特定
議論は設定された時間制限に従いましたが、間違いなく多くの資料が含まれていました。
この会話から得られた主な結論は、サーバー側とクライアント側の両方でのGraphQL実装のための追加の標準、またはさらに良いことに、詳細な仕様の緊急の必要性でした。開発者は、標準化の欠如のために、異なる言語間で同一のロジックを再適用することがよくあります。これにより、多くの場合、次の言語の基礎として1つの言語を使用することになります。
ただし、元のものからの逸脱がある場合、特に異なるスタックにまたがる多数の言語を扱う開発者にとって、開発者エクスペリエンスに悪影響を与える可能性があります。
仕様を作成することは、複雑なプロセスである必要はなく、有益であるために誰かの認可も必要ありません。数年前、Jayden SericはGraphQLマルチパートリクエスト仕様を導入しました。マルチパートアップロードを実装している人は、そのような単一の仕様によって提供されるガイダンスと洞察に感謝するでしょう。これにより、開発者はアプリケーションの構築と配信のタスクに集中できます。
最初のラウンドの休憩中に、私はUri GoldshteinがBeyond GraphQLグループを指導しているのを見る機会がありました。この興味深い対話では、OpenAPIやgRPCなどの他のツールや標準にGraphQLの概念を統合する方法を探りました。グループはまた、既存の隔たりとこれらの仕様を橋渡しするための潜在的な方法を熟考し、仕事に適したツールを選択できる、より統一された状況を目指しました。
Uriの巧みなモデレーションの下での議論は、自動化によってGraphQLを使用して既存のAPIを再利用する可能性を探るにつれて、エキサイティングな展開を見せました。GraphQL Mesh、Grafbase、SOFA、Hasura、Wundergraphなどの多くの組織やツールがすでにこの領域をナビゲートしています。彼らは、オープンソースプロジェクトを通じてこの進化するドメインに貢献することに関心のある人の参加を歓迎し、感謝しています。
Uriは結論として、「GraphQLエコシステム内での議論が「GraphQL対REST」の議論を超えて進化する時が来ました。代わりに、GraphQLの堅牢な機能を他の既存のAPIを強化するためにどのように適用できるかに焦点を当てる必要があります」と強調しました。
ラウンド2#
次に出席する議論を選ぶのは非常に難しい仕事であることが判明し、私が認めたくないほど長い間トピックカードのボードを見つめることになりました。私は次のトピックの間で板挟みになりました。
- Relay
- 実践におけるフェデレーション/GraphQL APIの結合と拡張
私の日々の役割は、開発者がGrafbaseを使用してGraphQL APIを拡張するのを支援することであるため、このトピックに強く惹かれました。しかし、私の直感と、Relayに対する目に見える成長しているサポートが、最終的に私の決断を導きました。
Denis Badurina、Marion Schleifer、Stephan Schneider、その他のRelayの経験について聞くことは啓発的でした。
私はグループに、Relayとの最後の出会いから数年経っていることを率直に認めましたが（正直に言うと、完全に成功したわけではありませんでした）、現在の使用パターンを理解し、開発者がRelayを最初の選択肢として選択しないことがよくある理由に関して、GraphQLの旅で出会ったいくつかの物語を共有したいと思っていました。
セッションが終わりに近づくにつれて、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からの重要な知見#
すべての会話に参加できたわけではありませんが、アフターパーティー、さらにはアフターアフターパーティーの間にも、無数のトピックが議論されたことは間違いありません。
以下は、一日を通してNotes Appに書き留めた主な知見です。
- その初期の複雑さとパラダイムシフトにもかかわらず、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コミュニティを豊かにしてください。
サンフランシスコでお会いしましょう!