FirebaseによるカスタムEコマース構築
既存のプラットフォームを使わず、ゼロからカスタムEコマースサイトを構築しました。Firebase Realtime DatabaseとNetlifyを使用しています。
目的は、POS端末の販売代理店向けにサービスを提供することでした。彼らにはカタログ、価格バリエーション、および管理パネルが必要でした。また、営業チームがサイトから直接注文を行えるようにする必要がありました。
以下に、構築方法と学んだ教訓をまとめます。
使用技術 (The Stack)
• Vanilla HTML, CSS, JS • データ管理にFirebase Realtime Database • ファイル保存にFirebase Storage • ホスティングとFunctionsにNetlify
主要な決定事項
1. データベースの分離
Eコマース用のデータベースを内部管理用のデータベースとは別にしました。これにより、商用データが給与や予算などの機密性の高い管理データと混ざるのを防いでいます。
2. グローバルな価格アーカイブ
各製品の中に価格プランを組み込むのではなく、グローバルな料金（tariffs）フォルダを作成しました。製品側にはIDの配列のみを持たせています。これによりデータの重複を避け、プランが変更された際も一度の更新で済みます。
3. アトミックな注文処理
複数のユーザーが同時に注文を行うと、レースコンディション（競合状態）が発生します。もし2人が同じ注文番号を読み取ってしまうと、一方の注文が消失してしまう可能性があります。そこで、Firebaseの runTransaction() を使用して、すべての注文に一意かつ連続した番号が割り当てられるようにしました。
4. 安全な管理者アクセス
ソースコード内にパスワードを保存しませんでした。Web Crypto APIを介してPBKDF2を使用しています。これにより、ブルートフォース攻撃を非常に困難にしています。コードにはソルト（salt）とハッシュ（hash）のみが含まれています。
学んだ教訓
• falsyな値に注意する。 JavaScriptでは 0 はfalsyです。製品価格が 0 の場合、"price || null" のような単純なチェックを行うと、価格が削除されてしまいます。0 を含めるには、常に "price != null" を使用してください。
• HTTPヘッダーでCSPを設定する。 Content Security Policyのメタタグは、サブドメインのワイルドカードをサポートしていません。Firebaseは動的なサブドメインを使用するため、動作させるためにCSPを netlify.toml に移動しました。
• 本格的な保護にはSecurity Rulesを使用する。 UI上でボタンを隠すことに頼ってはいけません。Firebaseのルールを使用して、誰がデータを読み書きできるかを制限してください。
カスタムソリューションの構築には、慎重なアーキテクチャの選択が求められます。トランザクション処理やヘッダー設定といった細かなディテールが、本番環境での重大な失敗を防いでくれます。
出典: https://dev.to/androve2k/custom-e-commerce-on-firebase-catalog-atomic-orders-and-admin-panel-42ec