spring-boot-modulesEl otro día me pregunté el cómo hacía Spring para tener tantos @EnableFoo, @EnableBa, etc… y viendo lo sencillo que es me he decido por compartirlo con vosotros.

Todo surge ante una necesidad, que es la de tener alguna configuración común que queramos reutilizar entre distintos proyectos. Imaginemos que todos nuestros proyectos hacen uso de la misma Base de Datos, la cual tenemos configurada con Spring Data JPA, pero queremos hacer la configuración de la misma muy sencilla (añadir dependencia y listo).

Lo primero que hacemos es crearnos un módulo de Spring Boot aparte, pero a este le borramos la clase de Application que nos genera, más que nada no es una aplicación. Y le vamos a añadir toda la configuración de Spring Data JPA: dependencias y propiedades que ya teníamos (estamos moviendo las cosas de sitio).

Eso sí, antes cuando levantábamos la aplicación Spring Boot hacia toda la magia, pero ahora eso no sucederá, tendremos que hacerlo nosotros. Para ello, definimos una clase de configuración que cargue todo.

@Configuration
@EnableAutoConfiguration
@PropertySource(value = {"classpath:jpa-${spring.profiles.active}.properties"}, ignoreResourceNotFound = true)
public class JpaSupportConfiguration {
}

Se utilizan ficheros properties en vez de yml porque con Spring no existe una forma tan sencilla de cargarlos y que spring data coja la configuración correcta.

Tendremos un fichero de propiedades por entorno y lo cargamos dependiendo del perfil activo de Spring (spring.profiles.active). A destacar, que todas las propiedades se podrán sobrescribir con tan solo añadirla al application.yml de nuestro proyecto.

Una vez en este punto, tenemos tres opciones para cargar nuestro módulo:

Uso de @Import

Eso es dentro de alguna clase de configuración de nuestra aplicación hacer un

@Import(JpaSupportConfiguration.class)

Uso de @EnableJpaSupport

Para ello creamos en el módulo una anotación que lo único que hará es el @Import de más arriba.

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE})
@Documented
@Import(JpaSupportConfiguration.class)
@Configuration
public @interface EnableJpaSupport {
}

De esta forma podemos sustituir el @Import por:

@EnableJpaSupport

Auto configuración

Por último, está la opción de que se auto-configure por el simple hecho de añadir la dependencia. Para ello añadimos dentro del classpath el fichero META-INF/spring.factories en el cual añadiremos una línea con nuestra clase de configuración:

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
edu.cinfantesa.config.JpaSupportConfiguration

Conclusiones

Como hemos podido ver, es muy sencillo crear módulo con Spring Boot. De forma que si nuestro proyecto es grande, nos permite tener cada configuración en su sitio y no replicada entre las distintas aplicaciones.

A mi personalmente, el modo de importar un módulo que más me gusta es el segundo, tal y como hace Spring con sus @EnableFoo….

Para temas más técnicos si que nos puede aportar algo más la parte de auto-configuración.

Anuncios

Pues me encuentro en fase de pensar substituir unos websockets que tenemos por server-sent events (SSE). Lo utilizamos sólo para recibir eventos, con lo que para nuestro caso de uso nos podemos olvidar de la bidireccionalidad que ofrece el websocket.

Si alguien se encuentra en un caso similar, puede ver el código fuente en este enlace.

El ejemplo se compone de tres piezas:

API Node.js

Hacer estas cosas en Node.js me encanta por su sencillez, y no tener necesidad de importar ninguna dependencia externa ni nada. Si no fuera una PoC el código sería hasta más bonito. Esta api simplemente abre un stream de datos, donde se envía un número aleatorio cada segundo (uno distinto para cada request), siempre y cuando la petición esté abierta.

Cliente Angular

Una sencilla aplicación creada con el CLI de Angular.

Dispone cuatro componentes iguales que se suscriben a los eventos enviados por la API Node.js. El EventSource se crea en la primera suscripción, y se cierra cuando ya no hay más observers. Podemos ver cómo se ha impementado en este servicio.

API Gateway

