karandudhbhate-10/support-ai

1. This repository is a single Next.js full-stack application using the App Router. It combines UI pages, server route handlers, and shared library code in one codebase.

2. The main user-facing surfaces are route-based pages under src/app: a landing/home page (/), a dashboard (/dashboard), an embed page (/embed), and a “learn more” page. These are the top-level navigation and presentation layer.

3. The app is split between server-rendered route handlers and client components. The src/components/*Client.tsx files likely hold browser-side interactivity for the home, dashboard, and embed experiences, while the src/app/*/page.tsx files wire those components into routes.

4. Authentication is handled through a dedicated auth subsystem under src/app/api/auth/*. There are explicit login, callback, and logout routes, which strongly suggests an external identity provider/OAuth-style flow rather than local username/password auth.

5. The src/lib/scalekit.ts file indicates Scalekit is the authentication provider or session/auth SDK used by the app. The callback route likely exchanges the provider response for an application session, and src/lib/getSession.ts is the shared server-side helper used to read the current user session in pages and APIs.

6. Persistent application data appears to center on settings. The src/app/api/settings/route.ts and src/app/api/settings/get/route.ts handlers, together with src/model/settings.model.ts, form the settings data path. This suggests the dashboard configures per-user or per-tenant behavior that is stored and retrieved through these endpoints.

7. Chat is a distinct backend capability exposed through src/app/api/chat/route.ts. Given the presence of public/chatBot.js and the /embed route, the likely architecture is that an embeddable widget or script sends chat requests to this API, which then serves as the runtime backend for conversational interactions.

8. The embed subsystem is important as an integration boundary. src/app/embed/page.tsx plus public/chatBot.js imply the project provides a drop-in client/embed experience that can be consumed outside the main dashboard, probably using the same auth/session and settings data model.

9. Data access and server-side integration live in src/lib/db.ts and the model layer. That separation suggests route handlers call into shared DB utilities, while settings.model.ts defines the shape or access logic for persisted settings.

10. src/proxy.ts is likely a request gatekeeper used by Next.js to protect routes or redirect unauthenticated traffic. Architecturally, that means access control happens before page rendering for sensitive routes like the dashboard and settings endpoints.

11. The app has the usual Next.js support files (layout.tsx, globals.css, next.config.ts, eslint.config.mjs, postcss.config.mjs, tsconfig.json), so the runtime is a standard TypeScript Next.js deployment with serverless-style route handlers rather than a separate backend service.

12. In diagram terms, the main flow is: browser or embed script hits the Next.js UI, UI calls route handlers for auth/chat/settings, route handlers use session helpers and DB/model code, and auth is delegated through Scalekit. The key boundaries are UI vs API, authenticated vs unauthenticated routes, and dashboard/admin configuration vs embeddable chat runtime.