Zenn
Open10

Amplifyの調査

AWS
Amplify
fumiyakifumiyaki

新しく覚えたAmplify CLIのコマンド

amplify configure project

Project information
AWS Profile setting
Advanced: Container-based deployments

amplify initで指定した設定を更新したり、コンテナでのデプロイが出来る。
amplify init時に指定したAWSアカウントではなく、別アカウントにデプロイ先を変えたいのでAWS Profile settingを選択して無事に変更が出来た。

fumiyakifumiyaki

新しく覚えたAmplify CLIのコマンド

amplify api gql-compile

amplify/backend/api/anariso/build/schema.graphqlにamplify/backend/api/anariso/schema.graphqlで書いたAmplify独自のSchemaを通常のgraphqlに変換してくれる。

こいつをgraphql code generatorに食わせたら良いのかな？
前までsrc配下に同じ用途のSchemaが生成出来たけど変わった？

fumiyakifumiyaki

Amplifyのドキュメントが更新されていて再学習が楽しい

fumiyakifumiyaki

テーブルのデータ消してしまう系の操作まとめ

The following schema updates require replacement of the underlying DynamoDB table:

  1. Removing or renaming a model
  2. Modifying the primary key of a model
  3. Modifying a Local Secondary Index of a model (only applies to projects with secondaryKeyAsGSI turned off)

When trying to push a schema change with one or more of these updates you will see an error message explaining that you will lose ALL DATA in any table that requires replacement. To confirm you want to continue with the deployment, run:

amplify push --allow-destructive-graphql-schema-updates

In general, this command should only be used during development.
If you are making a breaking change to a production API but you want to retain the data in the affected table(s), you can create a backup before running amplify push --allow-destructive-graphql-schema-updates

私の解釈
Schemaの更新で既存テーブル吹っ飛ばすから以下のActionには気をつけてね。

  1. @modelの削除・名前の変更
  2. @model内の@primaryKeyを変更する ex) Column名の変更、別Columnに@primaryKeyをつけるなど
  3. @model内のLocal Secondary Indexを変更する ex) @indexがついたColumnに変更を加える

3つめはリレーション貼ってるやつも駄目ということかな・・・？
どっかのタイミングでスクラップアンドビルドして試そうｗ

fumiyakifumiyaki
amplify rebuild api

何故かpush出来ない問題を救うCommandが出来ているｗｗｗ
いつの間に...
めちゃくちゃ待望の機能だ。
ALL DATA in ALL TABLES will be deleted.
とても怖い

注)本番でやっちゃ駄目

fumiyakifumiyaki

By default, owners can reassign the owner of their existing record to another user.

To prevent an owner from reassigning their record to another user, protect the owner field (by default owner: String) with a field-level authorization rule. For example, in a social media app, you would want to prevent Alice from being able to reassign Alice's Post to Bob.

type Todo @model @auth(rules: [{ allow: owner }]) {
 id: ID!
 description: String
 owner: String @auth(rules: [{ allow: owner, operations: [read, delete] }])
}

え、超怖い！？
何かしらユーザがPOST出来るサービスはここの設定をしなければエグいPOSTを別ユーザーの所有物に出来てしまう
操作履歴とかなければ・・・こわE