TCC2021 Team C
**学生街テイクアウトアプリ（仮）**
# MVP 技術構成案

飲食店のテイクアウト・店内飲食における**予約注文管理**および**集客**を目的としたモバイルアプリケーションシステム

## システム概要

### 構成図（準備中）

- F4C（Frontend for Consumers）
- F4S（Frontend for Stores）
- F4A（Frontend for Admins）
- BE（Backend）

### [F4C] 消費者ユーザー向けフロントエンド（モバイル）
- **基本要件**
- 電話認証（注文だけして逃げられるリスクを軽減）
- 店舗を選べる
- 店舗のメニューとクーポン一覧から好きなものを選べる
- 選んだものの合計金額を確認できる
- （決済はMVPではやらない）
- 予約注文を確定できる（テイクアウトまたは店内飲食を選べる）
- 商品準備のステータスを確認できる
- （商品準備が完了したら通知が来る）
- （ソーシャル機能 -> 具体化が必要）
- 候補
- **React Native**
- 言語: JS または TS
- メリット： Web と同じように書けるので学習コスト・実装コストが低い。 CSSによる自由なスタイリング。
- デメリット:
- **Flutter**
- 言語: Dart
- メリット: Material UI 標準搭載
- デメリット:

### [F4S] 店舗向けフロントエンド（モバイルまたはWeb）
- 基本要件
- ログインができる
- 店舗情報を編集できる
- 商品情報を編集できる
- 自店への注文リストを確認できる
- 注文リストの各注文の詳細情報を確認できる
- 各注文のステータス（未着手・着手・完成・提供可能・提供済）を変更できる
- 候補
- [F4C]と同じ + Webアプリ（React/Next）

### [F4A] 管理者向けフロントエンド（Web）
- 基本要件
- ログインができる
- （DBを編集できる）
- 候補
- **何もなし**
- DB を直接いじるだけなら、DB のフロントエンドを使えばいいのでは？
- **Retool**
- メリット: ローコード。
- デメリット: 管理しにくいのでは？
- **React/Next**
- メリット: スケールする。DBはあるのでそんなに大変じゃない。

### [BE] バックエンド
- **API**
- 基本要件
- 店舗 DB へのリクエスト処理（店舗情報の取得と編集）
- 商品 DB へのリクエスト処理（商品情報の取得と編集）
- 注文 DB へのリクエスト処理（注文リストの取得と注文の追加）
- 候補
- **Firebase Functions**
- 言語: JS
- メリット: 導入が楽。
- デメリット: 管理しにくい。できないことがあるからスケールしづらい。
- **Express.js**
- 言語: JS または TS
- インフラ: GAE、Heroku、Vercel など
- メリット: 書きやすい。自由に書けてスケールする。
- デメリット:
- **認証・認可**
- 基本要件
- 電話認証ができる（注文だけして逃げられるリスクを軽減）
- トークンで API 権限を制限できる
- 候補
- **Firebase Authentication**
- メリット: Auth0 より安価。他に代替がない。
- **DB**
- 基本要件
- 店舗 DB（店舗情報）
- 商品 DB（商品情報）
- 注文 DB（注文リスト）
- 消費者ユーザー DB（消費者ユーザー情報）
- 候補
- **RDB**（PostgreSQL、MySQL など）
- インフラ: GC SQL, AWS RDS, Heroku など
- メリット: ミッションクリティカルな目的では有用（決済など）
- デメリット: 遅い。厳密なデータモデリングを事前に設計する必要があって、面倒くさい（MVPには向かないのでは）
- **MongoDB**（NoSQL）
- インフラ: MongoDB Atlas（GCP/AWS/Azureからインスタンスを選べる）
- メリット: 高速。データモデリングが柔軟。
- デメリット:
- **FireStore**（NoSQL）
- インフラ: Firebase
- メリット: データモデリングが柔軟。
- デメリット: あまり複雑な構造にはできない。セキュリティルールに限界がある。