High-Level Architecture Diagram
The flow of data across client, integration, backend, and storage layers, highlighting the shift to Cloud Firestore.
Component Details & Firestore Adaptation
1. Client Layer (Frontend)
Technology: Flutter (Dart)
Uses local Hive/sqflite for offline caching. All cloud communication routes through the API Gateway for security.
2. Authentication & Security
Technology: Firebase Authentication
Manages user identities and issues JWT tokens for authorized API access.
3. Integration Layer
Technology: Google API Gateway
Single entry point that validates tokens and routes requests to specific Cloud Functions.
4. Backend Compute Layer
Technology: Google Cloud Functions (Python)
- cf-master-data: CRUD for ingredients/suppliers.
- cf-transact: Handles "Menu Waste Explosion" via batch writes.
- cf-sync-handler: Processes batched offline data.
- cf-ocr-processor: Orchestrates OCR.space integration.
5. Data & Storage Layer
Database: Google Cloud Firestore (NoSQL)
Denormalized document structure for read efficiency. Invoices store line items as embedded arrays.
{
"supplierId": "sup_A123",
"lineItems": [
{"ingredientId": "ing_55", "qty": 10}
]
}
Key Architectural Flows
The OCR Invoice Processing Flow
The Menu Waste "Explosion" Flow
When a chef logs finished dish waste, the system atomizes the impact on raw ingredients.
- Fetch: Retrieves recipe data from the Menu Item document.
- Calculate: Multiplies wasted portions by recipe quantities.
- Batch: Initiates a Firestore Batch operation.
- Commit: Logs both Menu Waste and multiple Ingredient Waste entries atomically.
// Logic Example
portions = 2
recipe = {"beef": "6oz", "bun": 1}
Total Waste:
beef_waste = 12oz
bun_waste = 2 units
Architectural Impact
This NoSQL approach eliminates complex joins and migrations, allowing the data model to evolve alongside the hotel's operational needs while maintaining high performance.