@quadcore-lib/notifications-server

Notificaciones in-app por usuario. El usuario autenticado lee/marca las suyas; un admin las crea. (Extendé con email/push reusando mailer-server.)

Endpoints

| Método | Ruta | Acceso | Descripción | |---|---|---|---| | GET | /notifications | usuario | Las del usuario actual (paginadas). | | GET | /notifications/unread-count | usuario | { count } de no leídas. | | PATCH | /notifications/:id/read | usuario | Marcar una como leída. | | POST | /notifications/read-all | usuario | Marcar todas como leídas. | | POST | /notifications | admin | Crear para un usuario. Body: userId, type, title, body?, data?. |

Entidad NotificationEntity (notifications)

id, userId (destinatario), type, title, body?, data? (JSON), readAt?, createdAt.

Notificaciones automáticas (autoNotify)

Con autoNotify: true + eventEmitter, este paquete crea notificaciones solo con que orders-server/payments-server cambien el estado de una orden/pago — sin instrumentar nada a mano en cada proyecto:

import { EventEmitter2 } from '@nestjs/event-emitter'; // o el EventEmitter nativo de Node

const eventEmitter = new EventEmitter2(); // UNA sola instancia, compartida

QuadcoreOrdersModule.forRoot({ eventEmitter /* ...resto de las opciones */ });
QuadcorePaymentsModule.forRoot({ eventEmitter /* ...resto de las opciones */ });
QuadcoreNotificationsModule.forRoot({ autoNotify: true, eventEmitter });

Cómo funciona: orders-server/payments-server emiten ORDER_STATUS_CHANGED/PAYMENT_STATUS_CHANGED (de @quadcore-lib/core-server) sobre eventEmitter al cambiar de estado. AutoNotifyBootstrap (provider interno, solo se registra con autoNotify: true) se suscribe a esos dos eventos con eventEmitter.on(...) en onModuleInit y crea la notificación correspondiente. Si la orden/pago no tiene userId (checkout de invitado), no hay a quién notificar in-app y se ignora — no es un error.

No depende de @nestjs/event-emitter más allá de que sea una opción cómoda para el consumidor: eventEmitter es cualquier objeto con emit(event, payload) y on(event, listener) — el EventEmitter nativo de Node también sirve. autoNotify: true sin eventEmitter lanza al armar el módulo (fail-fast: no tiene sentido pedir auto-notify sin decir de dónde escuchar).

⚠️ Tiene que ser la misma instancia en los tres forRoot(). Si por error pasás new EventEmitter2() (o new EventEmitter()) por separado a cada módulo en vez de reusar una sola, no hay ningún error, warning ni log — orders-server/payments-server emiten sobre una instancia que notifications-server nunca escucha, y las notificaciones simplemente no se crean nunca. Si autoNotify está prendido y no ves notificaciones, esto es lo primero a revisar.

Es best-effort: si crear la notificación falla, se loguea y no vuelve a intentarse — nunca revienta el flujo de negocio que disparó el evento (la orden/pago ya se guardó antes de emitir).

Migraciones

Este paquete trae sus migraciones de TypeORM en dist/src/migrations/*.js (se compilan junto al resto). Ver la guía completa (setup del DataSource, cómo combinarlas con las de otros paquetes, synchronize en dev vs. prod) en el README de @quadcore-lib/core-server, sección "Migraciones de DB".