
Amplify使い方色々
Kazuki Moriyama (森山 和樹)
Amplifyとは
- モバイルアプリケーションを簡単に構築する仕組み
- バックエンドの構築を自動化できる
- フロントエンドとの連携も自動化
- 内部はcloud formation
AWS Amplifyとはなんなのか3行で表現する - Qiita
カテゴリー
- 認証やバックエンドapiの機能の事
amplify add <category-name>で新しいカテゴリーを追加できる
カテゴリーの種類
- Api
- auth
- analytics
Api
- GraphQlやrestのバックエンド的な機能
- GraphQLでは
.graphql.config.ymlのmax-depth以上のネストの深さのスキーマは生成されないので注意
導入
AWS Amplify CLIの使い方〜インストールから初期セットアップまで〜 - Qiita
- これを見ればだいたい行ける
- 注意点はもともとIAMを持っているなら、新規登録しないでそのaccess keyとsecretを入力すればいい
コマンド
add auth
- 認証系をセットアップする
- デフォルトを使えばほぼ問題ない
status
- 現在利用可能なサービスカテゴリーの確認
- 設定されているgraph qlのキーやエンドポイントの確認
init
- 環境をローカルに構築する
aws-exports.jsを作成する
amplify経由のappsync
- プロジェクト以下の
amplify/backend/api/<project-name>/schema.graphqlがappsyncのgraphqlスキーマになっていく - これをいじることでdynamoの作成など行うことができる
amplify上のgitレポジトリファイルからappsync上にエンドポイントをデプロイする
- 以下はqueryを作成しているがmutationでも手順は同様
1. queryスキーマの作成
schema.graphqlに定義したいエンドポイントのqueryスキーマを追加する
2. リクエストマッピングテンプレートを作成
- amplifyプロジェクトの
amplify/backend/api/<project-name>/resolvers以下にQuery.<何でも良いからわかりやすい名前>.req.vtlでファイルを作成- テンプレートの名前はなんでもいいが1で作成したクエリスキーマと同じ名前がわかりやすいのでおすすめ
- 作成したテンプレート内にいつも通りの処理を記述
3. レスポンスマッピングテンプレートを作成
- amplifyプロジェクトの
amplify/backend/api/<project-name>/resolvers以下にQuery.<2で作成したreq.vtlと同じ名前>.res.vtlでファイルを作成- こちらも名前は何でもいいがわかりやすい用に揃えておいたほうが良い
- その中にいつもどおり処理を記述
4. cloud formationのresouceファイルの編集
- amplifyプロジェクトの
amplify/backend/api/<project-name>/stacks以下にあるCustomResources.jsonファイルを開く - その中の
Resourceskey以下に追加したいリソース情報を記述していく - まず好きな名前のkeyを
Resources以下に追加- 名前は何でも良いがわかりやすいのが良い
- ここでは仮に
QueryGetUserとする
Resource.QueryGetUserに以下のように属性値を記述- コメントしてる部分以外はコピペでいい
"QueryGetUser": {
"Type": "AWS::AppSync::Resolver",
"Properties": {
"ApiId": {
"Ref": "AppSyncApiId"
},
"DataSourceName": <データソース名>, // 必須
"TypeName": "Query", // mutationの場合は"Mutation"、必須
"FieldName": <1で作成したクエリのスキーマ名>, // 必須
"RequestMappingTemplateS3Location": {
"Fn::Sub": \[
"s3://${S3DeploymentBucket}/${S3DeploymentRootKey}/resolvers/<2で作成したテンプレートのファイル名>", // 必須
{
"S3DeploymentBucket": {
"Ref": "S3DeploymentBucket"
},
"S3DeploymentRootKey": {
"Ref": "S3DeploymentRootKey"
}
}
\]
},
"ResponseMappingTemplateS3Location": {
"Fn::Sub": \[
"s3://${S3DeploymentBucket}/${S3DeploymentRootKey}/resolvers/<3で作成したテンプレートのファイル名>", // 必須
{
"S3DeploymentBucket": {
"Ref": "S3DeploymentBucket"
},
"S3DeploymentRootKey": {
"Ref": "S3DeploymentRootKey"
}
}
\]
}
}
}
5. amplify pushをかます
- おわり
テーブルの定義
- スキーマに
@modelディレクティブをつける
API (GraphQL) - Directives - Amplify Docs
dynamoのプライマリキー・GSIの作成
@keyディレクティブをスキーマにつけるfields引数の第一要素がパーティションKey、第二要素がソートキーname引数を定義するとその定義はGSIになる
API (GraphQL) - Directives - Amplify Docs
custom resolverの定義
- schemaに
@modelディレクティブをつけると自動的にそれに対するcrud
例外対応
スキーマ変更したあとにpushしたのにAPI.tsが更新されない
- たまに変更を検知してくれない
- そういうときは微妙な変更をスキーマに施してもう一回pushすればいける
Attempting to edit the key schema of the ~ table in the ~ stack.
- dynamo tableのプライマリキーをテーブル作成後に編集しようするとでる
- プライマリ系はテーブル作成時に一緒に作成する必要がある
Local secondary indexes must be created when the table is created.
- dynamo tableのGSIをパーティションKeyと同じものをKeyの1つ目にして作成するとでる
- こういうGSIはテーブル作成時に一緒に作成してあげなければならないらしい











