Monoides en Cats

El tipe class monoid es cats.kernel.Monoid, que tiene el alias cats.Monoid. Monoid extiende cats.kernel.Semigroup, que tiene el alias de cats.Semigroup. Cuando usamos Cats, normalmente importamos estas clases : 

import cats.Monoid

import cats.Semigroup

Monoid sigue el patrón Cats estándar: el objeto complementario tiene un método de aplicación que devuelve la instancia del type class para un tipo en particular. Por ejemplo, si queremos la instancia monoide para String y tenemos los implícitos correctos en el alcance, podemos escribir lo siguiente:

import cats.Monoid

import cats.instances.string._ // for Monoid

Monoid[String].combine("Hi ", "there")

// res0: String = "Hi there"

Monoid[String].empty

// res1: String = ""

que es equivalente a:

Monoid.apply[String].combine("Hi ", "there")

// res2: String = "Hi there"

Monoid.apply[String].empty

// res3: String = ""

Como sabemos, Monoid extiende Semigroup. Si no necesitamos empty, podemos escribir de manera equivalente:

import cats.Semigroup

Semigroup[String].combine("Hi ", "there")

// res4: String = "Hi there"

Las instancias de clase de tipo para Monoid se organizan en cats.instances de la manera estándar. Por ejemplo, si queremos obtener instancias para Int, las importamos cats.instances.int:

import cats.Monoid

import cats.instances.int._ // for Monoid

Monoid[Int].combine(32, 10)

// res5: Int = 42

De manera similar, podemos ensamblar un Monoid[Option[Int]] usando instancias de cats.instances.int y cats.instances.option:

import cats.Monoid

import cats.instances.int._

 // for Monoid

import cats.instances.option._ // for Monoid

val a = Option(22)

// a: Option[Int] = Some(22)

val b = Option(20)

// b: Option[Int] = Some(20)

Monoid[Option[Int]].combine(a, b)

// res6: Option[Int] = Some(42)

Como siempre, a menos que tengamos una buena razón para importar instancias individuales, podemos importar todo.

import cats._

import cats.implicits._

Curso de Gugler

 

Monoides y Semigrupos parte 2

Seguimos con Monoides y Semigrupos. 

Un semigrupo es solo la parte combinada de un monoide, sin elemento vacio.

Si bien muchos semigrupos también son monoides, hay algunos tipos de datos para los que no podemos definir un elemento vacío. Por ejemplo, acabamos de ver que la concatenación de secuencias y la suma de enteros son monoides. Sin embargo, si nos restringimos a secuencias no vacías y enteros positivos, ya no podemos definir un elemento vacío sensible. Cats tiene un tipo de datos NonEmptyList que tiene una implementación de Semigroup pero no una implementación de Monoide.

Una definición más precisa (aunque todavía simplificada) de Cats' Monoid es:

trait Semigroup[A] {

  def combine(x: A, y: A): A

}

trait Monoid[A] extends Semigroup[A] {

  def empty: A

}

Veremos este tipo de herencia a menudo cuando discutamos las clases de tipos. Proporciona modularidad y nos permite reutilizar el comportamiento. Si definimos un Monoide para un tipo A, obtenemos un Semigrupo gratis. De manera similar, si un método requiere un parámetro de tipo Semigroup[B], podemos pasar un Monoid[B] en su lugar.

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/

Apache Superset

Apache Superset es una plataforma moderna de exploración y visualización de datos.

Apache Superset es rápido, liviano, intuitivo y está repleto de opciones que facilitan a los usuarios de todos los conjuntos de habilidades explorar y visualizar sus datos, desde simples gráficos circulares hasta gráficos geoespaciales deck.gl altamente detallados.

Apache Superset  proporciona:

