JK
>ŁADOWANIE // ŁADOWANIE
INICJALIZACJA WIDOKU
Ukończonotypescriptnodejsexpressmongodbcloudinaryjwtdotenveslint
Backend RESTful API w Express.js
Gotowy do produkcji backend REST API ze strukturą MVC i zoptymalizowanymi potokami agregacji w MongoDB.
Problem i rozwiązanie
Budowa stabilnej architektury backendowej ze standaryzowaną obsługą błędów i testami automatycznymi.
Funkcje
- Uwierzytelnianie JWT z rotacją tokenów odświeżania
- Middleware autoryzacji opartej na rolach
- Optymalizacja zapytań agregacyjnych w MongoDB
- Walidacja danych wejściowych i bezpieczeństwo
- Zestaw testów integracyjnych w Jest i Supertest
Stos technologiczny
| Technologia | Wersja | Cel | Dlaczego wybrano |
|---|---|---|---|
| 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 |
Architektura
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
Struktura projektu
src
adminUser
config
middlewares
orders
restaurant
users
app.ts
server.ts
Punkty końcowe API
RMS API (port 3000)
| Metoda | Trasa | Cel |
|---|---|---|
| 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 |
Projekt bazy danych
users
| Kolumna | Typ | Uwagi |
|---|---|---|
| _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
| Kolumna | Typ | Uwagi |
|---|---|---|
| _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
| Kolumna | Typ | Uwagi |
|---|---|---|
| _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
| Kolumna | Typ | Uwagi |
|---|---|---|
| _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
| Kolumna | Typ | Uwagi |
|---|---|---|
| _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.
Kluczowe decyzje projektowe
Modular Monolith Architecture
Decyzja: Single Express.js application with domain-based folder structure
Dlaczego: Appropriate for project scale (~15 endpoints, single deployment)
Korzyści: Simple deployment, easy debugging, low operational overhead, clear domain ownership
Kompromisy: Cannot scale domains independently, all modules share process, no service layer for reuse
JWT for Authentication
Decyzja: Stateless JWT tokens with Authorization: Bearer header
Dlaczego: Standard for REST APIs, no session storage needed
Korzyści: Stateless, no server-side session store, scales horizontally
Kompromisy: No server-side revocation, tokens valid until expiry even if user is deleted
No Service Layer
Decyzja: Business logic resides directly in controllers
Dlaczego: Simplicity for small project, fewer files to navigate
Korzyści: Fast development, fewer abstractions
Kompromisy: Untestable business logic, code duplication across auth controllers, hard to reuse logic
Cloudinary for Image Storage
Decyzja: Menu item images uploaded to Cloudinary CDN
Dlaczego: Managed service avoids S3/MinIO setup, provides CDN and image transformations
Korzyści: No infrastructure to manage, built-in CDN, free tier available
Kompromisy: Vendor lock-in, external dependency, cost at scale, latency for non-CDN regions
Client-Supplied Order Bill
Decyzja: orderBill is sent by the client, not calculated server-side
Dlaczego: Likely intentional simplification for MVP
Korzyści: Simpler server logic
Kompromisy: Critical security vulnerability — clients can manipulate order amounts
No Request Validation Library
Decyzja: Manual if (!field) validation instead of Zod/Joi
Dlaczego: Simplicity, fewer dependencies
Korzyści: No additional dependency, explicit control
Kompromisy: Inconsistent validation, no type inference from schemas, generic error messages
Testy
None installed•0 testów jednostkowych
Co jest testowane
Brakujące pokrycie
- 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
Kluczowe wyzwania
- 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
Kluczowe wnioski
- 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