Restaurant Ordering System — Full-Stack Product Platform
A full-stack restaurant ordering and operations platform: Next.js frontend, ASP.NET Core API, PostgreSQL, SignalR live kitchen updates, role-based dashboards, Docker/DevContainer setup, CI and documented architecture.
- Role
- Product / Full-Stack Engineering
- Status
- Open Source
This project is the clearest Product / Full-Stack proof in the portfolio: a complete restaurant ordering platform with role-specific workflows, real-time kitchen updates, backend APIs, relational persistence, tests, CI and documentation.
The important part is not that it has many features. The important part is that the product surface, backend boundaries, operational setup and technical documentation were designed as one system.
- ▸Role-based workflows for admin, waiter and kitchen staff
- ▸Real-time order status updates for kitchen operations
- ▸Menu, table, reservation, user and order management
- ▸Relational data model with migrations and seeded development data
- ▸Reproducible setup through Docker Compose and VS Code DevContainer
- ▸CI, automated tests and technical documentation
- ▸IHK project scope: complete enough to demonstrate product, architecture, implementation and documentation inside a fixed assessment window
- ▸Small-team/solo ownership: decisions had to optimize for clarity, testability and maintainability
- ▸Operational realism without unnecessary enterprise ceremony
- ▸Product completeness vs. assessment scope: focus stayed on role workflows, order lifecycle, data model and delivery evidence.
- ▸Real-time UX vs. implementation complexity: SignalR adds moving parts, but directly supports the kitchen workflow.
- ▸Reusable architecture vs. demo speed: layered backend and docs took longer, but made the system reviewable.
- ▸JWT authentication with refresh-token flow
- ▸Role-based access for admin, waiter and kitchen surfaces
- ▸Password hashing via BCrypt
- ▸EF Core migrations keep schema changes explicit
- ▸Paginated API responses avoid unbounded list endpoints
- ▸Dockerized services make local smoke tests repeatable
- ▸xUnit backend tests with FluentAssertions and Moq
- ▸Playwright E2E coverage for critical user flows
- ▸GitHub Actions CI workflow in the public repository
- ▸Docker Compose for production-like local stack
- ▸DevContainer for consistent review and onboarding
- ▸Swagger/OpenAPI for API inspection
- ▸Documented domain model, architecture and API reference
- ▸IHK final project assessed with 99/100 points
- ▸Public repository with full-stack implementation, CI badge and documentation structure
- ▸Concrete product proof: role dashboards, live order flow, API, persistence and repeatable setup
- ▸Public repository: github.com/amariwan/restaurant-ordering-system
- ▸README documents .NET 10, Next.js 16, PostgreSQL 18, SignalR, Docker Compose, GitHub Actions CI, xUnit and Playwright
- ▸IHK final project result: 99/100
- ▸Full-stack credibility comes from connected workflows, not isolated screens.
- ▸A reviewable system needs docs, setup and tests at the same level of care as UI features.
problem
A restaurant needs more than a menu UI: waiters must create orders quickly, kitchen staff need live status updates, admins need menu/table/user management and the system has to stay understandable enough to operate and extend.
context
Built as a complete product-grade full-stack system and documented as the IHK final project. The implementation combines a typed web frontend, layered backend API, relational model, real-time kitchen flow and a reproducible local/development setup.
requirements
constraints
architecture
Browser clients use a Next.js App Router frontend with role-specific screens. The ASP.NET Core API owns application logic, authentication and SignalR hubs. EF Core maps the domain model to PostgreSQL; Docker Compose and DevContainer scripts reproduce the stack locally. GitHub Actions runs the delivery checks.
key decisions
Why: The domain needs clear boundaries around ordering, users, payments, tables and kitchen events; a typed backend keeps those contracts explicit and testable.
More project structure and setup than a single JavaScript app, but stronger separation between product UI and business logic.
Why: Kitchen status changes are operational events; polling would make the product feel stale and add avoidable backend load.
Adds connection lifecycle handling and E2E surface area, but makes the core workflow real-time.
Why: The stack spans frontend, backend and PostgreSQL; reproducibility matters more than shaving a few lines from setup docs.
Requires Docker locally, but drastically reduces environment drift during review and maintenance.