tashdik-29/shopninja-server

1. Repository shape

- This is a small Node.js backend service, not a multi-package or microservice system.

- The top level contains only index.js, package.json, package-lock.json, vercel.json, and the README, which suggests a single deployable API entrypoint with minimal internal file structure exposed in this snapshot.

2. Core runtime

- The application runs on Node.js with Express.js as the HTTP server layer.

- index.js is the main bootstrap file and is likely responsible for creating the server, registering middleware, and wiring API routes.

3. Primary domain

- The domain is a delivery management system called ShopNinja.

- The system centers on parcel booking, approval, assignment, tracking, and delivery-status updates.

4. User roles and boundaries

- There are three functional actors:

- User: books parcels and tracks delivery progress.

- Admin: approves bookings, views all parcels, and assigns parcels to delivery personnel.

- Deliveryman: receives assigned parcels and updates delivery status.

- These roles define the main authorization boundaries in the architecture.

5. API security and identity

- The backend uses JWT to secure API access and enforce role-based behavior.

- The README also states Firebase is used for authentication, so authentication appears split between Firebase sign-in/sign-up and JWT-based authorization for protected API operations.

- In architecture terms, Firebase is the identity provider, while JWT is the session/access-control mechanism for the backend.

6. Data layer

- MongoDB is the persistent datastore.

- It likely stores user profiles, parcel bookings, approval state, assignment state, and delivery history.

- The data model is probably centered on parcel lifecycle records rather than isolated feature-specific services.

7. Parcel lifecycle flow

- The main business flow is:

- User creates a parcel booking.

- Booking enters a pending state.

- Admin reviews and approves it.

- Admin assigns it to a deliveryman.

- Deliveryman updates delivery progress and final delivery status.

- User can view status updates and history.

- This is the central data flow for the whole system.

8. Operational dashboards

- The README describes separate dashboards for admin, user, and deliveryman, which implies role-specific API endpoints and views on the client side.

- The backend serves these dashboards by exposing different parcel queries and mutations depending on role and authorization level.

9. Deployment / hosting

- vercel.json indicates the service is configured for Vercel deployment.

- That suggests the backend may be deployed as a serverless/edge-friendly Node application or a Vercel-hosted API, rather than a traditional long-running VM service.

10. External integrations

- The README mentions a Stripe Secret Key in environment setup, implying payment-related capabilities or future payment integration, even though payment flow is not described in detail.

- The key external services affecting architecture are therefore:

- MongoDB for persistence

- Firebase for authentication

- JWT for API authorization

- Stripe for payment-related integration

11. Architectural summary

- Overall, the repo appears to implement a single-service monolithic API with a simple server entrypoint, external auth, MongoDB persistence, and role-based parcel workflows.

- The important diagram boundaries are: client dashboards on one side, the Express API in the middle, and MongoDB/Firebase/Stripe as external dependencies on the other side.