tarekmonowar/e-commerce-backend

1. Repository shape

- This is a TypeScript/Node.js Express backend organized as a modular REST API.

- src/server.ts is the entry point, src/app.ts builds the Express app, and src/app/routes/index.ts aggregates the feature routes under a versioned API path.

2. High-level architecture

- The code follows a feature-module pattern rather than a single layered monolith.

- Each domain folder under src/app/modules/* usually contains a controller, service, model, route, validation, and interface files, which makes the boundaries easy to diagram: HTTP in → controller → service → persistence/external systems.

3. Core business domains

- The main business modules are auth, user, products, order, payment, coupon, otp, support, stats, and AI.

- This matches the e-commerce behavior described in the README: registration/login, product browsing, orders, payments, admin operations, and support workflows.

4. Persistence boundary

- The repository is clearly built around MongoDB models for the main entities such as users, products, orders, coupons, and stats.

- Services encapsulate the database logic, while controllers stay thin and translate HTTP requests into service calls.

5. Authentication and session flow

- Authentication is split across auth, user, and middleware.

- It supports JWT-based sessions, likely with refresh-token handling, plus Google OAuth via Passport (config/passport.ts).

- checkAuth middleware protects private routes, and the app appears to support role-based access for admin vs. regular users.

6. Validation and error handling

- Request validation is centralized through validateRequest, with per-module validation definitions in files like products.validation.ts, coupon.validation.ts, and support.validations.ts.

- Errors are normalized using AppError, then handled by globalErrorHandler and notFound, which gives the API a consistent failure boundary.

7. Product/catalog flow

- The product module is the main catalog boundary: it handles CRUD, filtering, and admin management.

- queryBuilder.ts suggests the API supports filtering, sorting, and pagination for list endpoints, which is important for drawing the catalog/data-access path.

8. Order, payment, and stock coordination

- Orders and payments are separate modules, with payment integration centered around Stripe per the README.

- reduceStock.ts indicates that successful order/payment flows also update inventory, so the order pipeline likely spans product stock, order persistence, and payment confirmation.

9. Uploads and media

- multer.config.ts and cloudinary.config.ts show a media pipeline for file uploads and hosted asset storage.

- In architecture terms, file upload is an external side-path from the API to Cloudinary, likely used by products or user/profile assets.

10. OTP and email delivery

- The otp module plus sendEmail.ts and EJS templates under utils/templates indicate email-based workflows for OTP, password reset, and newsletter-style messages.

- This is an asynchronous support boundary: API request → token/OTP generation → email dispatch → later verification.

11. AI subsystem

- The Ai module is a distinct subsystem with prompt, serve, vectorEmbedding, and ai.services.ts.

- embeddedData/basic.txt and advancedData.txt suggest the AI feature uses pre-embedded local knowledge sources rather than only live database content, with embeddings/storage managed separately from the main CRUD modules.

12. Caching and runtime infrastructure

- Redis appears in the config layer (redis.config.ts, uptash.redis.ts) and there is a cache-related middleware, so the app likely uses Redis for session/state/caching or AI/vector support.

- vercel.json indicates the backend is deployed to Vercel, so the diagram should include a deployment/runtime boundary from the Express app to the hosting platform.

13. Cross-cutting utilities

- Shared helpers in utils/ handle concerns like JWT creation, cookie setting, email sending, standardized API responses, async error wrapping, and token generation.

- These utilities reduce duplication across modules and are the main shared “platform” layer beneath the feature folders.