Archivos para las entradas con etiqueta: spring

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.

Anuncios

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 »

El tema de las anotaciones son más que conocidas en el mundo java y hoy en día casi todo lo configuramos con anotaciones, aquellos tiempos en los que se hacía todo en interminables ficheros xml que nadie era capaz de seguir se acabaron (gracias a dios).

Pero cuantas veces, sobre todo para los que usamos Spring Framework, hemos visto aquello de @EnableSomething y luego hacer uso de @Something? no os habéis preguntado nunca como funciona?

Todo esto surge, porque hace poco me surgió una necesidad en la que encajaba completamente una custom annotation para reutilizar el código. El caso en cuestión era suscribirse a eventos en kafka y me resultaba tedioso el tener que configurar kafka en cada módulo donde quisiera escuchar un evento y más aún los if que surgían… pongamos un ejemplo:

@KafkaListener(topics = "mitopic)
public void listener(String payload){
Event event = Event.from(payload);
if (event.name == "READ") {
// do something
} else if (event.name == "WRITE" {
// do something
} else if (event.name == "DELETE" {
// do something
}
}

Esta solución al menos a mi, me hace sangrar los ojos.. y es que no me llevo bien con los ifs y menos aún, con los concatenados.

Podríamos pensar en crear tres métodos distintos, uno para cada evento. Pero ni con esas vamos a conseguir quitarnos los ifs. Sin embargo, resultaría super sencillo contar con algo así:

@MyCustomAnnotation({Event.READ, Event.WRITE, Event.DELETE})
public void onEvent(String payload){
// do something
}

Incluso si quisiésemos separarlo, hasta quedaría bien:

@MyCustomAnnotation({Event.READ})
public void onRead(String payload){
// do something
}
@MyCustomAnnotation({Event.WRITE})
public void onWrite(String payload){
// do something
} 
@MyCustomAnnotation({Event.DELETE})
public void onDelete(String payload){
// do something
} 

¿A que queda mejor? ¿pero como hacerlo? Lo veremos en la segunda parte…

A %d blogueros les gusta esto: