Skip to content
Chethan Yadav
Work

Engineering/2025/Active

ERCS Backend

Emergency Response & Coordination System backend.

JavaScript
Repository

Overview

ERCS (Emergency Response & Coordination System) Backend is a JWT-authenticated REST API for logging and tracking emergencies and incidents — the kind of service that would sit behind a dispatcher dashboard or a citizen-reporting frontend. It's built on Express and MongoDB (via Mongoose), with a ws-based WebSocket server mounted on the same HTTP server alongside the REST routes.

The project models two related but distinct resources: incidents (a lighter-weight report — type, location, description, status) and emergencies (a richer record with geolocation, a named reporter/contact, an array of assigned responders, and media attachments). Both get full CRUD routes; user accounts get authentication and read access, with write operations still scaffolded rather than implemented.

Key Features

  • JWT-based auth — sign-up and sign-in issue a bcrypt-backed, JWT-secured session; protected routes verify the token and attach the resolved user via an authorize middleware
  • Incident reporting — full CRUD for lightweight incident reports (type, location, description, status: Pending / In Progress / Resolved)
  • Emergency reporting — full CRUD for richer emergency records, including geolocation (latitude/longitude/address), a named reporter/contact, an array of assignedResponders referencing user accounts, and media attachments, with a five-stage status pipeline (Pending → Dispatched → En Route → On Scene → Resolved)
  • User management — read access (list/get) is live and JWT-protected; create/update/delete routes exist but are still stub handlers
  • WebSocket server — a ws server runs alongside the REST API on the same HTTP server, currently as a connection/echo scaffold

API Reference

All routes are mounted under /api/v1.

POST   /api/v1/auth/sign-up
POST   /api/v1/auth/sign-in
POST   /api/v1/auth/sign-out        # route defined, handler not yet implemented
 
GET    /api/v1/users                # JWT-protected
GET    /api/v1/users/:id            # JWT-protected
POST   /api/v1/users                # placeholder response, not yet wired to the DB
PUT    /api/v1/users/:id            # placeholder response, not yet wired to the DB
DELETE /api/v1/users/:id            # placeholder response, not yet wired to the DB
 
POST   /api/v1/incidents/create
GET    /api/v1/incidents
GET    /api/v1/incidents/:id
PUT    /api/v1/incidents/:id
DELETE /api/v1/incidents/:id
 
POST   /api/v1/emergencies
GET    /api/v1/emergencies
GET    /api/v1/emergencies/:id
PATCH  /api/v1/emergencies/:id
DELETE /api/v1/emergencies/:id

Setup

git clone https://github.com/chethanyadav456/ERCS_Backend.git
cd ERCS_Backend
npm install

Environment variables are loaded from .env.<NODE_ENV>.local (e.g. .env.development.local):

PORT=3000
NODE_ENV=development
SERVER_URL=http://localhost:3000
DB_URI=your_mongodb_connection_string
JWT_SECRET=your_jwt_secret
JWT_EXPIRES_IN=1d
EMAIL_PASSWORD=your_email_app_password
npm run dev    # nodemon, auto-restart
npm run start  # plain node

How It Works

Sign-up and sign-in both hash/compare passwords with bcryptjs and return a jsonwebtoken-signed token; sign-up wraps user creation in a Mongoose session/transaction. Protected routes pull the token from the Authorization: Bearer header, verify it against JWT_SECRET, look the user up by the decoded ID, and attach it to req.user before continuing — anything that fails that chain gets a 401.

The WebSocket server (ws) is instantiated on the same http.Server the Express app runs on, so both share a port. As it exists in the repo it logs connections and echoes messages back — the plumbing a real-time incident/emergency broadcast layer would sit on top of, not that layer itself yet.

View on GitHub ↗