shuvomohajan/office-meal

1. Overall shape

This is a single Laravel application with an Inertia.js frontend. The backend is the Laravel/PHP layer, while the UI is built in React + TypeScript under resources/js. There is no separate API service; browser requests are handled by Laravel controllers and returned as Inertia pages.

2. Request/response boundary

The main entry points are public/index.php, Laravel routes in routes/web.php and routes/auth.php, and the Inertia root Blade view in resources/views/app.blade.php. The middleware app/Http/Middleware/HandleInertiaRequests.php bridges Laravel responses into Inertia page props.

3. Frontend architecture

The client-side app is organized around reusable UI building blocks in resources/js/Components, shared page shells in resources/js/Layouts, and feature pages in resources/js/Pages. Pages exist for authentication, dashboard, profile, users, and caterings. The app is bootstrapped through resources/js/app.tsx and built with Vite.

4. Backend domain modules

The backend is split into feature controllers and models for:

• Users

• Caterings

• Catering payments

• User payments

• Manager histories

• Meals

• Meal routines

The current TODO list shows meal-related workflows and dashboard analytics are not fully finished, while catering, catering payments, user management, user payments, and manager management are already implemented.

5. Data and persistence layer

Domain state is stored in a relational database via Eloquent models in app/Models. Schema is defined in database/migrations, including the core users table plus domain tables for caterings, meals, meal-user pivot, meal routines, payments, and manager histories. Seeders and factories exist for users, caterings, and meals, indicating test/demo data support.

6. Validation and form handling

Create/update operations use dedicated Form Request classes under app/Http/Requests. This keeps validation and authorization separate from controllers. The naming shows each feature has its own store/update request pair, which is a strong sign that CRUD flows are centralized and validation-driven.

7. Resource shaping

app/Http/Resources contains resource transformers such as CateringResource and UserResource. These are used to shape backend models into frontend-friendly payloads, which fits the Inertia pattern where page props are carefully curated rather than exposing raw models directly.

8. Primary user flows

The main flows are:

• Authentication and account management via the Auth controllers and routes/auth.php

• User CRUD and user payment management

• Catering CRUD and catering payment management

• Manager history tracking

• Meal and meal routine administration

The frontend pages mirror these flows with dedicated feature folders and modal-based create/edit/payment interactions.

9. UI composition pattern

Feature pages use a mix of index views and partial modal components, especially in Users and Caterings. This suggests the app favors a list-and-modal CRUD interaction pattern rather than separate full-page forms. Shared components like buttons, dropdowns, inputs, pagination, and theme toggle support consistent interaction across modules.

10. Authentication and profile subsystem

Authentication is built with the standard Laravel auth flow: login, registration, password reset, email verification, and password confirmation. Profile editing is handled separately through ProfileController and React profile partials. This subsystem is largely independent from the business modules, but shares the same Inertia shell and layout system.

11. Infrastructure and tooling

The repo uses Composer for PHP dependencies, PNPM/Yarn for JS dependencies, Vite for asset bundling, Tailwind/PostCSS for styling, and Pest/PHPUnit for tests. Configuration files for PHP CS Fixer and Prettier indicate the project enforces code style across both backend and frontend.

12. Likely architecture diagram boundaries

An accurate diagram should show:

• Browser

• Inertia/React frontend

• Laravel controllers and middleware

• Form request validation layer

• Eloquent models and migrations

• Database

• Auth subsystem as a cross-cutting concern

The key distinction is that UI and server are tightly coupled through Inertia, while business modules are still separated cleanly by controller/request/model/resource boundaries.