# Improvements & New Features Plan Based on a full read of the project (Laravel 12, Inertia + Vue 3, ride-hailing/booking, admin/owner/driver/dispatcher/agent/franchise/user, payments, zones, promo, support, chat, reports), here is a structured plan. --- ## 1. Code Quality & Maintainability ### 1.1 Validation - **Current:** Form Requests are used in only a few places (e.g. `CreateTripRequest`); most validation is inline in controllers. - **Improve:** Introduce Form Requests for all API and web actions (create/update trip, user, driver, promo, settings, etc.) to centralize rules and keep controllers thin. - **Benefit:** Consistent validation, easier testing, clearer API contracts. ### 1.2 TODOs in codebase - **Current:** Multiple `@TODO` comments for: “send SMS & email to user”, “validate if user has any trip with same time period”, “adhoc user transformer”, “check if rental is enabled”. - **Improve:** Turn these into tracked tasks; implement at least: (1) duplicate/same-time trip validation, (2) optional SMS/email notifications for trip lifecycle (or document why deferred). ### 1.3 Typo and consistency - **Current:** `firstorNew([])` / `firstornew([])` in `AppServiceProvider` (PHP is case-insensitive; standard is `firstOrNew`). - **Improve:** Use `firstOrNew([])` consistently and add null checks when using `->value` (e.g. `$admin_url->value ?? 'admin'`) to avoid errors when the setting row does not exist. ### 1.4 Bootstrap and settings - **Current:** `AppServiceProvider::boot()` uses `Schema::hasTable('settings')` and runs many `Setting::whereName(...)->firstOrNew([])` and `view()->share()` on every request. - **Improve:** Cache settings (e.g. Redis or `Cache::remember`) with a key like `app.settings` and invalidate on setting update. Move view-sharing to a dedicated middleware or Inertia shared data so boot stays light and install/migrate without `settings` table does not break. ### 1.5 Exception handling - **Current:** Exception handler has optional “send exception to email” logic; the actual send (e.g. `SendExceptionToEmailNotification`) is commented out. - **Improve:** Either enable and configure exception notification (email or Sentry/Bugsnag) or remove dead code. Prefer a dedicated error-tracking service for production. --- ## 2. Testing ### 2.1 Current state - Only default `ExampleTest` (feature + unit); no tests for auth, trips, payments, or permissions. - **Improve:** Add: - **Feature:** Auth (login/register per user type), create/cancel trip (API), key API endpoints (profile, request history, driver accept/reject). - **Unit:** Critical helpers (e.g. ETA, pricing, promo application), Form Request rules. - **Integration (optional):** One payment gateway (e.g. Stripe) with mocked HTTP. - Use `RefreshDatabase` (or a test DB) and factories for `User`, `Request`, `Driver`, `Zone`, etc. ### 2.2 Continuous integration - Add a CI workflow (GitHub Actions or similar) that runs `composer install`, `npm ci && npm run build`, `php artisan test`, and optionally `php artisan migrate --force` on a test database. --- ## 3. Security & Resilience ### 3.1 Login rate limiting - **Current:** `FortifyServiceProvider` has `RateLimiter::for('login', ...)` commented out. - **Improve:** Enable login rate limiting (e.g. 5 attempts per minute per IP or per email) to reduce brute-force risk. ### 3.2 API throttling - **Current:** Global API throttle (e.g. 60/min) and per-route throttles (e.g. 120, 30) in `bootstrap/app.php` and route files. - **Improve:** Keep throttling; consider stricter limits for auth-related and payment endpoints; document limits in API docs. ### 3.3 Authorization - **Current:** Permissions and roles (e.g. `RouteNeedsPermission`, `access()->hasRole()`); many permission constants in `App\Base\Constants\Auth\Permission`. - **Improve:** Consistently use policy or `authorize()` in controllers for resources (trip, driver, owner, promo, etc.) so forbidden access returns 403 with a clear message. --- ## 4. Performance ### 4.1 N+1 and queries - **Current:** Controllers use many direct `->get()`, `->first()`, and relationship access without eager loading. - **Improve:** Use `->with()` / `->load()` for relations (e.g. request with user, driver, zone_type). Run Laravel Debugbar or Telescope in dev and fix N+1 on list/detail endpoints (dashboard, request history, driver/owner lists). ### 4.2 Caching - **Current:** Some helpers use `Cache::get()` (e.g. currency); settings and third-party config are not cached. - **Improve:** Cache settings and non-secret third-party config (e.g. feature flags, map keys) with TTL or event-based invalidation. Cache heavy read-only or slow-changing data (e.g. zone list, cancellation reasons) where appropriate. ### 4.3 Queues - **Current:** Jobs exist (e.g. push notifications, MQTT, socket, mail, exception email); usage is mixed. - **Improve:** Ensure all “fire-and-forget” notifications (SMS, email, push) and non-critical side effects are dispatched to queues; run a queue worker in production and document it in README/deploy docs. --- ## 5. API & Documentation ### 5.1 API versioning - **Current:** Routes under `api/v1`; no formal versioning strategy. - **Improve:** Document that v1 is current; plan for v2 (e.g. new URL prefix or header) when making breaking changes. Keep v1 stable or clearly deprecated. ### 5.2 API documentation - **Current:** Some `@group` and `@bodyParam` in controller docblocks; no single source of truth for all endpoints. - **Improve:** Add OpenAPI (Swagger) spec generation (e.g. L5-Swagger or Scramble) and serve UI at e.g. `/api/docs`. Document auth (Sanctum), throttling, and error format. ### 5.3 Response format - **Current:** Fractal transformers used widely; response shape may vary by endpoint. - **Improve:** Standardize JSON shape (e.g. `{ data, message, errors }`) for success and validation/error responses; document in API docs. --- ## 6. Frontend (Vue 3 / Inertia) ### 6.1 State and data - **Current:** Vuex for permissions, layout, notifications, todo; Ziggy for `route()` (recently fixed). - **Improve:** Ensure Ziggy/`route()` is used consistently; consider Pinia for new modules if you prefer Composition API style. Keep permissions and shared app state in one place. ### 6.2 Composition API vs Options API - **Current:** Mix of Options API (e.g. `booking.vue`) and Composition API / `