本記事は AWS Amplify Advent Calendar 2020の18日目の記事です。
はじめに
Amplifyを使って爆速でサイト開発をする系の記事は多く存在しますが、いざ本格的にサイト開発に入るとまだまだ参考になる記事は、多くないように思います。
今回の記事では、そんなこれからAmplifyを本格的に使おうと考えている方へ向けて、これまで書いてきたAmplify記事の総集編とたまった知見の発表的な感じで記事を書いていきます。
AWS自体を全く知らない状態からAmplifyを始めて1年半、本当にAmplifyにはお世話になっていますので、この記事がAmplifyを利用する人の一助になり、少しでも還元になれば幸いです。
購読対象
- 爆速でサイトを作ってみたので、もっといろんな機能を使ってみたい
- これからAmplifyを使って本格的にサイト開発を考えている
- Amplifyの細かいバグにたくさんぶつかって楽しんでいる
Amplify初級〜中級程度の開発者が対象です。
各サービス知見まとめ
今回はAmplifyCLIを中心に、知っていると便利なことからドハマリ情報までまとめました。
Auth
このAuthのおかげで超簡単にAuth周りの設定を行うことができます。まだまだ基本的なことしか使えていないので、もっと深堀りしたいと思っているサービスNo1です。
【具体的な使い方の記事はこちら】
AWS amplify フレームワークの使い方Part1〜Auth設定編〜
[AWS Amplify フレームワークの使い方Part2〜Auth実践編〜]
(https://qiita.com/too/items/54992bb871fc1a2ab101)
[AWS Amplify フレームワークの使い方Part13〜Auth 設定更新編〜]
(https://qiita.com/too/items/52f35860bcb5bdf5e667)
初回にしか設定できない項目がある
サインインの方法や属性の設定などは、初回のamplify pushしたあとは変更できませんので、よく考えてから始めましょう。
GUIからどんな項目があって、設定変更が可能なのかを見てみるとAmplifyで何ができるのかイメージしやすいと思います。
GUIで変更はケースバイケース
基本は、GUIでの変更は行わなずにAmlifyCLIを通して行うことが推奨されますが、個人的にAuthについてはバグ回避やGUIならわかるのにamplifyCLIでどうやっていいかわからない場合ちょっとばかし触ってもいいかなと個人的には思っています。
例えば、メッセージ>カスタマイズ>メールアドレスのカスタマイズは、GUIからおこなっても全く問題ありません。
本当はCloudFormationのテンプレートファイルに記載してPUSHするのが一番スマートだとは思っていますが、テンプレートファイルの記載方法を調べる時間をなかなか作れず、さくっとGUIでやってしまっているというのが実情です。
推奨はしませんが、自己責任のもとGUIから操作する選択肢も持っておいてはいいのではないでしょうか。
API
Amplifyを使いこなすための要サービスです。一番お世話になっていて、一番苦しんだこのAPI。使えば使うほど素晴らしさを感じています。
【具体的な使い方の記事はこちら】
AWS Amplify フレームワークの使い方Part3〜API設定編〜
AWS Amplify フレームワークの使い方Part4〜API実践編〜
AWS Amplify フレームワークの使い方Part5〜GraphQL Transform @model編〜
[AWS Amplify フレームワークの使い方Part6〜GraphQL Transform @auth編〜]
(https://qiita.com/too/items/fae2879ea36f00c3ae10)
[AWS Amplify フレームワークの使い方Part7〜GraphQL Transform @key編〜]
(https://qiita.com/too/items/cb1dfb4f44536a3e9855)
AWS Amplify フレームワークの使い方Part8〜GraphQL Transform @connection編〜
AWS Amplify フレームワークの使い方Part16〜GraphQL Transform @function編〜
気軽にスキーマからテーブルを削除しない
何も紐付いていないテーブルの削除であれば何も問題有りませんが、functionに呼び出し権限を与えているなど何かしらamplify内で紐付いている場合、うっかり消してしまった日には、エラー祭りになり、APIを一度全て削除してやり直すしかなくなります。
スキーマからテーブルを削除するときは、amplify内でどこにも紐付いていないことを確認してから、削除するようにしましょう。
このあたり上手く連動して削除されるように早くなってくれないかな、、、。
APIと他のリソースを同時にpushするとgraphql内のqueryらが更新されない
これもいつかは改善されると思っていますが、知らないと地味にハマります。
複数のリソースの更新が重なった時は、$amplify push api
と実行して、APIリソースだけ先に更新しましょう。
複数の認証モードが利用できる
こちらも気づいたら対応していました。以下の4つの認証モードを併用が可能になっています。
- API Key
- IAM
- Cognito User Pool
- OpenID Connect
会員制のサイトの場合など、割と複数の認証モードは使えると便利なケースは多いと思います。
ただ使い方には、若干クセがあるように感じているので、また1記事くらいにまとめれたいいな、、、
@functionがすばらしい
@functionを知るまでは、Lambda関数については、管理はamplifyで行っていましたが、呼び出しについてはGUIから自作したAPIGatewayで行っていましたが、たった1つの設定でamplifyで呼び出しまで行えるようになるなんて、、、。
@authと併用すれば簡単に権限管理もできますので、本当に便利です。こういった機能が突然サービスに追加になっているので、こまめなチェックが必要だと改めて感じさせられました。
Function
始めの頃は、Lambdaのソースコード管理ってどうしよう、Serverless Frameworkとか使ってやるのかな?といろいろ思っていましたが、こちらを使えば一瞬でした。
アクセス権限も簡単に設定できますし、DynamoDBストリームのトリガー設定やレイヤーの作成など、どんどん使いやすくなっていっています。
【具体的な使い方の記事はこちら】
AWS Amplify フレームワークの使い方Part9〜Function 基礎編〜
AWS Amplify フレームワークの使い方Part11〜Function 権限管理編〜
[AWS Amplify フレームワークの使い方Part14〜Lambda レイヤー編〜]
(https://qiita.com/too/items/54de781085bd9a3a66d0)
関数削除の注意点
このfunctionを使いだした頃から、Amplifyで作成したリソースたちが、お互いのアクセス権限を付与しだします。
関数を削除する時は、必ず他のリソースに削除する関数へのアクセス権限が紐付いていないか確認しましょう。
ライブラリの手動インストール
私はNode.js環境でLambdaを実行していますが、package.jsonに必要なライブラリを記載して、追加した気になることがよくありました。基本的に自動ではインストールしてくれませんので、必ず自分でインストールしてからpushしましょう。(確か初回作成時のみ自動インストールしてくれた気がします。)
レイヤーが熱い
こちらも気づいたら追加されていたサービスの一つで、Lambda関数でのライブラリやコードの共通化を行うことができます。1関数5つまでの制限はありますが、それだけでも相当スッキリしたコードにできるので、本当にすばらしいですね。
私の場合は、割とGUIを使って細かいテストを繰り返し行うことが多いのですが、重たいライブラリを使っているとGUIからコード編集ができないので、ライブラリの共通化はテストのやりやすさにも役立っています。
素晴らしいこと満載のレイヤーですが、トラブルは割と起こりがちなので、気になる方は、上記の参考記事のレイヤー編をご確認ください。
DynamoDBストリームとの連携設定も簡単に
こちらも気づけば、functionの初回作成時にDynamoDBストリームとの紐付け設定ができるようになっておりました。
おそらくAmplifyCLI上では、初回時以外の設定変更項目は今のところない?(みつからない)ので、変更必要な場合はCloudformationファイルを変更する必要がありそうです。
Storage
Amplifyを通して簡単にCognitoユーザーのアクセス権限管理ができるS3を使うことができます。全然S3について知らない状態でもすぐに使えたので、ありがたい限りです。
【具体的な使い方の記事はこちら】
AWS Amplify フレームワークの使い方Part10〜Storage編〜
一定時間が経つとファイルが取得できなくなる
getして取得したURLにはtokenがついており、一定時間が経つと画像ファイルを取得できなくなります。
このURLを保存しておけば、わざわざidentityIdなんて知らなくてもicon画像取得し放題だ!と思ったもののしばらくすると取得できなくなるのでややハマりました。
これにより、identityIdと向き合うことになります。
protectedの場合、identityIdがわからないと取得できない
identityIdは各ユーザーに振られているuserIdとは別のcognitoが管理しているIDです。(ソーシャルログインをしてユーザープールにデータが作成されない人や未承認ユーザーを管理するためのもの?的なイメージ)
そんなあまり身近ではないidentityIdを使わずに、簡単に取得できる方法はないか?、と各方面で議論されているようですが、現状はまだ未実装のようです。
ただ、githubのissueでだいぶ議論されているようなので、そのうちひっそりと実装されている可能性はあるので、要チェックです。
identityIdの取得方法
とりあえずこれで取得できます。
const currentCredentials = await Auth.currentCredentials()
const identityId = currentCredentials.identityId
ENV
Amplifyを使って本気で開発をするのであれば、必須になるのがこちらです。開発環境と本番環境を簡単に分けられるだけでなく、各開発者ごとにバックエンドを簡単に複製できるので、めちゃくちゃ便利です。
【具体的な使い方の記事はこちら】
AWS Amplify フレームワークの使い方Part12〜ENV編〜
amplify env pull xxx(環境名)
多人数で同時開発する時は必ず必須のコマンドです。amplifyをローカル環境で何も触っていない時は、$amplify pull
で強制的にローカルのリソースを上書きすればよいですが、触っている時にはそうは行きません。
そんな時に、この$ amplify env pull xxx
でpullを行えば、現行のローカルのコードを残して、差分をローカルに上書きしてくれます。
知っていたら当たり前なことですが、このコマンドを知るまでは地味に苦労したことでした。
Hosting
気づいたら、AmplifyConsoleも選択ができるようになっていたこのHosting。私自身AmplifyConsoleを使ったGUIでの作業が中心で、今現在ほとんど触れていませんが、気づいたらどんどんできることが増えていそうなので、時が来たら一度向き合いたいと思っています。
WAFを使いたい
現状AmplifyConsoleでホスティングをした場合、CloudFrontの細かい設定は行えないため、WAFが利用できません。WAFを使いたい場合は、CloudFront+s3を選択してホスティングした上で、CloudFrontの設定を変更しましょう。
Amplify CLI全般
GUI上で各リソースを削除しない
これ絶対にやってはいけないやつです。Cloudformationで管理しているにもかかわらず、GUIで勝手に削除してしまうと、場合によってはすべて削除してAmplifyの設定を一からやり直す必要があります。Amplifyでaddしたものは必ずAmplifyでremoveすることを心掛けてください。
リソースにもよりますが、全く同じ名前で再度GUIから作成すると再認識してくれることがあるので、もしもの時は一度試してもいいかもしれません。
cloudformationのテンプレートに手を加えた時は気をつけて
自動生成されたcloudformationのテンプレートファイルに手書きでコードを足せば、amplifyCLIだけでは実現できない細かい設定まで対応できます。
が、その後にamplifyを使って更新するとその手書きしたコードは消えてしまいますので、注意が必要です。
だれかこの管理のベストプラクティスを知っている人がいたら教えていただきたい、、、。
消したはずのリソーストラブル
amplifyを通してちゃんとリソースを削除したはずなのに、なぜかamplify系ファイルの中にひっそりと残っていてエラーになることがあります。
その場合は、エラー分をよく読み、削除したはずのリソースなどで怒られているときは、その名前で検索をかけて、コード内から削除しましょう。私はこれで何度も救われました。
消した記憶のないコードトラブル
こちらは直近の記憶で起きたのはLambdaレイヤーで、amplify pullをした時などに、本来あるべきはずのコードが消えてしまい、エラーでpushがその後できなくなるということがありました。
この時は、team-provider-info.json
の差分を確認し、何故か消えているコードをもとに戻してpushすれば直りましたが、原因は未だに不明です。
よくあることではありませんが、何が悪いのかわからないエラーに出会った時は、一度差分を確認してみるといいことがあるかもしれません。
amplify push xxx yyy
リソースを指定してpushができます。例えば、echoFunctionというLambda関数だけ更新したい時は、$ amplify push function echoFunction
と実行すれば、他のリソースは更新されずに、echoFunctionのみ更新されます。地味に知っていると便利です。
--yes (-y)
以下のコマンドに--yes(-y) とつけるだけで、各作業工程のデフォルト値を自動で選択して進めてくれます。
地味ですが、いい活躍をしてくれます。
amplify init
amplify configure project
amplify push
amplify publish
amplify pull
SSR対応
今年ついにAmplifyがSSRに対応しましたね。素晴らしい。
AWS Amplify フレームワークの使い方Part15〜SSR対応導入編〜
AmplifyコンソールもSSR対応が検討されているようなので、こちらのissueはずっと注視しています。
https://github.com/aws-amplify/amplify-console/issues/412
ハマった時はすぐに公式ドキュメントとissueを見る
こちらは当たり前なことではありますが、困ったら公式ドキュメントとissueを見ましょう。
Amplifyはかなりのハイペースで改善と新機能の追加が繰り返されているので、これまでできなかったことができるようになっていたり、誰かがとりあえずの解決策をissueのコメントに上げてくれていることがよくあります。
環境の移動後のpushには注意
基本的には、環境を移動(amplify env checkout)したあとに、pushすれば、別の環境で整えた環境がそのまま同じように出来上がります。
単純な作業後にpushする分には問題有りませんが、たとえばLSIを設定したいから、一度テーブルを削除して再度追加したテーブルがある場合、移動した別環境でも同じことをしなければpushできませんので、そのあたり地味に注意が必要です。
git push/pull と amplify push/pull
何人かで開発をしていると起こりがちなのが、gitとamplifyのどちらかのpush/pullをし忘れによる、過去へのタイムリープ。大事にはならないことが多いですが、昨日作ったはずのリソースが消えている時は、だいたいこれです。
amplifyのpushをする時は、必ずgit pullとamplify pull、gitにpushする時は、事前のamplify pushを忘れずに行いましょう。
それでも人は失敗をする
気をつけていても、バックエンドを壊してしまうことはあるかもしれません。今のところ知っている最速での復旧方法を以下の記事に書いていますので、参考までに。
おわりに
本当にどんどん新しいサービスがAmplifyに追加されており、どんどん便利になっていっています。もっとAmplifyの利用者が増えてより活発に開発が進み、さらに便利になることをとても期待しております。
よきAmplifyライフを!!