【要約】富士山登頂記念に、AWS Blocks という山も少しずつ登ってみる（第1弾：五合目から八合目の山小屋へ ── 「地名→標高」アプリをローカル完結で） [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者が、フルスタックアプリの構築において、インフラ管理や環境差異の解消に多大な工数を費やす問題に直面している。具体的には以下の課題がある。
- ・API Gateway等のインフラ構築や、エンドポイントURLの管理に伴う手間。
- ・フロントエンドとバックエンド間の型不一致による、実行時の障害リスク。
- ・ローカル開発環境とAWS実環境における、リソース挙動の乖離。
// Approach
筆者は、AWS Blocksを採用し、インフラをコードから生成するIFC（Infrastructure from Code）アプローチによる開発を試みた。具体的な手法は以下の通りである。
- ・ApiNamespaceを用いた、バックエンドAPIの宣言的な定義。
- ・import { api } from 'aws-blocks' による、型安全なフロントエンドからの直接呼び出し。
- ・Building Block（DistributedTable等）による、環境に応じたリソースの自動切り替え。
// Result
筆者は、AWS Blocksを活用することで、AWSアカウント不要かつ費用0円での開発を実現した。得られた成果は以下の通りである。
- ・バックエンドの変更が、フロントエンドのビルド時に即座にエラーとして検知可能になった。
- ・npm run dev により、ローカル環境での迅速な動作確認を実現した。
- ・プレビュー版特有の型エラー（createLambdaHandlerの引数）を、1行の修正で解決した。
Senior Engineer Insight
> AWS Blocksは、インフラの抽象化により開発の認知負荷を劇的に下げる。特にAPIの型安全性がビルド時に担保される点は、大規模開発でのデグレ防止に極めて有効だ。ただし、プレビュー版ゆえのテンプレートの不備や、非Blockサービス利用時のモック作成コストには注意が必要である。実戦投入には、抽象化レイヤーが提供するリソースの挙動を深く理解することが求められる。