🚀

知っておくと便利なAmplifyの設定

2022/01/18に公開

AWS

GraphQL

Amplify

tech

はじめに

Amplify CLIでバックエンドを作っている際に便利だった設定について並べたものになります。
Amplify CLIのバージョンは7.6.8になります。
尚、バージョンに強く依存する機能なので、古いバージョンでは動かなかったり、未来のバージョンでは動かなかったり、というのがあると思います。
極力公式ドキュメントへのリンクを入れておくので、確認いただきながらご利用いただければと思います。

DynamoDBのPointInTimeRecoveryを有効にする

PointInTimeRecoveryはDynamoDBの継続的バックアップとロールバックができる機能です。

保存量に応じた有償の機能なので、enableにする際にはその点は注意してください。
PITRを有効にしているとDynamoDBテーブルのS3エクスポートもできるようになるので、データ分析等に利用する場合にも便利な機能だと思います。

amplify cliが新しくなってから（明確なバージョンがわからないのですが・・・）、docsも新しくなっていて、説明が無くなってしまったのですが、
旧バージョンのdocsの説明にある

こちらの設定が使えます。
amplify/backend/api/{projectName}/parameters.jsonに下記のように追記をしてあげればOKです。

amplify/backend/api/{apiName}/parameters.json

{
  "AppSyncApiName": "projectName",
  "DynamoDBBillingMode": "PAY_PER_REQUEST",
  "DynamoDBEnableServerSideEncryption": false,
+  "DynamoDBEnablePointInTimeRecovery": true
}

私の手元の7.6.8環境では

動いていそうです。

ちなみに、新しい設計では今後このような特定リソースのカスタマイズは

こちらのCDK constructsを用いた手法に変わるようです。

ttlを設定する例がありました。
まだこのあたりは試していないのですが、ご参考まで。

AppSyncのマネージドコンソールのクエリを利用可能にする

こちらは新しいAmplify CLIの機能だと思うのですが、AppSyncのマネージドコンソールのクエリのテストの際に全クエリを実行可能にする設定です。

説明にも書いてありますが、@authディレクティブで設定するiamのアクセス権限とは全く別のadmin権限が付与されることになります。

設定方法はamplify/backend/api/<your-api-name>/custom-roles.jsonに

amplify/backend/api/<your-api-name>/custom-roles.json

{
  "adminRoleNames": {"ユーザーやロールの名前"}
}

とすればOK

どうも@authディレクティブも同様なようですが、この設定はGraphQL Transformer v2で利用されているpipeline resolverでいうと、

こちらの3. Extending Amplify-generated pipeline resolversのAuthの部分に実装されるようです。

実際に生成されるレゾルバ、例えばamplify/backend/api/{apiName}/build/resolvers/Query.getBlog.auth.1.req.vtl
を見てみると

  #set( $adminRoles = ["設定したユーザーやロールの名前"] )
  #foreach( $adminRole in $adminRoles )
    #if( $ctx.identity.userArn.contains($adminRole) && $ctx.identity.userArn != $ctx.stash.authRole && $ctx.identity.userArn != $ctx.stash.unauthRole )
      #return($util.toJson({}))
    #end
  #end

という項があり、こちらが機能することでクエリが許される、という仕組みになっているようです。

逆に言えば、こちら迂闊なロールやユーザーを設定してしまうと困ることになるかなと思いました。
私は開発環境のアカウント分離とAWS SSOによるアクセス制御を導入しているので、ここにはAWSReservedSSO_***という自動生成されるロールを記入しています。例えばテスト環境のアカウントの特定ユーザー（or ロール）を入れて開発者がテストできるようにする、という運用がよさそうだなと思います。

ちなみに余談ですが、unAuthRoleというIAMのロールにはすべてのアクセス許可が記述されていて混乱しました。
GraphQL Transformer v2ではアクセス権の制御はすべてこのpipeline resolverの中で行うようにする方針のようです。

@modelで生成されるGraphQLのqueryを生成されなくする

こちらに。
リネームすることもできる機能です。
@modelの後に(queries: hoge, mutations: hoge, subscription: hoge)と書くことで指定ができます。
このページの下の方にある、@modelディレクティブの構造のうち、

input ModelMutationMap {
  create: String
  update: String
  delete: String
}

input ModelQueryMap {
  get: String
  list: String
}

input ModelSubscriptionMap {
  onCreate: [String]
  onUpdate: [String]
  onDelete: [String]
}

これらの値を入れるものだと思います。
実際に試してみたのですが、
@model (queries: {list: null, get: getPost}, subscriptions: null)
と書くことで、list queryとsubscriptionが生成されないことを確認しています。

気になる注意点は

個別の指定（上記の例で言うとqueries)をする際に省略してもデフォルトの設定は適用されない

queries: {list: null}と書いたところ、get Queryも生成されなくなってしまいました。
ちなみに上記のようにmutationsを省略していてもそちらはデフォルトのまま生成がされました。

名前はmodel名まで書く必要がある

queries: {list: null, get: get}としたところ、生成されたQueryはgetというクエリでした。
これはドキュメントの説明と食い違っている気もしていて、今後変わるかもしれません。

おわりに

Amplify CLIでバックエンドを作る際に便利な設定を紹介しました。
アップデートが盛んなフレームワークのため、ご利用の際には必ずご自身での確認は忘れないようにしていただければと思います。
amplify hooksやcustom、今回少し触れたoverride等、かなり自由度の高いカスタマイズが提供されるようになったと思いますので、今後もやりたいことに合わせてカスタマイズを試してみるとよいかと思います。
筆者はどちらかというとフロントエンドに近い部分をAmplify、ロジック周りはCDKとすみ分けて、@functionディレクティブでAmplifyとCDKをつなぐようなことを普段はしているのですが、今回のアップデートでAmplifyがCDKに近い（というか一部利用している理解）形になってきたのでまた色々とやれるだろうな、と思っています。