Kunal Chaudhari
Open to work Let's talk

(Healthcare) Aug 2025 — Present · Webbrains Technologies

Cure & Care

Four apps — for patients, doctors, admins and mobile — running on one shared backend.

Patients book visits and order medicines. Doctors run their day and send prescriptions. Admins manage everything. Four apps share one backend — so every screen updates the moment something changes.

Role
Full Stack Developer
Focus
Data model, API contract, access control
Status
Live and maintained

(01) In numbers

  • 406REST endpoints

    Grouped by module, validated in middleware

  • 53Mongoose models

    One clinical data model behind all four surfaces

  • 4Client surfaces

    Patient, doctor, admin and a mobile client

  • 1Backend

    One contract, and one place to fix a bug in it

(02) Under the hood

One call, from a patient's screen to the pipeline that answers it

  1. 01 · CLIENT

    Four surfaces

    Patients, doctors, admins and a mobile client all open the same API. What differs between them is not the data — it is which slice of it they are allowed to see.

  2. 02 · EDGE

    Nginx and PM2

    SSL terminates at Nginx; PM2 keeps the Node processes up and brings them back after a reboot.

  3. 03 · IDENTITY

    JWT session

    The token says who is asking. Nothing downstream re-derives it, and nothing downstream trusts a role the client supplied.

  4. 04 · ACCESS

    Permission gate

    Permissions resolve in middleware, ahead of the controller. A doctor route and a patient route are the same code with a different gate in front of it.

  5. 05 · API

    Module router

    406 routes grouped by subject rather than by caller — appointments, prescriptions, orders, catalogue — with validation and pagination already applied.

  6. 06 · DATA

    53 Mongoose models

    One clinical data model. Compound indexes sit behind the queries the dashboards make, so the aggregation has something to stand on.

  7. 07 · ANALYTICS

    Aggregation pipeline

    Dashboard figures are computed by MongoDB rather than assembled in Node. The pipeline returns the shape the screen draws.

  8. 08 · LIVE

    Socket.IO broadcast

    An appointment that moves is pushed to the surfaces that care about it, so a doctor's calendar and a patient's screen never disagree.

(03) The story

01 — The Problem

Four applications wanted the same record

Patients, doctors, administrators and a mobile client each needed the clinical record, and each needed a different part of it. Written per surface, that is four codebases drifting apart — and four places for a permission to be wrong.

  • One record, four readings of it — patient, prescriber, administrator, mobile.
  • Permissions that differ by role, not by endpoint.
  • Dashboards that summarise the same data the surfaces are writing.

02 — What I Built

One API, with the permissions in front of it

A single Express service organised by module rather than by client. Validation, pagination and permission checks all run before any controller does, so a route is only the part that is genuinely different.

  • 406 endpoints across 53 Mongoose models, grouped by domain module.
  • JWT sessions, with role and permission resolution in middleware.
  • Aggregation pipelines for the dashboard figures, compound indexes behind them.
  • Socket.IO for appointment changes, so the four surfaces stay in agreement.

03 — What Changed

One place to fix it

A permission rule is written once and applies to every surface that touches the route. A new screen consumes the contract that already exists instead of asking for an endpoint of its own.

  • A new surface is a consumer of the API, not a fork of it.
  • Dashboard figures come back from one pipeline instead of several round trips.
  • An appointment change reaches every screen that is watching it.

(04) Architecture

Six layers, pulled apart

  1. 01

    Client surfaces

    React dashboards for patients, doctors and administrators, and a mobile client against the same contract.

  2. 02

    Edge

    Nginx with SSL in front, PM2 keeping the Node processes alive, Winston writing the day down.

  3. 03

    API

    Express routers per module. Validation and pagination are middleware, not controller preamble.

  4. 04

    Access

    A JWT session, then a role and permission model that resolves per route.

  5. 05

    Domain

    Services for appointments, prescriptions, orders and catalogue, each owning its own rules.

  6. 06

    Data

    53 Mongoose models, aggregation pipelines for analytics, compound indexes behind the slow queries.

(05) Decisions

Why it is built this way

  1. (01)

    Permissions live in middleware

    A permission checked inside a controller is a permission checked in one place and forgotten in the next. Putting the check in front of the route makes the rule visible in the route table and hard to skip by accident.

  2. (02)

    Grouped by subject, not by caller

    Routes are organised by what they are about rather than who calls them. The mobile client and the admin dashboard hit the same appointment endpoints, which is exactly why they cannot drift apart.

  3. (03)

    Let the database do the arithmetic

    Dashboard numbers are produced by aggregation pipelines with compound indexes behind them, rather than by pulling documents into Node and adding them up there.

(06) Built with

What it runs on

Backend first, with every front end consuming the same contract.

For the technically curious406 endpoints and 53 models serving four applications from one backend. Four separate applications — patients, doctors, admins and a mobile client — all needed the same clinical data with completely different permissions over it. One backend now serves all four surfaces, with dashboard analytics coming out of aggregation pipelines and appointment changes pushed live over Socket.IO.

Node.jsExpressMongoDBMongooseReactSocket.IOJWTAggregationDockerNginxPM2Winston

Next case study Enterprise TATA Advanced Systems Company sign-in, and a permanent record of every stock movement.
Build something like this All case studies