How harmeet1994/demo-project works
1. This is a Laravel monolith with a mixed rendering model: the public-facing application is built with React via Inertia, while the admin area uses traditional Blade templates. The repo is not API-first; controllers directly render pages and manage form submissions.
2. HTTP entry starts at public/index.php, flows through Laravel middleware in app/Http/Kernel.php, and is split by route files in routes/web.php, routes/auth.php, and routes/api.php. HandleInertiaRequests is the key bridge between Laravel and the React frontend.
3. The public app lives in resources/js: Pages, Components, Layouts, Contexts, and hooks define the user-facing UI. React pages such as Home, Blogs, Jobs, CourseInquiry, ContactUs, and profile/auth screens are compiled by Vite into public/build.
4. The admin console is a separate boundary. resources/views/admin/** contains Blade screens, backed by app/Http/Controllers/Admin/** and protected by AdminMiddleware. It covers dashboard, users, blogs, jobs, course registrations, course inquiries, campus inquiries, and job applications.
5. Domain persistence is centered on Eloquent models and migrations. Main entities include User, Organization, Blog, JobMaster, JobApplication, JobInteraction, CourseRegistration, CourseInquiry, and CampusInquiry, plus the is_admin user flag. The architecture is a relational CRUD application with audit/review workflows around submissions.
6. Authentication is a major subsystem. There are separate controllers for standard user auth and admin login, plus registration, password reset, email verification, and profile management. Sanctum is present in config and migrations, indicating token support in addition to session-based web auth.
7. The public data-entry flows are lead-generation oriented: course inquiries, campus inquiries, job applications, organization submissions, and blog browsing. These flows are handled by dedicated controllers and then reviewed in the admin area, making the app a content-and-intake platform rather than a purely transactional site.
8. Jobs are a dedicated product area. Public job pages and application forms are implemented in React, while the backend stores job metadata and applications. Uploaded resume files appear in public/resumes, so file storage is part of the job-application flow.
9. There is also a payment/checkout-related path: PaymentController and the frontend PaymentFailed / ThankYou pages indicate a transactional flow with success/failure outcomes. The exact gateway is not visible in the tree, but the architecture clearly separates payment handling from content pages.
10. Google sign-in or OAuth is integrated through GoogleController, and mail-based account flows are supported by Laravel’s verification/reset controllers. These external touchpoints are part of the account boundary, not the core content model.
11. Static and built assets are intentionally split: legacy/vendor assets live under public/assets, while modern app bundles are produced into public/build from resources/js and resources/css. This suggests the app serves both prebuilt theme assets and a React SPA-like experience inside Laravel.
12. Tests are mostly framework feature tests for auth and profile behavior, so the repo emphasizes web-session correctness and user lifecycle rather than heavy domain-unit coverage. The overall diagram should show one Laravel backend, one React/Inertia frontend, and one Blade-based admin side sharing the same database and file storage.
Main entry points: web.php Web routes · Pages Pages · Controllers Public controllers · Kernel.php Kernel
Components 20
Laravel backend
HTTP entry, middleware, routing, controllers, and domain models.
- Entry point · Web requests enter Laravel here before routing and middleware.
public/index.php - Kernel · Registers and runs the HTTP middleware pipeline.
app/Http/Kernel.php - Inertia bridge · Shares data and connects Laravel responses to React pages.
app/Http/Middleware/HandleInertiaRequests.php - Admin guard · Protects the admin boundary.
app/Http/Middleware/AdminMiddleware.php - Web routes · Primary route split for browser-driven flows.
routes/web.php - Auth routes · Dedicated authentication and account routes.
routes/auth.php - API routes · Programmatic endpoints for token or API access.
routes/api.php - Public controllers · Controllers for content, intake, payment, profile, and OAuth flows.
app/Http/Controllers - Auth controllers · Session login, registration, verification, password reset, and admin login.
app/Http/Controllers/Auth
React/Inertia frontend
Public user interface built from React pages and shared components.
- Pages · Route-level public pages and auth screens rendered via Inertia.
resources/js/Pages - Components · Reusable public UI controls and page fragments.
resources/js/Components - Layouts · Shared app shells for guest and authenticated views.
resources/js/Layouts - Contexts · Client-side application state boundary.
resources/js/Contexts - Built assets · Compiled React and CSS output served to the browser.
public/build
Admin console
Blade-based management screens and admin controllers.
- Admin controllers · Controllers that manage back-office CRUD and review workflows.
app/Http/Controllers/Admin - Admin views · Traditional server-rendered admin pages.
resources/views/admin
Persistence
Relational entities, migrations, and token/auth storage.
- Domain models · Core relational entities for users, content, jobs, registrations, and inquiries.
app/Models - Migrations · Database schema evolution including users, organizations, blogs, registrations, and tokens.
database/migrations
File assets
Uploaded and built assets served from public storage.
- Resume files · Stored resume uploads used by the job application flow.
public/resumes - Legacy assets · Prebuilt theme assets and images used alongside the modern bundle.
public/assets
Connections 21
- Entry point → Kernel: boot · Laravel boots the HTTP middleware pipeline.
- Kernel → Inertia bridge: shares · Inertia middleware participates in request handling.
- Kernel → Admin guard: guards admin · Admin access control is enforced in the web stack.
- Kernel → Web routes: dispatches · Web requests are routed after middleware.
- Web routes → Public controllers: public flows · Browser pages and submissions are handled here.
- Web routes → Admin controllers: admin flows · Back-office routes map to admin controllers.
- Web routes → Inertia bridge: render react · Public pages are bridged into Inertia responses.
- Web routes → Admin views: render blade · Admin screens are server-rendered templates.
- Auth routes → Auth controllers: auth flows · Session, registration, reset, and verification flows.
- API routes → Public controllers: api handlers · Programmatic endpoints share backend controllers.
- Public controllers → Domain models: reads/writes · Content, intake, and profile actions persist through models.
- Admin controllers → Domain models: manages · Admin CRUD and review actions operate on the same domain entities.
- Auth controllers → Domain models: users · Authentication centers on the user record and flags.
- Domain models → Migrations: schema · Models are backed by the relational schema.
- Public controllers → Pages: inertia pages · Controllers choose the public React page to display.
- Pages → Components: compose · Pages reuse shared UI components.
- Pages → Layouts: wrap · Pages are framed by shared layouts.
- Pages → Contexts: state · Client state is provided through React context.
- Pages → Built assets: compiled to · Vite bundles the frontend into public build assets.
- Admin views → Legacy assets: uses · Admin templates rely on legacy/static assets.
- Public controllers → Resume files: uploads · Job application flows store resume files.