How smlimonparvez/medi-store-back-end works
1. Overall shape
- This is a layered Node.js backend built with Express + TypeScript.
- The main execution path is: entrypoint → Express app → middleware → route → controller → service → Prisma → PostgreSQL.
2. Entrypoints and deployment boundary
- src/server.ts is the normal server startup entrypoint.
- api/index.ts suggests a serverless/Vercel-compatible entrypoint, and vercel.json confirms the repo is prepared for that deployment model.
- src/app.ts likely contains the Express app configuration shared by both startup paths.
3. API composition
- The API is split into feature modules under src/modules/*.
- Each module has a consistent three-part structure: *.route.ts, *.controller.ts, and *.service.ts.
- This creates a clear boundary between HTTP concerns, request handling, and business logic.
4. Feature domains
- The main domains are auth, admin, seller, medicine, category, order, payment, review.
- The README’s route list matches this modular structure, with endpoints mounted under /api/auth, /api/medicines, /api/categories, /api/orders, /api/payments, /api/reviews, /api/sellers, and /api/admin.
5. Business logic layer
- Services are the core business boundary.
- Controllers should be thin: they parse the request, call a service, and return a standardized response.
- The service layer is where domain rules such as role-specific behavior, ordering, and payment handling are likely centralized.
6. Persistence layer
- Data access is handled through Prisma ORM in src/config/prisma.ts and the prisma/ directory.
- prisma/schema.prisma defines the database model, while prisma/migrations/ manages schema evolution.
- The primary backing store is PostgreSQL.
7. Authentication and authorization
- Authentication is based on JWT.
- src/middlewares/auth.middleware.ts likely enforces protected routes and role checks.
- The app supports role-based access for Customer, Seller, and Admin, so authorization is an architectural concern, not just a feature.
8. Cross-cutting middleware
- src/middlewares/error.middleware.ts centralizes error handling.
- src/middlewares/rateLimiter.middleware.ts protects the API from abuse.
- Security-related concerns also include CORS and password hashing via bcrypt, both called out in the README.
9. Validation and response handling
- Request validation is handled with Zod, via src/utils/schemas.ts and src/utils/validate.ts.
- src/utils/AppError.ts, catchAsync.ts, and sendResponse.ts indicate a standardized error/async/response pattern across modules.
- This means the API likely returns consistent envelopes and error shapes regardless of module.
10. Payment boundary
- Payments are isolated in src/modules/payment/*.
- The README says Stripe integration with webhooks, so the payment module is the main boundary to an external payment provider.
- Order/payment state changes probably flow through this module rather than directly from order handling.
11. Domain data flow
- Typical flow: client request enters a route, passes auth/rate-limit/validation, reaches a controller, then a service reads/writes via Prisma, and the result is formatted back to the client.
- For payment-related flows, an additional asynchronous path exists through Stripe webhooks, which can update order/payment state after the initial request.
12. Database lifecycle and bootstrap data
- prisma/migrations shows schema changes are managed explicitly and versioned.
- prisma/seed.ts provides initial or demo data, which is useful for bootstrapping categories, medicines, roles, or test users.
13. What to draw in an architecture diagram
- A good diagram should show:
- Clients calling the Express API
- Shared middleware around every request
- Separate feature modules with controller/service layers
- Prisma as the sole persistence gateway
- PostgreSQL as the database
- Stripe as an external payment system with webhook callbacks
- JWT-based auth and role checks as a cross-cutting control layer
Main entry points: app.ts Express app · prisma.ts Prisma client · sendResponse.ts Response helpers · payment.route.ts Payment module
Components 19
Entrypoints
Runtime startup paths and deployment boundary.
- Client · External HTTP clients calling the API.
- Serverless entry · Serverless-compatible entrypoint for deployment platforms.
api/index.ts - Server startup · Standard Node.js server bootstrap.
src/server.ts
API Layer
Express app composition, middleware, and request handling.
- Express app · Shared Express application setup used by both entrypoints.
src/app.ts - Auth guard · JWT authentication and role checks.
src/middlewares/auth.middleware.ts - Rate limit · API abuse protection layer.
src/middlewares/rateLimiter.middleware.ts - Error handler · Centralized error formatting and handling.
src/middlewares/error.middleware.ts - Response helpers · Shared async, error, validation, and response utilities.
src/utils/sendResponse.ts
Domain Modules
Feature areas implemented as route-controller-service slices.
- Auth module · Login, registration, and role-aware auth flows.
src/modules/auth/auth.route.ts - Admin module · Admin-only operations and controls.
src/modules/admin/admin.route.ts - Seller module · Seller-facing API and workflows.
src/modules/seller/seller.route.ts - Catalog module · Medicine and category catalog management.
src/modules/medicine/medicine.route.ts - Order module · Order creation and lifecycle management.
src/modules/order/order.route.ts - Payment module · Payment processing and webhook handling.
src/modules/payment/payment.route.ts - Review module · User reviews and product feedback.
src/modules/review/review.route.ts
Data & Integrations
Persistence, schema lifecycle, and external service boundaries.
- Prisma client · Central database access layer.
src/config/prisma.ts - Schema & migrations · Prisma schema, migrations, and seed lifecycle.
prisma/schema.prisma - PostgreSQL · Primary persistent datastore.
- Stripe · External payment system with webhook callbacks.
Connections 32
- Client → Serverless entry: HTTP requests · Clients can enter through the serverless deployment path.
- Client → Server startup: HTTP requests · Clients can enter through the standard server process.
- Serverless entry → Express app: bootstraps · Serverless entry reuses the shared Express app.
- Server startup → Express app: bootstraps · Server startup initializes the shared Express app.
- Express app → Auth guard: protects routes · Authentication and role checks wrap protected handlers.
- Express app → Rate limit: throttles · Requests may be rate-limited before reaching modules.
- Express app → Error handler: handles failures · Unhandled errors are normalized at the app boundary.
- Express app → Auth module: mounts · Auth routes are mounted into the API.
- Express app → Admin module: mounts · Admin routes are mounted into the API.
- Express app → Seller module: mounts · Seller routes are mounted into the API.
- Express app → Catalog module: mounts · Catalog routes are mounted into the API.
- Express app → Order module: mounts · Order routes are mounted into the API.
- Express app → Payment module: mounts · Payment routes are mounted into the API.
- Express app → Review module: mounts · Review routes are mounted into the API.
- Auth module → Response helpers: uses · Controllers use shared response and validation helpers.
- Admin module → Response helpers: uses · Controllers use shared response and validation helpers.
- Seller module → Response helpers: uses · Controllers use shared response and validation helpers.
- Catalog module → Response helpers: uses · Controllers use shared response and validation helpers.
- Order module → Response helpers: uses · Controllers use shared response and validation helpers.
- Payment module → Response helpers: uses · Controllers use shared response and validation helpers.
- Review module → Response helpers: uses · Controllers use shared response and validation helpers.
- Auth module → Prisma client: reads/writes · Auth services persist through Prisma.
- Admin module → Prisma client: reads/writes · Admin services persist through Prisma.
- Seller module → Prisma client: reads/writes · Seller services persist through Prisma.
- Catalog module → Prisma client: reads/writes · Catalog services persist through Prisma.
- Order module → Prisma client: reads/writes · Order services persist through Prisma.
- Payment module → Prisma client: reads/writes · Payment services persist through Prisma.
- Review module → Prisma client: reads/writes · Review services persist through Prisma.
- Prisma client → PostgreSQL: connects to · Prisma is the gateway to PostgreSQL.
- Prisma client → Schema & migrations: manages schema · The schema and migrations define the database lifecycle.
- Payment module → Stripe: charges via · Payments integrate with Stripe as an external provider.
- Stripe → Payment module: webhooks · Stripe callbacks can update payment and order state asynchronously.