GraphQL: プロダクションでの教訓

2020年です。あなたの チーム 単一ページのアプリケーションを構築したり、少なくとも通常の複数ページのアプリケーションにリッチなコンポーネントを含める傾向がますます強まっている。[GraphQL](https://graphql.org/)は現在[2年以上前](https://en.wikipedia.org/wiki/GraphQL)である。 JavaScript エコシステムの標準は成熟していると考えられる。私たちは少し冒険的な気分だったので、通常のJSON APIを見送って、すぐに飛び込んだ。

GraphQLサーバーが必要です。

ほとんどのフレームワークでは ウェブ開発JSONのAPIを構築するためのツールはすでにある。ルート構造を構築し、いくつかのGETやPOSTを簡単に受け入れ、JSONレスポンスを出力することができます。Ruby on Railsには特別な プロジェクト 通常のHTMLレンダリンググッズを排除し、APIの強固な基盤をその場所に置くセットアップスイッチ。最新のツールを使えば、熟練した開発者なら文字通り数分でバックエンドを作り上げることができる。

GraphQLはそうではない。のサーバー・ライブラリはあるが たげんごしかし、自分のエコシステムにとって何が正しいかを見極めなければならないだけで、ゲートからすぐにスピード・ペナルティが発生することに変わりはない。もっと個人的なことを言えば、プロジェクトに導入できるライブラリを「サーバー」という言葉で表現するのも好きではない。

終点は一つしかない

何年もの間、私たちはAPIの構造に関する特定の考え方に慣れ親しんできた。最も基本的なレベルでは、単純にRESTのプラクティスに従った。それは、アプリの論理モデルごとに複数のエンドポイントを作成することを意味した。これはAPIの作者にとってもコンシューマーにとっても把握しやすい構造だ。また、バックエンドで適切にスコープされたメソッドを生成し、API構造に関する推論を容易にする。 コード APIそのものと同じくらい簡単だ。 この構造はネームスペースも簡単で、例えば APIのバージョン管理.

GraphQLは単一のエンドポイントのみを採用しており、一般的に /graphql.あなたのAPIへのすべてのリクエストは、そのエンドポイントにPOSTリクエストとして届き、そこからクライアントが何を望んでいるかを把握し、適切に応答するのはGraphQLサーバーの責任です。

JSONAPIのすべてを1つのエンドポイントで行おうとすることを想像してみてほしい！ しかし、APIが成熟し、あるものが他のものに取って代わられるにつれて、それはすぐに意味を持ち始める。古典的なAPIにおける非推奨は、通常名前空間レベルで行われる。 v1 への v2.GraphQLは、単一のフィールドを非推奨にすることまで、はるかに多くの制御を可能にする。REST APIコンシューマーに 名称 フィールドで ファンシーネーム その代わりだ！最初は扱いにくいと感じていたことが、実は最高の機能のひとつであることがわかった。

すべてがタイプされている

JSONには、それほど多くの型があるわけではない。文字列、数値、配列、オブジェクトがある。それ以上は運がない。対照的に、GraphQLではすべてが型に始まり型に終わる。GraphQL DSLはサーバーとクライアントの両方で型チェックを実施し、さまざまな不意打ちを防ぎます。

TypeScriptやFlowのような代替手段を用いるなど、SPAのタイプチェック自体がますます増えているため、これは非常に重要である。 GraphQLは、デフォルト値の上に複雑な型や複合型を導入することを容易にし、バックエンドとフロントエンドの両方の開発者がすぐに自然に使いこなせるようにする。

続きを読む JavaScriptのテスト...Rubyで？

ドキュメントはビルトインされている

古典的なJSON APIでは、ドキュメントは後回しにされることがある。また、そうでない場合でも、選べる方法はたくさんある。例えば オープンAPI?Swaggerのようなツールで人間が読める形に変換するのか？それとも大量のMarkdownファイルをどこかに捨てるのか？この問題は何度も解決されているが、それでもチームの意識的な思考と努力が必要だ。APIに、例えば特定のユーザー・ロールによってのみアクセス可能なセクションがいくつかある場合は、さらに複雑な問題となる。

GraphQLでは、ほとんどのサーバーが型とリクエストをその場で文書化できるため、ドキュメンテーションは第一級市民です。2018年初頭からGraphQL Schema Definition Languageが公式仕様の一部となったため、GraphQL APIを文書化する方法はまさに1つです。また、GraphQLはグラフの特定の部分の可視性を定義することができるので、アクセスすべきでないユーザーは、アクセスできない部分のドキュメントを見ることを自動的に防ぐことができます。このような決定がなされ、明確なガイドラインがあることは、チームにとって大きな恩恵である。

アクションには2種類しかない

HTTPのGET、POST、PUT、PATCH、DELETEとは対照的に、GraphQLには2種類のアクションしかない：クエリーとミューテーションです。主な違いは、ミューテーションはシステムの状態を変更することができ、また変更することができ、クエリーは受動的にデータを読み出すだけだということです。

この件に関しては、まだ迷っていることを認めよう。私は、リソースとやりとりするためのHTTPの動詞の多さを楽しんでいるし、その仕事にぴったりのツールを使うことができる。GraphQLは、HTTPの動詞のどれかが正確にフィットしなかったような毛むくじゃらのケースに対処しやすくしてくれるが、特定の変異が実際に何に影響するのかを考えなければならないというペナルティが発生する。また、組み込みの標準的な命名規則がないため、内部のスタイルガイドを作成するか、一貫性のない混乱を構築するリスクがあるという指摘もできる。

クライアントが必要だ

HTTP経由のREST APIとのやり取りは、バニラのJavaScriptでは非常に簡単ですが、最新の フェッチ API。対照的に、GraphQLでは、本当に適切なパフォーマンスを望むなら、クライアント・ライブラリを使いたい。バニラのJavaScriptだけを使ってGraphQL APIとやりとりすることは不可能ではない。しかし、一般的なAPIコールにリクエストキャッシングのような長年のウェブテクノロジーを使っても、一般的にPOSTリクエストはキャッシュされないため、うまくいかないだろう。

すべての合理的なGraphQLクライアントは、クライアントサイドの結果キャッシュメカニズム、およびその他多くの機能を実装しています。これらすべての選択肢のおかげで、エントリーレベルでGraphQLクライアントの設定をハンドロールすることは完全に呆気ない作業です。GraphQLを使い始める際には、特に以下を参照することをお勧めします。 アポロ・ブースト 非常に合理的なデフォルト設定になっているからだ。

クライアントがデータを選ぶ

APIからデータのリストを取り出したら、関連するモデルに関する重要なフィールドが欠けていた。そしてN+1リクエストを含むハックを実装し、それを素早く追加するバックエンド開発者に不平を言う。よく実装されたGraphQL APIでは、好きなだけデータを深く掘り下げることができるため、通常はそのようなことはない。このバッチの注文の顧客の住所を見たい？少なくとも理論的には問題ない。

複雑さは予見しにくい

バックエンド側からGraphQLを設計する場合、クライアントがグラフを深く掘り下げることを考えるのは難しいかもしれません。グラフの使用状況を計測したり観察したりする方法はたくさんあり、フロントエンドの同僚にしばらく遊ばせておくと、データストアでかなり想像力豊かな読み取りを実行する長いクエリを目にするようになります。REST APIでは、1回のリクエストでアクセスされるデータの範囲を簡単に指定できるので、これをコントロールするのは簡単だ。本番環境にリリースしたとたん、このような複雑さを見逃すことが、しばしばあなたを苦しめることになる。多くの場合、自分で掘ったこの穴から脱出する方法は明らかではない。

番号付きページは本当に難しい

これは本当に皮肉を込めた不満だ。GraphQLがFacebookのためにデザインされたことは、ページネーションメカニズムの仕組みを見れば明らかだ。いわゆるコネクションは、基本的にグラフのエッジのエンドレス・ストリームであり、ナビゲーションは古典的なページの代わりにカーソルを使って行われる。これがフェイスブック流の無限の投稿フィードにどのようにフィットするかは簡単にわかるが、きちんとページ分けされたリストで、例えば42ページ目まで行けるようにしたい場合は、かなり苦労することになる。もちろん、それを回避する方法はあるが、それはあくまで回避策である。

またやりたいか？

上記のような不満や相違点があるため、おそらく私たちはGraphQLを実験として扱い、不味くなったのでそのままREST APIに戻ったと思うだろう。それは真実ではありません。どちらかというと、私たちは組織全体のプロジェクトでGraphQLをより広く使用するよう取り組んでいます。私たちの仕事をより簡単に、より良くしてくれる素晴らしいテクノロジーです。しかし、私たちは当初、どのような成長痛を経験することになるのか完全に理解しないまま、GraphQLに投資しました。

GraphQLが自分に合っているかもしれないと思ったら、思い切って挑戦してみることをお勧めします。十分な時間と安全に失敗する余地を自分に与えれば、いつの間にかその恩恵を享受することができるだろう！

あわせて読みたい：

– リモート開発者を効果的に管理するには？CTOのためのガイド

– PythonとRuby？製品開発にはどちらの技術を使うべきか？

– 独自のマーケットプレイスを構築し、発展させるためのクイックガイド。知っておくべきこととは？