• Una interfaz intuitiva para visualizar conjuntos de datos y crear paneles interactivos
• Una amplia gama de hermosas visualizaciones para mostrar sus datos
• Generador de visualización sin código para extraer y presentar conjuntos de datos
• Un IDE de SQL para preparar datos para visualización, incluido un navegador de metadatos enriquecido
• Una capa semántica ligera que permite a los analistas de datos definir rápidamente dimensiones y métricas personalizadas
• Soporte listo para usar para la mayoría de las bases de datos que hablan SQL
• Almacenamiento en caché y consultas asincrónicas en la memoria sin inconvenientes
• Un modelo de seguridad extensible que permite la configuración de reglas muy complejas sobre quién puede acceder a qué funciones y conjuntos de datos del producto.
• Integración con los principales backends de autenticación (base de datos, OpenID, LDAP, OAuth, REMOTE_USER, etc.)
• La capacidad de agregar complementos de visualización personalizados
• Una API para la personalización programática
• Una arquitectura nativa de la nube diseñada desde cero para escalar

Superset es nativo de la nube y está diseñado para tener una alta disponibilidad. Fue diseñado para escalar a grandes entornos distribuidos y funciona muy bien dentro de contenedores. Si bien puede probar fácilmente Superset en una configuración modesta o simplemente en su computadora portátil, prácticamente no hay límite para escalar la plataforma.

Superset también es nativo de la nube en el sentido de que es flexible y le permite elegir:

• servidor web (Gunicorn, Nginx, Apache),
• motor de base de datos de metadatos (MySQL, Postgres, MariaDB, etc.),
• cola de mensajes (Redis, RabbitMQ, SQS, etc.),
• backend de resultados (S3, Redis, Memcached, etc.),
• capa de almacenamiento en caché (Memcached, Redis, etc.),
• Superset también funciona bien con servicios como NewRelic, StatsD y DataDog, y tiene la capacidad de ejecutar cargas de trabajo analíticas contra las tecnologías de bases de datos más populares.

Superset se ejecuta actualmente a escala en muchas empresas. Por ejemplo, Superset se ejecuta en el entorno de producción de Airbnb dentro de Kubernetes y sirve a más de 600 usuarios activos diarios que ven más de 100 000 gráficos al día.

Sin más dejo link: https://superset.apache.org/

Google Java App Engine Standard es open source

Google ha abierto el código fuente de Java para el entorno estándar de Google App Engine, el runtime, las API de App Engine y el SDK.

Lanzado inicialmente en 2018, Google App Engine se diseñó para facilitar a los desarrolladores la implementación y el escalado de sus aplicaciones web. App Engine actualmente es compatible con muchos lenguajes como: Java, PHP, Python, Node.js, Go, Ruby.

Los desarrolladores de Java pueden implementar aplicaciones web basadas en servlets, utilizando Java 8, Java 11 y Java 17, así como otros lenguajes JVM como Groovy y Kotlin. Además, es posible utilizar muchos frameworks, como Spring Boot, Quarkus, Vert.x y Micronaut.

Queria compartir con ustedes esta noticia, que más que nada me llamo la atención. Dado que no conozco gente que este usando App Engine y me parece que estos esfuerzos para hacer la plataforma más popular llegaron tarde. 

Dejo link : https://cloud.google.com/blog/topics/developers-practitioners/open-sourcing-app-engine-standard-java-runtime

Monoides y Semigrupos

La adición de Ints es una operación binaria cerrada, lo que significa que sumar dos Ints siempre produce otro Int:

2 + 1

// res0: Int = 3

También existe el elemento de identidad 0 con la propiedad de que a + 0 == 0 + a== a para cualquier Int a:

2 + 0

// res1: Int = 2

0 + 2

// res2: Int = 2

También hay otras propiedades de la adición. Por ejemplo, no importa en qué orden agreguemos elementos porque siempre obtenemos el mismo resultado. Esta es una propiedad conocida como asociatividad:

(1 + 2) + 3

// res3: Int = 6

1 + (2 + 3)

// res4: Int = 6

Las mismas propiedades para la suma también se aplican para la multiplicación, siempre que usemos 1 como identidad en lugar de 0:

1 * 3

// res5: Int = 3

3 * 1

// res6: Int = 3

La multiplicación, como la suma, es asociativa:

(1 * 2) * 3

// res7: Int = 6

1 * (2 * 3)

// res8: Int = 6

También podemos agregar Cadenas, usando la concatenación de cadenas como nuestro operador binario:

"One" ++ "two"

// res9: String = "Onetwo"

y la cadena vacía como la identidad:

"" ++ "Hello"

