akshaymarch7/devtinder

Purpose and Runtime

This is a Node.js backend for a user-connection platform with authentication, profiles, connection requests, chat, and payments. The application entry point is src/app.js; persistence is initialized through src/config/database.js. Route modules expose the API surface.

HTTP API Composition

src/app.js is the composition boundary for middleware, database setup, and route registration. Domain endpoints are separated by concern:

• Authentication: src/routes/auth.js

• Users and profiles: src/routes/user.js, src/routes/profile.js

• Connection-request lifecycle: src/routes/request.js

• Chat and payment workflows: src/routes/chat.js, src/routes/payment.js

This routing layer should remain responsible for request orchestration rather than persistence or third-party integration details.

Identity and Access Boundary

Authentication is centralized in src/middlewares/auth.js, with user identity represented by src/models/user.js. Auth routes in src/routes/auth.js establish identity; protected routes should consume the middleware-provided identity rather than accepting a user identifier as authority.

Validation and shared domain constants are located in src/utils/validation.js and src/utils/constants.js, forming common input and state constraints across route flows.

Core Social Domain

User discovery/profile data is handled through src/models/user.js and profile-facing routes in src/routes/profile.js. Relationship state is a separate persisted concept in src/models/connectionRequest.js, exposed through src/routes/request.js.

Primary flow: authenticated user → profile/user action → create, review, or update a connection request → resulting relationship state gates downstream interactions such as chat.

Realtime Chat

Chat persistence is modeled in src/models/chat.js; HTTP-facing chat operations are in src/routes/chat.js. Realtime/socket behavior is isolated in src/utils/socket.js, creating a transport boundary between the main HTTP application and event-driven delivery.

Expected control flow is: authenticated/authorized participants → chat message persisted via the chat domain → socket layer broadcasts or delivers events. Relationship authorization should be enforced before chat access.

Payments and External Services

Payments are represented by src/models/payment.js, coordinated by src/routes/payment.js, and integrated through src/utils/razorpay.js. Razorpay is therefore an external payment-service boundary; payment records should track application-side state independently of provider responses.

Email delivery is abstracted through src/utils/sendEmail.js and src/utils/sesClient.js, indicating Amazon SES integration. Scheduled/background actions are centralized in src/utils/cronjob.js, which is the likely boundary for recurring jobs such as notifications, expiry handling, or payment/request reconciliation.

Data and Infrastructure Boundaries

Mongo-style model organization is implied by the domain model files under src/models/, while src/config/database.js owns database connectivity. The application depends on at least three infrastructure concerns: database persistence, Razorpay payment processing, and Amazon SES email delivery. Socket infrastructure is additionally required for realtime chat behavior.

Key architecture rule: routes coordinate requests; models own persisted entities; middleware owns cross-cutting authorization; utilities encapsulate external providers, sockets, and scheduled execution.