Web App + API Backend Specific Requirements

Project-Type Overview

CurryDash Admin-Vendor Portal operates as a dual-interface system:

1. Blade-Based Web Dashboards (MPA): Traditional multi-page application architecture serving authenticated admin and vendor users through server-rendered views
2. REST API Backend: JSON-based API layer serving Flutter mobile/web applications for customer-facing features

This hybrid approach leverages Laravel’s strengths: Blade templating for complex admin interfaces where SEO is irrelevant, and API controllers for mobile-optimized endpoints.

API Architecture

Endpoints Overview:

• 100+ documented endpoints across Admin, Vendor, and Customer contexts
• Organized by domain: packages, orders, subscriptions, restaurants, authentication
• Follows RESTful conventions with consistent response formatting

Authentication Model:

• Admin/Vendor Dashboards: Session-based authentication with CSRF protection
• Customer API: Laravel Passport (OAuth2) with JWT tokens
• Guards: admin, vendor, api (Passport)
• Role-Based Access Control: AdminRole model with JSON-based module permissions

API Versioning:

• Current: /api/v1/ (active, 457+ route lines)
• Future: /api/v2/ (stub exists, migration path available)
• Strategy: URI versioning with backward compatibility window

Data Formats:

• Request/Response: JSON (application/json)
• Date format: ISO 8601 (UTC)
• Currency: AUD with 2 decimal precision
• Images: URL references with cloud storage abstraction

Rate Limiting:

Error Response Format:

{
  "status": false,
  "message": "Human-readable error description",
  "errors": [
    { "field": "validation_field", "message": "Specific error" }
  ]
}

Web Dashboard Architecture

Technology Stack:

• Laravel 9.x (PHP 8.1+)
• Blade templating engine
• jQuery + Bootstrap for admin UI
• AJAX for dynamic operations (sort ordering, status toggles)

Browser Support:

Responsive Design:

• Admin dashboards optimized for desktop (1280px+)
• Vendor dashboards responsive to tablet (768px+) for counter-side order management
• Mobile-first not required (authenticated admin interfaces)

Performance Targets:

Accessibility (WCAG 2.1 Level A):

• Keyboard navigation for critical workflows
• Proper form labels and error announcements
• Sufficient color contrast (4.5:1 text, 3:1 UI components)
• Focus indicators on interactive elements

Authentication & Authorization Matrix

User Roles:

Permission Modules (AdminRole):

• order - Order management and tracking
• package - Package configuration CRUD
• restaurant - Vendor/restaurant management
• food - Menu item management
• reports - Analytics and reporting
• subscription - Subscription plan management
• customer - Customer account management
• delivery_man - Delivery personnel management
• zone - Geographic zone configuration
• settings - System configuration

Data Integration Points

External Services:

Internal Service Layer:

• CentralLogics: Orchestration utilities (refactoring to service classes recommended)
• TaxModule: Modular tax calculation service
• Notification system: Multi-channel (push, email, SMS, in-app)

Implementation Considerations

Existing Architecture Patterns:

• Eloquent ORM with global scopes (ZoneScope, RestaurantScope)
• Model accessors for computed properties and image URLs
• Polymorphic relationships for flexible associations
• Transaction-wrapped operations for data integrity

Technical Debt to Address:

1. Extract service classes from monolithic CentralLogics
2. Implement comprehensive test coverage (currently 0%)
3. Add queue jobs for async operations (notifications, reports)
4. Standardize API responses with Laravel Resources
5. Implement systematic caching strategy

Package System Integration: The custom Package → Configuration → Option model is fully implemented:

• Admin CRUD with wizard interface
• Vendor CRUD with drag-drop sorting
• API endpoints for mobile consumption
• Cart and order integration complete