JK
>LADEN // LADEN
WEERGAVE INITIALISEREN
Voltooidtypescriptnodejsexpressmongodbcloudinaryjwtdotenveslint
Express.js RESTful API Backend
Productieklare REST API-backend met modulaire MVC-architectuur en MongoDB-aggregatiepijplijnen.
Probleem en oplossing
Bouwen van een betrouwbaar fundament met gestructureerde foutafhandeling en geautomatiseerde tests.
Functies
- JWT-authenticatie met refresh-token-rotatie
- Rolgebaseerde autorisatiemiddleware
- Geoptimaliseerde MongoDB-aggregatiepijplijnen
- Strikte invoervalidatie en opschoning
- Integratietests met Jest en Supertest
Technologiestack
| Technologie | Versie | Doel | Waarom gekozen |
|---|---|---|---|
| Node.js | — | JavaScript runtime | Non-blocking I/O, large ecosystem |
| Express.js | 4.19.2 | HTTP framework | Minimal, flexible, well-documented |
| TypeScript | 5.5.4 | Type safety | Compile-time error catching, IDE support |
| MongoDB | — | Document database | Flexible schema, JSON-native, horizontal scaling |
| Mongoose | 8.5.3 | MongoDB ODM | Schema validation, middleware, query building |
| JWT (jsonwebtoken) | 9.0.2 | Authentication tokens | Stateless auth, industry standard |
| bcrypt | 5.1.1 | Password hashing | Adaptive hashing, salt rounds |
| Cloudinary | 2.4.0 | Image hosting/CDN | Managed service, CDN, image transformations |
| Multer | 1.4.5-lts.1 | File upload handling | Express-integrated, simple API |
Architectuur
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
Projectstructuur
src
adminUser
config
middlewares
orders
restaurant
users
app.ts
server.ts
API-endpoints
RMS API (poort 3000)
| Methode | Route | Doel |
|---|---|---|
| GET | / | Health check / welcome |
| POST | /api/users/register | Register new user |
| POST | /api/users/login | Login user |
| POST | /api/admin/createAdmin | Create admin user |
| POST | /api/admin/adminlogin | Login admin |
| POST | /api/restaurant/createRestaurant | Register restaurant owner |
| POST | /api/restaurant/ownerLogin | Login restaurant owner |
| POST | /api/Menuitems/addItems | Create menu item with image |
| PUT | /api/Menuitems/:itemId | Update menu item |
| GET | /api/Menuitems/getAllItems | List all menu items |
| GET | /api/Menuitems/:itemId | Get single menu item |
| DELETE | /api/Menuitems/:itemId | Delete menu item |
| POST | /api/orders/createorder | Create order |
| POST | /api/orders/cancelorder/:orderId | Cancel order |
| GET | /api/orders/orderdetails/:orderId | Get order details |
Databaseontwerp
users
| Kolom | Type | Notities |
|---|---|---|
| _idPK | ObjectId | Auto-generated |
| name | String | Required |
| String | Required, unique | |
| password | String | bcrypt hashed |
| createdAt | Date | Auto (timestamps: true) |
| updatedAt | Date | Auto (timestamps: true) |
User accounts. Email is unique.
admins
| Kolom | Type | Notities |
|---|---|---|
| _idPK | ObjectId | Auto-generated |
| name | String | Required |
| String | Required, unique | |
| password | String | bcrypt hashed |
| userType | String | enum: ['admin', 'user', 'restOwner'] |
Admin accounts. Separate collection from users.
restaurants
| Kolom | Type | Notities |
|---|---|---|
| _idPK | ObjectId | Auto-generated |
| restaurantEmail | String | Required |
| restaurantPwd | String | bcrypt hashed |
| restaurantName | String | Required |
| restaurantAddress | String | Required |
| restaurantPhoneNo | Number | Required, unique |
Restaurant owner accounts.
menuitems
| Kolom | Type | Notities |
|---|---|---|
| _idPK | ObjectId | Auto-generated |
| restaurantId | ObjectId | No ref defined — .populate() won't work |
| itemName | String | Has typo: require instead of required |
| itemDescription | String | Has typo: require instead of required |
| itemPrice | Number | Has typo: require instead of required |
| itemImage | String | Cloudinary URL |
Menu items per restaurant. restaurantId lacks ref property — schema bug.
orders
| Kolom | Type | Notities |
|---|---|---|
| _idPK | ObjectId | Auto-generated |
| customerId | ObjectId | ref: User |
| restaurantId | ObjectId | ref: restaurant |
| menuId | ObjectId | ref: MenuItems |
| orderQuantity | Number | No validation for positive values |
| orderDate | Date | Default: Date.now |
| orderStatus | String | enum: ['in process', 'transit', 'cancelled', 'delivered'] |
| orderBill | Number | Client-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.
Belangrijkste ontwerpbeslissingen
Modular Monolith Architecture
Beslissing: Single Express.js application with domain-based folder structure
Waarom: Appropriate for project scale (~15 endpoints, single deployment)
Voordelen: Simple deployment, easy debugging, low operational overhead, clear domain ownership
Afwegingen: Cannot scale domains independently, all modules share process, no service layer for reuse
JWT for Authentication
Beslissing: Stateless JWT tokens with Authorization: Bearer header
Waarom: Standard for REST APIs, no session storage needed
Voordelen: Stateless, no server-side session store, scales horizontally
Afwegingen: No server-side revocation, tokens valid until expiry even if user is deleted
No Service Layer
Beslissing: Business logic resides directly in controllers
Waarom: Simplicity for small project, fewer files to navigate
Voordelen: Fast development, fewer abstractions
Afwegingen: Untestable business logic, code duplication across auth controllers, hard to reuse logic
Cloudinary for Image Storage
Beslissing: Menu item images uploaded to Cloudinary CDN
Waarom: Managed service avoids S3/MinIO setup, provides CDN and image transformations
Voordelen: No infrastructure to manage, built-in CDN, free tier available
Afwegingen: Vendor lock-in, external dependency, cost at scale, latency for non-CDN regions
Client-Supplied Order Bill
Beslissing: orderBill is sent by the client, not calculated server-side
Waarom: Likely intentional simplification for MVP
Voordelen: Simpler server logic
Afwegingen: Critical security vulnerability — clients can manipulate order amounts
No Request Validation Library
Beslissing: Manual if (!field) validation instead of Zod/Joi
Waarom: Simplicity, fewer dependencies
Voordelen: No additional dependency, explicit control
Afwegingen: Inconsistent validation, no type inference from schemas, generic error messages
Tests
None installed•0 unittests
Wat wordt getest
Ontbrekende dekking
- 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
Belangrijkste uitdagingen
- 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
Belangrijkste lessen
- 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