sleman2022/restsurant

1. Repository shape

- This is a two-app setup: restaurant_backend is a Laravel API/backend, and restaurant_frontend is a Vue-based single-page admin UI.

- The two halves are loosely coupled through HTTP APIs; the backend owns persistence and domain rules, while the frontend owns layout, routing, and user interaction.

2. Backend architecture boundary

- The backend follows a classic Laravel layered structure: HTTP controllers, a service layer, Eloquent models, and API resources.

- Main entry points are routes/api.php for machine-consumed endpoints and routes/web.php for any browser-facing Laravel routes.

- Middleware and auth config indicate protected endpoints and request filtering are handled in the Laravel kernel.

3. Backend domain model

- The domain is restaurant management with four main entities: User, Menu, Category, and Item.

- Category_Menu is a pivot/join model, which suggests menus and categories are related many-to-many or otherwise linked through an intermediate table.

- Migrations show the schema is intentionally split into separate tables for menu, category, item, pivot mapping, and user extensions.

4. Backend application services

- Business logic is separated into interfaces and implementations under app/Services.

- There are dedicated service contracts for categories, items, menus, and users, which keeps controllers thin and makes the domain logic easier to swap or test.

- Controllers such as AuthController, CategoriesController, ItemsController, MenusController, and UsersController likely orchestrate requests and delegate to these services.

5. Backend presentation/output layer

- Response shaping is handled by resource classes under app/Http/Resources.

- Separate resources exist for list and detail views of categories and items, plus menu and user resources.

- This means the API does not expose raw Eloquent models directly; it returns curated payloads for the frontend.

6. Backend persistence and setup

- Data persistence is MySQL/PostgreSQL-style Laravel database migrations plus seeding.

- The README explicitly instructs running php artisan migrate:fresh --seed, which means the app expects a fully rebuilt schema and seed data during setup.

- Laravel Sanctum is present in config and migrations, indicating token-based API authentication is part of the backend boundary.

7. Frontend application shell

- The frontend is a Vue SPA with a generated admin dashboard layout, built with Vue CLI/Webpack tooling.

- main.ts, router, store, and layout form the core app shell; Layout.vue and the header/aside/toolbar components define the global frame.

- The app uses a large theme asset set under src/assets, which is mostly presentation infrastructure rather than business logic.

8. Frontend feature modules

- Feature screens are organized by domain: categories, items, menus, and users.

- Each domain has page components, and some have modal dialogs for create flows such as NewCategoryModal.vue, NewItemModal.vue, and NewMenuModal.vue.

- This points to CRUD-centric admin workflows rather than a consumer storefront.

9. Frontend state, routing, and API integration

- Vue Router defines page navigation, while Vuex store modules manage application state such as auth, breadcrumbs, config, and body/UI state.

- ApiService is the frontend’s main HTTP gateway to the backend API; AuthModule and JwtService suggest centralized auth/session handling on the client side.

- MockService and the core data files indicate some template-provided mock/demo capability, but the primary architecture is API-driven.

10. Shared UI/runtime infrastructure

- The frontend uses a component and plugin layer for common concerns like i18n, inline SVG, validation, charts, and theme behavior.

- Much of src/core and src/assets/ts is framework/theme infrastructure inherited from the admin template, supporting layout state and reusable UI behaviors.

- These pieces matter architecturally because they define how pages are composed, but they are not the domain logic itself.

11. Primary data flow

- Typical flow is: user action in Vue page/modal → frontend store/API service → Laravel controller → service layer → Eloquent models/database → API resource → JSON response → Vue updates.

- Authentication wraps this flow so protected screens can load only after the client has a valid token/session state and the backend authorizes the request.

12. Infrastructure and packaging

- Backend dependencies are managed with Composer and frontend dependencies with npm.

- Backend runtime is PHP/Laravel; frontend runtime is Node/Vue.

- The repo includes tests for Laravel and standard build configs for the Vue app, so the architecture is split not just by runtime but also by deployment boundary.