Slide 1

Slide 1 text

AWS AppSyncと 仲良くするためのTips 2024.07.09 フリーランスエンジニア 岡 春奈

Slide 2

Slide 2 text

Xへの投稿の際は、 ハッシュタグ #cm_odyssey でお願いいたします。 2 お願い

Slide 3

Slide 3 text

⾃⼰紹介 3 岡 春奈 / Haruna Oka バックエンドエンジニア   @OkaHaruna

Slide 4

Slide 4 text

本⽂タイトル ● 話すこと ○ 今使っている案件でのAppSyncの話 ● 話さないこと ○ フロントの話 ○ Amplifyの話(Gen2) 4

Slide 5

Slide 5 text

全体構成 5

Slide 6

Slide 6 text

6

Slide 7

Slide 7 text

AppSyncを1年使ってみた 7

Slide 8

Slide 8 text

アジェンダ ● 構成を変えたところ ● それぞれの難点‧利点 ● まとめ 8

Slide 9

Slide 9 text

構成を変えた部分 9

Slide 10

Slide 10 text

構成を変えた部分 ● リゾルバーの使い分けを⾒直した ● オニオンアーキテクチャの導⼊ ● APIの認証⽅式を変えた ● バリデーションスキーマを⾃動⽣成 10

Slide 11

Slide 11 text

リゾルバーの種類 ● ユニットリゾルバー ● パイプラインリゾルバー ● Lambdaリゾルバー 11

Slide 12

Slide 12 text

ユニットリゾルバー 12 公式Docs: AWS AppSync リゾルバー

Slide 13

Slide 13 text

パイプラインリゾルバー 13 公式Docs: AWS AppSync リゾルバー

Slide 14

Slide 14 text

Lambdaリゾルバー 14 正確にはLambdaをデータソースとし たユニットリゾルバー 公式Docs: AWS AppSync リゾルバー

Slide 15

Slide 15 text

リゾルバーの使い分け 15

Slide 16

Slide 16 text

元々の使い分け 16

Slide 17

Slide 17 text

開発進める中での問題点 17

Slide 18

Slide 18 text

開発進める中での問題点 ● JSリゾルバーの制約が⾟い ○ 組み込み関数が多々使えない ● Pipelineリゾルバーのメンテがしづらい ● コードサイズ制限に引っかかる 18

Slide 19

Slide 19 text

リゾルバーの使い分け(現状) 19

Slide 20

Slide 20 text

リゾルバーの使い分け(現状) ● Mutation系はLambdaに統⼀ ○ middyの導⼊ ● Pipelineリゾルバーを辞めた ○ (管理コストを下げるため) 20

Slide 21

Slide 21 text

リゾルバーの使い分け(現状) ● 結論 ○ Lambdaの同時実⾏数を気にしてJSリゾ ルバーに寄せていたが、Lambdaの同時 実⾏数を気にするようなアクセス数に なった時はAppSync⾃体を剥がしたほう が良さそう 21

Slide 22

Slide 22 text

オニオンアーキテクチャの導⼊ 22

Slide 23

Slide 23 text

オニオンアーキテクチャの導⼊ ● Lambdaリゾルバーに寄せたことで共通化 がしやすくなった ● 将来的にDBが変わる可能性も考慮してディ レクトリ構成を全体的に⾒直した 23

Slide 24

Slide 24 text

オニオンアーキテクチャの導⼊ ● /core ○ /domain ○ /infrastructure ● /graphql ○ スキーマとcodegenで⽣成したファイル 24

Slide 25

Slide 25 text

オニオンアーキテクチャの導⼊ 25

Slide 26

Slide 26 text

APIの認証⽅式を変えた 26

Slide 27

Slide 27 text

APIの認証⽅式を変えた ● APIは3つ ○ 管理者向け: Admin API ○ ユーザー向け: Customer API ○ ゲストユーザー向け: Public API 27

Slide 28

Slide 28 text

APIの認証⽅式を変えた ● Admin API ○ Cognitoユーザープール(グループ) ● Customer API ○ Cognitoユーザープール ● Public API ○ APIキー 28

Slide 29

Slide 29 text

APIの認証⽅式を変えた ● Admin API ○ Cognitoユーザープール(グループ) ● Customer API ○ Cognitoユーザープール ● Public API ○ APIキー → IAM認証に切り替えた 29

Slide 30

Slide 30 text

APIの認証⽅式を変えた 30

Slide 31

Slide 31 text

APIの認証⽅式を変えた 31

Slide 32

Slide 32 text

APIの認証⽅式を変えた 32

Slide 33

Slide 33 text

APIの認証⽅式を変えた 33

Slide 34

Slide 34 text

バリデーションスキーマの⽣成 34

Slide 35

Slide 35 text

バリデーションスキーマの⽣成 ● zodを導⼊ ● codegenのプラグイン ○ typescript-validation-schema ○ @constraintに最⼤⽂字数等を指定 35

Slide 36

Slide 36 text

バリデーションスキーマの⽣成 36

Slide 37

Slide 37 text

バリデーションスキーマの⽣成 37

Slide 38

Slide 38 text

他開発ツール 38

Slide 39

Slide 39 text

他開発ツール周り ● npm → pnpm にして扱いやすくなった ● APIドキュメントの⾃動⽣成 ○ magidocで⽣成 → Cloudflare Pagesで公開 ● CDKTFの導⼊ 39

Slide 40

Slide 40 text

CDKTFの導⼊ ● CDK for Terraformを導⼊ ● ⼀部のリソースでCloudflareを使っている ○ CDN, DNS等 ● 元々はterraformでやる想定だった ● CDKに合わせてCDKTFでやることに 40

Slide 41

Slide 41 text

CDKTFの導⼊ ● ⼀部のリソースでCloudflareを使っている ○ CDN, DNS等 ● 元々はterraformでやる想定だった ● CDKに合わせてCDKTFでやることに 41 →Typescriptで統⼀できて管理コストが下がった

Slide 42

Slide 42 text

反省点 42

Slide 43

Slide 43 text

反省点 ● 初⼿RDSにしておくべきだった ● DB設計にもっと時間をかけるべきだった ● そもそもAppSyncが適していなかったかも 43

Slide 44

Slide 44 text

まとめ ● AppSyncの開発効率を最⼤限に活⽤するな らやはりAmplifyと使うのが有⽤ ● GraphQL + monorepo = 相性良し ● ⾔語をtypescriptで統⼀できた(CDKTF) 44