JK
Projects
JK
>LOADING // LOADING
INITIALIZING VIEW
Built and Designed byJK
JK
>LOADING // PROJECT DETAILS
PARSING ARCHITECTURE, DIAGRAMS & API ENDPOINTS
Back to Projects
View on GitHub
RMS Backend
Completedtypescriptnodejsexpressmongodbcloudinaryjwtdotenveslint

RMS Backend

Backend for a multi-restaurant food ordering platform supporting three user roles (customer, restaurant owner, admin), JWT authentication, menu management with Cloudinary image uploads, and order lifecycle tracking.

Problem & Solution

Acts as the backend for a restaurant ordering platform where customers browse menus from multiple restaurants, place orders, and track delivery status. Restaurant owners manage their menu items. Admins manage the system. The API supports ~15 endpoints across 5 domains with a modular monolith architecture.

Features

  • User/Admin/Restaurant Owner registration and JWT authentication
  • Menu item CRUD with Cloudinary image hosting
  • Order creation with bill calculation, cancellation, and status tracking
  • Role-based ownership checks on menu items
  • Centralized global error handler middleware
  • Modular folder-per-domain structure (routes, controllers, models, types)

Tech Stack

TechnologyVersionPurposeWhy Chosen
Node.js—JavaScript runtimeNon-blocking I/O, large ecosystem
Express.js4.19.2HTTP frameworkMinimal, flexible, well-documented
TypeScript5.5.4Type safetyCompile-time error catching, IDE support
MongoDB—Document databaseFlexible schema, JSON-native, horizontal scaling
Mongoose8.5.3MongoDB ODMSchema validation, middleware, query building
JWT (jsonwebtoken)9.0.2Authentication tokensStateless auth, industry standard
bcrypt5.1.1Password hashingAdaptive hashing, salt rounds
Cloudinary2.4.0Image hosting/CDNManaged service, CDN, image transformations
Multer1.4.5-lts.1File upload handlingExpress-integrated, simple API

Architecture

Frontend Client

React :3000

Express App

app.ts :3000

CORS

express.json

JWT Auth Middleware

Global Error Handler

API Routes

/users, /admin, /restaurant, /menuitems, /orders

Controllers

User, Admin, Restaurant, Menu, Order

Mongoose Models

User, Admin, Restaurant, MenuItems, Order

MongoDB

localhost:27017/RMS

Cloudinary CDN

Local Filesystem

uploads
Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.
Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

Application Layers

  • Express.js middleware pipeline (CORS, JSON parsing, JWT auth)
  • Domain-based modular structure (users, adminUser, restaurant, orders)
  • Controllers with direct Mongoose access (no service layer abstraction)
  • Global error handler middleware with status code mapping

Infrastructure

  • MongoDB via Mongoose 8.5.3 for document storage
  • Cloudinary v2 for menu item image hosting and CDN
  • Multer for multipart file upload handling
  • JWT (jsonwebtoken) for stateless authentication

Project Structure

src
adminUser
config
middlewares
orders
restaurant
users
app.tsExpress app setup, middleware, route mounting
server.tsApplication entry point, starts DB then server

API Endpoints

RMS API (port 3000)

MethodRoutePurpose
GET/Health check / welcome
POST/api/users/registerRegister new user
POST/api/users/loginLogin user
POST/api/admin/createAdminCreate admin user
POST/api/admin/adminloginLogin admin
POST/api/restaurant/createRestaurantRegister restaurant owner
POST/api/restaurant/ownerLoginLogin restaurant owner
POST/api/Menuitems/addItemsCreate menu item with image
PUT/api/Menuitems/:itemIdUpdate menu item
GET/api/Menuitems/getAllItemsList all menu items
GET/api/Menuitems/:itemIdGet single menu item
DELETE/api/Menuitems/:itemIdDelete menu item
POST/api/orders/createorderCreate order
POST/api/orders/cancelorder/:orderIdCancel order
GET/api/orders/orderdetails/:orderIdGet order details

Database Design

users

4 cols
_idPK
ObjectId
name
String
email
String
password
String

admins

4 cols
_idPK
ObjectId
name
String
email
String
userType
String

restaurants

4 cols
_idPK
ObjectId
restaurantName
String
restaurantEmail
String
restaurantPhoneNo
Number

menuitems

5 cols
_idPK
ObjectId
restaurantId
ObjectId
itemName
String
itemPrice
Number
itemImage
String

orders

7 cols
_idPK
ObjectId
customerId
ObjectId
restaurantId
ObjectId
menuId
ObjectId
orderQuantity
Number
orderStatus
String
orderBill
Number
Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.
Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

