GraphQL：それはREST API「キラー」なのか？

ParseにGraphQLサポートが実装された後、多くの人が私にいくつかの質問を投げかけてきましたが、その中にはREST APIの将来について心配している人もいました。
GraphQLはREST APIを “殺して “しまうのか？
私のREST APIメソッドはどうなるのか？コードを書き直す必要があるのか？

この記事ではこれらの疑問について取り上げますが、簡単に答えると、GraphQLはREST APIを「殺す」ものではないので、心配する必要はありませんし、すでに動作しているREST APIメソッドを書き換える心配もありません。

では、GraphQLの何が問題なのでしょうか？

私のところに来るほとんどの人が抱く誤解のひとつは、GraphQLはバックエンド全体を置き換えるものではないということだ。

GraphQLはバックエンドを置き換えるものではない。フロントエンドを置き換えるものでもない。

GraphQLはクエリ言語であり、APIに対してどのような情報を探しているかを指定する方法であり、既存のデータからその情報を取得するランタイムである。

これは、アプリに必要な情報を正確に伝え、その情報を受け取るための別の方法（より良い方法と言えるかもしれない）だ。

すでに存在し、機能しているREST APIメソッドについて心配する必要はない。GraphQLを採用しても、それらは今と同じように機能し続ける。唯一注意しなければならないのは、GraphQLはParse 3.5.0以降でしか動作しないため、Parse 2.xまたはそれ以前のバージョンを使用している場合は、Parseのコード構造が変更されることになります。

ですから、Parse 3.0以上をお使いの方は、まったく心配する必要はありません。3.5.0以上のバージョンを選べば大丈夫です。
Parse 2.Xを使っている場合は、コーディングの手直しが必要になります。

REST APIがすでに動作しているのに、なぜGraphQLなのか？

この質問もよく出てきますが、REST APIよりもGraphQLを選ぶにはいくつかの重要な利点があると思います。

短期的に見れば、すでにREST APIを使ってアプリケーションを書いていて、それがすべてのニーズを満たしているのであれば、理由だけでGraphQLに移行してコードを書き直す意味はありません。

その一方で、もしあなたが今からアプリケーションを始める、あるいは進化するアプリケーションを予見しており、複雑さが増し、将来のメンテナンスが簡素化されることを望んでいるのであれば、GraphQLは本当に大きな価値をもたらすでしょう。

価値と言いましたか？

そうです。

GraphQLには、コード開発や長期にわたるメンテナンスを簡素化し、データ転送を節約するのに役立ついくつかの重要な利点があります！そうだ！その通りだ。

それでは項目ごとに見ていこう：

• コード開発の簡素化

  GraphQLを使い始めた当初は、少し多めのコードを作成しなければならないかもしれません。それを怖がらないでください。
  GraphQLコンソールを使用すれば、GraphQLはクエリをよりシンプルに書くことができます。Parseが自動的に作成するスキーマを使用し、すべてのクラスに対してクエリと変異の両方の汎用メソッドと固有メソッドを公開することで、多くの時間を節約できます。そして、多くの時間を節約することができます。
  ドキュメンテーション？問題ありません。それもカバーしています。しかも自動生成。
  また、GraphQLを使用すると、開発者はParseが生成するスキーマを頼りにすることができるため、使用可能なメソッド、各メソッドのパラメータ、さらに使用可能なリターン（出力）が事前にわかります。そのメソッドが何をするのか、どのパラメータが必要なのか、何を返すのかを推測したり、他の人に尋ねたりする必要はもうない。すべてお見通しなのだ。

• メンテナンスの簡素化

  GraphQLのメンテナンスは非常に簡単です。APIへの呼び出しは基本的に同じなので、渡すクエリや変異だけを変更したり、返される値やパラメータを追加したり削除したりするのは、それらを受け取ったり配信したりするクエリや変異を変更するのと同じくらい簡単です。
  多くのコールやブロック、プロミスを変更する必要はない。クエリーやミューテーションを変更する：完了！

• データ転送の節約

  Back4appでしばらく働いていると、より速いレスポンスを得るためにクライアントのコードを最適化する手助けをすることはよくあることです。そして、クライアントのコードで私が見つけた全ての問題から、その大部分は、アプリケーションがその時点で必要としないデータを取得することに起因しています。
  REST APIやParseフレームワークを扱う際に非常によくある間違いは、オブジェクトの全情報を取得し、その情報の一部だけを使用することです。例えば
  名前、電話番号、住所、社会保障番号、電子メール、その他いくつかのプロパティを持つPersonというクラスがあるとする。
  通常、REST APIやParse Frameworksを使用している人は、Personオブジェクトの全プロパティを取得し、そのうちの1つか2つだけを使用しようとします。
  GraphQLでは、取得する必要のある情報を正確に指定する必要があるため、開発者は不要な情報を取得する機会がなく、その結果、ペイロードが大幅に小さくなり、レスポンスの高速化、データプランの消費量の削減、そして全体的な送信トラフィックの削減につながります。なんと素晴らしいことだろう。

試してみる

GraphQLが開発プロセスにもたらすメリットを確認する最善の方法は、試してみることです。
ここでは、いくつかのシナリオを試してみて、どのように動作するかを見てみましょう：

• GraphQLクエリーを作成し、何を取得したいかを正確に指定しないでみる

  それはできない。何を取得したいかを指定するよう強制され、それだけを取得します。それ以外は何もしません。
  もしあなたやあなたの開発者がそうすることを忘れても、GraphQLはそれを許さないだろう。

何を取得しているのかわからない

そうだ！

• クエリを使ってオブジェクトを変更しようとする

  いいえ。何かを変更したいのですか？正しい方法を使おう：突然変異だ。
  もしあなたや開発者が間違ったメソッドを使用した場合、GraphQLは処理を続行させません。

データを変更するためのクエリ？いいえ、違います！

ミューテーションがあなたをカバーします！

• 複数のオブジェクト、複数のクエリー？いいえ！1つのクエリ！

  GraphQLは、1つのクエリで複数のオブジェクトの情報を取得することができ、開発を簡素化し、コードのエラーを少なくします。
  例えば、Personクラスがあり、Dogクラスから犬を飼うことができるとします。Personの名前と年齢、そしてDogの名前と犬種です。簡単だ：

バージョン管理？何のために？

バージョニング・コードなんて、2018年のものだ。
クエリーに新しいフィールドを追加してください。古い呼び出しはまだ機能します：

これは機能する

これも動作します。古い型への呼び出しは機能し続けます。

非推奨のフィールドだと？これも簡単だ：

結論

GraphQLは何かを殺すためにあるのではない。古いものに新しい方法をもたらすためにあるのだ。より良く、より速く、よりメンテナンスしやすく、よりエラーを起こしにくくする。

それは、あなたがスリップしたときに軌道修正をしてくれる。何ができて何ができないかを教えてくれる。

Parseと自動生成されるメソッド（一般的なものから特殊なものまで）、そしてドキュメンテーションを使えば、Parseの使い方を簡単に学ぶことができる。

まだ試したことがないのなら、ぜひ試してみてほしい。クールな子供たちはみんなやっている。

GraphQL vs RESTについてもっと知りたい方は、Mediumの投稿をご覧ください。