Hola mundo en Vaadin

Vamos a hacer un hola mundo en Vaadin. Yo voy a dar por sobreentendido que sabemos crear un proyecto con spring. Si no lo sabes es tan fácil como ir a https://start.spring.io/ y de ahi vas configurando las cosas y agregamos el framework vaadin. 

Luego creamos un nuevo paquete como por ejemplo : com.example.vaadin.ui. Dentro del paquete, creamos una nueva clase MainView.java

package com.example.vaadin.ui;

import com.vaadin.flow.component.button.Button;

import com.vaadin.flow.component.notification.Notification;

import com.vaadin.flow.component.orderedlayout.VerticalLayout;

import com.vaadin.flow.router.Route;

@Route("")

public class MainView extends VerticalLayout {

    public MainView() {

        Button button = new Button("Haz clic aquí",

                event -> Notification.show("¡Hola, Mundo!"));

        add(button);

    }

}

Y listo!! Vamos a localhost:8080 para chequear nuestro "Hola mundo". 

Inyectar condicionalmente un bean con profiles

Tengo 2 beans que implementan una interfaz, por ejemplo un repositorio jpa con una base de datos y otro con archivos o en memoria, ponele... Y quiero algunas veces utilizar un bean y otras otro dependiendo de una configuración, esto se puede resolver de 2 maneras. Se puedes utilizar la anotación @Conditional o @Profile.

Veamos ejemplo utilizando profile: 

public interface MyService {

    void performService();

}

@Service

@Profile("serviceA")

public class ServiceA implements MyService {

    @Override

    public void performService() {

        System.out.println("Service A implementation");

    }

}

@Service

@Profile("serviceB")

public class ServiceB implements MyService {

    @Override

    public void performService() {

        System.out.println("Service B implementation");

    }

}

Tenemos que configurar el perfil activo en application.properties:

# Para usar ServiceA

spring.profiles.active=serviceA

# Para usar ServiceB

#spring.profiles.active=serviceB

Y inyectamos el bean:

@RestController

public class MyController {

    private final MyService myService;

    @Autowired

    public MyController(MyService myService) {

        this.myService = myService;

    }

    @GetMapping("/perform")

    public String perform() {

        myService.performService();

        return "Service performed";

    }

}

Y listo!!

Libros gratuitos

 

Download FREE IT Guides!   Linux Bible, 10th Edition ($36.00 Value) FREE for a Limited Time Linux Bible, 10th Edition is the ultimate hands-on Linux user guide, whether you're a true beginner or a more advanced user navigating recent changes. this updated tenth edition covers the latest versions of Red Hat Enterprise Linux     Teach Yourself VISUALLY Windows 11 ($19.00 Value) FREE for a Limited Time Teach Yourself VISUALLY Windows 11 collects all the resources you need to master the day-to-day use of Microsoft’s new operating system and delivers them in a single resource. Fully illustrated, step-by-step     RESTful Architecture Cheatsheet The web has become an integral part of our daily lives, and with it, web applications have also become increasingly popular. However, as the number of web applications has grown, so has the complexity of managing them     Modern API Development with Spring and Spring Boot ($33.99 Value) FREE for a Limited Time Developers need to know how to adapt to these modern API design principles. Apps are now developed with APIs that enable ease of integration for the cloud environment and distributed systems.

Log con Aop de Spring boot

Supongamos que queremos logear cada cosa que pasa por cada método de nuestros objetos, para hacer esto podemos utilizar aop. 

Veamos un ejemplo: 

@Aspect

@Configuration

@Order(0)

class LogingAspect {

    private val logger = LogFactory.getLog(LoggingAspect::class.java)

    @Pointcut("execution(public * com.paquete..*(..))")

    fun allControllersMethods() {

    }

    @Around("allControllersMethods()")

    fun profileAllMethods(pjp: ProceedingJoinPoint): Any {

        val method: Method = (pjp.signature as MethodSignature).method

        logger.info("Started ${method.name}")

        try {

            return if (pjp.args != null) {

                pjp.proceed(pjp.args)

            } else {

                pjp.proceed()

            }

        } catch (ex: Exception) {

            logger.error("Error in ${method.name}", ex)

            throw ex

        } finally {

            logger.info( "Finished ${method.name}")

        }

    }

}

Y Listo!!

Interceptor de Retrofit

                                                                                                                                                                                                                                                                        

Supongamos que tenemos que enviar en todas las llamadas a web services, un valor o un token o cualquier cosa. 

Lo que podemos hacer con retrofit es un interceptor, este lo declaramos una vez y para todas las llamadas enviarán los valores. Veamos un ejemplo: 

@Component

class RetrofitClient {

    @Value("\${service.url}")

    private lateinit var baseUrl: String

    private lateinit var retrofit: Retrofit

    private lateinit var objectMapper: ObjectMapper

    @PostConstruct

    fun init() {

        objectMapper = ObjectMapper()

            .configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false)

            .registerModule(KotlinModule())

        val client = OkHttpClient.Builder().addInterceptor(EjemploInterceptor()).build()

        retrofit = Retrofit.Builder()

            .baseUrl(baseUrl)

            .client(client)

            .addConverterFactory(JacksonConverterFactory.create(objectMapper))

            .build()

    }

    fun <T> buildService(service: Class<T>): T {

        return retrofit.create(service)

    }

}

class EjemploInterceptor : Interceptor {

    companion object {

        private const val EJEMPLO = "ejemplo"

    }

