Restaurant Management System - Backend API

Project Overview

A production-ready RESTful backend for restaurant operations — authentication, menu browsing, order processing, table management, and reviews — with granular role-based access control across 3 roles and 30+ endpoints. Deployed on AWS EC2 with an Elastic IP for a stable endpoint.

Stack

Node.js 20 + Express 5, Prisma ORM (SQLite in dev, PostgreSQL in prod), JWT dual-token auth, bcrypt (10 rounds), Zod validation, Helmet, a CORS whitelist, express-rate-limit, and gzip compression. 14 strategic indexes keep queries fast.

Database Design

Seven normalized entities: Users, Categories, MenuItems, Tables, Orders, OrderItems, and Reviews. Two patterns are central:

• Price snapshot — when an order is created, the current menu price is copied into OrderItem.price so historical totals stay accurate even after menu prices change.
• Cascade strategy — CASCADE where children are integral (Order to OrderItem, reviews), RESTRICT to protect referenced data (cannot delete users or items with history), and SET NULL for tables so orders survive table removal.

Authentication & Authorization

Dual-token JWT balances security and UX: a 15-minute access token (memory-only) authorizes requests, while a 7-day refresh token issues new access tokens without re-login — stateless, revocable, and low-exposure.

Role-based access control spans 30+ endpoints across three roles:

Authorization is enforced by composable middleware — authenticateToken, then requireRole([...]), then an ownership check — so CUSTOMER queries are automatically scoped to their own userId.

Order Workflow

Orders follow a strict state machine; skipping states is rejected, and terminal states drive table status:

PENDING → CONFIRMED → PREPARING → READY → COMPLETED
    ↓
CANCELLED

Order creation validates item availability, quantity bounds (1–20), and order type (DINE_IN requires an available table; TAKEAWAY/DELIVERY must not specify one). It generates an ORD-YYYYMMDD-XXXX number, snapshots prices, and sums the total atomically.

Querying, Tables & Reviews

• Filtering — every collection endpoint supports pagination (page, limit up to 100), full-text search, sortBy/order, plus resource filters (category, price range, availability, status, date range), and returns pagination metadata.
• Table status — updates automatically from order lifecycle events: a DINE_IN order sets a table OCCUPIED; completion or cancellation of the last active order returns it to AVAILABLE; staff can manually set RESERVED.
• Reviews — verified only: a user can review an item only after a COMPLETED order containing it, with a unique (userId, menuItemId) constraint preventing duplicates.

Security & Deployment

Zod validates every request body (email format, password strength, enum values, numeric ranges, length limits, and custom refinements). Helmet sets security headers, CORS uses an origin whitelist, and critical endpoints are rate-limited (login and reviews 5 per 15 min, orders 10 per 15 min). bcrypt hashes passwords with constant-time comparison.

Deployed on an AWS EC2 t2.micro (Ubuntu 22.04) with a static Elastic IP (44.216.9.251), PM2 process management, and Nginx as a reverse proxy. Indexed queries stay under 50ms even at scale; login is intentionally slower due to bcrypt hashing.

Key Takeaways

• The price snapshot pattern is essential for immutable, historically accurate financial records.
• Dual-token JWT gives short-exposure access tokens without constant re-authentication.
• Role scoping must be explicit — always filter CUSTOMER queries by userId to prevent data leakage.
• A server-side state machine prevents invalid business transitions; strategic indexes prevent performance decay.

Repository: restaurant-api · Live API: 44.216.9.251/api · Course: Web Programming, Hasanuddin University, 2025