// res10: String = "Hello"

"Hello" ++ ""

// res11: String = "Hello"

Una vez más, la concatenación es asociativa:

("One" ++ "Two") ++ "Three"

// res12: String = "OneTwoThree"

"One" ++ ("Two" ++ "Three")

// res13: String = "OneTwoThree"

Tenga en cuenta que usamos ++ arriba en lugar del + más habitual para sugerir un paralelo con secuencias. Podemos hacer lo mismo con otros tipos de secuencias, usando la concatenación como operador binario y la secuencia vacía como nuestra identidad.

Formalmente, un monoide para un tipo A es:

• una operación o función que permite "combinar" dos elementos y retornar uno del mismo tipo, la firma sería : (A, A) => A

• un elemento vacío de tipo A

Esta definición se traduce muy bien en código Scala. Aquí hay una versión simplificada de la definición de Cats:

trait Monoid[A] {

   def combine(x: A, y: A): A

   def empty: A

}

Además de proporcionar las operaciones de combinar y vaciar, los monoides deben obedecer formalmente varias leyes. Para todos los valores x, y y z, en A, la combinación debe ser asociativa y el vacío debe ser un elemento de identidad:

def associativeLaw[A](x: A, y: A, z: A)

   (implicit m: Monoid[A]): Boolean = {

    m.combine(x, m.combine(y, z)) ==

    m.combine(m.combine(x, y), z)

}

def identityLaw[A](x: A)

   (implicit m: Monoid[A]): Boolean = {

   (m.combine(x, m.empty) == x) &&

   (m.combine(m.empty, x) == x)

}

La resta de enteros, por ejemplo, no es un monoide porque la resta no es asociativa:

(1 - 2) - 3

// res14: Int = -4

1 - (2 - 3)

// res15: Int = 2

En la práctica, solo necesitamos pensar en las leyes cuando escribimos nuestras propias instancias de Monoid. Las instancias ilegales son peligrosas porque pueden producir resultados impredecibles cuando se usan con el resto de la maquinaria de Cats. La mayoría de las veces podemos confiar en las instancias proporcionadas por Cats y asumir que los autores de la biblioteca saben lo que están haciendo.

Libros gratuitos de webcodegeeks

 

Download IT Guides!   The Best Web Programming Languages to Learn A more comprehensive list of tasks to which web development commonly refers, may include web engineering, web design, web content development, client liaison, client-side/server-side...     Web Developer Interview Questions A more comprehensive list of tasks to which web development commonly refers, may include web engineering, web design, web content development, client liaison, client-side/server-side...     Git Tutorial Git is, without any doubt, the most popular version control system. Ironically, there are other version control systems easier to learn and to use, but, despite that, Git is the favorite...     Docker Containerization Cookbook Docker is the world's leading software containerization platform. Docker containers wrap a piece of software in a complete filesystem that contains everything needed to run: code,...

Empezando con Cats parte 3

 Al trabajar con type class, debemos tener en cuenta dos cuestiones que controlan la selección de instancias:

• ¿Cuál es la relación entre una instancia definida en un tipo y sus subtipos? Por ejemplo, si definimos un JsonWriter[Option[Int]], ¿la expresión Json.toJson(Some(1)) seleccionará esta instancia? (Recuerde que Some es un subtipo de Option).
• ¿Cómo elegimos entre instancias de type class cuando hay muchas disponibles? ¿Qué pasa si definimos dos JsonWriters para Person? Cuando escribimos Json.toJson(aPerson), ¿qué instancia se selecciona?

Cuando definimos clases de tipo, podemos agregar anotaciones de variación al parámetro de tipo para afectar la variación de la clase de tipo y la capacidad del compilador para seleccionar instancias durante la resolución implícita.

La varianza se relaciona con los subtipos. Decimos que B es un subtipo de A si podemos usar un valor de tipo B en cualquier lugar donde esperamos un valor de tipo A.

Las anotaciones de covarianza y contravarianza surgen cuando se trabaja con constructores de tipos. Por ejemplo, denotamos la covarianza con un símbolo +:

trait F[+A] // the "+" means "covariant"

