この記事で振り返る範囲

• CDK で教材管理 API を構築開始
• 画像系 API/S3 連携の実装
• Route53/ACM/API Gateway/CloudFront への接続

当時の流れ（抜粋）

• be93fff4 (2024-10-08) 教材管理サービスを CDK で作成
• b8b23576 (2024-10-16) プリント管理サービスを CDK で構築
• 56f78e97 (2024-10-24) 画像追加処理を S3/Lambda/API Gateway で実装
• 5302659b (2024-10-25) 画像操作 Lambda の追加
• dcc93640 (2025-01-26) Route53/ACM 生成 CDK の仮実装
• 8e9c21c8 (2025-01-26) API Gateway カスタムドメインと Route53 エイリアス設定
• fe348b4c (2025-02-04) React を CloudFront 配信する CDK を追加
• 318e65c9 (2025-02-13) Lambda で Puppeteer 実行とサムネイル生成

学び

1. 先に API の枠組みを作ると UI 実装が進みやすい

フロントの編集体験を詰めるフェーズでも、保存・更新・取得の API が先に立つことで機能統合がスムーズになります。

2. ドメインと配信は「後回しにしない」方が安全

Route53/ACM/API Gateway/CloudFront を早めに接続しておくと、ローカルでは見えない CORS・証明書・キャッシュの問題を早期に検知できます。

3. サムネイル生成は別系統で設計する

Puppeteer を含む重い処理は、編集 API と同居させず非同期系として分離する設計が運用上有利でした。

この時期が現在に残したもの

現在の Printeach の中核である「編集 UI + API + 配信基盤」の基本形は、この時期にほぼ出来上がっています。機能追加の多くは、この土台を拡張する形で進んでいます。

参考コミット

• be93fff4 (2024-10-08)
• b8b23576 (2024-10-16)
• 56f78e97 (2024-10-24)
• 5302659b (2024-10-25)
• dcc93640 (2025-01-26)
• 8e9c21c8 (2025-01-26)
• fe348b4c (2025-02-04)
• 318e65c9 (2025-02-13)