theunstopabble/swadkart

1. Overall shape

SwadKart is a two-tier MERN platform: a React/Vite frontend and an Express/Node backend. The backend exposes a large REST API plus Socket.io real-time channels; the frontend consumes both and is organized around role-based pages for customers, admins, restaurant owners, and delivery partners.

2. Frontend boundary

The frontend is a single-page app built with React 19, Redux Toolkit, React Router, Tailwind, and Socket.io-client. It owns UI state, cart/user state, i18n, PWA behavior, voice search, biometric login UX, and live views such as order tracking and chat streaming. The app shell in App.jsx is the main composition point for routing, guards, and lazy-loaded pages.

3. Backend entry and request pipeline

backend/server.js is the backend composition root. Requests flow through middleware for auth, roles, validation, cache, fraud detection, and error handling before reaching controllers. This boundary is important: controllers orchestrate business actions, while middleware enforces cross-cutting policy such as JWT auth, rate limits, and sanitization.

4. Domain/API layer

The backend is split into many route/controller pairs, roughly by business domain: auth/users, products/restaurants, orders/payments, reservations/group orders, delivery, coupons, subscriptions, loyalty/gamification, analytics, GDPR, notifications, and image upload. This suggests a modular monolith rather than microservices; each route module maps to a feature area and delegates to a matching controller.

5. Persistence layer

MongoDB is the primary system of record through Mongoose models. The models cover core commerce entities like users, restaurants, products, orders, reservations, coupons, subscriptions, referrals, group orders, notifications, payouts, and conversations. The architecture likely centers on MongoDB documents as the source of truth for both transactional flows and conversational history.

6. Caching and fast-path reads

Redis is used for response caching and also backs jobs/queues where available, with an in-memory fallback mentioned in config. This cache layer sits beside MongoDB to reduce repeated reads for GET-heavy endpoints, chat rate limiting, and async work coordination.

7. Payments, fulfillment, and commerce flow

The core transaction path is: browse menu → build cart → apply coupon/subscription/surge logic → pay via Razorpay or COD → create order → dispatch to delivery tracking/updates. Order-related controllers and calculators indicate pricing is computed server-side, not trusted from the client, which is important for diagramming the trust boundary.

8. Real-time and delivery tracking

Socket.io supports live order status and GPS-style delivery tracking. Frontend components such as live maps and order progress consume these updates, while backend delivery/order controllers publish state changes. This is a separate real-time channel from the REST API and should be shown as a parallel path.

9. AI chatbot subsystem

The backend/services/chat subtree is a distinct subsystem: intent classification, language detection, sentiment, retrieval, token budgeting, fallback responses, and Groq integration. Tooling modules allow the chatbot to invoke business actions like order status, cancel, reorder, coupon lookup, delivery ETA, and FAQ. On the frontend, the chatbot UI streams responses via SSE-style event parsing, so the chatbot path is a mix of REST, streaming, and action execution.

10. Media, identity, and external integrations

Cloudinary handles uploaded images, Firebase is used for Google auth and push-related client setup, WebAuthn supports biometric login, and email delivery is offloaded through a worker queue. These integrations are not incidental: they define external boundaries for authentication, storage, notifications, and asynchronous processing.

11. Async processing

backend/workers/emailWorker.js and the chat cleanup/queue services show that the backend includes background jobs, not just synchronous API handlers. Email delivery and chat maintenance are decoupled from request-response latency, which matters for showing non-blocking workflows in the architecture diagram.

12. Security and policy layer

The repo emphasizes multiple enforcement layers: JWT cookies, role-based authorization, CSRF/origin checks, rate limiting, fraud detection heuristics, and input sanitization. There is also GDPR-specific functionality for export and deletion. These are horizontal controls across the API rather than separate features.

13. Frontend product areas

The UI is segmented by user role and workflow: public marketing/home, restaurant browsing, cart/checkout/payment, customer order history, admin analytics, restaurant owner dashboards, delivery partner dashboard, subscription/gamification, reservations, and support/chat. Reusable components under src/components are organized by these domains, not by generic design-system layers.

14. Testing, documentation, and delivery

The repo includes substantial automated testing, especially property-based tests for the chat pipeline, tools, and streaming behavior, plus integration tests. GitHub Actions runs backend syntax checks, frontend lint/build, and deployment-related validation. The docs/ folder contains explicit architecture, API, DB schema, deployment, and workflow docs, indicating the repo is designed to be diagrammed and operated as a production system.

15. Deployment topology

The intended deployment splits frontend and backend: frontend on Vercel, backend on Render, MongoDB Atlas for persistence, Redis as optional cache/job backend, and Cloudinary/Razorpay/Firebase/Groq as external SaaS dependencies. For an architecture diagram, it’s best to show the frontend as an edge-hosted SPA that talks to the backend API and Socket.io endpoint, which in turn connects to MongoDB and external service providers.