Day 1 - class-booking-system Project
Source: Dev.to
Day 1: Starting a Laravel Class Booking System
What I Did Today
I decided to build a class booking system with Laravel. I haven’t used Laravel in production before, but this project feels perfect for that. I’ve worked with Django, understand MVC structure, and know ORM concepts—the only new thing is the syntax.
Why Am I Building This?
When I worked at an academy, I built a booking system on a single page. It was fast, which was the priority then, but I wasn’t fully satisfied with its maintainability, scalability, and data integrity.
The original system:
- Built with pure PHP + jQuery
- All booking logic on one page
- State managed entirely in the frontend (JS)
- Final submit → straight to Google Sheets + DB
- Concurrent bookings could both see “available” → conflicts
It made sense at the time, but now I want to learn Laravel by rebuilding that system and see how I can improve it.
What I Want to Demonstrate with This Project
- Maintainable structure (using Laravel properly) – learning Laravel is part of the goal.
- Time‑based business logic – booking conflict detection, capacity management, state transitions (pending → confirmed → cancelled).
This isn’t about building something flashy; it’s about designing a system responsibly.
What Backend Work Really Means
CRUD is just the surface. The real work involves:
- Where do we enforce rules?
- When do we allow, and when do we block?
- How do we manage state transitions?
- What do we roll back when something fails?
👉 All of this is business logic.
Today’s Work: Architecture Design
Architecture Structure
Blade (UI)
└── JavaScript (filtering, state management)
└── Axios
└── Laravel API
└── Service Layer (business rules)
└── DB (transaction + lock)-
Controller = Entry guard
- Receive requests, handle auth/authorization, perform format validation.
-
Service = Rule enforcer (most important)
- Contains all business rule decisions, transaction management, and throws exceptions on failure.
-
Model = Data structure
- Defines relationships and simple state.
Booking Flow (Simplified)
- Login → verify grade level
- Select subject
- Select center (online/offline)
- Select date/time
- Ask API: “Can I book this?” → server checks time conflict, capacity, waiting list, etc.
- Final review (price, comments)
- Confirm → start DB transaction
- Re‑check, lock rows, create booking, commit
👉 No intermediate state is saved. Only confirmed bookings go to the DB.
Situations That Must Never Be Allowed
- New bookings for classes that have already started
- Overbooking beyond capacity
- Same student double‑booking the same time slot
- Free cancellations after a class starts
- Unauthorized force‑cancellations
What I Intentionally Avoided
- ❌ Saving incomplete booking states to DB – prevents database pollution.
- ❌ Restoring bookings after browser close – booking is an intentional action; only confirmation matters.
- ❌ Frontend‑only validation – critical decisions must happen on the server.
Before vs Now
| Before | Now | |
|---|---|---|
| Structure | Everything on one page | API‑first |
| Validation | Frontend | Server |
| Concurrency | Vulnerable | Transaction‑based |
Tech Stack
- Backend: Laravel
- Frontend: Blade + JS (Axios)
- Database: MySQL
- Focus: Backend architecture + business logic
What I Felt Today
The hybrid approach (looks like an SPA but is server‑controlled) feels solid. It showcases Laravel’s architecture while keeping a familiar UX. Designing with AI helped the structure come together much faster; doing it alone would have taken all day.
What I Learned Today
Why the Service Layer is necessary!
In Laravel, keep Controllers lightweight and concentrate all business logic in Services. In Django I put everything in Views; Laravel provides a clearer separation of concerns.
Next Steps
- DB schema design
- Use‑case writing
Time Spent
Total: 1 hour 30 minutes
- Structure planning: 40 min
- Design discussion with AI: 30 min
- Identifying issues (how to prevent race conditions?): 10 min
- Writing this post: 10 min
What stumped me:
Wondered if I should go full SPA, but since the goal is to demonstrate Laravel architecture, I chose the hybrid approach.