Covarianza significa que el tipo F[B] es un subtipo del tipo F[A] si B es un subtipo de A. Esto es útil para modelar muchos tipos, incluidas colecciones como List y Option:

traittraitList[+A]

Option[+A]

La covarianza de las colecciones de Scala nos permite sustituir colecciones de un tipo por una colección de un subtipo en nuestro código. Por ejemplo, podemos usar una Lista[Círculo] en cualquier lugar donde esperemos una Lista[Forma] porque Círculo es un subtipo de Forma:

sealed trait Shape

case class Circle(radius: Double) extends Shape

val circles: List[Circle] = ???

val shapes: List[Shape] = circles

En términos generales, la covarianza se usa para las salidas: datos que luego podemos obtener de un tipo de contenedor como List, o de otra manera devueltos por algún método.

¿Qué pasa con la contravarianza? Escribimos constructores de tipos contravariantes con un símbolo - como este:

trait F[-A]

La contravarianza significa que el tipo F[B] es un subtipo de F[A] si A es un subtipo de B. Esto es útil para modelar tipos que representan entradas, como nuestra clase de tipo JsonWriter anterior:

trait JsonWriter[-A] {

def write(value: A): Json

}

La varianza tiene que ver con la capacidad de sustituir un valor por otro. Considere un escenario en el que tenemos dos valores, uno de tipo Forma y otro de tipo Círculo, y dos JsonWriters, uno para Forma y otro para Círculo:

val shape: Shape = ???

val circle: Circle = ???

val shapeWriter: JsonWriter[Shape] = ???

val circleWriter: JsonWriter[Circle] = ???

def format[A](value: A, writer: JsonWriter[A]): Json = writer.write(value)

¿Qué combinaciones de value y JsonWriter pueden pasar a format? Podemos escribir un Círculo con cualquier escritor porque todos los Círculos son Formas. Por el contrario, no podemos escribir una Forma con circleWriter porque no todas las Formas son Círculos. Esta relación es lo que modelamos formalmente usando contravarianza.

JsonWriter[Shape] es un subtipo de JsonWriter[Circle] porque Circle es un subtipo de Shape. Esto significa que podemos usar shapeWriter en cualquier lugar donde esperemos ver un JsonWriter[Circle].

La invariancia es la situación más fácil de describir. Es lo que obtenemos cuando no escribimos un + o - en un constructor de tipos:

trait F[A]

Esto significa que los tipos F[A] y F[B] nunca son subtipos entre sí, independientemente de la relación entre A y B. Esta es la semántica predeterminada para los constructores de tipos de Scala.

Cuando el compilador busca un implícito, busca uno que coincida con el tipo o subtipo. Por lo tanto, podemos usar anotaciones de varianza para controlar la selección de instancias de clase de tipo hasta cierto punto.

Hay dos problemas que tienden a surgir. Imaginemos que tenemos un tipo de dato algebraico como:

sealed trait A

final case object B extends A

final case object C extends A

Los problemas son:

¿Se seleccionará una instancia definida en un supertipo si hay una disponible? Por ejemplo, ¿podemos definir una instancia para A y hacer que funcione para valores de tipo B y C?

¿Se seleccionará una instancia para un subtipo con preferencia a la de un supertipo? Por ejemplo, si definimos una instancia para A y B, y tenemos un valor de tipo B, ¿se seleccionará la instancia de B con preferencia a A?

Está claro que no existe un sistema perfecto. Cats prefiere usar clases de tipos invariantes.

Esto nos permite especificar instancias más específicas para subtipos si queremos. Significa que si tenemos, por ejemplo, un valor de tipo Some[Int], no se usará nuestra instancia de clase de tipo para Option. Podemos resolver este problema con una anotación de tipo como Some(1) : Option[Int] o usando "constructores inteligentes" como los métodos Option.apply, Option.empty, some y none.

Empezando con Cats parte 2

Cats proporciona importaciones de sintaxis separadas para cada type class.

Se puede especificar exactamente qué instancia necesitamos. Sin embargo, esto no agrega valor en el código de producción. Es más simple y rápido usar las siguientes importaciones:

• import cats._ importa todas las clases de tipos de Cats de una sola vez;

• import cats.implicits._ importa todas las instancias de clase de tipo estándar y toda la sintaxis de una sola vez.