    override fun intercept(chain: Interceptor.Chain): Response = chain.run {

        proceed(

            request()

                .newBuilder()

                .addHeader(EJEMPLO, "valor a agregar")

                .build()

        )

    }

}

En este ejemplo en todas las llamadas enviarán el valor agregado en el head. Y listo! 

Apis en diferentes lenguajes y frameworks en la plataforma Java

Estoy haciendo una aplicación con n microservicios en n tipos de tecnologías y lenguajes todos en la plataforma Java. 

Los de n tipos de tecnologías es mentiroso solo 2 framework use por ahora Spring boot y micronaut y a decir verdad use un 80% de spring boot pero quiero escribir un post tipo draft, por las dudas si me canso y nunca termino. 

Por ende, vamos a ver como me fue con Spring boot y diferentes lenguajes y luego hablo de micronaut. 

Java: Bueno, esta es la tupla más utilizada y creo que ustedes saben que anda muy bien. No sé si puedo agregar algo más que no sepan. 

Kotlin: Me encanto, por varias razones me parece mejor que java. Kotlin es un lenguaje, muy bueno y muy compatible con java lo que lo hace una opción super fácil de usar y no se sufre nada con la compatibilidad con spring boot. 

Groovy: Igual que Java, no encuentro una buena razón para elegir este lenguaje, esta bueno, pero el tipado dinamico, no ofrece mayor ventaja y si lo usamos con tipando estático, es similar a java o kotlin. 

Scala: Un infierno de incompatibilidad, no le recomiendo utilizar spring boot con scala, tenes que estar siempre cambiando tipos, de tipos de Scala a Java y de Java a Scala. No es una opción práctica...

Clojure: Otro infierno, no solo por los tipos, sino tambien por la generación de clases con anotaciones. Muy trabajoso, al final cuando te funciona una Api, no te acordas para que la querías. 

Micronaut lo utilice muy poco con Groovy y Java y me fue muy bien, casi casi puedo decir que me gusta más que spring boot. Y ahora sigo con Micronaut y Quarkus. 

Hacer un test de integración de un dao que guarda en Redis con Testcontainers y Spring boot

Me quedo relargo el titulo, pero la idea sería:

Tenemos una aplicación de spring boot y spring data que guarda información en Redis con un Dao y queremos probar este dao, ¿como lo hacemos?. Podemos usar testcontainers. 

Testcontainers es un framework que levanta una imagen de docker para que diferentes tecnologías esten accesibles para nuestros tests. 

Para utilizarlo debemos agregar esta dependencia en gradle o maven :

testImplementation "org.testcontainers:testcontainers:1.17.2"

Y en este ejemplo vamos a utilizar kotlin, pero funciona tambien con Java: 

@RunWith(SpringJUnit4ClassRunner::class)

@SpringBootTest(classes = [Application::class])

class EjemploRepositoryTest {

    @Autowired

    lateinit var ejemploRepository: EjemploRepository

    companion object {

        

        init {

            val redis : GenericContainer<Nothing>  = GenericContainer<Nothing>(DockerImageName.parse("redis:5.0.3-alpine"))

                .withExposedPorts(6379)

            redis.start()

            System.setProperty("redis.host", "${redis.host}")

            System.setProperty("redis.port", "${redis.firstMappedPort}")

        }

    }

    @Test

    fun `save and find all ejemplos`() {

        val count = ejemploRepository.findAll().count()

        val ejemplo = crearUnEjemplo() //este metodo te crea un ejemplo :D

        ejemploRepository.save(ejemplo)

        val ejemplos = ejemplo.findAll()

        Assert.assertNotNull(ejemplos)

        Assert.assertEquals(count + 1, ejemplos.count())

    }

}

En el código anterior falta el metodo crear ejemplo que va a crear el objeto para probar, no lo agrego porque no lo veo necesario. Por supuesto, el objeto ejemplo debe seguir con las notaciones de Spring data. 

Y listo! 

Como chequear si un registro esta siendo cacheado por Hibernate en una aplicación Spring boot.

Necesitaba ver si un registro estaba siendo cacheado por hibernate es decir JPA, en una aplicación spring boot. 

Hice lo que cualquiera hubiera hecho, puse show-sql en true, corrí un test que busca 2 veces el registro y me fije en el log que no hubiera 2 selects. Fácil pero poco científico, estaría bueno hacer un test que pruebe esto, y bueno hice esto : 

@RunWith(SpringJUnit4ClassRunner::class)

@SpringBootTest(classes = [Application::class])

class EjemploRepositoryTest {

    @Autowired

    lateinit var ejemploRepository: EjemploRepository

    @Autowired

    lateinit var entityManagerFactory: EntityManagerFactory

    @Test

    fun `find a Ejemplo from Empty cache`() {

        val ejemplo= getEjemplo()

        val cache = entityManagerFactory.cache

        Assert.assertFalse(cache.contains(Ejemplo::class.java, ejemplo.id))

    }

    @Test

    fun `find a Ejemplo from cache`() {

        val ejemplo= getEjemplo()

        saveAndFind(ejemplo)

        val cache = entityManagerFactory.cache

        Assert.assertTrue(cache.contains(Ejemplo::class.java, ejemplo.id))

    }

    private fun saveAndFind(ejemplo: Ejemplo): Ejemplo{

        ejemploRepository.save(ejemplo)

        return ejemploRepository.findById(ejemplo.id).get()

    }

    private fun getEjemplo(): Ejemplo{

        return  ... //Aca construimos un ejemplo 

    }

}

