GroceryApp — Online Grocery Ordering Platform

An online grocery workflow has several related actors and records: customers, products, addresses, orders and delivery partners. The repository is split into frontend and backend directories. The frontend uses React, TypeScript and Vite. The backend is a separate Express 5 TypeScript application. Keeping the frontend and API as separate deployable applications creates a clear HTTP boundary: the browser handles presentation and interaction, while the backend remains responsible for authoritative data changes and protected operations.

The backend has separate route modules for authentication, products, uploads, orders, addresses, administration and delivery partners. Controllers hold endpoint handling, while middleware modules include authentication, administrator and delivery authentication checks. Configuration modules initialise Prisma, Cloudinary and Nodemailer. This division helps make the HTTP entry points, access checks and external integrations discoverable instead of concentrating them in one server file.

The Prisma schema defines User, Address, Product, Order and DeliveryPartner models. A user can have multiple addresses and orders. An order belongs to a user and can optionally be assigned to a delivery partner. The order stores its items and shipping address as JSON snapshots, along with subtotal, delivery fee, tax, total, payment method, status, status history, delivery OTP, live location and payment state. A product stores catalogue information such as name, description, price, image, category, unit, stock and organic/rating fields. This model provides a concrete basis for exploring relational modelling and the deliberate use of JSON for order snapshots.

The dependency list includes JSON Web Tokens and bcrypt, while middleware modules are present for general authentication, administrator access and delivery-partner access. This indicates distinct request-access paths for customer, administrator and delivery workflows. A useful engineering review should trace where tokens are created and verified, how password hashes are produced and checked, and how middleware attaches the authenticated identity to each request. Do not infer that client-side role checks provide security; the API must enforce access rules itself.

The Order schema includes a status field, statusHistory, deliveryPartnerId, delivery OTP and optional liveLocation. These fields indicate that the order model is designed to represent more than a simple purchase record: it can retain a status progression and delivery assignment context. The backend exposes order and delivery route groups. When documenting the actual workflow, link each status transition to the responsible actor and endpoint, and define which transitions are permitted rather than treating status as arbitrary text.

The backend dependencies include Stripe, Cloudinary, Multer, Nodemailer and Inngest. The server registers a raw-body Stripe webhook route before applying the general JSON middleware, which is an important integration detail because webhook signature verification typically depends on the original request body bytes. Cloudinary and Multer support media-upload workflows. Nodemailer provides email capability. Inngest functions are served from a dedicated endpoint, allowing event-driven or background work to be separated from the synchronous API request path.

The frontend package uses React, TypeScript and Vite, with React Router, Axios, Tailwind CSS, Lucide icons, toast notifications and React Leaflet dependencies. These choices support client-side route handling, API communication, utility feedback and map-oriented views. The UI should treat server responses as authoritative for order state, prices, stock and access decisions. If the interface displays delivery or address coordinates, validate and handle unavailable location data gracefully.

The repository structure provides natural learning topics: transaction boundaries for order placement, inventory consistency, webhook idempotency, payment state transitions, delivery assignment, background retries, image-upload validation, API error handling and address privacy. These are useful areas to explain with actual controller and service flows. Before claiming a particular guarantee—such as exactly-once payment processing or atomic stock reservation—verify that the corresponding code implements it.