Introduccion

Las tecnologias del front están creciendo como la espuma y bien sabemos que el front ya no es solamente hacer validaciones o hacer marquesinas, ahora se desarrollan aplicaciones enteras con el concepto de Single Page Applications, dejando a Java solo en el Middleware o en Android. Y después de Kotlin ya ni en Android :P. Seamos sinceros al comparar una aplicación hecha con React o con Angular contra una aplicación en JSF, se nota el porque casi todas las grandes compañías del mundo voltearon a ver a Nodejs (que es mucho muy bueno) y a tecnologías puramente de Front.

Dejando atrás las discusiones sobre si Tomcat o Spring Batch o EJB o Nodejs, que ademas de nunca acabar, no dejan de ser servidores que entregan archivos HTML, JS, CSS y otros (pdf, imagenes, txt, csv, xls, xml), que pueden estar hechos como tu quieras (React, Angular, Aurelia, Vue, Jquery). Por lo que un servidor http siempre esta involucrado; muchas soluciones actuales dejan totalmente el Front en Nodejs y los servicios en Java, otros combinan Nginx con Nodejs y Java; mientras otros solo Java o solo Nodejs.

Las razones porque elegir uno u otro, pues dependerán de quien este tomando esas decisiones, en nuestro pequeño caso, vamos a crear un proxy http para servir contenido estático, de momento es un simple HTML un simple CSS y un simple JS.

Ademas, Camel esta separado de JAX-RS en las validaciones por lo que los errores no entraran en las rutas, puedes corroborar esto tratando de insertar una Question con algún parámetro invalido, la respuesta la obtendrás de CFX no de Camel, por tanto si quisiéramos hacer algo mas con ese error (bitacorizar, aplicar AI, enviar un SMS, un correo o avisarle al dueño de la empresa y a todos los vecinos); pues forzosamente necesitamos algo mas que lo haga, un proxy y si, lo podemos hacer con Camel para aplicar todo lo aprendido para integrarlo a cualquier endpoint.

Pre-requisitos

• El proyecto hasta el ultimo post

Desarrollo

Dependencias

Si haz trabajado con Wildfly o con JBoss EAP, en sus ultimas versiones, sabras que Undertow es uno de los elementos que los hacen realmente veloces al momento de servir applicaciones Web y servicios Web, Undertow es un servidor web hecho en java sumamente rápido, por eso lo vamos usar como nuestro proxy.

Agregamos a nuestro archivo build.gradle

Mejorando la respuesta al validar Question

Si hiciste la prueba, cuando tratas de guardar una Question con nombres de campo no validos (correctAnafre en lugar de correctAnswer por ejemplo). Notaras que el servicio regresa un nada agradable 500, ya mencione que esto se debe a la separación que existe entre JAX-RS y Camel, por eso vamos a agregar un handler para errores de este tipo de este modo podemos enviar una respuesta mas adecuada a nuestros clientes (clientes del API).

Creamos un nuevo Kotlin File/Class en la carpeta Java de nombre InvalidBodyProvider:

Ahora si cuando volvamos a intentar a enviar la Question con un mal cuerpo recibiremos un 400 con el mensaje adecuado. Pero esta validacion es 100% JAX-RS, esta respuesta no entrara a la Ruta de Camel y no podemos hacer nada en QuestionRoute si quisiéramos hacer algo con los errores 400.

Agregando mas properties

En el archivo camel.properties agregamos los parámetros para el nuevo servidor

Creando el proxy http

Creamos un archivo Kotlin de nombre StaticServer en la carpeta java:

Este es el Servidor de archivos estáticos y proxy http para nuestros servicios, al instalar esto en docker o en un servidor el único puerto que debemos habilitar es 8080 para el caso de que se use el mismo numero que yo puse de configuración. Solamente hacemos uso del choice para saber si el Path contiene question, o si se esta pidiendo un archivo.

A partir de esta linea .to("undertow:http://{{host}}:{{port}}/wizard/question?enableOptions=true") podemos realizar todos los procesos adicionales que queramos con la respuesta del servicio Question, ya sea exitosa o no.

Agregando contenido estatico

En la carpeta de resources, agregue una carpeta para el contenido web llamada web app con la siguiente estructura:

El contenido no es tan importante de momento, lo puedes obtener del repo git que estará en los comentarios finales

Actualizando el Main

Finalmente actualizaremos nuestro archivo Main para agregar la ruta y el Provider

Resultado final

Al final podremos ver que todo funciona de maravilla, la salida variara dependiendo que tengas en la base.

Notas finales

Este es el commit de este post recuerda no hacer caso de los archivos de la carpeta idea, son necesarios solo para el IDE

Los archivos de la carpeta web app los puedes obtener de ahi.