Y listo!!

Crear un proyecto Spring boot, con Leiningen y Clojure

La idea es crear un proyecto spring boot, con Clojure y Leiningen. (ya lo dice el titulo)

Primero hacemos un proyecto hello word con Leiningen (ojo tienen que tener Leiningen instalado, esta bueno instalarlo con sdkman, así :  sdk install leiningen) 

lein new app ejemplo

Luego agregamos las dependencias de spring boot al proyecto, para que quede algo así: 

(defproject github "0.1.0-SNAPSHOT"

  :description "FIXME: write description"

  :url "http://example.com/FIXME"

  :license {:name "EPL-2.0 OR GPL-2.0-or-later WITH Classpath-exception-2.0"

            :url "https://www.eclipse.org/legal/epl-2.0/"}

  :dependencies [[org.clojure/clojure "1.10.3"],

                 [org.springframework.boot/spring-boot-starter-web "2.6.7"],

                 [org.springframework.boot/spring-boot-configuration-processor "2.6.7"]]

  :main com.assembly.example.core

  :aot :all

  :target-path "target/%s"

  :profiles {:uberjar {:aot :all

                       :jvm-opts ["-Dclojure.compiler.direct-linking=true"]}})

Ojo, tambien hay que agregar :aot y :all 

Ahora hacemos el Application, yo modifique el hello wold que vino por default, pero si lo hacen tengan cuidado de ponerlo en un paquete. 

(ns com.assembly.example.core

  (:import (org.springframework.boot SpringApplication))

  (:gen-class

    :name ^{org.springframework.boot.autoconfigure.SpringBootApplication []

            org.springframework.context.annotation.ComponentScan {:basePackages ["com.assembly.example"]}}

    com.assembly.example.core.Application

    :main true)

  )