Podemos definir una instancia de Show simplemente implementando el trait :

import java.util.Date

implicit val dateShow: Show[Date] = new Show[Date] {

def show(date: Date): String = s"${date.getTime}ms since the epoch."

}

new Date().show

// res1: String = "1594650192117ms since the epoch."

Sin embargo, Cats también proporciona un par de métodos convenientes para simplificar el proceso. Hay dos métodos de construcción en el objeto complementario de Show que podemos usar para definir instancias para nuestros propios tipos:

object Show {

// Convert a function to a `Show` instance:

def show[A](f: A => String): Show[A] = ???

// Create a `Show` instance from a `toString` method:

def fromToString[A]: Show[A] = ???

}

Estos nos permiten construir instancias rápidamente con menos ceremonia que definirlas desde cero:

val implícito dateShow: Show[Date] = Show.show(date => s"${date.getTime}ms since the epoch.") 

Como puede ver, el código que usa métodos de construcción es mucho más conciso que el código sin ellos. Muchas clases de tipos en Cats proporcionan métodos auxiliares como estos para construir instancias, ya sea desde cero o transformando instancias existentes para otros tipos.

Empezando con Cats

Cats está escrito usando una estructura modular que nos permite elegir qué class type, instancias y métodos de interfaz queremos usar. Echemos un primer vistazo usando cats.Show como ejemplo.

Show proporciona un mecanismo para producir una salida de consola amigable para los desarrolladores sin usar toString. Aquí hay una definición abreviada:

package cats

trait Show[A] {

def show(value: A): String

}

Los type classes en Cats se definen en el paquete cats. Podemos importar Show directamente desde este paquete:

import cats.Show

El objeto complementario de cada clase de tipo Cats tiene un método de aplicación que localiza una instancia para cualquier tipo que especifiquemos:

val showInt = Show.apply[Int]

// error: could not find implicit value for parameter instance: cats.Show[Int]

// val showInt: Show[Int] = Show.apply[Int]

//

 ^^^^^^^^^^^^^^^

Vaya, ¡eso no funcionó! El método apply utiliza implícitos para buscar instancias individuales, por lo que tendremos que incluir algunas instancias en el alcance.

El paquete cats.instances proporciona instancias predeterminadas para una amplia variedad de tipos. Podemos importarlos como se muestra en la siguiente tabla. Cada importación proporciona

instancias de todas las clases de tipos de Cats para un tipo de parámetro específico:

cats.instances.int proporciona instancias para Int

cats.instances.string proporciona instancias para String

cats.instances.list proporciona instancias para List

cats.instances.option proporciona instancias para Option

cats.instances.all proporciona todas las instancias que se envían listas para usar con Cats

Importemos las instancias de Show para Int y String:

import cats.instances.int._ // for Show

import cats.instances.string._ // for Show

val showInt: Show[Int] = Show.apply[Int]

val showString: Show[String] = Show.apply[String]

Ahora tenemos acceso a dos instancias de Show y podemos usarlas para imprimir Ints y Strings:

val intAsString: String = showInt.show(123)

// intAsString: String = "123"

val stringAsString: String = showString.show("abc")

// stringAsString: String = "abc"

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

Raml, un modo simple de modelar APIs

Claramente no hemos encontrado el camino correcto y flexible de modelar APIs, porque si no tenemos un router que es una clase o archivo que tiene parte de la información. Tenemos que llenar nuestras clases de muchas anotaciones. 

Para resolver este problema llego Raml, y veamos un ejemplo: 

%RAML 1.0

title: Mobile Order API

baseUri: http://localhost:8081/api

version: 1.0

uses:

  assets: assets.lib.raml

annotationTypes:

  monitoringInterval:

    type: integer

/orders:

  displayName: Orders

  get:

    is: [ assets.paging ]

    (monitoringInterval): 30

    description: Lists all orders of a specific user

    queryParameters:

      userId:

        type: string

        description: use to query all orders of a user

  post:

  /{orderId}:

    get:

      responses:

        200:

          body:

            application/json:

              type: assets.Order

            application/xml:

              type: !include schemas/order.xsd

Dejo link: https://raml.org

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.