AWSって何？
Amplifyって何？美味しいの？
唐突にAWS案件を担当することになってから早1年。
溜まらなかった知見をあの頃の僕に捧げる......
AWS Amplifyは、フロントエンドとバックエンドを統合的に開発・運用できるフルスタッククラウドサービスです。
主な特徴
- 簡単なバックエンド構築（認証、データベース、ストレージなど）
- フルマネージドなホスティング（VueやReactなどのSPAをデプロイ可能）
- GraphQL & REST API サポート（AppSyncやAPI Gatewayと連携）
- CI/CD機能（Gitリポジトリと連携し、自動デプロイ）
フロントエンド開発者がクラウド機能を手軽に利用できるのが強みです。
CHATGPT
プロジェクトの構成はCLIで楽々。
クライアントではライブラリを読み込んで各リソースと楽々接続。
- DynamoDB
- S3
- API-Gateway
- AppSync
- Cognito
- Lambda
等のAWSリソースをポンっと作り、アプリに用いる事ができます。
また、ホスティング機能もあり、ブランチ設定での自動デプロイ、ドメイン設定やリダイレクト設定など様々設定できる。
つまりCLIを叩けばあらゆるリソースを自動で作成し紐づけてくれます。
なんて素晴らしいツールなんだ！！！！！
以下、Amplifyの感想は、AmplifyどころかAWSの経験ゼロのチームで体験した開発での主観となっています。
ビミョーなところ
- Amplify-Push地獄
- Amplify pullバグ
- Amplify env checkoutが効かない
- amplify固有のファイルへの理解が難しい
- CLIがそもそも低機能
- 処理のブラックボックス化
- 複数人作業にとにかく向かない
- CLIでのリソース反映とAWSコンソールでのリソース反映が合致しない
そして、実際にAmplifyを使った開発で何が起きたか。
.....→→→→→→→→.....
CLIの遅さ / amplify_push
例えばLambdaを新たに作成し、アプリと接続する場合。
作成にはamplify add functionコマンドを使用するが、これだけではローカルにしかリソースは反映されていない。
そしてこの状態ではAPIを通した実行はできない。
バックエンド環境に反映するためにはamplify pushコマンドを実行する必要がある。
これが問題で、コード規模にはよるもののamplify pushには毎度、2分~10分程の時間がかかる。
ローカルだけでLambdaをテストする為に、event.jsonを書いてamplify mock functionを実行することもできるが、複雑なリクエストともなるとやはり本物のクライアントから試したい場合も多い。
また、mock functionでテストする場合にもストレージリソースはバックエンド環境のものが使われてしまうのも少々厄介である。
もちろんLambda新規作成のときのみではなく、1行でもコードを変更してバックエンド環境に反映が必要な場合はamplify pushが必要となる。
つまりバックエンド開発をしている最中に頻繁に5分やら10分やらのタイムロスが生じることになる。
これは本当に厄介で、正直バックエンド開発の2割ほどはこのpushを含めたCLIの遅さで時間を喰っていたように思う。
開発した感覚では、小規模のLambdaコードなら2分ほど、中規模のコードならば毎回5,6分はかかった。
早く終る場合もあったが、何が影響していたかは定かではなく、修正箇所が小規模でも、全体が中規模のLambdaであれば5分かかるなど、本当に挙動がよくわからなかった。
amplify push以外にも、amplify pull,amplify checkout...その他にもリソースを管理するコマンドがいくつもあり、何をするにも最低1分ほど待たされることになる。
小規模ならまだしも、そこそこの規模の開発になるだけでかなりのストレスになることだろう.....。
また、細かいところでも不満がある。
CLIのプロセス表示では、現在のコマンドの進捗がターミナル上に表示されるが、プログレスバーが全体に表示され、毎秒更新される仕様。
終了後は毎秒書き換えられたプログレスバーの絵でターミナルの履歴が埋め尽くされ、満足に眺めることもできない（こうならないようにもできるはずだよな...？）
加えて、コマンド実行の際の実行確認すら粗末。
実行してよいかを「y/n」で聞かれるが、キー判定をif-elseでやってるのか、amplify pushでは、「n」でなければ何のキーでも実行された。
amplify pullでは、Yを入力してからEnterを押すと実行されるが、pushの場合は、Yを入力した瞬間に実行される。
不具合と呼んでいいだろうエラーも頻繁に発生。
pullの際はVSCodeで同ディレクトリを開いているだけでResource EBusyなるエラーが現れたり。
何かエラーを起こした場合もエラー理由が凄まじくあいまいで、ググってもAWS節が炸裂する公式ページしか出てこない場合も多く、正直初学者にはとても手に負えなかった。
Resource is not in the state stackUpdateComplete
Name: lambdaexecutionpolicy (AWS::IAM:Policy),Event Type: create, Reason: Resource handler returned message: "Resource storagedynamoIDIDIDIDArn must be in AR format or "*".(Service: Iam, Status Code: 400, Request ID: {})" (RequestToken: {},HandlerErrorCode: InvalidRequest), IsCustomResource: false
一番ひどかったのは🛑 Environment name is invalid.
Amplifyではバックエンドリソースを環境名で開発/検証というように分けて、切り替えることができるのだが、その切替コマンドcheckoutで環境が存在しているにも関わらず、上記エラーが頻繁に発生し、その度に再度amplifyフォルダを削除し再度pullしなおすという作業を余儀なくされた。
こういうエラー？バグ？にはプロジェクト内に自動作成されるamplify固有のファイルbackend-config.json等、も大いに関係していそうだが、どのパラメータがどこに繋がっているかが全く分からなかった。
複数人作業にとにかく向かない
既にこの問題に直面している方や、ここまで読んでお気づきの方もいるかと思うのだが、amplify Gen1は本当に複数人作業に向いていない。
Amplifyでは、バックエンド環境、つまりAWSリソース群が環境envごとに作られる。
そして、これらをローカルに配置することはできない。
何も考えずに開発を始めるとする。
開発者Aと開発者Bは必然的に、同じバックエンド環境に接続することとなり、お互いが好き勝手にamplify pushしてしまうと………。
amplify pushとは「リモート環境をローカル環境コードで上書きする」事であるので、当然ながらamplify pullした時点でのコード+開発者自身が変更した部分の反映となるので、もう一方の開発者が書いたコードは消えてしまう。
自動でマージでもしてくれれば幾分かマシなのだが、そんな機能は無いため、なんとかGit操作で頑張りつつ、変更を保つことになる。
当然ながら、チームのチャットには「Amplify Push」なるチャンネルが作成され、毎日のようにお互いのpush報告が飛び交うことになった....
ネット上で事例を見る限りは、開発者ごとにenvを立てているようなところもあるみたいだが、予算的にも馬鹿にならないので、そのような手が打てるところはかなり恵まれていると言えるだろう。
処理のブラックボックス化 / 固有ファイルの存在
Amplifyはローカルコードでのリソース定義変更に応じて、リソースを再構成しているらしいのだが、何か変更する際、何がトリガーになって何が変更されるか全く読めず……………
Amplifyとは要するにCLIで半自動的にリソース管理が可能というコンセプトなので、どうしようもない部分ではあるのだが、どうしてもいろいろな個所の処理がブラックボックス化してしまい、不具合が起きた場合や調査する場合など、目で見えないところを手探りでやってる感覚が否めなかった。
CLIリソース反映とAWSコンソール操作の競合
Amplifyは基本、CLIのみでリソースを管理することを前提としている。
その為、AWSコンソール側でリソースを変更してもCLI側には反映されず、amplify pushなどのタイミングで消されてしまう場合も多い。
（Lambdaの実行権限など）
Lambda実行権限などはCloudFormationテンプレートファイルがあるのでこれを編集する必要がある。
細かなカスタマイズが必要であれば、’override.ts’なるファイルが各リソース種別ごとに存在するのでこれに記載し、仕様を調整することとなる。
まとめ / 本当にAmplifyを使う必要があるのか？
結局のところ、おそらくAmplifyのリソース操作の大半はCloudformationによるものがほとんどだという話(完璧に理解しているわけでもないので推測だが)。
どの道、各機能の権限制御や接続、インフラ系の管理するためにリソースを整理する必要があるのなら、わざわざAmplifyに手を汚す必要は全くないようにも思える。
（ちなみに、Amplifyを使用するとAmplifyリソース管理のためなのか謎のリソースがS3に作成される。）
各リソースをきちんと設計して接続するように作るほうが後のことを考えるといい気がする。
Amplifyの利点は、Amplifyホスティングによる自動デプロイやホスティング設定の簡略化。
加えて、クライアントライブラリに関しては非常に使い勝手がいい(S3へのアクセスなどは非常に簡潔に記載できる)ので、ここらが要になると思っている。
反対に、バックエンドのデプロイに関しては、特に開発環境での労力があまりに大きく、開発後半になればなるほどバックエンド環境への反映作業が重荷になっていく現実があった。
印象とは反対に、商用や大規模開発には向かないように思えるし、逆に個人開発でAWSのメジャーサービスを一通り触ってみたいぐらいのレベルでフィットするのかもしれない。
結論
弱小チームにAmplifyはきつかった！！！
とはいえ、Amplifyは「v2」がリリースされており、使ってみた記事も出始めている。
v2では開発者のローカル環境にサンドボックスなる仮想環境が作成され、デバッグもそこで可能とのことなので、v1のamplify push地獄問題はひとまずv2では解決されたようにも思える。
まだ使ったことはないため、結局のところ、全体的なCLIのクオリティや、カスタマイズの煩雑さなどがどこまで解消・向上されているかが個人的に気になるところです。
Amplifyでうまくいった！という経験がある有識者の方、コメントください...。
以上！