GraphQL 2021翻訳
この記事は、2021年10月に新しい GraphQL の仕様が公開されたタイミングで書かれた解説記事を Lee Byron氏（@leeb）の許可を得て翻訳した記事になります。
翻訳元記事：GraphQL 2021
翻訳メンバー：sho.oatni, いっせい | TechLead, fukuden, HirosawaTsuyoshi, 宮﨑
本日、GraphQL Foundation によって承認されたGraphQL仕様の初めてのリリースを迎えました。
これは3年間に及ぶ技術的な取り組みと膨大な手続きの集大成です。
これは偉大な瞬間で、称賛に値すべきものです。
時間がかかったのはどうしてなのか？
最後に承認された仕様の公開は3年以上前の2018年6月のことでした。
今回のリリースにはどうして時間がかかったのでしょうか？確かに世界的なパンデミックは私たちが継続して集中することを妨げる要因になりました。
しかしこの数年間で大規模なプロセスの向上があり、特筆すべきはGraphQL Foundationの成立でした。
2018年6月のリリースはFacebookのオープン・ソースプログラムの管理監督の元での最後のリリースでした。
当時、Facebookはその技術全般において、一方的な決定権をもっていました。
これは一部の怒りを引き起こすだけでなく、誰がどのように貢献できるかに影響していました。
Facebookに所属している間、私はGraphQLをMITやOWFa ライセンスに移行することにより、法的な関心を低減することを推し進めていましたが、単独の企業による管理はGraphQLの採択を支援する以上に明確に支障のあるものでした。
2018年に私がFacebookを離れてから、このコントリビューションにおける枠組みによって、私はプロジェクトを進めづらくなっていました。
GraphQL Foundation はGraphQLのオープンで中立的な本拠地として機能し、GraphQLの開発を推進する責務を負っています。
これは口で言うほど簡単ではなく、組織の立ち上げには膨大な量の作業が行われました。
あなたの企業はGraphQLから利益を享受していますか？
ぜひ我々の一員となり、この責務を維持することの手助けをおねがいします！
Githubのアカウントやドメイン、商標権やその他の法的保護はGraphQL Foundationへ移管されました。
GraphQLの仕様策定プロジェクトは、中立的なオーナーシップを保証しつつコントリビュートや利用するための法的な枠組みを提供する Joint Development Foudationに参加しました。
私たちは決定を民主的にするための技術運営委員会(TSC)を立ち上げました。
この新しいコントリビューションの枠組みへの移行は痛みになりました。
また、私たちはたくさんの過去のコントリビューターと新しい合意を結んでいく必要がありました。
私たちは、すべての自動化を支援してくれる Github のボットを準備しました。
とても沢山の人々にGraphQL Foundationの運営やこの新しい開発モデルによるプロジェクトの支援をしていただきましたが、GraphQL Foundation のプログラム・マネージャーであるBrian Warnerの尽力と手引に深く感謝したいと思っています。
GraphQL 2021の新機能は？
2018年6月のリリース以来、35のコントリビューターが細かい明確化から主要な変更まで及ぶ仕様文章への100近くの変更を行ってきました。
これらの変更を掘り下げる前に、GraphQLのユーザーとして、日常業務で新しいことに気付くことはほとんどないということを指摘しておきます。
それは、長年にわたる２段階リリースプロセスのためです。
重要な変更は、まず広くフィードバックを集め、 ワーキングドラフトに入れる前に合意形成をとり、仕様編集者によって承認・マージされるというRFCプロセスを経ます。
多数の変更を積み重ねられたあと、ワーキングドラフトは、のちに批准されたバージョンのリリースとしてGraphQLの技術運営委員会によって承認されました。
ほぼ全てのGraphQLライブラリやツールは、最新のバージョンリリースではなく、ワーキングドラフトを実装しています。
これは、今回のリリースに含まれる全ての新機能を含む、それぞれの新しく承認された機能に素早くアクセスできることを意味します。
とはいえ、ここでカバーできないほど多くの細かい改善や説明があるので、注目に値するいくつかの重要な変更にフォーカスしていきましょう。
カスタムスカラーの仕様
GraphQL は少数の組み込みのスカラー型を提供しており、これらを使って全体の構造を自己定義することができます。
しかし、これらのカスタムスカラーはツールから見るとどういう風に取り扱うべきものなのかがわからないという欠点があります。
ツールの製作者たちは URL や Date といった頻出するカスタムスカラーは適切に取り扱いたいと思っていますが、それにルールに乗っ取った取り扱い方の同意が必要になります。
当初は、私たちは少ないスカラーのルールを直接GraphQLの仕様に定義することを検討しましたが、すぐに問題に直面しました。
概念的にシンプルである一方で、Date型のような詳細部分は驚くほど複雑です！
大量の変動性やトレードオフがISO-8601やRFC-3339のような既存規格の中に見つかり、私たちワーキンググループはGraphQL仕様のルール設定に合意することに苦心しました。
しかもなお悪いことに、この型を「Date」 や「DateTime」の名前で導入しようとしたところ、多くの既存サービスですでにこれらの名前でカスタムスカラーが使用され、私たちが合意したものとは違うルールで使っていることに気づきました。
私たちは、絶対に既存サービスを壊すことをしたくありませんでした。
私たちは、型名だけで(the only way tools)よく知られたカスタムスカラーを識別する必要はないことに気づきました。
代わりに、@specifiedBy(url:)という新しいディレクティブを導入しました。
これによりカスタムスカラーはフォーマットを定義したURLを含むことができ、ツールはよく知られたスカラーの仕様のURLを識別することができ、特定の動作を付与することができます。
違う名前のスカラー(DateやTime)が同じものを解釈されたり、同じ名前のスカラーの多くの実装でも、違う解釈をされることがあります(ISO-8601やユニックスタイムなど)。
最も重要なことは、これらはコミュニティの誰でも定義出来ることです。
詳細は最初の提案(proposal)と仕様書を読んでください。
この変更には多くのコントリビュートがありました。
EvanHuus、Andreas Marek、Matt Farmerには特に支援していただきました。
ディレクティブの順序と繰り返し
GraphQLを導入した当初、私たちは、言語を拡張する方法を提供することが必要だろうと考えました。
GraphQL Directivesは、エコシステム全体のツールであり、型システムのあらゆる側面に、カスタムの動作を追加できます。
それにも関わらず、いくつかの仮定を立てたことで、制約が多すぎることが分かりました。
当初は、私たちは “Directive は一箇所に一つだけしか適用しないこと” を要求していました。
一箇所に複数の Directive が適用されることで、解釈の仕方が一致せずに、予期せぬ動作をしたり、情報を失ったりする可能性を懸念していました。
しかし、このルールを削除しただけでは、私たちが避けようとした問題は発生してしまいます。
この問題を解決するため、一箇所に複数の Directive を適用可能とし、個別でオプト・インできるようにしました。
次の問題は、仕様では Directive の記述された順序が意味を持つのかどうか、明示的に記載されていないことでした。
一部の実装は、内部で Directive を表現するために順序付けされていないデータ構造を使用していましたが、それにより同じソースに対して異なった解釈を引き起こしていました。
また、特定の順序で Directive を記述した一部のケースにおいて、強い制限となることが分かりました。
現在は、この Directive の順序が尊重されることは明白です。
さらに詳しく知りたい場合は、 repeatable proposalとdirective order proposalを参照してください。
最後に、この仕様に深く関わり GraphQL の登場初期に、偉大な貢献をしてくれた オレグ・イリエンコに追悼と感謝の意を捧げます。
中間インターフェース
GraphQLのインターフェースは、スキーマに異なる種類のデータを導入する主要な方法で、一箇所に現れるかも知れない、複数の種類に渡って使用可能なフィールドの共通セットを定義しています。
他の言語では型階層は非常に複雑で強力である一方、GraphQLは複雑な表現力よりシンプルであることを好み、型階層を1段階に制限し軽症をサポートしないことにした。
この制限は常に論争の種になっていた一方、殆どの場合スキーマ作者にはメリットを提供していた(例えば、コネクションなどにおいて)
GraphQLコネクションは、 ページングされたデータへの一般的な慣習で、インターフェースとつなぎ合わせたとき、過度に制限された型システムになり得ます。
マイクはこの問題と解決方法を、自身のブログ記事で素晴らしく深堀り探求している
現状、インターフェースの階層を任意で深くすることができます。
しかしながら、望ましいシンプルさは、継承を制限することで保たれています。
詳細については、最初の提案をお読みください。
この変更を支持してくれたMike Marcacciに多大な感謝を。
パーサーの曖昧さ（多義性）を取り除く
GraphQL は常に仕様に準じた文法によって記述され、それによって GraphQL Query は常にひとつの解釈がなされるようになっています。
文法の曖昧さは多くの言語で発生し、 Greedy maximal munch （貪欲な最長一致）と呼ばれるルールを導入して回避されます。
しかし実際にはこのルールではすべての問題を避けられるわけではありません。
現在の GraphQL もこのルールを採用しています。
同時に「先読みの制限（ lookahead restrictions ）」も利用することで、曖昧さの回避以外にも文法エラーに対してより活用しやすいエラーメッセージを提供できるようなっています。
これに関してはより詳細なブログをシリーズで書きたいと思っていますが、興味がある方は以下のプロポーザルを読んでみてください。
- greedy lexer proposal （貪欲な字句解析機に関するプロポーザル）
- number lookahead proposal （数字の先読みに関するプロポーザル）
- type lookahead proposal （型の先読みに関するプロポーザル）
what's next?
安定した基盤として GraphQL （の仕様）を進化させていくことが私たちのゴールですが、同時に現在 20 に近いプロポーザルが議論されています。
これには エラーレポートの改善 や スキーマのコーディネート 、クエリでの null の扱い、広範囲のユニコードサポート、ユニオンの入力やタグづけされたユニオン、広範囲のコンバリアンスへのサポートの調査などが含まれます。
これらすべての作業はJDFによって定められたコラボレーションルールに同意したコミュニティメンバーの支援によって RFC プロセスに乗っ取り行われます。
また、GraphQL ワーキンググループによるミーティングという公開された場で議論され、詳細な議事録（※）と共に映像も共有されています。
※特にベンジー・ギリアムの協力に感謝します。
最後になりますが、我々の関連するエコシステムに対する活動が健全で中立に運用を続けて行けるように、もしあなたの組織が GraphQL の恩恵を受けているならぜひメンバーになってください
