こちらは AWS AmplifyとAWS×フロントエンド #AWSAmplifyJP Advent Calendar 2024 の 25日目の記事です。

みなさまこんにちは。tacckです。

2024年11月15日に TSKaigi Kansai 2024 にて登壇する機会をいただきました。

Amplify Gen2 Deep Dive / バックエンドの型をいかにしてフロントエンドへ伝えるか という内容で発表させてもらったので、そこで得た知見を少しまとめたいと思います。

概要

Amplify Gen2 で得られる開発者体験(Developer Experience)の向上のうち、 Sandbox が CDK を実際に呼び出すまでの流れを追ってみました。

結果、 yargs パッケージを使ってCLIとしての実装が行なわれており、 execa パッケージを使って CDK のコマンドを実行する、という流れを読み解くことができました。

内容

起点から CDK コマンド実行箇所までのフロー

コードを追ったファイルのフローは、下記のような形になりました。

文字も見えづらいので、さらに概要を記載していきます。

packages/cli/src/

ここが起点です。 実行は npx ampx sandbox と行なうので、 ampx コマンドの実装から読み始めます。

ampx.ts / main_parser_factory.ts

ampx.ts には yargs を使うことを前提として、パーサーの呼び出しと実行が実装されています。

main_parser_factory.ts の方で、オプションの sandbox の場合の実行内容を呼び出すようになっています。

packages/cli/src/commands/sandbox/

sandbox_command_factory.ts / sandbox_command.ts

sandbox オプションの定義と実行内容の登録(の具体的内容としてCDKの呼び出し)を行なう箇所になります。

この辺りは、 yargs の実行処理の登録方法、という感じなので、ぱっと見のコードの繋がりがわかりにくくなっています。 ここは、慣れが必要そう。

packages/sandbox/src/

sandbox_singleton_factory.ts / file_watching_sandbox.ts / sandbox_executor.ts

ここは、 Amplify Gen2 の sandbox らしい動きが具体的に実装されていくところになります。

./amplify ディレクトリ以下のファイル更新を監視し、更新があれば処理を実行、、というのはここで実装されています。

「更新時の実行処理」としてバックエンドのデプロイ処理に繋がっています。

packages/backend-deployer/src/

cdk_deployer_singleton_factory.ts / cdk_deployer.ts

バックエンドのデプロイ処理として、具体的に CDK コマンドやオプションが実装されています。

CDKのバージョンアップなどによってオプションが変更された場合は、ここの実装が変更されることになりそうです。

packages/cli-core/src/package-manager-controller/

ここで、実際の CDK コマンドを呼び出すための処理が実装されています。

途中でパッケージマネージャー(NPMなど)に応じたクラスを挟んで、 execa パッケージの呼び出し処理に繋がっています。

そして、 execa に先に実装された CDK コマンドやオプションが渡されて、無事に CDK が実行されていきます。

感想

sandbox が実装されて便利になった、ということの裏側が、具体的にどのように実装されているのかを知ることができました。

表面的には CDK を呼んでいる、というのはわかっていても、意外と複雑な実装になっていて驚きました。 ただ、それぞれの階層の意味を見ていくと、考えられた階層に分けられているというのもわかります。

例えば、CDKを使わないでデプロイする手段があった場合は、 packages/backend-deployer/src/ このレイヤーにその実装を行なって切り替えられるようにする、というのもイメージがつきます。

今回を契機に Amplify Gen2 の内部のコードを読むための知識を少し手に入れたので、コミットにも挑戦していきたいと思います。