rsayyed591/ai-dev-assistant

1. This repository is a two-part monorepo: a Next.js frontend in ai-dev-assistant-frontend and an Express/MongoDB backend in ai-dev-assistant-backend. The frontend is the user-facing shell; the backend owns authentication, AI calls, persistence, and request policy.

2. The frontend uses the Next.js App Router structure (app/page.tsx, app/commit/page.tsx, app/rephrase/page.tsx, app/history/page.tsx, app/profile/page.tsx). That suggests five main screens: landing, commit generation, text rephrasing, history, and profile. components/AuthModal.tsx is the key shared UI boundary for sign-in/sign-up.

3. The backend is organized in a standard layered Express shape: routes define HTTP endpoints, controllers handle request/response logic, middleware enforces auth and rate limits, services isolate the Groq LLM integration, models define MongoDB data structures, and utils/prompts.js centralizes prompt templates. This clean separation is the main architectural boundary in the API.

4. Authentication is JWT-based. auth.controller.js and auth.route.js handle register/login, auth.middleware.js protects AI and user routes, and the frontend likely stores and forwards the token for protected requests. The API design assumes all AI features are unavailable until the user is authenticated.

5. The primary business flows are two AI generation paths: rephrasing and commit message generation. /api/rephrase and /api/commit likely accept user text plus tone/context, pass that input through prompt builders in utils/prompts.js, call the Groq service in services/groq.service.js, and return a cleaned-up natural-language result.

6. History tracking is a separate user-centric subsystem exposed via /api/history. Because the backend tree only includes user.model.js and no dedicated history model, the last-10-request history is likely stored on the user document itself rather than in a standalone collection. That makes history a bounded per-user record, not an application-wide audit log.

7. The profile subsystem (/api/profile) is the read side of user state. It probably returns account metadata plus usage-related data that the frontend profile page can display. This sits alongside history as the “account data” boundary, distinct from the AI generation endpoints.

8. Rate limiting is enforced in backend middleware (rateLimit.middleware.js) and is described as per user/IP. Architecturally, that means request throttling sits in front of the AI endpoints to protect the Groq integration and control abuse, while remaining independent from business logic.

9. Persistence is MongoDB via Mongoose, configured in src/config/db.js. The only visible model is user.model.js, so user identity, auth-related fields, and any stored history are probably the core persisted state. No separate cache, job queue, or analytics store is present in the tree.

10. The backend also has a vercel.json and a top-level api/index.js, indicating it is deployable as a serverless-compatible Express API on Vercel. That deployment boundary matters because the backend is not just a local Node server; it is packaged to run behind a serverless platform while still exposing the same route structure.

11. The external dependency with the biggest architectural impact is Groq’s LLM API. The backend is effectively a thin orchestration layer between authenticated user input, prompt templates, and the model response. This keeps prompt logic centralized and prevents the frontend from ever talking directly to the LLM provider.

12. Overall data flow is: user interacts with the Next.js pages → frontend sends authenticated requests to Express endpoints → middleware checks JWT and rate limits → controllers validate/shape input → prompt utilities and Groq service generate output → MongoDB stores user/history state → response returns to the UI. The main boundaries are UI, API/auth policy, LLM orchestration, and persistence.