Spring Boot Parte 2 - Externalizando la Configuración de la Aplicación

Algo muy importante y fácil de olvidar cuando creamos una aplicación, es que (si todo sale bien), esta vera la luz en un mundo productivo y será ahí cuando comenzará su vida útil, en un mundo fuera de la computadora del desarrollador.

Antes de llegar a su destino final (el ambiente de producción) una aplicación sana debería pasar por al menos dos ambientes. El primero es el ambiente del desarrollador, la computadora o computadoras en las que nunca nada falla ni sale mal :). El segundo ambiente debería ser el ambiente de integración continua; aquí será una computadora configurada en la que la aplicación se compilará y se ejecutarán una serie de pruebas automáticas que van desde las pruebas funcionales, hasta pruebas de carga y estrés. El tercer ambiente es un ambiente de testing, aquí un profesional altamente capacitado (el tester) hará su mayor esfuerzo por hacer que nuestra aplicación falle o "se rompa" en formas que nunca imaginamos al momento de escribir nuestro código productivo o de pruebas unitarias.

Una vez que nuestra aplicación sobrevive en los ambientes anteriores, llegará finalmente al ambiente productivo. En este ambiente es donde pasará su vida útil sirviendo a usuarios que no estuvieron involucrados dentro del proceso de construcción.
Como podemos ver, nuestra aplicación pasara a través de varios ambientes, algunos de los cuales no tendremos control y serán distintos al ambiente creado dentro de las máquinas de desarrollo. Debido a esto es muy importante tener un mecanismo que nos permita externalizar la configuración de nuestras aplicaciones Spring Boot y que se ejecute de la misma forma sin importar el ambiente en el que se encuentre. Algunos elementos que comúnmente cambian dependiendo del ambiente en el que ejecutemos la aplicación son: rutas, usuarios de conexiones a base de datos, puertos de funcionamiento, nombres de servidores, etc.

En este tutorial aprenderemos las formas que Spring Boot proporciona para colocar esta información de configuración fuera del código fuente de la aplicación (evitando con esto que tengamos que recompilarla cada vez que vayamos a moverla de ambiente), y las prioridades o precedencias que Spring Boot asigna a cada una de estas formas.

Lombok, escribiendo menos código y logrando más cosas

En este tutorial no veremos un Framework, sino una herramienta Java que nos ayudará a simplificar mucho el código que escribimos en cada una de nuestras clases de datos; o sea, las clases que no contienen lógica de negocio, sino que nos ayudan a "transportar" información, como son los POJOs o los Value Objects.

Lombok es una librería Java que automáticamente se conecta a nuestro editor o herramienta de construcción (como pueden ser Maven o Eclipse) y que nos ayuda a generar código para las tareas más repetitivas de nuestras clases como son la generación de métodos setter y getter, constructores, toString, equals, etc. ¿Recuerdan en los tutoriales de Hibernate como la parte más tardada era generar las entidades por la cantidad de métodos getter y setter que estas tenían? Esas clases ocupan mucho espacio, en término de líneas de código; todo ese código podremos ahorrárnoslo con Lombok, ya que por medio de anotaciones le indicaremos qué es lo que queremos que genere.

En este tutorial aprenderemos cómo instalar Lombok en nuestro IDE y veremos algunos ejemplos de uso.