notifications-microservice

Este repositorio es parte del backend de la aplicacion class-connect, para conocer informacion mas general sobre el proyecto visita el siguiente link Organization Homepage.

Descripción

Este microservicio es responsable de gestionar las notificaciones dentro de la aplicación. Sus principales funciones incluyen:

• Envio de Notificaciones: Push o Correo Electrónico.
• Manejo de Permisos: Explicitamente para notificaciones particulares a los usuarios. se puede desactivar las push o las de correo.
• Envío de emails informativos a todos los usuarios en caso de actualizaciones de reglas o políticas. Esta operación requiere la inclusión de un encabezado Authorization con un token JWT válido de administrador.
• Registro de Logs: Tres estados posibles para un notificación:
  • Sent
  • Not Sent - No Permissions
  • Error
• Historial de Notificaciones Push: Mantiene un registro por usuario, incluyendo la capacidad de marcar cada notificación como leída o no leída.

Endpoints

Los endpoints de este microservicio se pueden encontrar en el swagger del mismo, los mismos son:

• GET /swagger (Documentacion de la API)

• POST /push (Envio de notificaciones push a los usuarios por uuid)

• GET /email?by=(id or email) (Envio de correos a los usuarios por uuid o email. El parametro send_to_all es para admins y requiere autentificación con el JWT token de admins)

• GET /user/permissions (Obtiene los permisos de un usuario según su JWT token)

• PUT /user/permissions (Actualiza los permisos de un usuario según su JWT token)

• GET /user/history (Obtiene el historial de notificaciones push de un usuario según su JWT token.)

• PUT /user/history (Marca una notificación del historial como leída)

• GET /logs

Estructura

Se utiliza la arquitectura package by layer, donde los controladores se pueden encontrar en la carpeta endpoints, los servicios en services y los repositorios en repository.

Despliegue

1. Se hace feature branching desde la rama dev.
2. Una vez listo para integrar se realiza PR a dev, donde corre el pipeline de testing y coverage.
3. Una vez esta listo para desplegar se realiza PR a main, se vuelven a correr pipelines de calidad de codigo.
4. Cuando se hace el push a main se ejecuta el pipeline de continous delivery, construye la imagen y la desplega a k8s.