AppSync
- APIGateway → 複数のAPIエンドポイントを提供
- AppSync → 単一のGraphQLのエンドポイントを提供
GraphQL
GraphQLの何がいいの？
-
必要なデータだけを取得
RestfulなAPIではレスポンスの情報は決まっているので、必要ない情報も全て取得せざるを得ない。
→ GraphQLではサーバ側で必要ない情報をフィルタリングして返却する。 -
一度のリクエストで多くのリソースを取得
RestfulなAPIでは1つの処理をするのにいくつものURLからAPI経由でデータを取得する必要があるケースが多い。
→ GraphQLでは1度のリクエストで必要なデータを取得することでパフォーマンス向上を図ることができる。 -
型を見れば動きがわかる
RestfulAPIでは仕様書を見ないとパスからはレスポンスがわからなかった。
→ GraphQLではスキーマ定義≒仕様書なので型をみれば何が返るかがわかる。仕様書のメンテコストの削減。 -
version管理しない
RestfulAPIではパスを変えエンドポイントを増やすことでversionを管理するが、管理が大変。
→ GraphQLでは呼び出し元で明示的に取得する値を指定するため対応しやすい。@deprecatedを付すことで削除予定であることを明示できる。 -
データや言語に依存しない
種々の言語に対応。AppSyncではSDL(Schema Definition Language)で記述する。
やってみる
スキーマとリゾルバ
▼ スキーマ定義とそこで定義したノードに対応するリゾルバのコンソール
▼ スキーマ定義
▼ リゾルバ定義
→ マッピングテンプレートの文法
データソース
= リゾルバの処理する先。どこのデータソースに対してリクエストを投げるか。
Postmanからコールする
参考) https://learning.postman.com/docs/sending-requests/supported-api-frameworks/graphql/
データソースをLambdaとする場合
DynamoDBをデータソースとする場合にはマッピングテンプレートの中で処理を記述していたが、AppSyncから直接アクセスできないRDSやEC2上に独自構築したDBなどをデータソースとする場合にはLambdaを噛ませ、その中に処理を書く必要がある。
リゾルバ
DynamoDBの時と違ってLambdaにリクエストを横流しするだけ。種々のクエリはLambda側で処理を振り分ける必要がある。
データソース
リゾルバ
スキーマ定義のすべてのノードに対してリゾルバをアタッチできる。
なぜ値(ノード)に対してもリゾルバがアタッチできるのか？
→ GraphQLがグラフとしての性質を利用していることを考えるとわかる。
→ この記事がとてもわかりやすい。
この仕組みにより、上記の例ではrelatedPostが呼ばれた時だけリゾルバで再起的に処理されて値が返され、逆にrelatedPostが呼ばれない時にはこの処理をしなくていいので無駄な演算なくレスポンスを返すことができる。(RestfulAPIではリクエスト側が必要としていないデータだったとしても内部の不要な演算を省いたりできないのでGraphQLのメリットの一つ。)
ただし、ここでもしgetPostで生成されるPostノードが複数あり、それぞれに対してrelatedPostを求めるリゾルバを呼ぶとなるとLambdaのコール回数がバカにならないので困る。
そこで、リクエストマッピングテンプレートにてBatchInvokeを指定することですべてのPostを1度のLambdaで処理することができる。
エラーハンドリング
Lambdaでエラーした場合、リクエストにエラーの内容が含まれる。