Realizado con Spring Cloud Gateway, utiliza el RouteLocatorBuilder. para mapear las peticiones contra el servicio Node.js (ruta /sse) o contra el cliente web (ruta /*).

Y bueno, el ejemplo funcionando tiene esta pinta.

sse.gif

Recomiendo descargarlo y trastear con él. Incluye un docker-compose.yml para que sea más fácil montarlo.

¡Ah! Y para seguir cacharreando, node y java utilizan las imágenes distroless de Google.

Quiero hacer también otra versión en que los SSE se emitan desde un proyecto Spring Boot, pero es que es taaan fácil hacer esto con Node…

Cuando estén las dos, quiero hacer una versión para utilizarlo en conjunción con Protocol Buffers, que también venimos usándolo, aunque sólo con JavaScript. Así veremos su uso en varios lenguajes.

El otro día estuve haciendo un sencillo editor de markdown para una formación de Angular.

Aunque está disponible en Github Pages, también hay una imagen de Docker con una versión de la aplicación servida a través de un nginx.

Dado que no es una aplicación universal, una vez construida la aplicación realmente se trata de contenidos estáticos. Así que para servirlos no necesito node.js ni nada que se le parezca. Es por ello que la imagen de Docker se genera a través de un proceso de construcción multi-etapa.

En la primera de ellas, el CLI de Angular genera un entregable de producción.

En la segunda, utilizamos nginx para servir el contenido generado previamente.

Las construcciones multi-etapa son muy útiles, porque podemos necesitar unos recursos para construir, y otros para servir, como es el caso que se presenta aquí. Además, nos eliminamos muchas etapas intermedias (recordemos que cada RUN engorda nuestra imagen un poquito más), consiguiendo así que nuestras imágenes “pesen” menos.

Vamos a ver cómo realizar un backup de una base de datos mongo y restaurarlo en otra instancia.

Para ello, haremos uso combinado de los comandos mongodump y mongorestore.

Un ejemplo de uso del comando mongodump sería el siguiente:

mongodump \
  --host ip.direccion.origen \
  --port 27017 \
  --username miUsuario \
  --password M1P455W0rD \
  --db nombre_bd \
  -o bd_dump

Donde el parámetro -o hace referencia al directorio donde se almacenarán los backups.

En el caso de mongorestore, indicaremos el host donde queremos recuperar los datos, así como la carpeta bd_dump, donde están los backups:

mongorestore \
  --host ip.direccion.destino\
  --port 27017\
  --username miUsuario \
  --password M1P455W0rD \
  --db nombre_bd\
  bd_dump

Serán incontables ya las muchas veces que he instalado paquetes globales de npm para ejecutarlos sólo una vez y luego desinstalarlos.

Es para gente como yo que, a partir de la versión 5.2.0 de npm, también tenemos npx.
Leer el resto de esta entrada »

I’m doing a personal project that uses ionic framework, firestore and part of the @ngrx platform. One of de decisions I’ve made is to use Effects to perform navigation.

On that use case, it’s useless for an effect to dispatch an action.
Leer el resto de esta entrada »

After reading this Gil Fink’s post, I wanted to set context mode in StencilJS in order to determine whether the application is loaded on a Windows Phone, Android, iOS, or a Desktop the same way ionic framework does.
Leer el resto de esta entrada »

We are currently doing some spike applications that involve part of the Spring Cloud Netflix stack.

One of them is a Zuul edge server to proxy some microservices and handle authentication. On these microservices we need some special, custom headers. So we are going to see how to create a custom Zuul filter in our Spring context that add the user’s name on a header before proxying:
Leer el resto de esta entrada »

Recientemente leí este artículo de mi buen amigo Norman Coloma.

En él, introduce una mejora en el uso de validadores asíncronos con respecto a muchos de los ejemplos que verás por internet, llevándose su lógica a un servicio externo.

Aún así, y tras hablarlo con él, vimos que ese componente era demasiado listo:

  • ¿Por qué saber de servicios externos?
  • ¿Por qué saber de controles abstractos?
  • ¿Por qué hacer ese bind a la hora de validar?
  • ¿Por qué no introducir un validador asíncrono de una manera tan fácil como hacemos con los síncronos?

Leer el resto de esta entrada »

Hoy he tenido que copiar unos ficheros al interior de un contenedor Docker (concretamente, un backup de una base de datos SQLServer).

Podría haberlo hecho montando un volumen que apuntara al sistema de ficheros, pero he preferido ver si había otra manera. Y la hay. Cómo no, en Docker también existe el comando cp:

docker cp backup_de_mi_DB.DAT mssql-server-linux:/tmp

Obviamente, también podemos extraer datos del docker para guardarlos en nuestra máquina local:

docker cp mssql-server-linux:/ruta/hacia/el/fichero ./fichero
A %d blogueros les gusta esto: