Community Platform

Architecture

Community Platform is a single Laravel 10 application (PHP 8, MySQL) serving server-rendered Blade pages, deployed as one unit. Authentication is session based; authorization uses a custom role model stored as a JSON column on the user, checked by middleware, with four platform roles (admin, communication, member, other) kept separate from the member's functional profile, which is what governs vehicle access. Business logic that does not belong in controllers lives in dedicated services (Sunday meals, birthdays, notifications, QR codes). The vehicle planner keeps its grid current through a small self-hosted polling API, which is what production runs on; a Laravel Echo and Pusher broadcasting layer is wired in for instant push and can be enabled without touching the pages, and every broadcast call is wrapped so a real-time failure never breaks the underlying reservation. Recurring work runs through the Laravel scheduler: three maintenance commands (generate upcoming meals, close sign-ups, purge old notifications) plus a database-backed queue worker that the scheduler restarts every minute, which removes the need for a long-running worker process on the server. Outgoing email goes through a wrapper that catches every send failure, records it in a dedicated table, and lets the request complete.

Engineering challenges

• Two members booking the same car at the same second. Checking availability and then inserting a reservation is a race. I wrapped the booking in a transaction with a row lock on the vehicle and added a unique database index on the active slot, so the second write is rejected by the database itself and the user gets a clear "just taken" message instead of a silent overlap.
• The planner flashed on every refresh. The grid was re-fetched and re-rendered on a timer, which made it blink. I centralised data fetching into one source of truth that updates the grid in place, so a new booking appears without the whole table redrawing.
• Keeping the grid current without depending on a real-time service. Pusher adds an external dependency that is not guaranteed on site, so production runs the planner on a self-hosted polling API; the Echo/Pusher layer stays in the codebase as an opt-in, and every broadcast call is wrapped so a real-time failure never breaks the underlying reservation.
• Chores that depend on a person remembering them. Opening the next meals and closing sign-ups were manual. Moving them into scheduled artisan commands, plus running the queue from the scheduler, made the recurring side of the app self-sufficient.

Technical decisions

• Custom JSON role column over a full permissions package. The community has a small, stable set of roles. A JSON roles column on the user with a middleware check covers it without the schema and query overhead of a general permissions library, and keeps platform roles cleanly separate from the functional profile that drives vehicle access.
• Server-rendered Blade over a separate front-end. One developer, one deploy target, an audience that mostly needs forms and lists. Blade with a light sprinkle of JavaScript on the planner ships faster and is far simpler to host and hand over than an API plus a single-page app.
• Polling in production over a hosted real-time service. The planner needs to reflect other people's bookings within a few seconds, not within milliseconds. A self-hosted polling endpoint delivers that with no third-party account, no extra cost, and nothing to break; the Echo/Pusher path is kept ready for the day sub-second updates are worth the dependency.
• Database queue and scheduler-driven worker over a dedicated queue service. Email is sent asynchronously so a slow SMTP server never blocks a member, but running the worker from the scheduler avoids adding a supervised process (or a Redis dependency) to a modest server.