Billcraft Server

Core Architecture

The server follows a classic micro‑service style, with a single Express application exposing a set of RESTful routes grouped by domain: auth, products, customers, shops, and bills. Each route file delegates business logic to a dedicated controller, keeping the routing layer thin and the controllers focused on orchestrating data access via Mongoose models.

Data Ingestion & Persistence

All domain entities are persisted in a MongoDB Atlas cluster named construction_billing. Mongoose schemas enforce field types, required constraints, and custom validation logic. The application uses a soft delete strategy for products, customers, shops, and bills, marking records with an isActive flag instead of physically removing them, which preserves historical data for audit and reporting.

Execution Flow

A typical request follows this pipeline: the request hits an Express route, passes through AuthMiddleware (token verification, role checks, and rate limiting), then ValidationMiddleware (schema validation via validator), and finally the controller performs the requested CRUD operation. Responses are sent with standardized JSON payloads, and errors are caught by a global error‑handling middleware that logs details via morgan and returns a sanitized error message.

Security Guardrails & Build Topology

Security is layered: helmet sets secure HTTP headers, cors restricts origins, express‑rate‑limit throttles authentication endpoints, and JWTs are signed with a secret stored in environment variables. The build topology is simple: the start script runs node index.js, while dev uses nodemon for hot reloading. Deployment instructions in DEPLOYMENT.md outline a CI‑CD pipeline that builds the Docker image, pushes to a registry, and deploys to a cloud provider, with the frontend served from Vercel, Netlify, or Render.