これはdevコミュニティで議論されているトピックです。多くの人がこれについて異なる意見を持っています。だから私はどちらを使うべきですか？先に進む前に、RESTとGraphQLを理解しましょう。

RESTとは何ですか？

REPresentational State TransferまたはRESTは、Web APIの実装のための特定のガイドライン、制約に準拠するアーキテクチャー・スタイルです。ロイ・フィールディングがPh.Dの論文で提案したものです。ステートレスモードの情報交換を使用してクライアントとサーバーを分離することを推奨します。すべてのAPIがRESTではなく、すべてのRESTfulサービスがAPIであることに注意してください。

GraphQLとは何ですか？

GraphQLはWeb APIのクエリ言語です。2012年にFacebookによって作成され、2015年にオープンソース化されました。これはアーキテクチャパターンでもWebサービスでもありません。これは、さまざまなデータソースから受け取ったデータを照会するのに役立つ仲介役を果たします。これらのデータソースは、データベースまたはWebサービスです。

RESTは長年にわたってWeb APIの支配的な標準となっています。標準のHTTPメソッド（GET、POST、PUT、DELETEなど）を使用して以来、インターネットのWebアプリケーションが増加するにつれて勢いと人気を得ました。さらに、言語とプラットフォームに依存しないため、Webサービスを作成する上でより良い選択となっています。すべてのデータは、URLが呼び出されたときに送信されるリソースとして扱われるため、WebブラウザでもcURLリクエストでも呼び出すことができます。

RESTの短所

RESTは非常に成功しましたが、RESTfulなサービスが規模と複雑さが増したことで非常に明らかになったのは欠点です。

1.複数のエンドポイント（複数回の往復）

RESTfulサービスでは、URLは単一のリソースを示しています。したがって、複数のリソースにアクセスする必要がある場合は、複数のエンドポイントを呼び出す必要があるため、すべての必要なデータを取得するために複数のラウンドトリップが必要になります。

たとえば、ブログアプリケーションを考えてみましょう。あなたはブログ投稿があり、各投稿にはコメントがあります。このための典型的なRESTエンドポイントは次のようになります。

# 特定の投稿を取得する
GET /posts/                                          
# 投稿に関連するすべてのコメントを取得する
GET /posts//comments                         
# 特定の値を取得
GET /posts//comments/ 

エンドポイントの長さが増えていることがわかります。エンティティ間の関係が増加するにつれて、エンドポイントURLの量も増加します。アプリケーションが大きくなるにつれて、これらのAPIを維持するのは煩雑になります。

2.データのオーバーフェッチ/アンダーフェッチ

関連するAPIと一緒に不必要なデータを取得したり、十分なデータを受け取っていないため、複数回のトリップが発生することがあります。これはRESTfulなサービスでよく見られる問題です。2〜3の値しか必要としない場合がありますが、応答として20〜25の値が得られます。これは、レスポンス時間を長くすることによって、大量の未使用データを転送することになります。後者の場合は、単一のエンドポイントから得られる情報より多くの情報が必要な場合があります。したがって、複数のラウンドトリップを行う必要があります。これはまた、クライアントが必要なすべてのデータを取得するのにかかる全体的な時間を増加させる。

3. APIのバージョン管理

APIのバージョン管理は、レスポンス形式の変更を伴うクライアントアプリケーションの破壊を回避するための方法です。APIの応答形式が変更されると、新しいバージョンが作成されます。これは、プロダクションクライアントアプリケーションが期待どおりに動作し、開発者が新しいAPIバージョンに移行するための時間を与えるために行われます。

しかし、このバージョン管理は、新しいバージョンがリリースされたときに新しいエンドポイントを意味するように問題になります。APIのメンテナンスと消費が困難になり、またコードが重複することがよくあります。

4.弱いタイピング

RESTfulサービスから受け取ったデータのすべてが強く型付けされているわけではありません。つまり、特定のデータが適切に与えられていません。これは、クライアントがエンドポイントを呼び出すことで期待できるデータの種類を指定する必要があるため、APIを文書化する際に問題になります。

5.クライアントが暗闇の中で暮らす

クライアントはそれを受け取るまで応答構造を認識しません。だから、クライアントはどのような対応が期待できるのか暗闇の中で守られています。これはしばしばエラーを引き起こし、データが適切に処理されないため、APIの消費の信頼性が低下します。

GraphQLの利点

GraphQLは、主にRESTの欠点を克服するためにFacebookによって考案されました。

1.すべてのものを手に入れるための1つの要求

GraphQLサービスは、クライアントがデータを取得するために必要なクエリを渡すことができる1つのエンドポイントだけを公開します。前に考えた同じ例を使って、GraphQLクエリを見てみましょう

{
    findPost(id: ) {
        id
        title
        content
        author
        comments {
            id
            comment
            commentedBy
        }
    }
}

ご覧のように、1回のリクエストですべての必要なデータが取得されます。したがって、新しいフィールドが必要な場合は、クエリに追加するだけで、レスポンスに表示されます。

2.強く型付け

GraphQLは厳密に型付けされたスキーマによって支配されます。これらのタイプは、プリミティブまたは派生です。強力なタイピングシステムにより、APIを自己文書化することができるため、クライアントは特定のクエリをクエリするときにどのような応答を得るのかを知ることができます。

3.クライアントはドライバです

GraphQLは、クライアントが正確に必要なフィールドを指定できる宣言構文を提供します。これにより、スキーマに基づいてGraphQLサーバにデータ要件が記述されているクライアントとして、データが過度に取得され、アンダーフェッチされる可能性が排除されます。

4. APIの進化

GraphQLのすべてがスキーマ駆動型であるため、新しいフィールドが既存のフィールドに影響を及ぼさず、GraphQLが@deprecatedアノテーションを導入してフィールドを非推奨にするため、問題はありません。 これにより、APIのバージョニングが不要になります。

5.トランスポート層アゴニスト

これはGraphQLの非常に優れた利点です。APIサーバは、HTTP、HTTPS、WebSocket、TCP、UDPなどのプロトコルを介して情報を交換することができます。これは、GraphQLがクライアントとサーバ間で情報がどのように交換されるかにほとんど影響しないためです。

GraphQLの短所

GraphQLは素晴らしいです。しかし、それは普遍的に知られている真実であり、この世界のすべてがキャッチを持ち、GraphQLはこの真実を逃れることができません。

1.非存在キャッシング

GraphQLは、ネイティブHTTPキャッシュメカニズムを使用するRESTfulサービスとは異なり、ブラウザとモバイルキャッシングをサポートしていません。これはキャッシングを達成するための開発努力につながる。Relayのようなツールはキャッシングをいくらかサポートしますが、RESTfulサービスで使用されるキャッシング機構ほど成熟していません。

2.監視とエラー報告

RESTfulなサービスは、発生する可能性のあるさまざまなエラーに対してHTTPステータスコードを活用します。これにより、開発者にとってAPIの監視が非常に簡単かつ容易になります。しかし、GraphQLサービスは常に200 OK応答を返します。一般的なGraphQLのエラーメッセージは、ステータスコードで次のようになります200 OK。

{
    errors: [
        { 
            message: 'Some error occurred'
        }
    ]
}

これは、エラーシナリオを処理することを非常に困難にし、監視プロセスを煩雑にする。

3.公開されたスキーマとリソースの攻撃

RESTfulサービスとは異なり、GraphQLサービスは、クライアントが照会するデータスキーマについて知っておく必要があります。APIを第三者に公開する場合、基本的に内部データ構造が公開されます。クライアントがサーバー上でDoS（サービス拒否）攻撃を受ける可能性のある費用がかかる結合クエリを作成しないように、細心の注意を払わなければなりません。

4.セキュリティ - 認証と承認

GraphQLサーバのセキュリティ部分を処理する方法については、GraphQLコミュニティの間で混乱が起こっています。認証と承認を統合するためのネイティブソリューションはまだありません。これは通常、ビジネスロジック層に抽象化されてユーザーを認証しますが、認証されていないユーザーのクエリを解析して検証する必要がありますかは、依然としてGraphQLの問題です。

5. N + 1問合せ問題

RESTfulなサービスでは、実行されたSQLクエリをログに記録してさらに最適化するのは非常に簡単です。しかし、解決の性質が動的であるGraphQLの場合、正確なクエリを取得し、それをさらに最適化するのは非常に困難です。フィールドリゾルバは、N + 1のクエリの問題や高価なジョイン操作につながることがあります。しかしFacebookはこの問題を解決するためにDataLoaderのようなツールを開発している。だから将来的にはこれは不利益ではないでしょう。

6.若年生態系

GraphQLは、このAPIエコシステムの赤ちゃんによく似ています。つまり、問題が発生し、変更が毎回発生するため、GraphQLに関連するライブラリやモジュールを使用する際には、非常に徹底しなければなりません。

結論

GraphQLは単なるツールであり、RESTはアーキテクチャパターンであるということから始めましょう。GraphQLがRESTを置き換えることができると言っても間違いです。しかし、Microservicesのこの時代には、APIを原子レベルで分離して作成しています。これを利用することで、銀色の弾丸は1つもありません。

GraphQLサーバは、RESTfulなサービスが信頼性を維持しながら、パフォーマンスを最優先に保ちます。

GraphQLエンドポイントは、既存のRESTfulサービスを介して/graphql、特定のユースケースのRESTエンドポイントを維持しながらGraphQLクエリを実行するゲートウェイとして機能するエンドポイントとして公開することができます。

GraphQLを使う方がいいし、RESTが確実に勝つ特定のユースケースがある特定のユースケースがあります。だから、どちらが良いかを言う前に、要件とデータを分析して、どちらを使うことができるかの結論に至ります。