(defn -main []

  (SpringApplication/run (Class/forName "com.assembly.example.core.Application") (into-array String '()))

  )

Y ahora hacemos un endpoint, en este ejemplo voy a hacer un hola mundo : 

(ns com.assembly.exanple.controller.greet

  (:import (org.springframework.web.bind.annotation PathVariable RequestMapping RequestMethod RestController)

           (org.springframework.http ResponseEntity))

  )

(gen-class

  :name ^{RestController {}

          RequestMapping {:value ["/v1/greet"]}} com.assembly.exanple.controller.greet.GreeterEndPoint

  :methods [[^{RequestMapping {:value ["/hello"]

                               :method [RequestMethod/GET]}} sayHello [] Object ]

            [^{RequestMapping {:value ["/helloto/{name}"]

                               :method [RequestMethod/GET]}} sayHelloTo [^{PathVariable {:value "name"}} String] Object ]

            ]

  :state injected

  :init init

)

(defn -init

  "Initialize the class by setting the state to an empty map, which can be populated with injected dependencies."

  []

  [[] (atom {})])

(defn -sayHello

  [this]

  (ResponseEntity/ok "Hello"))

(defn -sayHelloTo

  [this name]

  (ResponseEntity/ok (str "Hello " name)))

Y listo, si corremos el main, vamos a levantar el tomcat embebido de spring y vamos a : 

http://localhost:8080/v1/greet/hello

y veremos como nos saluda spring boot con clojure!! 

Crear un proyecto Spring boot, con Scala y Sbt

La idea es crear un proyecto spring boot, con scala y sbt. (ya lo dice el titulo)

Primero hacemos un proyecto hello word con sbt (ojo tienen que tener sbt instalado, esta bueno instalarlo con sdkman) 

sbt new scala/hello-world.g8

Luego, tenemos que agregar nuestra dependencia web de spring boot en build.sbt : 

// https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-web

libraryDependencies += "org.springframework.boot" % "spring-boot-starter-web" % "2.6.7"

libraryDependencies += "org.springframework.boot" % "spring-boot-configuration-processor" % "2.6.7"

Deberían de modificar bastante el buld.sbt en mi caso me quedo así :

scalaVersion := "2.13.8"

organization := "com.miCompania"

name := "ejemplo"

version := "1.0"

libraryDependencies += "org.scala-lang.modules" %% "scala-parser-combinators" % "2.1.1"

// https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-web

libraryDependencies += "org.springframework.boot" % "spring-boot-starter-web" % "2.6.7"

libraryDependencies += "org.springframework.boot" % "spring-boot-configuration-processor" % "2.6.7"

Ahora lo que debemos de hacer es crear un paquete y mover el main a ese paquete para luego modificarlo de tal forma que llame a run de spring boot : 

package com.miCompania

import org.springframework.boot.SpringApplication

import org.springframework.boot.autoconfigure.SpringBootApplication

@SpringBootApplication

class Application

object Main extends App {

  SpringApplication.run(classOf[Application], args:_*)

}

Ojo, tienen que tener el main en un paquete sino no anda. 

Por ultimo hacemos nuestro endpoint, en este ejemplo voy a hacer un hola mundo, comun. Pero en este punto podemos utilizar todas las ventajas de spring boot : 

package com.assembly.endpoint

import org.springframework.http.ResponseEntity

import org.springframework.web.bind.annotation.{PathVariable, RequestMapping, RequestMethod, RestController}

@RestController

@RequestMapping(Array("/v1"))

class GreeterEndPoint {

  @RequestMapping(value=Array("/hello/{name}"), method = Array(RequestMethod.GET))

  def sayHello(@PathVariable(name = "name") name:String): ResponseEntity[String] =

    ResponseEntity.ok(s"Hello ${name}")

}

Lo puse en otro paquete, esto solo para que quede más ordenado, y listo!!! 

Cache con Redis y Spring boot

Vamos ha hacer una pequeña cache para unos servicios en spring boot. 

Primero es necesario tener instalado Redis, y si ...

Luego agregamos esta dependencia a nuestro proyecto (uso gradle) : 

implementation("org.springframework.boot:spring-boot-starter-cache")

implementation("org.springframework.boot:spring-boot-starter-data-redis")

Luego configuramos en nuestro cache con esta clase : 

 package com.uap.demo.config

import org.springframework.context.annotation.Bean

import org.springframework.context.annotation.Configuration

import org.springframework.data.redis.cache.RedisCacheConfiguration

import org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer

import org.springframework.data.redis.serializer.RedisSerializationContext.SerializationPair

import java.time.Duration

@Configuration

class CacheConfig {

    @Bean

    fun cacheConfiguration(): RedisCacheConfiguration? {

        return RedisCacheConfiguration.defaultCacheConfig()

            .entryTtl(Duration.ofMinutes(60))

            .disableCachingNullValues()

            .serializeValuesWith(SerializationPair.fromSerializer(GenericJackson2JsonRedisSerializer()))

    }

}

Yo le puse 60 minutos de vida a mis datos dado que no cambian tan frecuente. 

Ahora en el Application agregamos @EnableCaching, algo así : 

@SpringBootApplication

@EnableCaching

class DemoApplication

fun main(args: Array<String>) {

runApplication<DemoApplication>(*args)

}

Por ultimo a nuestro servicio le decimos que vamos a cachear los datos, en este ejemplo tengo un servicio X : 

@Service

class XServiceImpl : XService {

    @Cacheable(value = ["xxxxx"])

    override fun x(parametro: String): List<String> {

          ...

    }

}

Lo que va a ocurrir es que cuando llamemos al servicio con un parametro, se va generar una entrada en Redis, y la próxima vez que llamemos este servicio usará la cache. 

Y listo!!! 

Apache Isis

 

Apache Isis permite el desarrollo de aplicaciones basadas en domain-driven al generar automáticamente una interfaz de usuario para sus aplicaciones Spring Boot. Eso significa:

• Productividad: la aplicación es principalmente lógica comercial.
• Descubrimiento: los expertos en el dominio comercial y los técnicos pueden trabajar de la mano para comprender el espacio del problema y luego el espacio de la solución.
• Facilidad de uso: los usuarios comerciales encontrarán que la aplicación es fácil de aprender, ya que los conceptos comerciales están al frente y al centro.
• Arquitectura limpia: el marco garantiza la separación de responsabilidades dentro de la arquitectura interna de su aplicación
• Integración simple: publica automáticamente un evento de dominio genérico para integraciones asíncronas y una API REST para integración de sincronizas.
• Y debido a que Apache Isis es de código abierto, se basa en estándares industriales/de facto como Spring Boot.

Dejo link : https://isis.apache.org/

Escribiendo clientes Eureka con Feign

Una alternativa a la clase RestTemplate habilitada para Spring Ribbon es la biblioteca cliente Feign de Netflix. La biblioteca Feign adopta un enfoque diferente para llamar a un servicio REST al hacer que el desarrollador primero defina una interfaz Java y luego anote esa interfaz con las anotaciones de Spring Cloud para mapear qué servicio basado en Eureka invocará Ribbon.

Spring Cloud generará dinámicamente una clase de proxy que se utilizará para invocar el servicio REST de destino. No se escribe ningún código para llamar al servicio que no sea una definición de interfaz.

Para habilitar el uso del cliente Feign se debe agregar una anotación, @EnableFeignClients, a la clase Application.java

Luego de habilitar el cliente de Feign, veamos una definición de interfaz de cliente de Feign que se puede usar para llama:

/*Package and import left off for conciseness*/

@FeignClient("ejemploService")

public interface EjemploFeignClient {

 @RequestMapping(method= RequestMethod.GET,  value="/v1/ejemplo/{ejemploId}",

 consumes="application/json")

Ejemplo getEjemplo( @PathVariable("ejemploId") String ejemploId);

}

La gente mayor recordarán un framework que trabajaba de forma similar llamado cxf. 

En la anotación @FeignClient le pasámos el nombre de la identificación del servicio que deseamos que represente la interfaz. A continuación, defimos un método, getEjemplo el cual retorna un objeto Ejemplo.

Como se puede ver la definición de la clase usa anotaciones de las cual ya estamos familiarizados. 

Para usar la clase EjemploFeignClient, todo lo que necesitamos hacer es injectarla y usarla. El código de Feign Client se encargará de todo el trabajo de codificación.

Cuando utiliza la clase Spring RestTemplate estándar, todos los códigos de estado HTTP de las llamadas de servicio se devolverán a través del método getStatusCode() de la clase ResponseEntity. Con Feign Client, cualquier código de estado HTTP 4xx – 5xx devuelto por el servicio al que se llama se asignará a una FeignException. FeignException contendrá un cuerpo JSON que se puede analizar para el mensaje de error específico. Feign le brinda la capacidad de escribir una clase de decodificación de errores que asignará el error a una clase de excepción personalizada. 

Dejo link : https://github.com/OpenFeign/feign

Descubrir un servicio publicado con Eureka con Spring boot, parte 3

Seguimos con el post anterior.

Veamos un ejemplo de cómo usar un RestTemplate que es Ribbonaware. Este es uno de los mecanismos más comunes para interactuar con Ribbon a través de Spring. Para usar una clase RestTemplate con un balanceador de carga, debe definir un método de construcción de bean RestTemplate con una anotación de Spring Cloud llamada @LoadBalanced. 

El siguiente código muestra el método getRestTemplate() que creará el bean Spring RestTemplate respaldado por Ribbon.

package com.thoughtmechanix.licenses;

//...Most of import statements have been removed for consiceness

import org.springframework.cloud.client.loadbalancer.LoadBalanced;

import org.springframework.context.annotation.Bean;

import org.springframework.web.client.RestTemplate;

@SpringBootApplication

@EnableDiscoveryClient

@EnableFeignClients

public class Application {

  @LoadBalanced

  @Bean

  public RestTemplate getRestTemplate(){

    return new RestTemplate();

  }

  public static void main(String[] args) {

    SpringApplication.run(Application.class, args);

  }

}

Ahora que la definición del bean para la clase RestTemplate respaldada por Ribbon está definida, cada vez que desee usar el bean RestTemplate para llamar a un servicio, solo necesita conéctelo automáticamente a la clase que lo usa.

El uso de la clase RestTemplate con balanceador de carga se comporta prácticamente como una clase Spring RestTemplate estándar, excepto por una pequeña diferencia en cómo se define la URL para el servicio de destino. En lugar de utilizar la ubicación física del servicio en la llamada RestTemplate, creará la URL de destino utilizando el ID de servicio de Eureka del servicio al que desea llamar.

Veamos esta diferencia mirando el siguiente código.

/*Package and import definitions left off for conciseness*/

@Component

public class OrganizationRestTemplateClient {

  @Autowired

  RestTemplate restTemplate;

  public Organization getOrganization(String organizationId){

    ResponseEntity<Organization> restExchange =

    restTemplate.exchange("http://organizationservice/v1/organizations/{organizationId}",

                   HttpMethod.GET, null, Organization.class, organizationId);

    return restExchange.getBody();

  }

}

Este código debería parecerse un poco al ejemplo anterior, excepto por dos diferencias clave. Primero, Spring Cloud DiscoveryClient no está a la vista. En segundo lugar, la URL que se utiliza en la llamada restTemplate.exchange() debería parecerte extraña:

restTemplate.exchange("http://organizationservice/v1/organizations/{organizationId}",

                   HttpMethod.GET, null, Organization.class, organizationId);

El nombre del servidor en la URL coincide con el ID de la aplicación de la clave de servicio de la organización con la que registró el servicio de la organización en Eureka:

http://{identificación de la aplicación}/v1/organizaciones/{identificación de la organización}

El RestTemplate habilitado para Ribbon analizará la URL que se le pasó y usará lo que se le pase como el nombre del servidor como clave para consultar a Ribbon por una instancia de un servicio. La ubicación real del servicio y el puerto están completamente abstraídos del desarrollador.

Además, al usar la clase RestTemplate, Ribbon equilibrará la carga por turnos de todas las solicitudes entre todas las instancias de servicio.

Descubrir un servicio publicado con Eureka con Spring boot, parte 2

Seguimos con el post anterior. Pero para no quedar tan colgado retomemos este código : 

/*Packages and imports removed for conciseness*/

@Component

public class OrganizationDiscoveryClient {

  @Autowired

   private DiscoveryClient discoveryClient;

   public Organization getOrganization(String organizationId) {

     RestTemplate restTemplate = new RestTemplate();

     List<ServiceInstance> instances = discoveryClient.getInstances("organizationservice");

     if (instances.size()==0) return null;

        String serviceUri = String.format("%s/v1/organizations/%s", instances.get(0).getUri().toString(),

            organizationId);

        ResponseEntity< Organization > restExchange = restTemplate.exchange(serviceUri, 

                                                                                                     HttpMethod.GET,

                                                                                                     null, Organization.class, organizationId);

      return restExchange.getBody();

   }

}

Solo debemos usar Discovery-Client directamente cuando el servicio necesita consultar Ribbon para comprender qué servicios e instancias de servicio están registrados con él. Hay varios problemas con este código, incluidos los siguientes:

No se está aprovechando el balanceador de carga del lado del cliente de Ribbon: al llamar a Discovery-Client directamente, obtenemos una lista de servicios, pero tambien responsabilidad elegir qué instancias de servicio a invocar.

Se está haciendo demasiado trabajo: en este momento, debe crear la URL que se utilizará para llamar a su servicio. Es algo pequeño, pero cada pieza de código que puede evitar escribir es una pieza menos de código que tiene que depurar.

Es posible que los desarrolladores observadores de Spring hayan notado que está instanciando directamente la clase RestTemplate en el código. Esto es la antítesis de las invocaciones normales de Spring REST, ya que normalmente Spring Framework inyectaría RestTemplate en la clase que lo usa a través de la anotación @Autowired.

Ha creado una instancia de la clase RestTemplate porque una vez que haya habilitado Spring DiscoveryClient en la clase de aplicación a través de la anotación @EnableDiscovery-Client, todas las RestTemplates administradas por Spring Framework tendrán un interceptor habilitado para Ribbon. Al instanciar directamente la clase RestTemplate le permite evitar este comportamiento.

En resumen, existen mejores mecanismos para llamar a un servicio respaldado por Ribbon.

Descubrir un servicio publicado con Eureka con Spring boot

Ya tenemos el servicio registrado en Eureka. Ahora necesitamos llamarlo sin tener conocimiento directo de la ubicación. De tal manera que este ultimo buscará la ubicación física mediante Eureka.

Para nuestros propósitos, vamos a ver tres bibliotecas de clientes de Spring/Netflix diferentes en las que un consumidor de servicios puede interactuar con Ribbon. Estas bibliotecas pasarán del nivel más bajo de abstracción para interactuar con Ribbon al más alto.

Las bibliotecas que exploraremos incluyen

•  Spring Discovery 
•  Spring Discovery  con RestTemplate habilitado 
•  Netflix Feign

Spring Discovery Client ofrece el nivel más bajo de acceso a Ribbon y los servicios registrados en él. Usando Discovery Client, puede consultar todos los servicios registrados con el cliente y sus URL correspondientes.

Veamos un ejemplo simple del uso de DiscoveryClient para recuperar una de las direcciones URL de un servicio y luego llamaremos al servicio mediante una clase RestTemplate estándar. Para comenzar a usar DiscoveryClient, primero debe anotar la clase Application.java con la anotación @EnableDiscoveryClient:

@SpringBootApplication

@EnableDiscoveryClient

public class Application {

   public static void main(String[] args) {

     SpringApplication.run(Application.class, args);

  }

}

Veamos un ejemplo de un descubrimiento de un cliente : 

/*Packages and imports removed for conciseness*/

@Component

public class OrganizationDiscoveryClient {

  @Autowired

   private DiscoveryClient discoveryClient;

   public Organization getOrganization(String organizationId) {

     RestTemplate restTemplate = new RestTemplate();

     List<ServiceInstance> instances = discoveryClient.getInstances("organizationservice");

     if (instances.size()==0) return null;

        String serviceUri = String.format("%s/v1/organizations/%s", instances.get(0).getUri().toString(),

            organizationId);

        ResponseEntity< Organization > restExchange = restTemplate.exchange(serviceUri, 

                                                                                                     HttpMethod.GET,

                                                                                                     null, Organization.class, organizationId);

      return restExchange.getBody();

   }

}

DiscoveryClient es la clase que usamos para interactuar con Ribbon. Para recuperar todas las instancias de los servicios de la organización registrados con Eureka, se puede usar el método getInstances(), pasando la clave del servicio que está buscando, para recuperar una lista de objetos ServiceInstance.

La clase ServiceInstance se utiliza para contener información sobre una instancia específica de un servicio, incluido su nombre de host, puerto y URI.

Tomamos la primera clase ServiceInstance de su lista para crear una URL de destino que luego se puede usar para llamar a su servicio. Una vez que tenga una URL de destino, puede usar un Spring RestTemplate estándar para llamar al servicio y recuperar datos.

En post posteriores veremos otras opciones. 

Registrar un servicio Spring boot en Eureka

 

En el post anterior levantamos un servidor Eureka, ahora vamos registrar un servicio. 

Lo primero que debe hacer es agregar la dependencia Spring Eureka al archivo pom.xml del servicio que queremos registrar :

<dependency>

    <groupId>org.springframework.cloud</groupId>

    <artifactId>spring-cloud-starter-eureka</artifactId>

</dependency>

El artefacto spring-cloud-starter-eureka contiene los archivos jar que Spring Cloud usará para interactuar con su servicio Eureka.

Después de configurar su archivo pom.xml, debe indicarle a Spring Boot que registre el servicio en el servidor Eureka. Este registro se realice tenemos que configurarlo con el archivo src/main/java/resources/application.yml 

spring:

  application:

    name: myService

  profiles:

    active:

       default

    cloud:

      config:

        enabled: true

eureka:

  instance:

    preferIpAddress: true

  client:

    registerWithEureka: true

    fetchRegistry: true

    serviceUrl:

      defaultZone: http://localhost:8761/eureka/

Todo servicio registrado en Eureka tendrá dos componentes asociados: el ID de la aplicación y el ID de la instancia. El ID de la aplicación se utiliza para representar una instancia de servicio de grupo. En un microservicio basado en Spring-Boot, el ID de la aplicación siempre será el valor establecido por la propiedad spring.application.name. Para su servicio de organización, su spring.application.name se llama creativamente servicio de organización. El ID de la instancia será un número aleatorio destinado a representar una sola instancia de servicio.

La segunda parte de la configuración proporciona cómo y dónde debe registrarse el servicio con el servicio Eureka. La propiedad eureka.instance.preferIpAddress le dice a Eureka que desea registrar la dirección IP del servicio en Eureka en lugar de su nombre de host.

El atributo eureka.client.registerWithEureka es el disparador para decirle al servicio de la organización que se registre en Eureka. El eureka.client.fetchRegistry se utiliza para indicarle al cliente Spring Eureka que obtenga una copia local del registro. Establecer este atributo en true, almacenará en caché el registro localmente en lugar de llamar al servicio Eureka con cada búsqueda. Cada 30 segundos, el software del cliente volverá a ponerse en contacto con el servicio de Eureka para cualquier cambio en el registro.

El último atributo, el atributo eureka.serviceUrl.defaultZone, contiene una lista separada por comas de los servicios de Eureka que el cliente usará para resolver la ubicación del servicio. Para este ejemplo, solo tendrá un servicio Eureka.

Se puede usar la API REST de Eureka para ver el contenido del registro. para ver todos los

instancias de un servicio, presione el siguiente punto final GET:

http://<servicio de eureka>:8761/eureka/apps/<ID DE APLICACIÓN>

Por ejemplo, para ver el servicio de organización en el registro, puede llamar a 

http://localhost:8761/eureka/apps/myservice.

El formato predeterminado que devuelve el servicio Eureka es XML. 

Consumir configuraciones de un servidor de configuración con Spring Cloud

Se acuerdan que en un post anterior hicimos un servidor de configuración con Spring Cloud. Ahora vamos a utilizarlo. 

Cuando el cliente se inicia por primera vez, pasará el perfil de Spring y el end point para comunicarse con el servicio de configuración de Spring Cloud. El valor del perfil Spring se asigna al entorno de las propiedades que se recuperan para el servicio Spring. El servicio Spring Cloud Config luego usará el repositorio de configuración de back-end configurado (sistema de archivos, Git, Consul, Eureka) para recuperar la información de configuración específica para el valor del perfil de Spring pasado en el URI. Spring Boot luego inyectará estos valores en las partes apropiadas de la aplicación.

Lo primero que debe hacer es agregar un par de entradas más al archivo Maven :

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-config-client</artifactId>

</dependency>

La dependencia, spring-cloud-config-client, contiene todas las clases necesarias para interactuar con el servidor de configuración de Spring Cloud.

Una vez definidas las dependencias de Maven, debe indicarle al servicio dónde ponerse en contacto con el servidor de configuración de Spring Cloud. En un servicio Spring Boot que usa Spring Cloud Config, la información de configuración se puede establecer en uno de dos archivos de configuración: bootstrap.yml y application.yml.

El archivo bootstrap.yml lee las propiedades de la aplicación antes de utilizar cualquier otra información de configuración. En general, el archivo bootstrap.yml contiene el nombre de la aplicación para el servicio, el perfil de la aplicación y el URI para conectarse a un servidor Spring Cloud Config.

Cualquier otra información de configuración que desee mantener local para el servicio (y no almacenada en Spring Cloud Config) se puede configurar localmente en los servicios en el archivo application.yml. Por lo general, la información que almacena en el archivo application.yml son datos de configuración que quizás desee tener disponibles para un servicio, incluso si el servicio Spring Cloud Config no está disponible. Los archivos bootstrap.yml y application.yml se almacenan en un directorio de proyectos src/main/resources.

Para que el cliente se comunique con su servicio Spring Cloud Config, debe agregar un archivo /src/main/resources/bootstrap.yml y configurar tres propiedades: spring.application.name, spring.profiles.active y spring.cloud.config.uri.

El archivo bootstrap.yml de los servicios de licencias se muestra en la siguiente lista.

spring.application.name es el nombre de su aplicación y debe asignarse directamente al nombre del directorio dentro de su servidor de configuración de Spring Cloud. Para el servicio de licencias, desea un directorio en el servidor de configuración de Spring Cloud llamado licenseservice.

La segunda propiedad, spring.profiles.active, se usa para decirle a Spring Boot con qué perfil debe ejecutarse la aplicación. Un perfil es un mecanismo para diferenciar los datos de configuración consumidos por la aplicación Spring Boot. Para el perfil del cliente, admitirá el entorno al que se asignará el servicio directamente en su entorno de configuración de la nube. Por ejemplo, al pasar dev como nuestro perfil, el servidor de configuración de Spring Cloud usará las propiedades dev. Si establece un perfil, el servicio de licencias utilizará el perfil predeterminado.

La tercera y última propiedad, spring.cloud.config.uri, es la ubicación donde el servicio de licencias debe buscar el servidor de configuración de Spring Cloud.

punto final. De forma predeterminada, el servicio de licencias buscará el servidor de configuración en http://localhost:8888. Más adelante en el capítulo, verá cómo anular las diferentes propiedades definidas en los archivos boostrap.yml y application.yml al iniciar la aplicación. Esto le permitirá decirle al microservicio de licencias en qué entorno se debe ejecutar.

Ahora, si abre el servicio de configuración de Spring Cloud, con la base de datos de Postgres correspondiente ejecutándose en su máquina local, puede iniciar el servicio de licencias utilizando su perfil predeterminado. Esto se hace cambiando al directorio de servicios de licencias y emitiendo los siguientes comandos:

 

 mvn spring-boot: ejecutar

Al ejecutar este comando sin establecer ninguna propiedad, el servidor de licencias intentará conectarse automáticamente al servidor de configuración de Spring Cloud utilizando el punto final (http://localhost:8888) y el perfil activo (predeterminado) definido en bootstrap.yml archivo del servicio de licencias.

Si desea anular estos valores predeterminados y apuntar a otro entorno, puede hacerlo compilando el proyecto de servicio de licencias en un JAR y luego ejecutar

el JAR con una anulación de propiedad del sistema -D. La siguiente llamada de línea de comando demuestra cómo iniciar el servicio de licencias con un perfil no predeterminado:

java -Dspring.cloud.config.uri=http://localhost:8888 \

-Dspring.profiles.active=dev \

-jar destino/servicio de licencias-0.0.1-SNAPSHOT.jar

Con la línea de comando anterior, está anulando los dos parámetros:

spring.cloud.config.uri y spring.profiles.active. Con la propiedad del sistema -Dspring.cloud.config.uri=http://localhost:8888, está apuntando a un servidor de configuración que se está ejecutando fuera de su caja local.

Con la propiedad del sistema –Dspring.profiles.active=dev, le indica al cliente que use el perfil de desarrollo (leído del servidor de configuración) 

Construyendo nuestro servidor de configuración con Spring Cloud

El servidor de configuración de Spring Cloud es una aplicación basada en REST que está construida sobre Spring Boot. No viene como un servidor independiente. En su lugar, puede elegir embeberlo en una aplicación Spring Boot existente o iniciar un nuevo proyecto Spring Boot con el servidor embebido.

Vamos a hacer una nueva aplicación string boot como servidor de configuraciones. Yo voy a utilizar spring initializr pero podemos agregar estas dependencias en un nuevo proyecto o uno existente. 

<dependencies>

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-config</artifactId>

</dependency>

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-config-server</artifactId>

</dependency>

</dependencies>

O con gradle sería así : 

implementation 'org.springframework.cloud:spring-cloud-starter-config'

implementation 'org.springframework.cloud:spring-cloud-config-server'

La primera dependencia es la dependencia spring-cloud-starter-config que utilizan todos los proyectos de Spring Cloud. La segunda dependencia es el proyecto de inicio spring-cloud-config-server. Esto contiene las bibliotecas centrales para spring-cloud-config-server.

Necesitamos configurar un archivo más para que el servidor de configuración central esté en funcionamiento. Este archivo es el archivo application.yml y lo debemos generar en el directorio src/main/resources. El archivo application.yml le dirá a su servicio de configuración de Spring Cloud qué puerto escuchar y dónde ubicar el back-end que entregará los datos de configuración. En mi caso el appication.yml es así : 

server:
  port: 8888
spring:
  profiles:
    active: native
  cloud:
    config:
      server:
        native:
          searchLocations: file:///{projectPath}/resources

Ojo que {projectPath} es donde esta el proyecto, la dirección por ejemplo el mio esta en /home/emanuel/misProyectos/application. 

En la configuración de Spring Cloud, todo funciona con una jerarquía. La configuración de la aplicación está representada por el nombre de la aplicación y luego un archivo de propiedades para cada entorno para el que se desea tener información de configuración. En cada uno de estos entornos, configurará dos propiedades de configuración. 

Vamos a suponer que tenemos 3 entornos uno de dev, otro de uat y otro de prod. Vamos a crear directorios para cada uno de los entornos en src/main/resources una carpeta por cada entorno. 

El mapeo de las carpetas y los archivos va a ser de la siguiente manera : 

/{application}/{profile}[/{label}]

/{application}-{profile}.yml

/{label}/{application}-{profile}.yml

/{application}-{profile}.properties

/{label}/{application}-{profile}.properties

Noten que el label es opcional. Por lo tanto si hacemos archivos application-dev.properties o application-uat.properties esto debería andar. 

Y por ultimo le decimos a spring que vamos a utilizar spring config con esta anotación : 

@SpringBootApplication
@EnableConfigServer
public class SettingsApplication {

Ahora levantamos el servidor y si necesitamos las configuraciones de uat deberíamos hacer : 

http://localhots:8888/application/uat

Tendremos este resultado : 

{"name":"demo","profiles":["uat"],"label":null,"version":null,"state":null,"propertySources":[{"name":"file:/home/emanuel/Projects/spring-cloud/settings/src/main/resources/demo-uat.yml","source":{"env":"dev"}},{"name":"file:/home/emanuel/Projects/spring-cloud/settings/src/main/resources/application.yml","source":{"server.port":8888,"spring.profiles.active":"native","spring.cloud.config.server.native.searchLocations":"file:///home/emanuel/Projects/spring-cloud/settings/src/main/resources"}}]}

Y listo, nos queda ver como podemos consumir estos settings. (pero eso es para otro post) 

Dejo link: https://cloud.spring.io/spring-cloud-config

Comunicar el estado de un microservicio con Spring Boot Actuators

Un agente de descubrimiento de servicios o service discovery no actúa solo como un policía de tráfico que guía al cliente a la ubicación del servicio. En una aplicación de microservicio basada en la nube, a menudo tendremos varias instancias de un servicio en ejecución. Tarde o temprano, una de esas instancias de servicio fallará. El agente de descubrimiento de servicios supervisa el estado de cada instancia de servicio registrada con él y elimina cualquier instancia de servicio de sus tablas de enrutamiento para garantizar que no se envíe a los clientes una instancia de servicio que haya fallado.

Después de que haya surgido un microservicio, el agente de descubrimiento de servicios continuará monitoreando y haciendo ping a la interfaz de verificación de estado para asegurarse de que ese servicio esté disponible.

Al crear una interfaz de verificación de estado coherente, puede utilizar herramientas de supervisión basadas en la nube para detectar problemas y responder a ellos de forma adecuada.

Si el agente de descubrimiento de servicios descubre un problema con una instancia de servicio, puede tomar medidas correctivas, como cerrar la instancia con problemas o activar instancias de servicio adicionales.

En un entorno de microservicios que utiliza REST, la forma más sencilla de crear una interfaz de verificación de estado es exponer un end point HTTP que pueda devolver una carga útil JSON y código de estado HTTP. En un microservicio no basado en Spring-Boot, a menudo es responsabilidad del desarrollador escribir este end point pero en Spring boot tenemos Spring Actuator. Spring Actuator proporciona end points operativos listos para usar que lo ayudarán a comprender y administrar el estado de su servicio. Para usar Spring Actuator, debemos incluir las siguientes dependencias de Maven:

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-actuator</artifactId>

</dependency>

Y listo! 

Si vamos a http://localhost:8080/actuator/health, debería ver los datos de estado del microservicio.  Algo como esto: 

{"status":"UP"}

Dejo link: https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html