| name | nestjs-notification |
| description | Standards for Notification Types, Service Architecture, and FCM Integration. Use when building notification services or integrating FCM in NestJS. (triggers: notification.service.ts, notification.entity.ts, notification, push, fcm, alert, reminder) |
NestJS Notification Architecture
Priority: P0 (Standard)
Implement a "Dual-Write" notification system: persist to Database (In-App) and send via FCM (Push).
Structure
src/modules/notification/
├── notification.service.ts # Logic: DB Save + FCM Send
├── entities/
│ └── notification.entity.ts # DB Schema + NotificationType Enum
└── types/
└── notification.types.ts # Interfaces for Payloads/Metadata
Implementation Guidelines
- Use Dual-Write: Save to DB first, then attempt FCM. Catch FCM errors so they don't block the logic.
- Define Granular Types: Use
NotificationType Enum (e.g., APPOINTMENT_REMINDER) for frontend icon/color logic.
- Stringify Metadata: Store routing data (IDs) as JSON string in DB, but Map to string-only Key-Values for FCM
data.
- Handle Tokens: Check for
fcmToken existence before sending. Fail gracefully if missing.
- Serialize Dates: Convert Dates to ISO strings before sending to FCM.
Anti-Patterns
- No Generic Types: Avoid
type: string. Always use the Enum.
- No Blocking FCM: Never
await FCM without a try/catch. It shouldn't crash the request.
- No Complex Data in Push: Keep FCM
data payload flat and minimal (IDs only). Fetch details on open.
References