El consumo de una API REST es un caso muy habitual cuando trabajamos en una arquitectura de microservicios, y es casi que la opción por defecto para el tráfico entre los distintos microservicios (aunque si es por eficiencia, deberíamos usarlo solo para tráfico norte-sur y optar por otras opciones más eficientes como gRPC para el tráfico este-oeste). Normalmente, en el mundo de Spring usamos por defecto dos opciones: Si estamos usando el stack bloqueante (web) RestTemplate. Si usamos el stack reactivo (webflux) WebClient. Los años de RestTemplate (13) se notan si hemos usado WebClient, ya que tiene una API mucho más concisa y fluida, más elegante. La contraprestación es que está diseñado para trabajar con Spring WebFlux y por tanto usa los tipos de datos reactivos Flux y Mono, por lo que si tu aplicación sigue un modelo bloqueante, vas a trufar todos los usos de WebClient con bloqueos para obtener los resultados y conversiones de Mono a tipos concretos o de Flux a colecciones.

En 2016 decidí pasar este blog de un WordPress (que me costaba un dinero anual en hosting) a un sitio estático (aunque con comentarios de Disqus). En ese momento estuve muy influenciado por la web de Trisha que usaba esta arquitectura pero usando todo el potencial de GitHub Pages, con Jekyll y la construcción automática del sitio al subir los archivos markdown a GitHub (curiosamente ella ahora usa WordPress, pero claro tiene infinito más contenido que yo y de más calidad, jaja).

Últimamente he tenido que provisionar dos equipos nuevos (en casa y en el trabajo) y parte del proceso es instalar Git para acceder a los distintos repositorios (como el de este blog). El acceso a un repositorio remoto de Git se puede hacer de dos maneras: Por cruce de clave SSH: De lejos el más cómodo y mejor una vez configurado. Generas un clave en tu equipo, subes la parte pública a GitHub, GitLab, etc… y a volar. El problema es que es harto tedioso. Mediante HTTPS: Cada vez que operemos sobre el repositorio remoto será como acceder a una página web y nos pedirá usuario y contraseña (credenciales). Este sistema es el más sencillo, pero dado el número de operaciones que puedes hacer en un rato sobre un remoto resulta muy tedioso estar introduciendo usuario y contraseña continuamente. Ahí entra el concepto de [Credential Helper] (https://git-scm.com/docs/gitcredentials), habiendo a su vez varias opciones:

Los contenedores no solo tienen la ventaja de ser entornos aislados sino que además ocupan muy poco espacio en disco. Esto se debe a varias causas: No tienen el sistema operativo al completo (como una máquina virtual) lo cual ya de por sí es un ahorro de espacio. El proceso de tener una imagen e ir “instanciando” contenedor no ocupa tanto como podríamos esperar (tamaño de imagen x contenedores) gracias a UnionFS, ya que solo se cambian los cambios de cada contenedor en particular. Esto esta de maravilla y por ejemplo, hoy he montado un Oracle XE en un contenedor para lo que he tenido que hacer mi propia imagen. Si hago

Una de las ventajas de Docker es que te aisla del problema de tener que instalar el software que necesitas para desarrollar. La encapsulación en contenedores no es solo una ventaja para los pasos a producción y la infraestructura como código sino que lo es, especialmente en entornos de desarrollo. En muchas ocasiones instalas una base de datos o una cola de mensajes y ajustando la configuración te la terminas cargando y tienes que volver a crearla. La ventaja de Docker es que parte de esa premisa, se asume que te vas a cargar el sistema… y que no pasa nada. Y seamos sinceros, esto es muy frecuente que pase en los entornos de desarrollo (para eso estan). Si bien hay tareas que son relativamente sencillas como instalar un PostgreSQL que se puede hacer a tiro de apt, con Docker es MUCHO más sencillo y además tiene la ventaja de que si te cansas, puedes eliminar los contenedores y las imágenes y no has tocado tu sistema.