MICROSERVICIOS CON HELIDON

Una alternativa tecnológica para escribir microservicios en Java es Helidon, un nuevo proyecto de Oracle. Veamos qué tal le va en ésta competencia.

Hechos

Cuenta con tres componentes:

1. WebServer: un API HTTP con características reactivas, provistas por Netty.
2. Config: un framework de configuración flexible que soporta múltiples fuentes y formatos.
3. Security: herramientas para autenticación, autorización y propagación de contexto.

Se puede elegir entre dos modelos de programación:

1. Helidon SE: estilo de programación funcional que usa los tres componentes mencionados anteriormente.
2. Helidon MP: modelo declarativo que soporta las APIs de Microprofile

Cuenta también con soporte para Docker y Kubernetes, lo que lo hace atractivo para aplicaciones con arquitecturas basadas en microservicios.

Prerrequisitos

Al parecer los prerrequisitos son muy simples:

1. Java 8 o superior
2. Maven

Opcionalmente:

1. Docker, si necesitamos desplegar en contenedores.
2. Kubectl, si necesitamos desplegar en Kubernetes
3. Kubernetes Cluster

Las versiones mínimas son las siguientes:

1. Java 8 SE u Open JDK 8
2. Maven 3.5
3. Docker 18.02
4. Kubectl 1.7.4

No se necesita nada adicional. Veamos si es tan simple como parece.

Máquina Virtual

Estoy usando una máquina virtual que me pasó mi compi @domix. Validaré los prerrequisitos:

Arquetipos

Como mencioné anteriormente, existen dos modelos de programación que podemos elegir: Helidon SE y Helidon MP. El primer paso es generar el proyecto usando los arquetipos de Maven para Helidon. El resultado será un servicio REST con la misma API, sin embargo, la implementación es distinta.

Helidon SE

Helidon MP

Proyectos

Lo anterior generará dos proyectos: uno de Helidon SE y otro de Helidon MP. Misma API REST, distinta forma de implementar.

Construcción de la aplicación

Para ambos casos (SE y MP), vamos a construir la aplicación utilizando Maven.

Lo anterior, va a compilar el código, ejecutar un set de pruebas y finalmente crear un JAR.

La diferencia entre SE y MP es el servidor que ejecuta la aplicación. En el caso de Microprofile, el tiempo de arranque es de 151 milisegundos. ¡Nada mal!

Finalmente, podemos observar los JAR generados de la aplicación. También se puede observar que el JAR de MP es ligeramente más grande que el de SE. Es el precio por tener un arranque mucho más rápido, aunque la diferencia en tamaño del mismo código no es significativa.

Ejecutar y Probar la Aplicación

Ahora que ya tenemos el paquete, vamos a ejecutarlo y probarlo. La ejecución es simple, como cualquier otro JAR ejecutable. Al ser un servicio REST el que expusimos en la aplicación, sólo tenemos que enviar peticiones HTTP adecuadas. El set de pruebas ejecutado es el siguiente:

1. GET a /greet, RESPONSE: Hello World!
2. GET a /greet/{nombre}, RESPONSE: Hello {nombre}!
3. PUT a /greet/greeting/{saludo} (esto modificará el mensaje del saludo), RESPONSE: {saludo}
4. GET a /greet/{nombre}, RESPONSE: Hola (nuevo saludo) {nombre}!

Helidon SE

Helidon MP

No es por presumir, pero ésta vez la aplicación tardó 136 milisegundos en iniciar. El servicio expuesto cumple con la misma interfaz que en el caso de SE, por lo que si ejecuto el mismo set de pruebas, el resultado debe ser el mismo.

Conclusiones

Pienso que al ser Helidon una colección de librerías para escribir microservicios en Java, muchos desarrolladores de la comunidad pueden tanto colaborar como hacer uso de ellas. Me parece que podría haber un buen futuro si se promueve el uso y colaboración en el desarrollo del proyecto.

Iniciar a escribir código es muy rápido (quizá no tanto como el Starter de SpringBoot, pero bastante decente), además de que el uso de Maven y los arquetipos hace que tengas un proyecto de código listo literalmente en minutos (versión inicial o cascarón).

La opción de Microprofile ha sido una gran decisión, pues ayuda en la controversia del uso de Java (y el tiempo de inicio) en arquitecturas orientadas a microservicios. En mi caso, la aplicación tarda en promedio 150 milisegundos en iniciar. Me parece un tiempo bastante decente para una aplicación de éste estilo. Faltaría probar al incluir más servicios y con mayor complejidad y dependencias.

Helidon SE

Si revisamos un poco el código, es bastante simple. Tenemos una clase principal de la aplicación, donde definiremos el inicio del servidor y el contexto inicial o base de la API REST:

Del lado de la implementación, tendríamos que sobreescribir el método update de la clase Service para definir las URIs y métodos HTTP a exponer, así como la referencia a los métodos que implementan la lógica de cada recurso:

Finalmente, escribimos la lógica de cada uno de los métodos de implementación de los recursos:

Helidon MP

Para el caso de Microprofile, tenemos una clase principal muy similar donde definimos el contexto base de la aplicación. Sin embargo, los métodos para iniciar la aplicación y la configuración del logging resultan mucho más simples:

El resto del código es el de una aplicación con JAX-RS usando Java EE:

Esto parece una buena decisión, pues quienes ya creaban aplicaciones con JAX-RS, lo van a poder seguir haciendo de la misma forma y aquí el que sirve es Microprofile.

Docker y Kubernetes

La decisión de soportar Docker y Kubernetes hace a Helidon una alternativa bastante interesante para aplicaciones Cloud Native pues, como dijo mi amigo @RuGI, Docker no debe tardar en convertirse en un estándar en contenedores.