JHipster es un generador de código que nos permite a través de Yeoman generar una aplicación spring-boot con un front-end en angularJS. JHipster es Open Source, su código fuente se puede encontrar en GitHub, la capa back-end está construida con Java y Spring-boot, el front-end es responsive y está implementado con angularJS y Bootstrap. Para la construcción del proyecto se utilizan varias herramientas como son Yeoman, Bower, Grunt, Maven, Gradle…
En este post vamos a ver cómo se crea una aplicación con JHipster, cuáles son las ventajas y los inconvenientes de utilizar este generador de código.
“JHipster, or “Java Hipster,” is a handy application generator that will create for you a Spring Boot (that’s the Java part) and AngularJS (that’s the hipster part) application”.
JHipster utiliza las siguientes tecnologías en la capa front-end:
Y las siguientes en la capa back-end:
Como vemos existe una amplia variedad de librerías, herramientas, bases de datos… incluyendo las soluciones más populares del mercado. Aquí podéis ver el detalle de cada una de ellas.
JHipster es bastante conocido, tanto que hasta en el blog de Spring hablan de él, como se puede ver fue creado por un exempleado de Spring Source, Julien Dubois. El proyecto tiene en el momento en que se escribe este artículo 3518 estrellas en Github, lo cual lo convierte en una solución a tener en cuenta.
Para la creación de la aplicación JHipster te realiza 15 preguntas para determinar qué tecnologías incluir y qué código ha de generar. Las preguntas son las siguientes:
- What is the base name of your application?
- What is your default Java package name?
- Which type of authentication would you like to use? Aquí escogeremos entre tres opciones:
- Mecanismo de autenticación basado en sesiones
- Autenticación basada en OAuth 2.0
- Aproximación basada en tokens
- Which type of database would you like to use? Aquí tendremos las dos siguientes opciones:
- Base de datos SQL
- NoSQL: Cassandra o MongoDB
- Which production database would you like to use? La base de datos que usarás en tu entorno de producción.
- Which development database would you like to use? Base de datos que usarás para tu entorno de desarrollo. Tienes las siguientes opciones:
- H2 almacenando en memoria.
- H2 persistiendo a disco.
- La misma que hayas escogido para tu entorno de producción.
- Do you want to use Hibernate 2nd level cache? En caso de querer usarla podemos escoger entre caché local con ehcache o distribuida con Hazelcast.
- Do you want to use a search engine in your application? En caso de incluirlo se utilizará Elasticsearch.
- Do you want to use clustered HTTP sessions?
- Do you want to use WebSockets?
- Would you like to use Maven or Gradle?
- Would you like to use Grunt or Gulp.js for building the frontend?
- Would you like to use the LibSass stylesheet preprocessor for your CSS?
- Would you like to enable translation support with Angular Translate?
- Which testing frameworks would you like to use? Por defecto se incluyen tests unitarios/integración con JUnit para Java y unitarios con Karma.js para JavaScript. Esta opción nos permite incluir tests de rendimiento con Gatling o de comportamiento con Cucumber.
La aplicación generada incluye de serie funcionalidades como gestión de usuarios, seguridad, gestión de configuración, swagger… Se generan automáticamente pantallas de autenticación, de métricas, de auditoría, de gestión del nivel de log... A continuación se pueden ver capturas de algunas de esas pantallas, todas ellas generadas de forma automática:
Una vez tenemos el esqueleto de nuestra aplicación, un esqueleto bastante completo como podéis ver, JHipster también nos permitirá generar de forma automática el código y pantallas para la gestión de las operaciones CRUD sobre diferentes entidades. Simplemente nos preguntará qué entidades queremos crear, qué campos tendrán, sus tipos, si son obligatorios, cómo se relacionan… Esto lo podemos hacer desde la línea de comandos o si queremos existen herramientas para hacerlo de forma gráfica como JHipster UML o JDL Studio.
Aquí podéis encontrar el código de una aplicación de ejemplo, como véis la cantidad de clases y configuración generadas es bastante abundante. Además la aplicación se construye configurando dos perfiles, uno para desarrollo y otro para producción.
En estos vídeos (JHipster Blog Demo e Introduction to JHipster) podéis ver los pasos necesarios para crear un proyecto de cero, parte del código generado, cómo crear instancias, cómo interactuar con la aplicación, cómo desplegar...
Este tipo de soluciones utilizadas para la generación de código tendrán una serie de ventajas, así como de inconvenientes. A continuación pasamos a detallar las ventajas:
- Incrementa la velocidad de desarrollo: nos permite tener en muy poco tiempo una aplicación que proporciona una funcionalidad básica con las operaciones CRUD sobre entidades con una interfaz gráfica lista para gestionarlas. Si necesitas desarrollar una aplicación sencilla que sea simplemente eso ya lo tienes resuelto, pero incluso en aplicaciones más complejas que incluyen una gran cantidad de lógica de negocio, estas también necesitan definir recursos e implementar operaciones CRUD sobre los mismos, por lo que JHipster también agilizará tus tiempos de desarrollo en esos casos.
- Toma de contacto con otras tecnologías: para el ingeniero back-end puede suponer una toma de contacto con las tecnologías front-end y viceversa fomentando también la creación de ingenieros full-stack. Además en el caso de los ingenieros back-end esto nos permite incluir fácilmente un front para probar el código desarrollado.
- No necesitas pasarte horas montando arquitecturas engorrosas para nuevos proyectos con horas de desarrollo de funcionalidades transversales o integrando y configurando nuevos frameworks o librerías. JHipster ya lo hace por ti. La arquitectura de la aplicación incluye las funcionalidades transversales necesarias para la mayoría de tus proyectos.
- Líneas de mejora: aunque no utilices JHipster como tal para generar tu aplicación, puede darte ideas de frameworks/librerías a incluir en la misma para solucionar determinadas necesidades, además de ser un ejemplo de cómo configurarlas.
- Abstracción de tareas básicas: de forma similar a como ocurre en otros contextos, como en el mundo PaaS que busca abstraernos de la infraestructura para que nos podamos centrar en el desarrollo, con JHipster podemos abstraernos de tareas de desarrollo más básicas y repetitivas como creación de CRUDs, integración de librerías, configuración básica... y así centrarnos en el desarrollo de la lógica de negocio, lo verdaderamente importante. Algo similar ocurre con la filosofía ‘convention over configuration’ de Spring Boot que nos proporciona una configuración básica para poder agilizar la velocidad de desarrollo.
- Marco de trabajo controlado: JHipster puede ser especialmente beneficioso para los perfiles junior ya que proporciona un marco de trabajo controlado con un montón de funcionalidades adicionales ya configuradas. En este marco, el desarrollador junior puede comenzar un proyecto con tareas sencillas de desarrollo y, poco a poco, conforme gane confianza y conocimiento, ir interactuando con los diferentes frameworks/librerías y su configuración. Al incluir también patrones de diseño representa, así mismo, un ejemplo para el aprendizaje del desarrollo como tal. Siendo además muchas de sus tecnologías casi el ‘estándar’, puede ser una guía para la evolución técnica del desarrollador.
Y ahora los inconvenientes:
- Curva de aprendizaje: en este caso no nos referimos tanto al uso de la herramienta en sí, sino al código generado y los frameworks/librerías. La herramienta como tal no es difícil de usar, pero sí puede llevar tiempo revisar el código generado así como llegar a conocer las diferentes herramientas y librerías que se utilizan, más cuando se entremezclan dos mundos como son el front-end y el back-end. Se podría decir que de la misma forma tendríamos que conocer el código de las librerías de terceros que utilizamos como podría ser un driver de BD o jquery, pero en esos casos tú no eres el propietario de ese código, no como en este caso, que aún siendo código generado tú serás su propietario y deberás mantenerlo.
- Otro tipo de arquitecturas: uno de los usos más habituales de spring-boot es para la construcción de arquitecturas de microservicios. Si bien JHipster no será necesario para construir tu servidor de configuración, tu registro de microservicios… gracias a las soluciones proporcionadas por spring-cloud-netflix, en caso de que lo uses para generar tus microservicios funcionales te encontrarás con mucho código duplicado, el cual deberías sacar a una librería de arquitectura. Lo mismo ocurre si tu arquitectura es una SPA realizando peticiones REST al back-end, en ese caso deberás sacar los recursos de front a un servidor de estáticos.
- Sobrearquitecturar: JHipster incluye muchas funcionalidades y librerías que puede que tu aplicación no necesite y la tendencia será a dejarlas ahí, aunque no las uses, “ensuciando” tu proyecto. Además todo el código generado tendrá que ser mantenido lo cual puede suponer un sobreesfuerzo innecesario. Así mismo este código y configuración siempre pueden generar conflictos con otras herramientas/librerías que quieras añadir. Por desgracia actualmente aún sigue existiendo una fuerte tendencia a sobrearquitecturar. No es lo mismo crear una arquitectura modular y extensible que pasarse tres días añadiendo soporte para funcionalidades que ni siquiera sabes si se van a incluir. Recordad: menos es más.
JHipster es una herramienta muy interesante ya sea para utilizarla como tal para generar tus proyectos o a nivel de innovación como toma de contacto con nuevas tecnologías/frameworks/librerías o para entender el funcionamiento interno de un generador de código. Te proporciona un marco de trabajo innovador y de calidad con el que incluir las últimas tecnologías y convertir tu proyecto en un referente técnico.
Conceptualmente representa una idea interesante para implantar a nivel corporativo (ya sea JHipster como tal o hacer tu propia versión del mismo), yendo más allá de las típicas soluciones utilizando frameworks/librerías de software libre con ligeras modificaciones que tanto se dan en las grandes empresas. Siempre y cuando quieras meterte en ese bosque.
Abraham Rodríguez
Abraham Rodríguez actualmente desarrolla funciones de ingeniero backend J2EE en Paradigma donde ya ha realizado diversos proyectos enfocados a arquitecturas de microservicios. Especializado en sistemas Cloud, ha trabajado con AWS y Openshift y es Certified Google Cloud Platform Developer. Cuenta con experiencia en diversos sectores como banca, telefonía, puntocom... Y es un gran defensor de las metodologías ágiles y el software libre.
Ver más contenido de Abraham.
Cuéntanos qué te parece.