Este codelab está planeado para ver una forma en que se puede crear un proyectos de tipo microservicio para una aplicación basada en APIs.
Requisitos:
- NodeJS LTS
- Git
- Generador de JHipster
- Docker (opcional)
Para poder crear el proyecto, primero se debe crear un directorio, posicionarse en él y ejecutar el comando de JHipster.
mkdir appMs
cd appMs
jhipster app --jhi-prefix core --skip-user-management --skip-fake-data
Una vez iniciado el generador de JHipster, es necesario seleccionar como tipo de proyecto microservice.
Se debe indicar el nombre del proyecto.
Se deberá indicar que la aplicación es reactiva; esto se respondiendo que el proyecto es reactivo con Spring Webflux (responder con y).
Se debe especificar el puerto que va a usar el microservicio, este no debe chocar con ninguna otra aplicación que se tenga en el ambiente local.
Se debe indicar la estructura de paquetes a utilizar en el proyecto.
Se debe indicar el tipo de service discovery a utilizar.
Se debe indicar el tipo de autenticación a utilizar.
Los proyectos JHipster usan a liquibase para auto administrar la base de datos (relacional) y a mongock para auto administrar a MongoDB.
La auto administración implica que el proyecto creará y mantendrá actualizadas las estructuras y contenido de la base de datos para ser compatible con el código.
Base de datos SQL
Si el modelo de datos del proyecto es muy tradicional (no se pude manejar con single documents) o no se tiene muy claro que tipo de datos usar, lo ideal es utilizar una base de datos SQL.
Motor de base de datos para producción
Motor de base de datos para desarrollo
Base de datos NoSQL
Si el proyecto requiere una lectura de datos muy rápida y el modelo de datos se puede definir con pocos single documents (con documentos embebidos), es probable que el proyecto se pueda desarrollar con MongoDB.
Sin base de datos
En caso de que el proyecto requiera conectarse a una base de datos administrada de forma tradicional (por un DBA), se deberá seleccionar sin base de datos.
Para este caso, se recomienda seguir el codelabs proyecto con una base de datos externa.
Es posible seleccionar el administrador de proyecto java (Maven o Gradle).
Como parte de otras tecnologías que JHipster puede incluir en el proyecto, se deberá seleccionar el generador de OpenAPI.
Si se desea, se puede agregar el soporte de internacionalización al proyecto.
Se define español como lenguaje principal.
Se define inglés como lenguaje secundario (se pueden seleccionar más lenguajes)
Por default, el proyecto tiene soporte con JUnit; sin embargo, si se desea otra tecnología, es posible seleccionar otros frameworks extras.
JHipster tiene la posibilidad de agregar otros generadores, sin embargo, no seleccionaremos nada extra.
Una vez que se contesta la última opción, el generador creará el proyecto, creará un repositorio git y se compilará una primera versión.
Al concluir las operaciones, deberá salir una pantalla como la siguiente.
Después de crear el proyecto, es recomendable revisar el codelab de adecuaciones extras a proyectos de microservicios para realizar cambios requeridos en los proyectos de Conacyt.
Por otro lado, se recomienda tener en cuenta lo siguiente:
OpenAPI
Se deberá editar el archivo src/resources/swagger/api.yml para definir los diferentes endpoints que requiera el negocio.
Base de datos relacional
Si la base de datos es PostgreSQL, se deberá usar a liquibase para definir la estructura de la base de datos.
Una forma de hacer un modelo inicial, es creando un archivo JDL y luego importarlo para generar tanto las clases como los archivos de liquibase.
Base de datos MongoDB
Se debe evitar usar el generador de JHipster de entidades.
Para facilitar la codificación, se puede agregar el soporte de lombok al proyecto.
Integración continua
Al proyecto se le deberá agregar un proceso de integración continua
Publicación de OAS
La interacción entre el proyecto de microservicio y otros proyectos es por medio del OAS (OpenAPI Specification).
cambios en la arquitectura
Cualquier cambio en la arquitectura (uso de otras tecnologías, cambios en la estructura del proyecto, cambios en el tipo de seguridad, etc.); deberá ser consultado y autorizado por el equipo de arquitectura.