web-dev-qa-db-ja.com

マイクロサービスに設定されたHATEOASとGraphQLの決定基準？

私は最近、HATEOAS RESTエンドポイントの開発を完全にスキップしてGraphQLを支持している」と言った人と話していました。したがって、GraphQLをいつ使用するかを決定するための基準セットが何であるかについて興味があります。対HATEOASまたはGraphQLはAPIゲートウェイ/エッジサーバーアーキテクチャの一般的な方が良い選択ですか？

graphqlhateoas
14
Ole

それぞれの長所と短所は次のとおりです。

GraphQL

プロ：

  • 不要なトラフィックを回避するために、返されるデータを細かく制御します
  • 添付/「フォローオン」データのために何度も何度も井戸に戻る必要がなくなります
  • 上記に続いて、ソフトウェア設計者はレイテンシーを削減することで優れたパフォーマンスを提供できます-各クエリは必要なものをすべて指定し、GraphQL実装は1つのクライアント<->サーバートランザクションでそれをアセンブルして配信できます
  • バージョン管理されたAPIの代わりに遅い非推奨の可能性
  • それはクエリ言語です
  • イントロスペクションが組み込まれています

短所：

  • キャッシングを処理しません（ただし、これを処理するライブラリがあります）

HATEOAS/REST

プロ：

  • キャッシングはよく理解されている問題です
  • 比較的成熟していてよく理解されている
  • 負荷を分散するためのCDNなどの多くのインフラストラクチャ
  • マイクロサービスに非常に適しています
  • ファイルのアップロードが可能です

短所：

  • 「井戸に戻る」問題
  • 厳密に指定されていない
  • サーバーとクライアントの各実装は、独自の決定を行う必要があります
  • クエリは標準ではありません

結論

興味深い比較の1つは、人々がGraphQLをREST APIのフロントエンドとして使用していることですが、その逆を検討する人は誰もいないでしょう。フェデレーション/マイクロサービスの設計を選択する場合は、 GraphQLサーバーフロントは他の人のために、フロントエンドとマイクロサービスの間でAPIの共通仕様を使用できます。これは、マイクロサービスがRESTである場合はそれほど確実ではありません。

適切な質問を念頭に置いている限り、GraphQLは適切に設計されたシステムの重要な部分になると思います。残念ながら、HATEOASを完全にスキップするかどうかは、「状況によって異なります」。

ソース

私自身の経験に加えて、Phil Sturgeonの GraphQL vs REST：概要

14
Ed.

Edが私の概要へのリンクを投稿したのは気に入っていますが、それよりも関連性が高いと思われる別の記事があります。

状態の表現は、2つの間で完全に異なります。

https://blog.apisyouwonthate.com/representing-state-in-rest-and-graphql-9194b291d127

GraphQLは、意味のある標準化された方法で一連の「次のステップ」を提供することはまったくできません。

それを行ったとしても、他のHTTPAPIとの通信を助けることはできません。これは本当に残念です。

とにかく、それはすべてその記事です！ :)

6
Phil Sturgeon