AppSync と仲良くなろう

#r_serverlesslt で発表した資料です。

Transcript

1. AppSyncと仲良くなろう
 山本隼汰@トドケール

2. はじめに

3. GraphQL 好きですか？

4. はじめに
 お話しすること
 • AppSync を使う上で注意しておきたいポイント
 お話ししないこと
 • AppSync を最大限活用する方法・発展的な利用
 • 各ポイントに関する詳細な解説
 
 ※今回の発表は個人的な見解です。
 AWSが提唱するベストプラクティスと一部乖離する可能性があります。ご了承ください

5. まとめ
 1. 気軽に動作確認できる環境を作ろう
 a. ローカルシミュレータが使えるなら積極的に使おう 
 b. 共有の開発環境を使うしかないなら、インフラをコード化しておこう 
 2. なるべく薄く、シンプルな構成に
 a. AppSync はバックエンドのフィルタリングツールなんだ、と刷り込む 
 b. パイプラインリゾルバーで色々やりたい！と思った時は危険 
 3. ログと仲良くなろう
 a. まずは、ログの種類を知るところから 
 b. X-Ray を有効化しよう 
 c. ログに対してクエリを書けるようになろう 

6. 気軽に動作確認できる環境を作ろう
 1. ローカルシミュレータが使えるなら積極的に使おう
 a. Amplify や ServerlessFramework ならローカルで起動できる 
 i. https://docs.amplify.aws/cli/usage/mock/#function-mocking-with-graphql 
 ii. https://github.com/bboure/serverless-appsync-simulator 
 2. 共有の開発環境を使うしかなければ、インフラをコード化しておこう
 a. 一部の関数を開発環境にデプロイして動作確認した後に、すぐに戻せるようにしておく 
 b. これだけで動作確認の気楽さがかなり増す。（破壊的な処理を入れる時は注意がいるが...） 

7. なるべく薄く、シンプルな構成に
 1. AppSync はバックエンドのフィルタリングツールなんだ、と刷り込む
 a. Velocity Template Language (VTL) で複雑なこともやれるが、正直おすすめはしない。 
 b. RESTなどのレスポンスをよしなにサーバーサイドでフィルタリングしているんだ、 
 くらいの認識でいた方がAPIをシンプルに保てる。 
 c. GraphQL か REST かではなく、GraphQL と REST で考える。 
 i. 相互補完はできる。あとは状況に応じて、利用割合を調整するだけ 
 2. パイプラインリゾルバーで色々やりたい！と思った時は危険。
 a. パイプラインリゾルバーは、直列処理。 
 i. 時間のかかる処理が一つでもあると、全体のパフォーマンスが落ちる 
 b. 途中で失敗した時のリカバリを考えるのが大変 
 i. Transaction をうまく活用したりする必要が出てくる 

8. ログと仲良くなろう
 1. まずは、ログの種類を知るところから
 a. とにかく一覧をみよう → こちら
 b. 予算が許せば、フィールドレベルログも取得するとよい 
 2. X-Ray を有効化しよう
 a. AppSync のログから、処理のボトルネックを把握するのはかなり難しい 
 b. X-Ray のトレースで、各処理にかかっている時間を計測する方が直感的でわかりやすい 
 3. ログに対してクエリを書けるようになろう
 a. AppSync のログはデフォルトでJSONで構造化されて出てくる（朗報） 
 b. CloudWatch なら Log Insightsで、OpenSearch なら Dashboard で検索をかけると良い 

9. まとめ（再掲）
 1. 気軽に動作確認できる環境を作ろう
 a. ローカルシミュレータが使えるなら積極的に使おう 
 b. 共有の開発環境を使うしかないなら、インフラをコード化しておこう 
 2. なるべく薄く、シンプルな構成に
 a. AppSync はバックエンドのフィルタリングツールなんだ、と刷り込む 
 b. パイプラインリゾルバーで色々やりたい！と思った時は危険 
 3. ログと仲良くなろう
 a. まずは、ログの種類を知るところから 
 b. X-Ray を有効化しよう 
 c. ログにクエリをかけるようになっておく