hasibur14/zagato-fashion-admin

1. This is a Next.js App Router application with two major user-facing surfaces: a public marketing site and an authenticated admin dashboard. The app-level routes live under src/app, with shared UI and feature components under src/components, and domain models under src/models.

2. The public site is composed from section-based components rather than a single monolithic page. Home page content is split into reusable blocks such as AboutZagato, BestSeller, ProductCollection, Testimonials, Partners, Sustainability, and WhyChooseUs. Other public content sections include AboutUs, Compliance, and ServicesPage, which suggests the site is mostly content-driven and CMS-like.

3. The admin experience is separated under src/app/dashboard, with dedicated dashboard pages for managing home content, about-us, compliance, contact-us, enquiry-us, hero, products, services, privacy policy, and terms & conditions. A shared dashboard layout and shared navigation UI live in src/app/dashboard/layout.tsx and src/components/Shared, indicating a consistent authenticated shell around these management pages.

4. The application exposes many resource-oriented API endpoints under src/app/api, each with collection and item routes. The endpoints map closely to content domains such as hero, about-status, about-zagato, best-seller, brand, categories, sub-categories, products, product-collection, services, team, testimonials, partners, process, sustainability, mission-vision, why-choose-us, privacy-policy, terms, contact, enquiry-us, compliance-status, and admin. This makes the backend layer look like a content management API rather than a single-purpose business API.

5. Data persistence is model-driven and likely MongoDB-backed. The src/models directory contains one model per domain entity, and src/lib/connectToDB.ts centralizes database connection setup. That means the request flow is generally: Next.js route handler → DB connection → Mongoose-style model → JSON response.

6. Authentication is implemented as a separate subsystem under src/app/api/auth with login, logout, and register routes, plus a user/me endpoint for session-aware identity lookup. Supporting code in src/lib/auth includes JWT and cookie helpers, and src/lib/validations/auth.ts handles input validation. This indicates token-based auth with server-side cookie/session handling rather than a client-only auth scheme.

7. The admin/user boundary is enforced by route handling and likely middleware-like logic in src/proxy.ts. Even without seeing the implementation, the presence of a proxy file plus dedicated auth endpoints and a dashboard section suggests protected routes and role-aware access control around the management surface.

8. Media handling is a notable subsystem. src/components/ui/CloudinaryImageInput.tsx, CloudinaryVideoInput.tsx, and the hooks useCloudinaryUpload.ts / useCloudinaryVideoUpload.ts indicate that images and videos are uploaded to Cloudinary rather than stored locally. This affects the architecture because content records likely store media URLs, while the actual assets are hosted externally.

9. Rich content editing is supported through a custom Slate-based editor in src/components/Editor. That implies some content fields in the dashboard are editable rich-text blocks, and content models/API routes must preserve structured text rather than plain strings.

10. The UI is organized into reusable feature components and modal-based CRUD dialogs. For example, src/components/modal/HeroModal, BlogModal, and ProjectModal encapsulate add/edit workflows, while product management components handle categories, sub-categories, and products. This suggests the admin UI is built around CRUD interactions backed by the resource API routes.

11. Type safety is reinforced with shared TypeScript types in src/types, covering auth, contact, hero, policy, product, project, sidebar, solution, terms, and topbar data. These types likely mirror API payloads and model shapes, reducing drift between the dashboard UI and backend resources.

12. The runtime is a standard Next.js/Vercel stack, as shown by the README and next.config.ts. The repo also includes environment templates, ESLint, and PostCSS configuration, which points to a conventional frontend deployment model with server-rendered pages, API route handlers, and external service integration for auth/media.

13. In diagram terms, the main boundaries are: public website pages, authenticated dashboard pages, server-side API routes, database models/connection, auth cookies/JWT, and external Cloudinary storage. Most data flows are content CRUD flows from dashboard forms to API routes to MongoDB-backed models, with public pages reading the same content back through components or API fetches.