Hostel Den
Hostel bookings on one REST contract for Next.js admin and React Native staff tools.
- Role
- Web + Mobile Development
- Type
- Booking + staff operations
- Client
- Hostel Den
- Status
- Live
Hostel Den
Screenshot pending
Outcome
Staff and public booking share one state machine; concurrent edits lose in the API with a clear error instead of silent double-books.
Operators split bookings, rooms, and guest comms across tools. Simultaneous staff edits could overlap inventory. Mobile booking dropped off when the funnel was long. Reporting belonged on web, not in a deep mobile nav.
Single REST contract. Server-side overlap checks on create/update. Inventory mutations serialized per room or date bucket. React Native scoped to daily tasks; heavy reporting stays on web.
- Frontend
- Next.js for marketing and authenticated admin. SSR/server components where they cut static-page JS.
- Backend
- REST used by both web and RN. State machine in the API.
- Databases
- MongoDB: bookings, rooms, guests. Compound indexes on propertyId + date range for conflict checks.
- Auth
- Token in secure storage on RN; cookie/session on web admin as implemented.
- Deployment
- Web at hostelden.com. Store listings not claimed here.
- Booking states (held / confirmed / checked-in / closed) enforced in the API
- Admin availability uses the same endpoints as public booking
- React Native: stack nav, refresh-on-focus for ops data, offline-tolerant reads where acceptable
- Pricing rules as data the API interprets; UI is an editor
- Guest funnel with field-path validation
Challenge
Simultaneous updates created booking conflicts.
Decision
Conditional updates / transactions on the write path — last confirmation does not silently win.
Implementation
Overlap query + guarded insert. Losers get a conflict response; UI shows dates no longer available.
Result
Bad inventory is an API error, not a silent overlap. No invented 'zero double-book' SLA.
Challenge
Staff needed phones on the floor without a full admin console.
Decision
Split surfaces: RN for daily tasks, Next.js for admin/reporting.
Implementation
Shallow RN navigation for check-in, room flip, notes. Same types as web where practical.
Result
Mobile stays operable; reporting does not have to be a native table.
Shared REST for web and React Native
One set of booking rules. Two clients cannot drift on what 'confirmed' means.
Alternative. Separate BFF per client.
Tradeoff. API must stay mobile-friendly (payload size, error shape). Admin-only reports stay on web routes.
MongoDB with conflict indexes
Booking docs fit the workflow; compound indexes make overlap checks cheap enough.
Alternative. SQL exclusion constraints.
Tradeoff. Uniqueness is enforced in the write path + indexes, not a native exclusion constraint.
- BuiltNext.js admin/marketing surfaces that talk to the booking API
- BuiltReact Native staff flows for daily operations
- BuiltAPI conflict checks and booking state transitions used by both clients
- Property operations and brand content are the client's.
Overlapping reservations fail closed. Web and mobile cannot apply different booking rules. Guest funnel was shortened as a UX bet — no formal A/B cited.