1 TL;DR
A restaurant and a bar under one name, run from one admin. A TypeScript API on Fastify covers orders, reservations, menus, events, coupons and analytics, and every endpoint is documented.
2 Context The problem
A restaurant and a bar under one name need two public faces, one for dining and one for drinks and events, run from a single admin. Orders, reservations, the menu, events, coupons and reporting have to share one data model, behind an HTTP API the admin UI can rely on.
3 What I built
- Designed the models: menu items, categories, orders, reservations, events, coupons, contact messages and admin users.
- Built the Fastify API in TypeScript, with admin login on JWT and bcrypt, image uploads, and menu import and export as CSV or Excel.
- Documented every endpoint with Swagger, served at /api/docs.
- Built the React admin: sales and order charts, order tracking, and editors for the menu, events and coupons.
- Added a read-only demo role: it opens every admin screen, and the API answers any change from it with 403.
4 Hard problems And how they were solved
One data model for several workflows
Orders, reservations, events and coupons had to share a model the admin could trust. Each workflow lives in its own Fastify route module and model, with the API contract in front of all of them.
Bulk menu changes without retyping
The API exports the menu as CSV or Excel and imports an edited file back, so prices change in a spreadsheet instead of item by item.
A read-only demo that is really read-only
The demo role is enforced in the API, not hidden in the UI: every write from it returns 403.
5 Results Real outcomes only
- A live demo at royalwow.websuprime.com, with a read-only admin login.
- A public GitHub repository you can read, run and judge.
- Swagger-documented APIs for orders, reservations, menus, events, coupons, messages and reporting.
6 Next revision
Porting the API to FastAPI and the data to PostgreSQL.
JSON for this page: curl rajshubham.com/api/v1/projects/royal-wow-meal-bar