El microservicio de Messages, es el encargado de gestionar las distintas operaciones que se pueden realizar en el chat entre dos usuarios. La creación de dichos chats, se produce al interactuar ambos usuarios con una misma canción al “darle a like” a esta.

Entre estas operaciones se encuentra el envío de mensajes a otros usuarios, la edición de mensajes propios, la traducción de mensajes ajenos (utilizando la API externa DeepL API) o la denuncia de mensajes ajenos. Por otra parte, se pueden efectuar operaciones a nivel de las salas de chats, entre las que se encuentran la creación de salas, la edición del nombre y de la descripción de la sala y la eliminación de la misma.

Toda la información de la sala y de los mensajes persistirá en una base de datos MongoDB, utilizando Node.js como backend y React.js como frontend.

Nivel 9.

El microservicio Messages está compuesto por dos entidades principales:

• Message, realizada por Jorge, representa un mensaje enviado por un usuario en una room concreta.

{
  userId: { type: Schema.Types.ObjectId, required: true },
  roomId: { type: Schema.Types.ObjectId, required: true },
  text: { type: String, required: true, maxLength: 255 },
  translatedText: { type: String, maxLength: 255 },
  replyToId: { type: Schema.Types.ObjectId },
  reportedBy: {
    userId: { type: Schema.Types.ObjectId },
    reason: { type: String },
    madeAt: { type: Date },
    isBanned: { type: Boolean }
}

• Room, realizada por Félix, representa una sala de chat entre dos usuarios.

{
    name: { type: String, required: true },
    description: { type: String, required: true },
    songId: { type: Schema.Types.ObjectId, required: true },
    participants: [
      {
        userId: { type: Schema.Types.ObjectId, required: true },
        role: { type: Number, enum: Object.values(Role), default: Role.NORMAL }
      }
    ],
}

Ambas entidades han seguido una estructura de código fuente acorde a las carpetas:

• models → Incluye los modelos de las dos entidades.

• controllers → Incluye la funcionalidad de las dos entidades, recibiendo peticiones y devolviendo respuestas.

• routes → Incluye los endpoints de las dos entidades.

• services → Incluye servicios auxiliares que tienen una cierta abstracción con respecto a ambas entidades.

Como se mencionó en el apartado de Descomposición del microservicio de Messages, para la implementación de la API REST, se ha llevado la estructuración de carpetas models, controllers, routes y services.

Cada entidad tiene sus rutas asociadas y por consiguiente sus controladores asociados. De esta manera, se pueden recibir peticiones a través del endpoint correspondiente desde el frontend, y se pueden enviar las respuestas correspondientes a dichas llamadas (con el código de estado y el contenido apropiado).

Para más información sobre las rutas existentes, se proporciona la documentación en Swagger.

✔️ - Microservicio básico completamente implementado.

• El backend debe ser un API REST tal como se ha visto en clase implementando al menos los métodos GET, POST, PUT y DELETE y devolviendo un conjunto de códigos de estado adecuado. → Dicho backend se puede encontrar en el código fuente de este repositorio.

• La API debe tener un mecanismo de autenticación. → Se utilizó JWT para realizar la autenticación.

• Debe tener un frontend que permita hacer todas las operaciones de la API (este frontend puede ser individual o estar integrado con el resto de frontends). → Se utilizó un Frontend común.

• Debe estar desplegado y accesible en la nube. → Accesible desde

• La API que gestione el recurso también debe ser accesible en una dirección bien versionada. → La ruta de la API está bien versionada: se especifica tras el hostname (y puerto en caso de ser en local), el texto api/v1, indicando que es la primera versión de la API.
  Esta versión es seguida del resto del endpoint que dependerá de la operación que queramos hacer sobre un recurso concreto; i.e. si queremos hacer una llamada que realice una operación sobre room, llamaremos a api/v1/room seguido del endpoint necesario para realizar la acción.

• Se debe tener una documentación de todas las operaciones de la API incluyendo las posibles peticiones y las respuestas recibidas. → Nuevamente, referencia a Swagger.

• Debe tener persistencia utilizando MongoDB u otra base de datos no SQL. → Se utilizó MongoDB para la persistencia de datos. La configuración de la base de datos se puede encontrar en el fichero db.js.

• Deben validarse los datos antes de almacenarlos en la base de datos (por ejemplo, haciendo uso de mongoose). → Se ha utilizado mongoose para la validación de los datos antes de almacenarlos. Esto, se puede ver en los modelos de las distintas entidades.

• Se debe utilizar gestión del código fuente y mecanismos de integración continua: o El código debe estar subido a un repositorio de Github siguiendo Github flow o El código debe compilarse y probarse automáticamente usando GitHub Actions u otro sistema de integración continua en cada commit.

• Debe haber definida una imagen Docker del proyecto

• Debe haber pruebas de componente implementadas en Javascript para el código del backend utilizando Jest y pruebas de integración con la base de datos. → Dichas pruebas se encuentran aquí.

✔️ - Diseño de un customer agreement para la aplicación en su conjunto con dos planes de precios que considere características funcionales y extrafuncionales. Este diseño debe contemplar el uso de SendGrid o algún otro servicio externo con un plan de precios múltiple.

✔️ - Este documento que se está leyendo actualmente.

✔️ - Vídeo demonstración de la aplicación en funcionamiento.

✔️ - Presentación de la aplicación.

✔️ - Todos los requisitos del nivel hasta 5 puntos

✔️ - Aplicación basada en microservicios básica implementada, i.e. la interacción completa entre todos los microservicios → Esto se ha logrado con llamadas a los distintos endpoints, siguiendo el esquema de la aplicación. Asimismo, a través de la API Gtateway

✔️ - Análisis de límites de capacidad del customer agreement asumiendo que esto no tiene implicaciones en el precio.

✔️ - Al menos 3 de las características del microservicio avanzado implementados.

Se han implementado las siguientes características:

• Implementar un frontend con rutas y navegación, utilizando react-router-dom

• Usar redux como forma de gestionar el estado de los componentes de React en el frontend.

• Consumir alguna API externa. Se utilizó DeepL API para la traducción de mensajes.

✔️ - Todos los requisitos del nivel hasta 7 puntos

✔️ - Un mínimo de 20 pruebas incluyendo casos positivos y negativos. → El con junto de pruebas se puede encontrar aquí.

✔️ - Justificación del coste de cada plan del customer agreement.

✔️ - Tener el API REST documentado con Swagger.

✔️ - Al menos 5 de las características del microservicio avanzado implementados.

✔️ - Al menos 3 de las características de la aplicación basada en microservicios avanzada implementados, que son: