Microservice Paciente
Microservicio Paciente
Este servicio nos permite manejar y utilizar los datos de los usuarios. Podemos guardar pacientes, consultar a un paciente por su DNI, por su email, actualizar los datos de los usuarios, actualizar el número de teléfono, además de consultar a los pacientes que solo están activos y/o por su tipo de imagen y eliminar a un usuario.
Funcionalidades
- Guardar pacientes
- Consultar a un paciente por su DNI
- Consultar a un paciente por su email
- Actualizar los datos de los usuarios
- Actualizar el número de teléfono
- Consultar a los pacientes activos
- Consultar a los pacientes por su tipo de imagen
- Eliminar a un usuario
Arquitectura
Estamos utilizando Consul para manejar los key/values de la base de datos MongoDB. Consul nos ayuda a conectarnos de forma segura a las aplicaciones.
Modelo de Paciente
El modelo de nuestro paciente es el siguiente. Hacemos validaciones de algunos de nuestros atributos, como el DNI, que no puede ser nulo ni estar vacío, entre otros. Además, lo anotamos como una entidad de MongoDB que se guarda en la colección patient.
Manejo de Excepciones
Para manejar las excepciones de manera sencilla para el usuario, creamos un ExceptionMapper que envía una respuesta con un estado de 404 y el tipo de ConstraintViolation que se ha realizado en formato JSON.
Ejemplo de respuesta:
Documentación de Paciente
La documentación se realiza con Swagger. Las configuraciones generales de Swagger se realizan en el archivo application.properties.
Así es como se visualiza en la interfaz:
Chequeos de Salud
Por defecto, cuando tenemos la dependencia de chequeos de salud en Quarkus, ya se levantan algunos chequeos. Por ejemplo, si estamos usando la base de datos MongoDB, se levantará un chequeo que nos indicará si está lista para usarse. También podemos crear nuestros propios HealthCheck.
Ejemplo de SimpleHealthCheck:
Quarkus ofrece muchas herramientas, una de ellas es /health-ui, que nos muestra qué servicios están levantados.
Controlador
Vamos a analizar algunos extractos de las imágenes de nuestro resource o controlador de pacientes.
En esta primera imagen vemos algunas anotaciones:
@Operation: Esta es una anotación de OpenAPI que nos ayuda a agregar información y un resumen a nuestro endpoint para brindar una explicación detallada.@Counted: Es una anotación de métrica que nos ayuda a tener un conteo de cuántas veces se utiliza este endpoint.@Timed: Otra métrica que nos ayuda con el tiempo que tomó en dar un resultado.
Lo diferente aquí es la anotación @Metered del endpoint que actualizará el número de teléfono del usuario. Esta anotación es otra manera en la que podemos medir la eficiencia de la respuesta que tiene ese endpoint.
Finalmente, las métricas se visualizan de la siguiente manera:
