Movie Booking Platform
A full-stack movie booking web app with authentication and booking history, on the MERN stack.
A complete authenticated booking flow — accounts, listings, bookings — built end to end on the MERN stack as a full-stack exercise in RESTful API design, not a wrapper around a single feature.
Requirements
- A working authentication flow with real session/account state, not a stubbed login
- Three independently addressable REST resources (accounts, listings, bookings) rather than one monolithic endpoint
- A booking-history view so users see their own state, not just a one-way create action
Problem
- Building a complete, authenticated booking flow end-to-end — accounts, listings, and bookings — as a full-stack exercise in RESTful API design.
Architecture
- Express.js/Node.js REST API with endpoints for user accounts, movie listings, and bookings, backed by MongoDB.
- React frontend consumes the same REST endpoints, with Bootstrap handling responsive layout.
API Design
- Three REST resources — /accounts, /listings, /bookings — each with its own route module rather than one shared controller, following standard REST resource conventions.
Database
- MongoDB, a single shared instance across all three resources — a document model was a natural fit for the mostly-independent, mostly-flat shape of accounts, listings, and bookings.
Authentication
Handled as its own resource module (/accounts), kept separate from listings and bookings specifically so auth logic doesn't leak into unrelated routes. No rate limiting on login attempts yet — flagged directly in the roadmap as the most security-relevant gap in the current implementation.
Infrastructure
- A standard Node.js/Express process serves the API, with the React frontend built and served separately.
Deployment
- Deployed as a conventional Node.js app — no CI/CD pipeline was built for this project the way it was for the media pipeline, since the focus here was REST API and full-stack design rather than automation.
Monitoring
No formal monitoring or logging infrastructure — errors currently surface the same way any Express app's unhandled errors do, in process logs. Reasonable for the traffic this project has actually seen; would need real logging/alerting before production traffic.
Engineering Decisions
- Implemented user authentication and a booking-history view so users can see their own booking state, not just create new ones.
- Designed the API surface (accounts / listings / bookings) as separate resources rather than one monolithic endpoint, matching standard REST conventions.
Challenges & Trade-offs
- Keeping booking state consistent between the client and MongoDB without a real-time layer — handled with straightforward request/response REST calls rather than adding unnecessary complexity.
Performance
- No formal load testing has been done — at the traffic this project has actually seen, a single shared MongoDB instance with no caching layer has been sufficient.
Scaling
- The Express API is a stateless Node process — the layer most straightforward to scale horizontally behind a load balancer if traffic grew.
- MongoDB is a single shared instance across all three resources today; the first real scaling move would be splitting the write-heavy bookings collection onto its own resource.
- Listings is the best caching candidate, since listing data changes far less often than bookings.
Lessons Learned
- This project is where the REST API design habits used in the later, backend-focused projects were first formed.
Future Roadmap
- Add rate limiting on the auth endpoints and an atomic check to prevent race-condition double bookings on the same slot.
Process timeline
The real execution order of this system, stage by stage — not a development calendar, the actual request/data flow, with what dominates time at each step (also explorable interactively above via "Trace a request").
- 1React frontendNo client-side caching means every view re-fetches from the API, even for data that rarely changes, like listings.
- 2Express.js APIStateless Node process — the layer most straightforward to scale horizontally if traffic grew.
- 3/accountsLow request volume expected relative to listings/bookings — not a current bottleneck.
- 4/listingsRead-heavy and the best candidate for caching — listings change far less often than bookings.
- 5/bookingsWrite-heavy — the first resource likely to need its own scaling path under real load.
- 6MongoDBNo connection pooling tuning done yet — a concurrency spike could exhaust default connections before any single collection becomes the bottleneck.
Code examples
Where each piece actually lives in the repository — pointers to the real source, not reconstructed snippets. Browse the full repo →
client/src/React frontendserver/routes/Express.js APIserver/routes/accounts.js/accountsserver/routes/listings.js/listingsserver/routes/bookings.js/bookingsserver/db/connection.jsMongoDB