$ amplify pushしてできるamplifyディレクトリの役割

AWS Amplifyを使ってバックエンドを構築するプロジェクトにて、$ amplify pushすると、ルートディレクトリにamplifyという名前のディレクトリができる。

カテゴリとしてApi・Auth・Hostingを追加した状態のディレクトリは以下のようになっている。



# 2階層までツリー表示
$ tree -L 2 amplify
amplify
├── #current-cloud-backend
│   ├── amplify-meta.json
│   ├── api
│   ├── auth
│   └── hosting
└── backend
    ├── amplify-meta.json
    ├── api
    ├── auth
    ├── awscloudformation
    └── hosting

#current-cloud-backendとbackendで同じようなディレクトリ構造をしていて紛らわしい。それぞれ以下のような役割となっている。

#current-cloud-backendは、AWS Amplifyの前身であるAWS Mobile SDKにはフロントエンドのプロジェクトでバックエンドの環境を構築するような機能がなかった頃、バックエンドの情報をフロントエンドに持ってくる機能で使っていたディレクトリの名残とのこと。AWS Amplifyを使う上で、特に変更する必要のないディレクトリ。

AWS AmplifyでAppSyncをAPIエンドポイントとして使う場合のスキーマやリゾルバーの変更の流れ

AWS AppSyncのマネジメントコンソールでは、以下のような画面でスキーマを記述していく。

スキーマに記述した内容を元に右側の表のエリアに情報が表示されるので、そこからリゾルバーをアタッチすることになる。 リゾルバーの変更は以下のような画面で行うことになる。

AppSyncのスキーマやリゾルバーはこのマネジメントコンソールから設定することもできるが、せっかくAWS Amplifyを使ってフロントエンドのプロジェクトでバックエンドの設定ができるので、フロントエンドのプロジェクトで全て完結させることが理想的。

AWS Amplify経由でAPIを変更しないと、次回$ amplify pushしたときにせっかく変更したスキーマやリゾルバーがフロントエンドのプロジェクトの設定内容で上書きされてしまう。

AWS Amplify経由でAppSyncをAPIエンドポイントとして作っていく際には、そのスキーマ設計をamplify/backend/api/<プロジェクト名>/schema.graphqlに記述していく。

$ amplify add apiコマンドを実行すれば対話形式で設定することができるので、以下のようなスキーマが書かれているかもしれない。



type Task
  @model
{
  id: ID!
  title: String!
  description: String
}

このschema.graphqlにスキーマを書いた状態で$ amplify pushすることで、自動的にリゾルバーが作成されて、バックエンドのAppSyncに設定が適用される。

リゾルバーはフロントエンドのプロジェクトのamplify/backend/api/<プロジェクト名>/build/resolversというディレクトリにMutation.createTask.requestのように作成されるが、こちらも変更してしまうと次回の$ amplify pushの実行時に上書きされてしまう。

AWS Amplifyを使う上では、リゾルバーを直接変更することは避けてschema.graphqlを変更してAppSyncを設定する必要がある。

もしschema.graphqlの変更では生成できないようなリゾルバーを作成したい場合は、AWS AmplifyのGraphQL Transformという機能を利用して、自力でスキーマファイルからリゾルバーを生成するロジックを書く必要がある。

公式ドキュメント：GraphQL Transform - AWS Amplify

AWS Amplifyを使ってAppSyncのデータソースにDynamoDBを指定した場合にGSI・LSIを設定する方法

前述の通り、AWS Amplifyを使うならマネジメントコンソールからバックエンドの設定を調整するのは避けたい。しかし現状AWS AmplifyでDynamoDBのインデックスを作成するような設定項目がないため、自力でCloudFormationの設定を書く必要がある。

$ amplify pushコマンドにて生成されるamplify/backend/api/<プロジェクト名>/cloudformation-template.jsonにバックエンドの詳細な設定を書くことができるので、ここでDynamoDBのGSI・LSIの設定を書くことになる。

ユーザー認証にCognitoユーザープールを使ってAppSyncのAPIを呼び出すとき、未認証でも呼び出せるようにする

AppSyncにはクライアントの認証タイプが4つ存在する。

• API key
• AWS Identity and Access Management (IAM)
• Amazon Cognito User Pool
• OpenID Connect

このうち、Amazon Cognito User Poolを選択することで、Cognitoで認証したユーザーに対してのみ呼び出しを許可することができる。また、AppSyncのスキーマに@aws_authディレクティブをつけることで、特定のQuery・Mutationに制限をかけたり、許可したりすることができる。 （@aws_authをつけたQuery・Mutationが許可になるか拒否になるかはSettingsのDefault actionの設定による）

@aws_authディレクティブでは、Cognitoの特定のグループにログイン中のユーザーが属しているかで許可・拒否ができたり、リゾルバー中で$context.identityでログイン中のユーザーの情報や所属グループ情報を取ってきて利用することができる。

しかし、Amazon Cognito User Poolを選択した場合、未ログイン状態でAPIを呼び出すことはできない。

未認証でAppSyncのAPIを呼び出したり、さらにログイン中のユーザーに対して細かい権限管理を行いたい場合は認証タイプをAWS Identity and Access Management (IAM)にする。

認証タイプをAWS Identity and Access Management (IAM)にすることで、クライアントにはCognitoのIdentity Poolで指定されている認証済みクライアントに割り当てられるロール（Auth Role）と未認証のクライアントに割り当てられるロール（Unauth Role）がログイン状態に応じて割り当てられる。

未認証状態ではユーザーを識別する術が無いためUnauth Roleが割り当てられるが、認証済みのクライアントにはCognitoユーザープール上でユーザーが属するグループごとにロールを分けることができる。

AWS Amplifyを使ってバックエンドを構築するプロジェクトでProduction環境・Staging環境などを分ける方法

本番環境と開発環境を分けてバックエンドを構築してデプロイするには、multienvバージョンのAWS Amplifyを利用する。まだベータ版なので今後仕様が変更になる可能性がある。



$ npm install -g @aws-amplify/cli@multienv

公式ドキュメント：Multiple environments and team workflows (beta) - AWS Amplify

「優れた設計のアプリケーションで必要なテーブルは 1 つのみ」であるDynamoDBのはずが、ChatQLでは複数のテーブルが生成される

ChatQL: An AWS AppSync Chat Starter App written in Angular

AWSの公式サンプルのChatQLでは、$ amplify pushするとDymamoDBに複数のテーブルが生成される。 NoSQL設計ベストプラクティス的には「優れた設計のアプリケーションで必要なテーブルは 1 つのみ」であり、ソリューションアーキテクトの方的には一つのテーブルで設計することがベストプラクティスとのこと。

ただし、あくまでも基本であり、必要に応じてテーブルを分けても問題ない。

免責

こちらはAWS Amplify/AWS AppSync/Amazon Cognito/Amazon DynamoDB等について調査してわからなかったことを目黒のAWS Loft TokyoのAsk An Expertブースにて質問して、私が理解できた範囲での内容となります。

各項目についてこれから具体的にサンプルアプリケーションを立ち上げて検証していく過程で誤り等を発見し次第訂正していきます。