Firebase Cloud Functions の実体調査 — Webhook 処理は過度なインフラ

背景

Enterprise フレームワークからエッジコンピューティングへの移行時、既存の Firebase Cloud Functions の必要性を再評価。

発見

Firebase Cloud Functions で実装していた sendMail の実体は単なる Slack Incoming Webhook への POST。

// Firebase Cloud Functions の実体
export const sendMail = httpsCallable(async (data) => {
  return fetch('https://hooks.slack.com/services/...', {
    method: 'POST',
    body: JSON.stringify({ text: message })
  });
});

問題点

• GCP インスタンス起動、スケーリング、ホスト、監視の複雑さ
• コールドスタート遅延
• 固定コスト（Active プロジェクト課金）
• 学習コスト・運用オーバーヘッド

解決策

エッジ関数（CF Pages Functions）で同じ処理を 1 行で実装。

// CF Pages Functions (functions/contact.ts)
export const onRequest: PagesFunction = async (context) => {
  const { name, email, message } = await context.request.json();

  await fetch('https://hooks.slack.com/services/...', {
    method: 'POST',
    body: JSON.stringify({ text: `${name}: ${message}` })
  });

  return new Response('OK');
};

学び

インフラの複雑さは必要性から逆算すべき。 単純な webhook 処理には GCP VM より CF Functions の方が適切。デプロイも自動。

移行メリット

• デプロイが簡単（functions/ に置くだけ）
• コールドスタートなし
• 従量課金（Free 10万req/日）
• 監視・スケーリング不要