GraphQL"はApollo社が公開しているGraphQL開発のベストプラクティス集です。principledgraphql.com背景として、近年のアプリケーション開発では「データグラフ」が重要になってきているとしています。GraphQLを通じて、ある企業のすべてのアプリのデータとサービスとを統合してデータグラフとして提供することで、クライアントとしてのアプリケーションから効率よく簡単にサービスを使うことができるようになります。GraphQLはクエリ言語というより、クライアントとサービス間の接続を担う包括的なソリューションなので、いろいろと考えるべきことも多く、GraphQL開発の統合環境を提供していて経験豊富なApolloがベストプラクティスをまとめた、というところのようです。実際のところ最近GraphQLを触っていないのですが、ざっくり読んでみました。App"に影響を受けていて、各項目では守るべき原則を表す簡潔なタイトルとリード文に続いて、具体的な説明が載る構成。GraphQL"は10箇条であり、次の3件にカテゴリ分けされている。APIなどをApolloプロダクトでデータグラフとして統合すべき、という意図と読める。Federationでバックエンドの違いは吸収できる。Graph"と表裏一体の関係にあるような原則。registryのこと。知らなかったが便利そう。Schemaスキーマとサービス/クライアントを疎結合にして、実装を隠して柔軟に利用できる抽象層として扱うdemand-orientedで開発する既存のグラフで機能開発しているアプリ開発者の開発者体験(DX)を高められるようなスキーマとするインタフェースを設けることでバックエンドのアーキテクチャ変更も理論的には可能になるというのはソフトウェアエンジニアリングで頻出なので、もはや一般的な原則という感じもする。Development実際の要求に基づいてインクリメンタルにスキーマは開発していく定期的なバージョニングより必要なときにリリースするスキーマにバージョンをつけて半年ごとに公開するよりは、必要なときに頻繁にリリースいつでも新規フィールドを追加する。registryを使って変更の影響をつねに確認できるようにしておくのも効果的Apolloだと@deprecatedディレクティブがある。Performanceグラフ利用者がどのように使おうとしているかをAPI開発者は知るべき実際に送られる形のクエリのパフォーマンス改善をすべき本番ではパフォーマンスを継続的に監視するGraphQLはエンドポイントが一つで従来のAPMが使いづらいので、パフォーマンス監視のために後述するtracerがあったほうがよさそう。型のついたスキーマを使うと補完が捗りそうというのは容易に想像がつく。GraphQLはクエリのコストを気にする必要があるので、そこへの対策もここで入ってくる。APIを公開するときはもちろん、内部的なAPIとして使うときも意図せずクエリのコストが高くなることはあるだろうと考えられるので、とにかく実行されるクエリの管理やコストの事前計測が大事そう。Gatewayのような役割。FederationにおけるGatewayがここで述べられている層の役割の一部を担っている。感想スキーマの活用が便利というのはもちろんのこと、クエリのコストについてさまざまな方法で十分な注意を払うべきという主張がなされているのは興味深かったです。原則を示しつつ、Apolloがそれに対応するツールを用意しているところが強いなという印象でした。興味があるかたは読んでみてください。1.8で使うための方法これの続きです。APIが導入されました。引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。