users

ColumnTypeNotes
_idPKObjectIdAuto-generated
nameStringRequired
emailStringRequired, unique
passwordStringbcrypt hashed
createdAtDateAuto (timestamps: true)
updatedAtDateAuto (timestamps: true)

User accounts. Email is unique.

admins

ColumnTypeNotes
_idPKObjectIdAuto-generated
nameStringRequired
emailStringRequired, unique
passwordStringbcrypt hashed
userTypeStringenum: ['admin', 'user', 'restOwner']

Admin accounts. Separate collection from users.

restaurants

ColumnTypeNotes
_idPKObjectIdAuto-generated
restaurantEmailStringRequired
restaurantPwdStringbcrypt hashed
restaurantNameStringRequired
restaurantAddressStringRequired
restaurantPhoneNoNumberRequired, unique

Restaurant owner accounts.

menuitems

ColumnTypeNotes
_idPKObjectIdAuto-generated
restaurantIdObjectIdNo ref defined — .populate() won't work
itemNameStringHas typo: require instead of required
itemDescriptionStringHas typo: require instead of required
itemPriceNumberHas typo: require instead of required
itemImageStringCloudinary URL

Menu items per restaurant. restaurantId lacks ref property — schema bug.

orders

ColumnTypeNotes
_idPKObjectIdAuto-generated
customerIdObjectIdref: User
restaurantIdObjectIdref: restaurant
menuIdObjectIdref: MenuItems
orderQuantityNumberNo validation for positive values
orderDateDateDefault: Date.now
orderStatusStringenum: ['in process', 'transit', 'cancelled', 'delivered']
orderBillNumberClient-supplied — security concern

Orders are client-supplied bill amounts — no server-side price calculation.

One-to-Many: Users→Orders, Restaurants→MenuItems, Restaurants→Orders, MenuItems→Orders. All via ObjectId references. No many-to-many relationships. menuitems.restaurantId lacks ref property.

Key Design Decisions

Modular Monolith Architecture

Decision: Single Express.js application with domain-based folder structure

Why: Appropriate for project scale (~15 endpoints, single deployment)

Benefits: Simple deployment, easy debugging, low operational overhead, clear domain ownership

Trade-offs: Cannot scale domains independently, all modules share process, no service layer for reuse

JWT for Authentication

Decision: Stateless JWT tokens with Authorization: Bearer header

Why: Standard for REST APIs, no session storage needed

Benefits: Stateless, no server-side session store, scales horizontally

Trade-offs: No server-side revocation, tokens valid until expiry even if user is deleted

No Service Layer

Decision: Business logic resides directly in controllers

Why: Simplicity for small project, fewer files to navigate

Benefits: Fast development, fewer abstractions

Trade-offs: Untestable business logic, code duplication across auth controllers, hard to reuse logic

Cloudinary for Image Storage

Decision: Menu item images uploaded to Cloudinary CDN

Why: Managed service avoids S3/MinIO setup, provides CDN and image transformations

Benefits: No infrastructure to manage, built-in CDN, free tier available

Trade-offs: Vendor lock-in, external dependency, cost at scale, latency for non-CDN regions

Client-Supplied Order Bill

Decision: orderBill is sent by the client, not calculated server-side

Why: Likely intentional simplification for MVP

Benefits: Simpler server logic

Trade-offs: Critical security vulnerability — clients can manipulate order amounts

No Request Validation Library

Decision: Manual if (!field) validation instead of Zod/Joi

Why: Simplicity, fewer dependencies

Benefits: No additional dependency, explicit control

Trade-offs: Inconsistent validation, no type inference from schemas, generic error messages

Testing

None installed•0 unit tests

What's Tested

    Missing Coverage

    • No test framework installed (no jest, mocha, vitest)
    • No test files or test directories
    • No unit tests for controllers or middleware
    • No integration tests for API endpoints
    • No authentication flow tests
    • No database operation tests

    Key Challenges

    • Image upload lifecycle management — temp files, Cloudinary upload, cleanup on error
    • Ownership verification without foreign keys — menuitems.restaurantId lacks ref property
    • Multi-role authentication with three separate entity types (User, Admin, Restaurant)
    • Consistent error response formats across all endpoints

    Key Learnings

    • Scalable structure and request lifecycle with Express
    • Practical JWT authentication with bcrypt password hashing
    • Cloudinary integration for image upload/delete lifecycle
    • Trade-offs of monolithic architecture at small-to-medium scale