Composición de FreeMonad

En la entrada anterior, FreeMonad en Cats, realicé una descripción de cómo definir un DSL utilizando una FreeMonad pero, en ciertas situaciones, necesitamos utilizar un segundo DSL conjuntamente con el primero. En la entrada de hoy, Composición de FreeMonad, realizaré un ejemplo de una aplicación que utiliza conjuntamente dos DSL para la definición de un programa.

Presentación del problema

Continuando con las entidades de dominio de la entrada anterior, supongamos que necesitamos realizar la creación de un esquema de base de datos, realizar unas inserciones, eliminar y consultar; es decir, necesitamos un programa que realice unas operaciones básicas de tipo CRUD; pero además, necesitamos que las operaciones sean trazadas en un log en la salida estándar; pudiendo ser de dos tipos: mensajes informativos, tipo info; y, mensajes de depuración, tipo debug.
Para definir un programa que cumpla con estos requisitos necesitamos lo siguiente: definir un DSL para las operaciones en base de datos, definir un DSL para las operaciones de log y un intérprete que entienda el lenguaje de los DSL`s.

Definición de los ADT`s

Definiré dos ADT’s para los dos tipos de operaciones: DBOperations, para el ADT’s de las operaciones en base de datos; y, LogOperation. Antes de definir los ADT’s, definiremos el alias a utilizar. Definimos un alias con nombre Response con un tipo genérico, define un contenedor binario de tipo Either de un tipo Exception y un tipo genérico. La definición del alias es el siguiente:

type Response[A] = Either[Exception, A]

El ADT que define las operaciones de base de datos es el mismo que se utiliza en la entrada anterior, mediante la siguiente estructura de clases:

sealed trait DBOperation[A]
case class Configure(xa: Aux[IO, Unit]) extends DBOperation[Response[Unit]]
case class CreateSchema() extends DBOperation[Response[Boolean]]
case class Insert(author: Author) extends DBOperation[Response[Int]]
case class Select(key: Int) extends DBOperation[Response[Option[String]]]
case class Delete(key: Int) extends DBOperation[Response[Int]]

Las clases definidas definen las siguientes operaciones: clase Configure, define la operación de configuración de Transactor de la base de datos; CreateSchema, creación del esquema de base de datos: Insert, inserción de una entidad Author; Select, seleccionar un autor por clave; Delete, eliminación de un autor por clave.

El ADT que define las operaciones de escritura de log se define mediante la siguiente estructura de clases:

sealed trait LogOperation[A]
case class Info(msg: String) extends LogOperation[Response[Unit]]
case class Debug(msg: String) extends LogOperation[Response[Unit]]

Las clases definidas definen las siguientes operaciones: Info, define la escritura de un mensaje de tipo informativo; Debug, define la escritura de un mensaje de tipo depuración.

En los dos ADT’s, se define como respuesta de la operación el tipo Response.

Definición de los DSL’s

Una FreeMonad permite a un Functor tener la funcionalidad de una mónada; añadir esta funcionalidad, la proporciona el tipo Free[_]. Además, para poder trabajar con otros DSL, es necesario añadir elementos que permitan la unión de los DSL; para ello se utilizan las siguientes herramientas:

  • InjectK[DBOperation, F].- Type class que permite inyectar el tipo DBOperation en el tipo F del contexto de ejecución.
  • Free.inject[DBOperation, F].- Función que permite enlazar el tipo DBOperation al tipo F del contexto de ejecución.

La definición de los DSL`s DBOperations y LogOperations se realiza definiendo una clase y su companion object el cual define una referencia implícita a la instancia de la clase. El código de los DSL`s se definen en el siguiente snippet:

class DBOperations[F[_]](implicit I: InjectK[DBOperation, F]){
  def configure(xa: Aux[IO, Unit]): Free[F, Response[Unit]] = Free.inject[DBOperation, F](Configure(xa))
  def createSchema(): Free[F, Response[Boolean]] = Free.inject[DBOperation, F](CreateSchema())
  def insert(elem: Author): Free[F, Response[Int]] = Free.inject[DBOperation, F](Insert(elem))
  def delete(key: Int): Free[F, Response[Int]] = Free.inject[DBOperation, F](Delete(key))
  def select(key: Int): Free[F, Response[Option[String]]] = Free.inject[DBOperation, F](Select(key))
}
object DBOperations{
  implicit def dboperations[F[_]](implicit I: InjectK[DBOperation, F]) = new DBOperations[F]()
}
class LogOperations[F[_]](implicit I: InjectK[LogOperation, F]){
  def infoLog(msg: String): Free[F, Response[Unit]] = Free.inject[LogOperation, F](Info(msg))
  def debugLog(msg: String): Free[F, Response[Unit]] = Free.inject[LogOperation, F](Debug(msg))
}
object LogOperations{
  implicit def logopearations[F[_]](implicit I: InjectK[LogOperation, F]) = new LogOperations[F]()
}

Definición de los intérpretes

Los intérpretes son los functores de transformación. Realizan la interpretación del DSL, interpretando el lenguaje para el que está definido, ejecuta la funcionalidad requerida y retorna el valor transformado.

El intérprete del DSL DBOperations se define en el objeto DBOperationInterprete el cual es un functor de transformación de un tipo DBOperation a OperationResponse. El tipo OperationResponse es un alias del tipo identidad definido en Cats. El alias se define de la siguiente forma:

type OperationResponse[A] = Id[A]

DBOperationsInterprete define una referencia a un transactor de la librería Doobie con una configuración por defecto, esta configuración es un valor mutable ya que puede ser configurada de forma dinámica. Para todo elemento del ADT, se utiliza el repositorio de Author y se trata el resultado como un tipo OperationResponse[A]. El snippet del código con el intérprete es el siguiente:

object DBOperationsInterpreter extends (DBOperation ~> OperationResponse){
  implicit val cs = IO.contextShift(ExecutionContexts.synchronous)
  // TODO var -> val?
  private var xa = Transactor.fromDriverManager[IO](
    s"com.mysql.jdbc.Driver", s"jdbc:mysql://host:port/doobie", s"user", s"pwd",
    Blocker.liftExecutionContext(ExecutionContexts.synchronous) // just for testing
  )
  override def apply[A](fa: DBOperation[A]) = fa match {
    case Configure(xaTransactor) => {
      this.xa = xaTransactor
      val result: OperationResponse[Response[Unit]] = Right(Unit)
      result
    }
    case CreateSchema() => {
      val resultCreateSchema: Response[Boolean] = AuthorRepository.createSchemaIntoMySqlB(xa)
      val result: OperationResponse[ Response[Boolean]] = resultCreateSchema
      result
    }
    case Insert(author) =>{
      val resultTask: Response[Int] = AuthorRepository.insertAuthorIntoMySql(xa, author)
      val result: OperationResponse[Response[Int]] = resultTask
      result
    }
    case Delete(key) => {
      val resultTask: Response[Int] = AuthorRepository.deleteAuthorById(xa, key)
      val result: OperationResponse[Response[Int]] = resultTask
      result
    }
    case Select(key) => {
      val resultTask: Response[Option[String]] = AuthorRepository.selectAuthorById(xa, key)
      val result: OperationResponse[Response[Option[String]]] = resultTask
      result
    }
  }
}

Para el lector interesado en el código de ejemplo del repositorio Author puede acceder a través del siguiente enlace.

El intérprete del DSL`s de operaciones de Log se define en el objeto LogOperationsInterprete el cual define un functor transformador de un tipo LogOperation a un tipo OperationResponse. El intérprete define las operaciones para los mensajes de tipo info y debug escribiendo mensajes en la salida estándar. El snippet de código con el intérprete es el siguiente:

object LogOperationsInterpreter extends (LogOperation ~> OperationResponse){
  override def apply[A](fa: LogOperation[A]) = fa match {
    case Info(msg) =>
      println(s"[*** INFO] ${msg}")
      val result: OperationResponse[Response[Unit]] = Right(Unit)
      result
    case Debug(msg) =>
      println(s"[*** DEBUG] ${msg}")
      val result: OperationResponse[Response[Unit]] = Right(Unit)
      result
  }
}

Un aspecto importante a destacar es que en los dos funtores de transformación, es decir, los intérpretes, tienen el mismo tipo de salida definido en el alias OperationResponse[A].

Llegado a este punto, tenemos definidos los dos intérpretes de forma individual pero, nos falta la definición del intérprete que comprenda los dos lenguajes; para ello, tenemos que definir un tipo que englobe a los dos ADT de los DSL definidos y, posteriormente, define un functor que transforma del tipo anterior al resultado final.

El tipo DoobiePureComposingApp es un alias que define un tipo EitherK con los tipos DBOperation, LogOperation (ADT de los DSL definidos) y el tipo A. Este tipo comprende los tipos de las gramáticas de los DSL.

type DoobiePureComposingApp[A] = EitherK[DBOperation, LogOperation, A]

El tipo que define el resultado es el tipo identidad de los DSL definidos.

type OperationResponse[A] = Id[A]

Así, la definición del intérprete que engloba a los dos DSL se define de la siguiente forma:

val interpreter: DoobiePureComposingApp ~> OperationResponse = DBOperationsInterpreter or LogOperationsInterpreter

Definición del programa de uso de los DSL

Llegado a este punto, estamos en disposición de declarar un programa que realice operaciones en base de datos de la entidad Author y con capacidad de escribir en un log. Como comentamos al inicio de la entrada, el programa declara un conjunto de operaciones representativas con un objetivo pedagógico. El snippet del código es el siguiente:

implicit val cs = IO.contextShift(ExecutionContexts.synchronous)
final case class DatabaseConfig( host: String, port: String, user: String, password: Secret[String])
def loadEnvironmentVariables(): DatabaseConfig = {
  val host: ConfigValue[String] = env("DDBB_HOST").or(prop("ddbb.host")).as[String]
  val port: ConfigValue[String] = env("DDBB_PORT").or(prop("ddbb.port")).as[String]
  val user: ConfigValue[String] = env("DDBB_USER").or(prop("ddbb.user")).as[String]
  val password: ConfigValue[Secret[String]] = env("DDBB_PWD").secret
  val configureEnv: ConfigValue[DatabaseConfig] = (host, port, user, password).parMapN(DatabaseConfig)
  configureEnv.load[IO].unsafeRunSync()
}
val dataConfigure: DatabaseConfig = loadEnvironmentVariables()
private val xa = Transactor.fromDriverManager[IO](
  "com.mysql.jdbc.Driver",
  s"jdbc:mysql://${dataConfigure.host}:${dataConfigure.port}/doobie",
  s"${dataConfigure.user}",
  s"${dataConfigure.password.value}",
  Blocker.liftExecutionContext(ExecutionContexts.synchronous) // just for testing
)
def programBusiness(xa: Aux[IO, Unit])(implicit DB: DBOperations[DoobiePureComposingApp],
L: LogOperations[DoobiePureComposingApp]): Free[DoobiePureComposingApp, Response[Option[String]]] = {
  import DB._
  import L._
  for {
    _ <- debugLog("Configuring database...")
    _ <- configure(xa)
    _ <- debugLog("Creating database...")
    result <- createSchema()
    numInsert1 <- insert(Author(0, "AuthorTest1"))
    numInsert2 <- insert(Author(0, "AuthorTest2"))
    numDelete1 <- delete(key = 1)
    nameAuthor <- select(key = 2)
    _ <- infoLog("Created Database.")
  } yield {
    nameAuthor
  }
}
val result = programBusiness(xa).foldMap(interpreter)
println(s"Result=${result}")

El código presentado, realiza la carga de la configuración de base de datos desde variables de entorno utilizando la librería Ciris; esta funcionalidad, queda definida en la función loadEnvironmentVariables la cual retorna una clase DatabaseConfig con la configuración; se define el Transactor de la librería Doobie con la configuración la cual es utilizada posteriormente en la declaración del programa; y, por último, se declara el programa en la función programBusiness el cual define como implícitos las referencias a las instancias de los DSL con el tipo DoobiePureComposingApp y, como retorno, un tipo Free con el tipo DoobiePureComposingApp y el tipo de retorno del programa Response[Option[String]].

La salida por consola es la siguiente:

[*** DEBUG] Configuring database…
[*** DEBUG] Creating database…
[*** INFO] Created Database.
Result=Right(Some(AuthorTest2))

Para el lector interesado en el código puede acceder a través del siguiente enlace y, para la entrada en donde explico el uso de la librería Ciris, puede acceder mediante el siguiente enlace

FreeMonad en Cats

Definimos FreeMonad como aquella construcción que permite construir una mónada desde un functor. En la presente entrada, FreeMonad en Cats, describiré cómo definir y utilizar una FreeMonad mediante un ejemplo.

Según Wikipedia, definimos funtor como sigue:

“En teoría de categorías un funtor o functor es una función de una categoría a otra que lleva objetos a objetos y morfismos a morfismos de manera que la composición de morfismos y las identidades se preserven”.

Un functor cumple la propiedad de identidad y de composición.

Según Wikipedia, definimos mónada como sigue:

“En la programación funcional , una mónada (monad en inglés), es una estructura que representa cálculos definidos como una secuencia de pasos”

Una mónada cumple la propiedad de identidad y asociativa.

La FreeMonad permite lo siguiente:

  • Representar cálculos con estado como datos y ejecutarlos.
  • Ejecutar cálculos recursivos.
  • Definir un DSL.
  • Reorientar un cálculo a otro intérprete utilizando transformaciones naturales.

La implementación de FreeMonad que utilizaremos en el ejercicio es aquella que se ha definido en la librería Cats y, el módulo de cats empleado, es el paquete que se define en cats-free. Una FreeMonad se define como Free[_]

La definición de dependencias del módulo sbt en el fichero build.sbt es la siguiente:

lazy val catsEffect = (project in file("cats-effect"))
  .settings(
    name := "example-cats-effect",
    assemblySettings,
    scalacOptions ++= basicScalacOptions,
    libraryDependencies ++=
      catsEffectDependencies ++ Seq(
        scalaTest
      )
  )
lazy val catsEffectDependencies = Seq(
  cats_effect,
  cats_effect_laws
)

La definición de las coordenadas de los paquetes a utilizar en el módulo para la librería cats-free son las siguientes:

lazy val cats_effect_laws = "org.typelevel" %% "cats-effect-laws" % "2.2.0" % "test"
lazy val cats_free = "org.typelevel" %% "cats-free" % "2.2.0"

Presentación del problema

Supongamos que tenemos un aplicativo el cual maneja una entidad Autor y necesitamos persistir los datos de la entidad Autor en base de datos. Para ello, necesitamos realizar operaciones sobre base de datos como son: creación del esquema, insertar, borrar y buscar elementos. La definición de la entidad de dominio del problema se define en la siguiente case class:

case class Author(id:Long, name: String)

Para dar solución a este problema, definiremos un DSL que soporte las funcionalidades requeridas. Evidentemente, es un problema teórico con el objetivo describir la definición de una FreeMonad.

Definición de la gramática

La gramática del DSL queda definida en un ADT (Tipo de dato Algebraico) el cual define las operaciones a realizar. El ADT con las operaciones de base de datos OperationDB[A] queda definido en la siguiente estructura de clases:

sealed trait OperationDB[A]
case class CreateSchema() extends OperationDB[OperationDBResponse[Boolean]]
case class Insert(author: Author) extends OperationDB[OperationDBResponse[Int]]
case class Select(key: Int) extends OperationDB[OperationDBResponseOption[String]]
case class Delete(key: Int) extends OperationDB[OperationDBResponse[Int]]

Las operaciones de base de datos son: CreateSchema, operación para la creación del esquema de la entidad Autor; Insert, operación de inserción de un Autor; Select, búsqueda de un Autor en función de una clave; y, Delete, eliminación de un Autor por clave. El tipo parametrizado es el tipo de retorno de cada operación cuyos tipos son los representados en los siguiente alias:

type OperationDBResponse[A] = Either[Exception, A]
type OperationDBResponseOption[A] = Either[Exception, Option[A]]

Los alias descritos anteriormente define contenedores binarios de Tipo Either cuyo valor Left representa una excepción y, su valor Right, representa el resultado de la operación de tipo A u Option[A]

Definición del DSL

El DSL se define mediante una FreeMonad la cual, utilizando Cats, queda definida con el tipo Free[_]. Así, el alias del tipo de operación del DSL se define utilizando el siguiente alias:

type Operation[A] = Free[OperationDB, A]

El alias Operation[A] define una FreeMonad cuyo valor de entrada es una operación de tipo OperationDB y cuyo resultado es un tipo genérico A.

El DSL debe de definir funciones para las siguientes operaciones: creación de un esquema, inserción, borrado y consulta. Las funciones del DSL son las siguientes:

import cats.free.Free
import cats.free.Free.liftF
[...]
def createSchema(): Operation[OperationDBResponse[Boolean]] =
    liftF[OperationDB, OperationDBResponse[Boolean]](CreateSchema())
def insert(elem: Author): Operation[OperationDBResponse[Int]] =
    liftF[OperationDB, OperationDBResponse[Int]](Insert(elem))
def delete(key: Int): Operation[OperationDBResponse[Int]] =
    liftF[OperationDB, OperationDBResponse[Int]](Delete(key))
def select(key: Int): Operation[OperationDBResponseOption[String]] =
    liftF[OperationDB, OperationDBResponseOption[String]](Select(key))

Las funciones del DSL utilizan la función liftF que permite subir de contexto de una operación OperationDB con un tipo de respuesta a una FreeMonad, Free[_].

Definición del intérprete del DSL

Una vez definido el lenguaje de dominio es necesario definir aquel intérprete que sea capaz de traducir el lenguaje en operaciones de base de datos. En nuestro caso, utilizaremos una entidad repositorio el cual sea capaz de realizar las operaciones de base de datos, consiguiendo desacoplar las operaciones de interpretación del lenguaje con las operaciones directas de base de datos.

El repositorio es un objeto llamado AuthorRepository el cual utiliza la librería funcional Doobie para realizar las operaciones.

Para cada operación del lenguaje, el intérprete gestiona un estado. Los estados son los siguientes: Init, estado inicial que representa el estado previo a la creación del esquema; Created, estado que indica que el esquema ha sido creado; Deleted, estado que representa la eliminación del esquema, en la práctica no se utiliza.

Los estados quedan representados en la siguiente estructura:

sealed trait StateDatabase
case object Init extends StateDatabase
case object Created extends StateDatabase
case object Deleted extends StateDatabase

Dada la existencia de estados, el intérprete utilizará la mónada estado para gestionar el retorno de estado de cada operación.

El intérprete define un functor de transformación, representado por el símbolo ~> el cual transforma entidades de tipo OpearetionDB en OperationState. El functor intérprete recibe como parámetro un Transactor de Doobie de la base de datos con la que se opera. El snippet de código del intérprete es el siguiente:

import cats.~>
[...]
def pureInterpreter(xa: Aux[IO, Unit]): OperationDB ~> OperationState = new(OperationDB ~> OperationState){
override def apply[A](fa: OperationDB[A]): OperationState[A] = fa match {
  case CreateSchema() => {
    val resultCreateSchema: Either[Exception, Boolean] = AuthorRepository.createSchemaIntoMySqlB(xa)
    resultCreateSchema
      .fold( ex => State[StateDatabase, OperationDBResponse[Boolean]]{ state => (Init,  resultCreateSchema) },
        value => State[StateDatabase, OperationDBResponse[Boolean]]{ state => (Created,  resultCreateSchema) } )
  }
  case Insert(author) =>{
    State[StateDatabase, OperationDBResponse[Int]]{ state =>
      (Created,  AuthorRepository.insertAuthorIntoMySql(xa, author))
    }
  }
  case Delete(key) => {
    State[StateDatabase, OperationDBResponse[Int]]{ state =>
      (Created,  AuthorRepository.deleteAuthorById(xa, key))
    }
  }
  case Select(key) => {
    State[StateDatabase, OperationDBResponseOption[String]]{ state =>
      (Created,  AuthorRepository.selectAuthorById(xa, key))
    }
  }
 }
}

Definición del repositorio de la entidad Autor.

El repositorio con las operaciones de base de datos está definiado en un objeto AuthorRepository que utiliza la librería Doobie. El objeto define un conjunto de funciones con las operaciones que utiliza el intérprete del DSL; como ejemplo, la operación de creación del esquema es la siguiente:

val dropAuthor: ConnectionIO[Int] = sql"""DROP TABLE IF EXISTS Author""".update.run
val createAuthor: ConnectionIO[Int] = sql"""CREATE TABLE Author (id SERIAL, name text)""".update.run
def createSchemaIntoMySqlA[A](xa: Aux[IO, Unit]): Either[Exception, Unit] = {
  val creator: ConnectionIO[Unit] = for {
    _ <- dropAuthor
    _ <- createAuthor
  } yield ()
  try{
    val resultDatabase: Unit = creator.transact(xa).unsafeRunSync
    Right(resultDatabase)
  } catch {
    case e: java.sql.SQLException =>{
      println(s"Error create schema: ${e}")
      Left(e)
    }
  }
}

Para el lector interesado en el código del repositorio puede acceder en el siguiente enlace.

Definición de los programas

Una vez definida en un objeto AuthorDSL las funciones del DSL, alias e intérpretes, estamos en disposición de definir las declaraciones de los programas que pueden utilizar dicho lenguaje; para ello, necesitamos importar el DSL y definir el Transactor de base de datos, estas operaciones, se realizan de la siguiente forma:

import doobie.Transactor
import doobie.util.ExecutionContexts
import es.ams.freemonaddoobie.AuthorDSL._
[...]
implicit val cs = IO.contextShift(ExecutionContexts.synchronous)
val xa = Transactor.fromDriverManager[IO](
  "com.mysql.jdbc.Driver",
  "jdbc:mysql://localhost:3306/doobie",
  "root",
  "root",
  Blocker.liftExecutionContext(ExecutionContexts.synchronous) // just for testing
)

Para la correcta ejecución del programa es necesario tener una base de datos levantada en la configuración que se especifica en el Transactor; en mi caso, he utilizado un contenedor Docker con una base de datos MySQL.

La definición de un programa está compuesta por la secuencia de funciones del DSL definidas en un for comprehension y, para su ejecución, se utiliza  la función foldMap con el intérprete definido. Al utilizar la mónada estado, es necesario arrancar la ejecución con un estado.

En los siguientes apartados, se describen ejemplos de las declaraciones de programas del DSL definido

1.- Ejemplo de programa de creación de un esquema.

def createDatabase(): Operation[Either[Exception, Boolean]] = for {
  result <- createSchema()
} yield (result)
val resultCreate = createDatabase().foldMap(pureInterpreter(xa)).run(Init).value
println(s"Create database=${resultCreate}")
println

La salida por consola es la siguiente:

Create database=(Created,Right(true))

2.- Ejemplo de programa de inserción de un Autor en base de datos.

def insertAuthor(): Operation[Either[Exception, Int]] = for {
  num <- insert(Author(0, "Author1"))
} yield (num)
val resultInsertAuthor = insertAuthor().foldMap(pureInterpreter(xa)).run(Created).value
println(s"Insert Author=${resultInsertAuthor}")
Println

La salida por consola es la siguiente:

Insert Author=(Created,Right(1))

3.- Ejemplo de programa de eliminación de un Autor en base de datos.

def deleteAuthor(): Operation[Either[Exception, Int]] = for {
  numInsert10 <- insert(Author(0, "Author10"))
  numInsert11 <- insert(Author(0, "Author11"))
  numInsert12 <- insert(Author(0, "Author12"))
  numDeleted <- delete(2)
} yield (numDeleted)
val resultDeleteAuthor = deleteAuthor().foldMap(pureInterpreter(xa)).run(Created).value
println(s"Delete Author=${resultDeleteAuthor}")
println

La salida por consola es la siguiente:

Delete Author=(Created,Right(1))

4.- Ejemplo de programa de consulta de un autor por clave.

def selectAuthorOK(): Operation[Either[Exception, Option[String]]] = for {
  author <- select(1)
} yield (author)
val resultSelectAuthorOK = selectAuthorOK.foldMap(pureInterpreter(xa)).run(Created).value
println(s"Select Author=${resultSelectAuthorOK}")
println

La salida por consola es la siguiente:

Select Author=(Created,Right(Some(Author1)))

Para el lector interesado puede acceder al código de la entrada en el siguiente enlace.

Ciris

En toda aplicación, es común realizar la carga de configuración desde variables de entorno.En el ecosistema de Scala, la tarea de carga de estos valores los podemos realizar con la solución Ciris. Ciris es una librería funcional que realiza esta funcionalidad. En la presente entrada, Ciris, realizaré una breve descripción de esta librería sencilla.

Definición de dependencias

Ciris está compuesta por un conjunta de paquetes que utilizan otros módulos, como pueden ser: Circe, Refined o Squants; pero, para poder trabajar correctamente, es necesario añadir el paquete refined-cats el cuál no se referencia en la documentación.

La definición de las dependencias necesarias para trabajar con Ciris son las siguientes:

lazy val ciris_ciris = "is.cir" %% "ciris" % "1.2.1"
lazy val ciris_circe = "is.cir" %% "ciris-circe" % "1.2.1"
lazy val ciris_enumeratum = "is.cir" %% "ciris-enumeratum" % "1.2.1"
lazy val ciris_refined = "is.cir" %% "ciris-refined" % "1.2.1"
lazy val ciris_squants = "is.cir" %% "ciris-squants" % "1.2.1"
lazy val ciris_refined_cats = "eu.timepit" %% "refined-cats" % "0.9.18"

Para cargar las dependencias definidas anteriormente en el proyecto, modificamos el fichero build.sbt para realizar la carga del módulo y realizar los ejemplos básicos. El código resultante del fichero de configuración sbt es el siguiente:

import Dependencies._
[...]
lazy val ciris = (project in file("ciris"))
  .settings(
    name := "example-ciris",
    assemblySettings,
    scalacOptions ++= basicScalacOptions,
    libraryDependencies ++=
    cirisDependencies ++ Seq(
      scalaTest
    )
  )
lazy val cirisDependencies = Seq(
  ciris_ciris
  ,ciris_circe
  ,ciris_enumeratum
  ,ciris_refined
  ,ciris_squants
  ,ciris_refined_cats
)

Casos de uso de ejemplo

En el presente apartado, realizaré la presentación de unos ejemplos de prueba de la librería Ciris.

  • Carga de una variable de entorno de tipo entera

Sea la variable de entorno API_PORT=8080 y el siguiente snippet de código el cual realiza lo siguiente: lectura de la varibla API_PORT como entero creando un objeto port de tipo ConfigValue[Int]; el objeto port, es cargado como un tipo IO de cats-effect y la función unsafeRunSync resuelve el valor del tipo IO obteniendo el valor resultado.

def exampleLoadIntENV(): Unit = {
  val port: ConfigValue[Int] = env("API_PORT").or( prop("api.port") ).as[Int]
  val portResult: Int = port.load[IO].unsafeRunSync()
  println(s"Port=${portResult}")
  println()
}

El resultado por pantalla es el siguiente:

Port=8080
  • Carga de variables de entorno en una clase.

Sean las variables de entorno API_PORT=8080 y API_TIMEOUT=100 millis y el siguiente snippet de código el cual realiza lo siguiente: lectura de la varibla API_PORT como entero creando un objeto de tipo ConfigValue[Int]; lectura de la variable API_TIMEOUT de tipo Duration de tipo ConfigValue[Duration]; definición de la clase Config con un campo de tipo entero y otro de tipo Duration; parseo de los dos objetos anteiores para carga los valores de tipo ConfigValue[A] a la clase Config; y, para finalizar, carga del objeto de tipo ConfigValue[Config] como un tipo IO de cats-effect y la función unsafeRunSync resuelve el valor del tipo IO obteniendo el valor resultado.

def exampleLoadPairEnvVar(): Unit = {
  val port: ConfigValue[Int] = env("API_PORT").or( prop("api.port") ).as[Int]
  val timeout: ConfigValue[Option[Duration]] = env("API_TIMEOUT").as[Duration].option
  final case class Config(port: Int, tiemout: Option[Duration])
  val config: ConfigValue[Config] = (port, timeout).parMapN(Config)
  val resultConfig: Config = config.load[IO].unsafeRunSync()
  println(s"Result Config->${resultConfig}")
  println()
}

El siguiente snippet de código es idéntico al anterior pero se utiliza for comprehension.

def exampleLoadWithForCom(): Unit = {
  final case class Config(port: Int, tiemout: Option[Duration])
  val config = for{
    eport <- env("API_PORT").or( prop("api.port") ).as[Int]
    etimeout <- env("API_TIMEOUT").as[Duration].option
  } yield{
    Config(eport, etimeout)
  }
  val result: Config = config.load[IO].unsafeRunSync()
  println(s"Result Config->${result}")
  println()
}

La salida por consola es la siguiente:

Result Config->Config(8080,Some(100 milliseconds))
  • Carga de variable de entorno y valor por defecto

Sean las variables de entorno API_PORT=8080 y API_TIMEOUT=100 millis. Los siguientes snippet de código son idénticos a los anteriores salvo que se utiliza la función default para determinar el valor por defecto: en el primer caso, con un valor de tipo Duration; y, en el segundo, con una clase Config.

def exampleDefaultValue1(): Unit = {
  val timeDefault: ConfigValue[Duration] = env("API_TIME_DEEFAULT").as[Duration].default(10.seconds)
  val result: Duration = timeDefault.load[IO].unsafeRunSync()
  println(s"Result default 1=${result}")
  println()
}
def exampleDefaultValue2(): Unit = {
  final case class Config(port: Int, tiemout: Option[Duration])
  val config = (
    env("API_PORT").or( prop("api.port") ).as[Int],
    env("API_TIMEOUT").as[Duration].option
  ).parMapN(Config).default{
    Config(8082, 20.seconds.some)
  }
  val result: Config = config.load[IO].unsafeRunSync()
  println(s"Result default 2=${result}")
  println()
}

La salida por consola es la siguiente:

Result default 1=10 seconds
Result default 2=Config(8080,Some(100 milliseconds))
  • Carga de variables de entorno con un secreto

Sea la variable de entorno API_KEY=keyRR01234567890123456789. El siguiente snippet realiza la carga de una variable de entorno que representa un secreto; en este caso, se emplea la función secret la cual retorno un objeto de tipo Secret[String]

def exampleSecrets(): Unit = {
  val apiKey: ConfigValue[Secret[String]] = env("API_KEY").secret
  val resultSecret: Secret[String] = apiKey.load[IO].unsafeRunSync()
  println(s"secret=${resultSecret.value}")
  println()
}

La salida por consola es la siguiente:

secret=keyRR01234567890123456789

Para el lector interesado puede acceder al código a través del siguiente enlace.

Scala 3. Dotty II: tipo unión

En la presente entrada, Scala 3. Dotty II: tipo unión, describiré el tipo Unión. El tipo Unión es parecido al tipo intersección descrito en la entrada anterior. El tipo Unión permite que una determinada instancia sea de un tipo determinado o bien de otro. El tipo unión se representa por el símbolo | y cumple la propiedad conmutativa.

En el siguiente ejemplo, se muestra una función con un argumento de tipo unión.

trait TypeA{
  val elemA: String
}
trait TypeB{
  val elemB: String
}
case class ClassTypeA(elemA: String) extends TypeA
case class ClassTypeB(elemB: String) extends TypeB

def printPretty(arg: ClassTypeA | ClassTypeB): Unit = {
  val value = arg match{
    case ClassTypeA(eA) => eA
    case ClassTypeB(eB) => eB
  }
  println(s" Value argument=$value")
}
object Main{
  def main(args: Array[String]): Unit = {
    val a = ClassTypeA("aa")
    val b = ClassTypeB("bb")
    printPretty(a)
    printPretty(b)
  }
}

El código define lo siguiente: se define dos case class de tipo TypeA y TypeB implementadas en las clases ClassTypeA y ClassTypeB; se define una función printPretty cuyo parámetro puede ser del tipo ClassTypeA o bien ClassTypeB; y, para finalizar, se define un objeto Main cuya función main realiza dos llamadas a la función printPretty con dos parámetros con los posibles tipos definidos.

La salida por consola del código es la siguiente:

Value argument=aa
Value argument=bb

Lo más destacado del código anterior es la función printPretty. La función recibe un argumento cuyo tipo puede ser de los tipos definidos ClassTypeA, o bien, ClassTypeB, en función del tipo de entrada, la función escribirá por consola diferentes valores.

En la siguiente entrada, Dotty III: enumeraciones, describiré el tipo enumeración.

AWS Lambda en Scala. Operaciones con AWS S3

Las tres grandes soluciones utilizadas en el mundo empresarial para definir sistemas cloud son Amazon AWS, Microsoft Azure y Google Cloud. Las tres soluciones permiten la posibilidad de desarrollar arquitecturas serverless la cual se implementan con funciones lambda. En la presente entrada, AWS Lambda en Scala. Operaciones con AWS S3, describiré cómo definir una función lambda en Amazon AWS.

 

 

 

 

 

Definimos arquitectura Serverless como aquella arquitectura que define sistemas con aplicaciones y servicios, con capacidad de ejecución, así como, la posibilidad de crear nuevas aplicaciones y servicios, sin necesidad de administrar infraestructura.

Definimos una función Lambda de AWS como “un un servicio informático que permite ejecutar código sin aprovisionar ni administrar servidores. AWS Lambda ejecuta el código sólo cuando es necesario, y se escala de manera automática, pasando de pocas solicitudes al día a miles por segundo”.

Las funciones Lambda pueden ser definidas en diferentes lenguajes como pueden ser: Java, Python, Node, Scala,… en las diferentes plataformas. Dada la diversidad de plataformas y lenguajes, las soluciones son amplias y diversas. Para unificar funcionalidad ante las plataformas y lenguajes existen frameworks que ofrecen operaciones para simplificar la tarea al desarrollador. Un ejemplo de este tipo de tecnología es el framework Serverless.

El framework Serverless es una herramienta Open Source la cual permite el desarrollo y despliegue de aplicaciones serverless en AWS, Azure, Google y otras más.

Instalación en entorno Linux/Mac

La instalación del framework en un entorno Linux o Mac es muy sencilla, simplemente es necesario ejecutar el siguiente comando desde la línea de comando:

curl -o- -L https://slss.io/install | bash

Para la verificación de la instalación, se ejecuta el siguiente comando:

serverless -h

El resultado del comando anterior deberá de mostrar la información de los comandos del framework.

Descripción funcional de la función de ejemplo

Definiremos una función que opere sobre la solución cloud de Amazon. Desde un punto de vista funcional, la función es sencilla, realizará ciertas operaciones con el servicio S3 de AWS descritas en el siguiente listado:

  • Listado de los bucket existentes.
  • Creación de un bucket en S3.
  • Subida de un fichero a S3.
  • Descarga de un fichero a S3.

Creación de la función con Serverless

Para realizar la creación de una función, utilizaremos el comando create del framework Serverless; para ello, en la consola del sistema, crearemos una carpeta (por ejemplo: serverless-scala-aws-s3) y ejecutaremos el comando create de serverless. El snippet copn los comandos son los siguientes:

cd serverless-scala-aws-s3
serverless create --template aws-scala-sbt --path lambda-s3

El comando create emplea la plantilla para un proyecto en Scala con sbt y define el path a la función. Además de la plantilla del lenguaje Scala, se pueden definir funciones en otros lenguajes como Python, Java, kotlin, Go,…

La vista de la estructura creada desde un IDE es el siguiente:

Los componentes del proyecto son los siguientes:

  • build.sbt Fichero sbt para la gestión del ciclo de vida del código de la función. Al tener que operar con S3 se debe de definir la dependencia de la librería AWScala en la referencia libraryDependencies. Las librerías utilizadas en este proyecto son las siguientes:
libraryDependencies ++= Seq(
  "com.amazonaws" % "aws-lambda-java-events" % "2.2.7",
  "com.amazonaws" % "aws-lambda-java-core" % "1.2.0",
  "com.amazonaws" % "aws-lambda-java-log4j2" % "1.1.0",
  "com.github.seratch" %% "awscala" % "0.8.+"
)
  • Componentes de Scala. La plantilla del framework crea automáticamente cuatro componentes, siendo el más importante el Handler de la función.
    • Handler.- El componente handler define dos clases: Handler, para la función lambda a desarrollar; y, ApiGatewayHandler, para definir la clase para el servicio API Gateway; en nuestro caso, nos centraremos en la clase Handler.La clase Handler define un método handleRequest en el cual desarrollaremos la funcionalidad del ejemplo.
import scala.jdk.CollectionConverters._
class Handler extends RequestHandler[Request, Response] {
  val logger: Logger = LogManager.getLogger(getClass)
  def handleRequest(input: Request, context: Context): Response = {
    implicit val region = Region.US_EAST_1
    implicit val s3 = S3()
    val buckets: Seq[Bucket] = s3.buckets
    logger.info(s"\n1 buckets: $buckets \n")
    val bucket: Bucket = s3.createBucket("prueba2fromlambdafunction")
    logger.info(s"\n2 bucket: $bucket \n")
    // Upload operation of the file example1-file.txt with name example1-uploaded-file.txt
    bucket.put("example1-uploaded-file.txt", new java.io.File("example1-file.txt"))
    val s3obj: Option[S3Object] = bucket.getObject("example1-uploaded-file.txt")
    logger.info(s"\n3 Uploaded: ${s3obj.getOrElse("Empty")} \n")
    logger.info(s"Received a request: $input")
    Response("Go Serverless v1.0!!!!! Your function executed successfully!!", input)
  }
}
    • Request.- Define la clase Request con los parámetros del evento de entrada.
import scala.beans.BeanProperty
class Request(@BeanProperty var key1: String, @BeanProperty var key2: String, @BeanProperty var key3: String) {
  def this() = this("", "", "")
  override def toString: String = s"Request($key1, $key2, $key3)"
}
    • Response.- Define la clase respuesta del tipo de retorno del Handler.
import scala.beans.BeanProperty
case class Response(@BeanProperty message: String, @BeanProperty request: Request)
    • ApiGatewayResponse.- Define la clase de respuesta para el caso de APIGateway.
case class ApiGatewayResponse(@BeanProperty statusCode: Integer, @BeanProperty body: String,
@BeanProperty headers: java.util.Map[String, String], @BeanProperty base64Encoded: Boolean = false)
  • Serverless.yml. El fichero serverless.yml es aquel lugar donde se configura la función para que sea desplegada en AWS. El fichero está compuesto por varias secciones en donde se define las variables, la función, o bien, aquellos recursos necesarios de AWS. Este fichero es el que empleará el framework Serverless para definir la plantilla de CloudFormation para su despliegue en AWS. La secciones son:
    • Service.- Definición del nombre del servicio de la función en AWS.
    • Provider.- definición de las variables internas a AWS.
    • Custom.- Definición de las variables específicas para la función como por ejemplo: nombre del proyecto, región,… proporcionada por los valores definidos en Provider, o bien, desde la línea de comando.
    • Environment.- Definición de las variables de entorno globales.
    • Package.- configuración del paquete a crear para realizar la subida a AWS. Se puede definir qué ficheros incluir o excluir, o bien, el nombre del jar con el que se trabaja.
    • Functions.- definición de la función Scala, definición de la referencia del rol, variables de entorno,…
    • Resources.- definición de los recursos empleados por la función en AWS; en nuestro caso, definición del role y las políticas de seguridad.

El contenido del fichero es el siguiente:

service: lambda-s3
provider:
  name: aws
  project: scalaproject
  runtime: java8
  stage: ${opt:stage, 'dev'}
  region: us-east-1
  timeout: 900
  iamRoleStatements:
    - Effect: Allow
      Action:
        - s3:GetObject
        - s3:PutObject
      Resource:
        - "arn:aws:s3:::prueba2fromlambdafunction/*"
custom:
  currentStage: ${opt:stage, self:provider.stage}
  currentProject: ${self:provider.project}
  currentRegion: ${opt:region, self:provider.region}
environment:

package:
  individually: true
  artifact: target/scala-2.13/lambda-s3.jar

functions:
  lambda-s3:
    handler: app.Handler
    role: LambdaRole
    environment:
      ENV: ${self:custom.currentStage}
resources:
  Resources:
    LambdaRole:
      Type: AWS::IAM::Role
      Properties:
        RoleName: ${self:custom.currentProject}-lambda-s3-${self:custom.currentStage}
          AssumeRolePolicyDocument:
          Statement:
            - Effect: Allow
              Principal:
                Service:
                  - lambda.amazonaws.com
              Action: sts:AssumeRole
        Policies:
          - PolicyName: ${self:custom.currentProject}-lambda-s3-${self:custom.currentStage}
            PolicyDocument:
              Statement:
                - Effect: Allow
                  Action:
                    - logs:CreateLogGroup
                    - logs:CreateLogStream
                    - logs:PutLogEvents
                    - s3:*
                  # - ec2:DescribeNetworkInterfaces
                  # - ec2:CreateNetworkInterface
                  # - ec2:DeleteNetworkInterface
                  # - ec2:DescribeInstances
                  # - ec2:AttachNetworkInterface
                 Resource: "*"

De snippet anterior resaltar las líneas comentadas en la definición de los permisos; éstas líneas, corresponden a los permisos que se deben de añadir si se desea que la función Lambda se ejecute en una subred de una VPC determinada.

Ciclo de vida

Configuración del profile de AWS. Para trabajar con AWS es necesario instalar el cliente de AWS y definir las credenciales del usuario para poder realizar las operaciones de despliegue en la cuenta de Amazon.

  • Creación del artefacto. Para realizar el despliegue, es necesario construir el artefacto con los componentes Scala y su ensamblado con las librerías necesarias. El comando SBT a ejecutar en la carpeta de la función es el siguiente:
sbt assembly
  • Despliegue de la función en Amazon AWS. El proceso de despliegue consiste en crear o modificar los recursos en AWS o el código de la función utilizando el stack de cloudformation asociado al fichero serverless.yml. El comando a ejecutar en la carpeta de la función es el siguiente:
serverless deploy -r us-east-1
  • Eliminación de la función. Si se desea eliminar la función se puede eliminar la función y sus recursos asociados con el siguiente:
serverless remove

Librería AWScala

La librería AWScala es aquella librería que permite realizar las operaciones con S3 u otros servicios de AWS. En nuestro caso, nos centraremos en definir las operaciones en S3.

  • Instancia del cliente S3. La creación de un cliente para realizar operaciones con S3 se realiza creando un componente de tipo S3. Dado que la función tiene asociado un role con los permisos de acceso, no es necesario asignar las credenciales. El snippet de ejemplo es el siguiente:
import awscala._, s3._
import awscala.s3._
import awscala.Region
implicit val region = Region.US_EAST_1
implicit val s3 = S3()
  • Listado de los buckets existentes. Una vez creado el cliente, se realiza la conexión al servicio S3 y, con la función buckets, obtenemos una lista con los bucket existentes. El snippet de ejemplo es el siguiente:
val buckets: Seq[Bucket] = s3.buckets
  • Creación de un bucket. De la misma manera que el caso anterior, el cliente S3 tiene una función de creación de bucket cuyo nombre es createBucket al cual se le pasa un nombre único del bucket a crear. El snippet de ejemplo es el siguiente:
val bucket: Bucket = s3.createBucket("prueba2fromlambdafunction")
  • Subir un fichero a S3. Para subir un fichero a S3, el cliente S3 emplea la función put al cual, como primer parámetro, se le pasa el nombre que tendrá en el bucket; y, como segundo parámetro, se le pasa un objeto File con la referencia del fichero. En nuestro caso, existe un fichero de texto example1-file.txt en el proyecto. El snippet de ejemplo es el siguiente:
bucket.put("example1-uploaded-file.txt", new java.io.File("example1-file.txt"))
  • Descarga de un fichero de S3. Para descargar un fichero de S3, el cliente emplea la función getObject a la cual se le pasa como parámetro el nombre del elemento a descargar. El snippet de ejemplo es el siguiente:

val s3obj: Option[S3Object] = bucket.getObject(“example1-uploaded-file.txt”)

Ejecución

Una vez desplegada la función con el comando de serverless deploy, hay que entrar en la consola de AWS y navegaremos hasta la consola de funciones lambda;y,
una vez en la consola, tendremos la referencia a la función. Para las pruebas, crearemos un evento con unos datos de pruebas como los siguientes:

{
"key1": "value1",
"key2": "value2",
"key3": "value3"
}

Para ejecutar la función, pulsaremos el botón de Test en la parte superior derecha; tras la ejecución, se reportará el resultado de la función y se crearán en el cloudwatch las trazas de la función. El aspecto de la consola de AWS con la información de la función es el siguiente:

El resultado de la función en S3 es la creación de un fichero en el bucket prueba2fromlambdafunction. La vista de la consola S3 tras la ejecución de la función es la siguiente:

 

Si el lector está interesado en el código puede acceder al siguiente repositorio de GitHub.

Conclusiones

La selección del lenguaje con el que se opera con AWS depende del equipo de desarrollo ya que, en función del conocimiento de los posibles lenguajes, se seleccionará uno u otro. Desde mi experiencia en los equipos en lod que he trabajado, siempre se ha elegido el lenguaje Python por su sencillez de uso utilizando la librería boto3. Con el presente ejemplo, quiero poner de manifiesto la sencillez con el lenguaje Scala y, dado que estamos construyendo funciones lambda sin infraestructura, utilizar un lenguaje con paradigma funcional permite construir componentes software orientados a la funcionalidad a desarrollar.

Scala 3. Dotty I: Tipos intersección

Inicio una serie de entradas sobre las nuevas características del compilador Dotty el cual representará la versión 3 de Scala que será lanzado en los próximos meses.

Para la realización de los ejemplo, utilizaré el editor de código Scatie. Si el lector está interesado en la descripción del editor, puede acceder al siguiente enlace.

En la presente entrada, me centraré en el operador de intersección de tipos. El operador se representa con el carácter &. La intersección de tipos permite determinar que una instancia puede ser de dos los tipos determinados, es decir, sean dos tipos definidos A y B y una instancia cuya definición de tipo es del tipo A & B, determina que dicha instancia es del tipo A y del tipo A. El operador & es conmutativo con los cual A & B es igual a B & A. A continuación, se muestra el siguiente ejemplo descriptivo:

trait TypeA{
  val elemA: String
}
trait TypeB{
  val elemB: String
}
case class ClassTypeA(elemA: String) extends TypeA
case class ClassTypeB(elemB: String) extends TypeB
case class IntersectionAB(elemA:String, elemB:String) extends TypeA with TypeB

def printPretty(arg: TypeA & TypeB): Unit = println("printPretty:" + arg.elemA + " & " + arg.elemB)
def printPretty2(arg: IntersectionAB): Unit = println("printPretty2:" + arg.elemA + " & " + arg.elemB)

object Main{
  def main(args: Array[String]): Unit = {
    val x = IntersectionAB("aa", "bb")
    printPretty(x)
    println(x)
    val x2 = new IntersectionAB("aa", "bb")
    printPretty(x2)
    println(x2)
    val x3 = new IntersectionAB("aa", "bb")
    printPretty2(x3)
    println(x3)
  }
}

En el ejemplo anterior, se definen dos tipos definidos en los trait TypeA y TypeB; se definen dos case clases de los tipos anteriores cuyos nombres respectivos son ClassTypeA y ClassTypeB; se define una case class IntersectionAB que implementa los tipos anteriores; se define una función printPretty cuyo parámetro es un tipo intersección de los tipos TypeA y TypeB; se define una función printPretty2 cuyo parámetro es del tipo IntersectionAB; y, para finalizar, se define un objeto Main con la función main en donde se instancia objetos intersección y se pasan a las dos funciones de impresión. La funcionalidad de las funciones pretty son sencillas, solo imprimen por consola los tipos pasados por parámetro.

La salida por consola del código es la siguiente:

printPretty:aa & bb
IntersectionAB(aa,bb)
printPretty:aa & bb
IntersectionAB(aa,bb)
printPretty2:aa & bb
IntersectionAB(aa,bb)

Lo más destacado del ejemplo es la función printPretty la cual define un argumento cuyo tipo debe de ser del tipo TypeA y TypeB. Si a la función no se le pasa un objeto con dicha condición, el código no compila.

En la siguiente entrada, Scala 3. Dotty II: uniones de tipo, describeré el tipo unión.

Scastie

Scastie  es un editor de código para trabajar con Scala. Scastie puede ser configurado  para poder operar con las diferentes versiones de Scala (2.12.12 y 2.13.3); puede ser configurado con el nuevo compilador de Scala Dotty; puede ser configurado para trsabajar con TypeLevel; o bien, puede ser configurado para utilizar Scala.js.

Scastie es una muy buena herramienta para realizar pequeños snippet de código para realizar pruebas sencillas sin necesidad de instalar un entorno de trabajo. Scastie tiene dos funciones:

  • Editor de código.- En la parte izquierda, existe la opción “Editor” el cual permite activar el editor de código. El aspecto del editor es el siguiente:

editor

  • Configuración.- En la parte izquierda, exista la opción “Build Settings” el cual permite activar la configuración del editor. El aspecto de la configuración es el siguiente:

settings

Scastie utiliza sbt para la gestión del ciclo de vida y permite la definición de las librerías necesarias como las opciones de configuración.

Analizando la imagen del editor de código en la parte superior, destacamos los siguientes botones de acciones:

  • Save.- Guarda y ejecuta el código.
  • New.- Abre un nuevo snippet de código.
  • Format.- Verificación del estilo del código.
  • Clear Messages.- Elimina los mensajes de error de compilación y error de formateo.
  • Download.- Descarga del código.

En la parte inferior del editor, se encuentra la salida de la consola. En el lateral izquierdo de Scastie, se dispone del botón “Help” el cual muestra la ayuda del editor; y, el botón “Light” el cual permite cambiar el fondo del editor con una opción de fondo oscura y otra de forma clara.

Scastie es una buena herramienta para desarrollar y probar pequeñas cantidades de código. Por otro lado, al permitir ejecutar código en las diferentes versiones de los compiladores, es una buena herramienta para tener un entorno de trabajo para aprender nuevas características, como por ejemplo Dotty, sin necesidad de instalar un entorno local.

Inyección de dependencias en programación funcional III. Mónada Reader

Llegamos a la la última entrada de la sería de inyección de dependencias con la entrada, Inyección de dependencias en programación funcional III. Mónada Reader. El objetivo de la misma es mostrar al lector cómo se realiza la inyección de dependencias con la mónada Reader en lenguaje Scala. Para el lector interesado, las entradas de la serie son las siguientes:

La diferencia conceptual respecto a las otras dos es el uso de la mónada Reader. La mónada Reader es aquella mónada la cual puede leer un determinado componente; en dicho  componente, es donde definimos los elementos con las referencias de las funciones a inyectar. Así, necesitamos definir un elemento, en nuestro caso una case class, con las referencias a las funciones las cuáles están definidas en los componentes. Por otro lado, el servicio de negocio lo definimos a partir de un trait con un constructor de tipos.

Desde un punto de vista gráfico, la vista estática de los componentes queda definida como sigue:

Los tipos utilizados son los siguientes:

import cats.data.Reader
import cats.syntax.either._
import scala.language.higherKinds
object typesEjem3{
  type MensajeError = String
  type GetComponent1 = (String) => Either[MensajeError, String]
  type GetComponent2 = (Int) => Either[MensajeError, Int]
  type ResponseService = Either[MensajeError, String]
  type ParameterString = String
  type ParameterInt = Int
  type ServiceOperation[A] = Reader[ServiceContext, A]
  case class ServiceContext( funcComponent1: GetComponent1, funcComponent2: GetComponent2 )
}

La definición de los componentes de negocio del ejemplo son los representados por el objeto Component1Ejem3 y Component2Ejem3. El snippet del código de los componentes es el siguiente:

object Component1Ejem3{
  import typesEjem3._
  val response1: MensajeError = "Error en Response1"
  val doSomething: GetComponent1 = (elem: String) => {
    elem.length match {
      case lengthElem: Int if lengthElem > 0 => (elem + " modificado").asRight
      case _ => response1.asLeft
    }
  }
}
object Component2Ejem3{
  import typesEjem3._
  val response2: MensajeError = "Error en Response2"
  val doSomething: GetComponent2 = (num: Int) => {
    num match {
      case elem: Int if elem > 0 => elem.asRight
      case _ => response2.asLeft
    }
  }
}

La definición del servicio de negocio se realiza con un type class empleando un trait Service3 y el objeto ServiceImpl. Para el lector interesado en conocer lo que es un Type Class en los siguientes enlaces describo cómo se define y describe dicho patrón. Los enlaces son los siguientes:

El snippet del código del servicio es el siguiente:

trait Service3[ F[_] ]{
  def doBusiness(msg: typesEjem3.ParameterString): F[ Either[typesEjem3.MensajeError, String] ]
}
object ServiceImpl extends Service3[typesEjem3.ServiceOperation]{
  override def doBusiness(msg: typesEjem3.ParameterString): typesEjem3.ServiceOperation[Either[typesEjem3.MensajeError, String]] = Reader{ ctx =>
    for{
      response1 <- ctx.funcComponent1(msg).right
      response2 <- ctx.funcComponent2(msg.length).right
    }yield{
      response1 + "-" + response2
    }
  }
}

Como se muestra en el snippet anterior la función doBusiness del objeto ServiceImpl define la funcionalidad del servicio y es donde se utiliza la mónada Reader. La Mónada Reader se define de la siguiente manera : Reader[ServiceContext, A]; siendo la entrada de tipo ServiceContext; y, como salida, el tipo A el cual en nuestro caso es de tipo Either. Analizando la función, el objeto de entrada es de tipo ServiceContext con las referencias a los componentes que se inyectan y, como resultado, se retorna un elemento de tipo Either.

La aplicación que usa los anteriores elementos es la siguiente:

object Ejem3DependencyInyector extends App{
  import typesEjem3._
  def ejemplo1(): Unit = {
    val context = ServiceContext(Component1Ejem3.doSomething, Component2Ejem3.doSomething)
    val message1 = "Mensaje de prueba"
    ServiceImpl.doBusiness(message1).run(context) match {
      case Right(msg) => println(s"Test1=${msg}")
      case Left(error) => println(error)
    }
    println
  }
  ejemplo1()
}

En la aplicación anterior, se muestra cómo usar un servicio con una mónada Reader: lo primero, es definir una clase ServiceContext con las funciones de los componentes; segunda, crear e invocar la clase con la mónada usando la función run; y, para finalizar, tratar el resultado con un pattern matching.

La salida por consola es la siguiente:

Test1=Mensaje de prueba modificado-17

La definición de los test del servicio de negocio descrito en el ejemplo es el siguiente:

import cats.syntax.all._
import es.ams.dependencyinyector.typesEjem3.{ GetComponent1, GetComponent2, ServiceContext} //
import org.scalatest.{Matchers, WordSpec}
class Ejem3DependecyInyectorTest extends WordSpec with Matchers {
  "Example Mock" should {
    "Example OK" in {
      val context = ServiceContext(Component1Ejem3.doSomething, Component2Ejem3.doSomething)
      val msg: String = "prueba"
      val result: String = ServiceImpl.doBusiness(msg).run(context) match {
        case Right(msg) => { println(msg); msg}
        case Left(error) => error
      }
      result shouldBe(msg + " modificado-6")
    }
    "Example OK: mock component1" in {
      val funcGetResponse1Mock: GetComponent1 = (num: String) => "mock".asRight
      val context = ServiceContext(funcGetResponse1Mock, Component2Ejem3.doSomething)
      val msg: String = "prueba"
      val result: String = ServiceImpl.doBusiness(msg).run(context) match {
        case Right(msg) => { println(msg); msg}
        case Left(error) => error
      }
      assert(result.length > 0)
      assert(result.equals("mock-6"))
    }
    "Example OK: mock component2" in {
      val funcComponent2: GetComponent2 = (num: Int) => 0.asRight
      val context = ServiceContext(Component1Ejem3.doSomething,funcComponent2)
      val msg: String = "prueba"
      val result: String = ServiceImpl.doBusiness(msg).run(context) match {
        case Right(msg) => { println(msg); msg}
        case Left(error) => error
      }
      assert(result.length > 0)
    }
    "Example OK: mock component1 and mock component2" in {
      val funcGetResponse1Mock: GetComponent1 = (num: String) => "mock".asRight
      val funcGetResponse2Mock: GetComponent2 = (num: Int) => 0.asRight
      val context = ServiceContext(funcGetResponse1Mock, funcGetResponse2Mock)
      val msg: String = "prueba"
      val result: String = ServiceImpl.doBusiness(msg).run(context) match {
        case Right(msg) => { println(msg); msg}
        case Left(error) => error
      }
      assert(result.length > 0)
      assert(result.equals("mock-0"))
    }
  }
}

La inyección de dependencias desde un punto de vista funcional sigue la misma filosofía que la inyección de dependencias de objetos. La primera consecuencia es la desaparición de la utilización de framework de Mock necesarios en otros paradigmas como el utilizado en los lenguajes Java o Python. La utilización del paradigma funcional permite la composición de elementos más intuitiva aunque, evidentemente, la curva de aprendizaje es mayor.

Inyección de dependencias en programación funcional II

En la entrada anterior, Inyección de dependencias en programación funcional I, realicé la descripción de cómo se realizaba la inyección de funciones en programación funcional en lenguaje Scala; en la presente entrada, Inyección de dependencias en programación funcional II, modularizaré el código existente en la primera entrada organizando el código con una perspectiva orientada a objetos sin perder el aspecto funcional.

La vista estática del problema es la definida en el diagrama de clases de la siguiente imagen:

 

Los tipos utilizados en el ejemplo son los siguientes:

import cats.syntax.either._
object typesEjem2{
  type MensajeError = String
  type GetComponent1 = (String) => Either[MensajeError, String]
  type GetComponent2 = (Int) => Either[MensajeError, Int]
  type ResponseService = Either[MensajeError, String]
  type ParameterString = String
  type ParameterInt = Int
  type BusinessService = (GetComponent1, GetComponent2) => ParameterString => ResponseService
}

La definición de los componentes de negocio del ejemplo son los representados por los objetos Component1 y Component2. Respecto al ejemplo de la entrada anterior, se han definido las funciones dentro de un objeto con lo cual modularizamos la funcionalidad. El snippet del código de los componentes es el siguiente:

object Component1{
  import typesEjem2._
  val response1: MensajeError = "Error en Response1"
  val doSomething: GetComponent1 = (elem: String) => {
    elem.length match {
      case lengthElem: Int if lengthElem > 0 => (elem + " modificado").asRight
      case _ => response1.asLeft
    }
  }
}
object Component2{
  import typesEjem2._
  val response2: MensajeError = "Error en Response2"
  val doSomething: GetComponent2 = (num: Int) => {
    num match {
      case elem: Int if elem > 0 => elem.asRight
      case _ => response2.asLeft
    }
  }
}

La definición del servicio de negocio del ejemplo es el definido por el objeto Service. La estrategia de modularización es la misma que con los componentes. El snippet del código del servicio es el siguiente:

object Service{
  import typesEjem2._
  val doBusinessActivity: BusinessService = (objComp1, objComp2) => (msg) => {
    for {
      respon1 <- objComp1 (msg)
      respon2 <- objComp2(msg.length)
    } yield {
      respon1 + "-" + respon2
    }
  }
}

La aplicación de ejemplo que usa los anteriores elementos es la siguiente:

object Ejem2DependencyInyectorApp extends App {
  def ejemplo1(): Unit = {
    val message1 = "Mensaje de prueba"
    Service.doBusinessActivity(Component1.doSomething, Component2.doSomething)(message1) match {
      case Right(msg) => println(s"Test1=${msg}")
      case Left(error) => println(error)
    }
    val message2 = ""
    Service.doBusinessActivity(Component1.doSomething, Component2.doSomething)(message2) match {
      case Right(msg) => println(s"Test2=${msg}")
      case Left(error) => println(error)
    }
  }
  ejemplo1()
}

La salida por consola es la siguiente:

Test1=Mensaje de prueba modificado-17
Error en Response1

La definición de los test del servicio de negocio descrito en el ejemplo es el siguiente:

import org.scalatest.{Matchers, WordSpec}
import es.ams.dependencyinyector.typesEjem2.{GetComponent1, GetComponent2}
import cats.syntax.all._
class Ejem2DependecyInyectorTest extends WordSpec with Matchers {
  "Example Mock" should {
    "Example OK" in {
      val msg: String = "prueba"
      val result: String = Service.doBusinessActivity(Component1.doSomething, Component2.doSomething)(msg) match {
        case Right(msg) => { println(msg); msg}
        case Left(error) => error
      }
      result shouldBe(msg + " modificado-6")
    }
  "Example OK: mock component1" in {
    val funcGetResponse1Mock: GetComponent1 = (num: String) => "mock".asRight
    val msg: String = "prueba"
    val result: String = Service.doBusinessActivity(funcGetResponse1Mock, Component2.doSomething)(msg) match {
      case Right(msg) => { println(msg); msg}
      case Left(error) => error
    }
    assert(result.length > 0)
    assert(result.equals("mock-6"))
  }
  "Example OK: mock component2" in {
    val funcComponent2: GetComponent2 = (num: Int) => 0.asRight
    val msg: String = "prueba"
    val result: String = Service.doBusinessActivity(Component1.doSomething, funcComponent2)(msg) match {
      case Right(msg) => { println(msg); msg}
      case Left(error) => error
    }
    assert(result.length > 0)
  }
  "Example OK: mock component1 and mock component2" in {
    val funcGetResponse1Mock: GetComponent1 = (num: String) => "mock".asRight
    val funcGetResponse2Mock: GetComponent2 = (num: Int) => 0.asRight
    val msg: String = "prueba"
    val result: String =Service.doBusinessActivity(funcGetResponse1Mock, funcGetResponse2Mock)(msg) match {
      case Right(msg) => { println(msg); msg}
      case Left(error) => error
    }
    assert(result.length > 0)
    assert(result.equals("mock-0"))
    }
  }
}

En esta entrada he realizado la modularización del código definido en la entrada, Inyección de dependencias en programación funcional I; en la siguiente entrada, subiré el nivel de abstracción y describiré el mismo problema utilizando la mónada Reader.

Scala Future con Ejemplos, continuación

En la entrada anterior, “Scala Future con Ejemplos”, realicé una descripción de cómo utilizar la entidad Future en Scala con ejemplos. En la presente entrada, “Scala Future con Ejemplos, continuación”, realizaré una ampliación de Future y, además, describiré ejemplos de utilización de Future con Actores.

El modelo de actores, segun wikepedia, es un modelo matemático de computación simultánea que trata a los actores como los primitivos universales de la computación concurrete. La implementación que utilizaremos es la que proporciona Akka y voy a suponer que el lector tiene unos conocimientos mínimos del modelo de actores y de Akka. La definición de dependencia de la librería Akka en sbt es la siguiente:

libraryDependencies += "com.typesafe.akka" %% "akka-actor" % akkaVersion,

Para la realización de los siguientes ejemplos, es necesario definir un actor con una mínima funcionalidad. La funcionalidad es la siguiente: si el actor recibe un mensaje de tipo String (msg), el actor responde con la concatenación del contenido de msg con el texto “Recibido en Actor”; si el actor recibe cualquier otro mensaje, el actor responde con el mensaje “Hola Mundo.” La implementación del actor es la siguiente:

import akka.actor.{Actor, Props}
import scala.concurrent.Future
object ActorEjemplo {
  def props() = Props(new ActorEjemplo())
}
class ActorEjemplo extends Actor {
  import context.dispatcher
  def receive = {
    case msg:String =>{
      val respuesta = msg + " Recibido en Actor"
      println(respuesta)
      sender() ! respuesta
    }
    case _ => {
      val respuesta = "Hola Mundo"
      println(respuesta)
      sender() ! respuesta
    }
  }
}

La lista de ejemplos que se muestran son los siguientes:

  • Ejemplo 1: ejemplo de Futures con tratamiento funcional
  • Ejemplo 2: ejemplo de Futures con tratamiento funcional
  • Ejemplo 3: ejemplo de Futures con tratamiento funcional.
  • Ejemplo 4: ejecución de un Actor con tiempo de espera.
  • Ejemplo 5: ejecución de un Actor sin tiempo de espera.
  • Ejemplo 6: composición de Futures.
  • Ejemplo 7: composición de Furures con for comprehension.
  • Ejemplo 8: conversión de List[Future[A]] -> Future[List[A]]
  • Ejemplo 9: conversión de Future[List[A]] -> List[Future[A]]
  • Ejemplo 10: morfismos con Future, función fold.
  • Ejemplo 11: morfismos con Future, función reduce
  • Ejemplo 12: el primero que termine, se ejecuta; función firstCompletedOf

Ejemplo 1: ejemplo de Futures con tratamiento funcional

Sea un Future future1 cuyo resultado sea el texto “Hello world!”; sea el Future future2 cuyo resultado es el valor entero 3; y, por último, sea el Future future3 que define una secuencia de operaciones con futuro1 y future2 para realizar un cálculo numérico a partir de la ejecución secuencial de future1 y future2.

El snippet del código con las ejecución de las tres futuros  la solución es la siguiente:

def ejemplo(): Unit = {
  val future1 = Future {
    "Hello world!"
  }
  val future2 = Future.successful(3)
  val future3 = future1 map { elemf1 =>
    future2 map { elemf2 =>
      elemf1.length * elemf2
    }
  }
  future3 onComplete {
    case Success(resultado) => println(s"resultado ejemplo3=${resultado}")
    case Failure(error) => println(s"error ejemplo3=${error}")
  }
}

La salida por consola de la ejecución del código anterior es la siguiente:

resultado ejemplo3=Success(36)

Ejemplo 2: ejemplo de Futures con tratamiento funcional

El siguiente ejemplo es el mismo que el caso anterior pero empleando la función foreach.

def ejemplo(): Unit = {
  val future1 = Future {
    "Hello world!"
  }
  val future2 = Future.successful(3)
  val future3 = future1 flatMap { elemf1 =>
    future2 map { elemf2 =>
      elemf1.length * elemf2
    }
  }
  future3 foreach { elem => println(s"Resultado ejemplo4=${elem}") }
}

La salida por consola de la ejecución del código anterior es la siguiente:

Resultado ejemplo4=36

Ejemplo 3: ejemplo de Futures con tratamiento funcional

Sean tres Futures cuyo resultado individual son tres operaciones matemáticas simples y, el último Future, define un filtro. El resultado será la multiplicación del segundo por el tercero.

El snippet del código con la solución es la siguiente:

def ejemplo5(): Unit = {
  val resultado = for {
    a <- Future(10 / 2)
    b <- Future(a + 1)
    c <- Future(a - 1)
    if c > 3
  } yield {
    b * c
  }
  resultado foreach { elem => println(s"Resultado ejemplo5=${elem}") }
}

La salida por consola de la ejecución del código anterior es la siguiente:

Resultado ejemplo5=24

Ejemplo 4: ejecución de un Actor con tiempo de espera

El ejemplo siguiente realizará la creación de un actor, envío de un mensaje y el tratamiento de la respuesta del actor con un tiempo de espera; para finalizar, se realizará la eliminación del actor del ejemplo enviándole el mensaje “PoisonPill”. La definición del actor es la definida al principio de la entrada y el sistema de actores es el identificado con el identificador “Ejem”.

El código del ejemplo es el siguiente:

import scala.concurrent._
import ExecutionContext.Implicits.global
implicit val system = ActorSystem("Ejem")
implicit val timeout = Timeout(2 seconds)
def ejemplo1(): Unit = {
  val actorEjemplo1 = system.actorOf(ActorEjemplo.props(), "ActorEjemplo1")
  val future: Future[Any] = actorEjemplo1 ? "Mensaje"
  val result: String = Await.result(future, timeout.duration).asInstanceOf[String]
  println(s"\nresultado ejemplo1=${result}")
  actorEjemplo1 ! PoisonPill
}

La salida por consola de la ejecución del código anterior es la siguiente:

Mensaje Recibido en Actor
resultado ejemplo1=Mensaje Recibido en Actor

La creación del actor se realiza con la función actorOf del sistema de actores identificado  como system; el envío de un mensaje a un actor se utiliza la función “?”; y, su resultado, es gestionado por el componente Await el cual opera con la respuesta de tipos Future que retorna el actor.

Ejemplo 5: ejecución de un Actor sin tiempo de espera

El siguiente ejemplo es idéntico que el anterior pero se espera la respuesta del actor de tipo Future sin tiempo de espera. La lógica es la misma que el ejemplo anterior pero se emplea la función onComplete para gestionar el resultado de ejecución. El código del ejemplo es el siguiente:

def ejemplo2(): Unit = {
  val actorEjemplo2 = system.actorOf(ActorEjemplo.props(), "ActorEjemplo2")
  // La función mapTo retorna un nuevo Future con la respuesta si es Success; en otro caso, ClassCastException.
  val future: Future[String] = ask(actorEjemplo2, "mensaje").mapTo[String]
  future onComplete {
    case Success(resultado) => println(s"\nresultado ejemplo2=${resultado}\n")
    case Failure(error) => println(s"\nerror ejemplo2=${error}\n")
  }
  actorEjemplo2 ! PoisonPill
}

Ejemplo 6: composición de Futures.

Supongamos que necesitamos ejecutar dos futuros y, su resultado, es la entrada de un tercer futuro. Una posible solución con un tiempo de espera determinado es la siguiente:

def ejemplo6(): Unit = {
  val actorEjemplo6_1 = system.actorOf(ActorEjemplo.props(), "ActorEjemplo6-1")
  val actorEjemplo6_2 = system.actorOf(ActorEjemplo.props(), "ActorEjemplo6-2")
  val actorEjemplo6_3 = system.actorOf(ActorEjemplo.props(), "ActorEjemplo6-3")

  val future1 = actorEjemplo6_1 ask ("Mensaje a Actor6_1")
  val future2 = actorEjemplo6_2 ask ("Mensaje a Actor6_2")

  val respuestaFuture1 = Await.result(future1, 3 seconds).asInstanceOf[String]
  val respuestaFuture2 = Await.result(future2, 3 seconds).asInstanceOf[String]
  val future3 = actorEjemplo6_3 ask ("##" + respuestaFuture1 + "&" + respuestaFuture2 + "##")
  val respuestaFuture3 = Await.result(future3, 3 seconds).asInstanceOf[String]
  println(s"resultado ejemplo6=${respuestaFuture3}")
}

La salida por consola de la ejecución del código anterior es la siguiente:

Mensaje a Actor6_1 Recibido en Actor
Mensaje a Actor6_2 Recibido en Actor
##Mensaje a Actor6_1 Recibido en Actor&Mensaje a Actor6_2 Recibido en Actor## Recibido en Actor
resultado ejemplo6=##Mensaje a Actor6_1 Recibido en Actor&Mensaje a Actor6_2 Recibido en Actor## Recibido en Actor

Ejemplo 7: composición de Furures con for comprehension

El siguiente ejemplo es el mismo que el caso anterior pero se emplea for comprehensión.

def ejemplo7(): Unit = {
  val actorEjemplo7_1 = system.actorOf(ActorEjemplo.props(), "ActorEjemplo7-1")
  val actorEjemplo7_2 = system.actorOf(ActorEjemplo.props(), "ActorEjemplo7-2")
  val actorEjemplo7_3 = system.actorOf(ActorEjemplo.props(), "ActorEjemplo7-3")
  val future1 = actorEjemplo7_1 ask ("Mensaje a Actor7_1")
  val future2 = actorEjemplo7_2 ask ("Mensaje a Actor7_2")
  val future3 = for {
    f1 <- future1.mapTo[String]
    f2 <- future2.mapTo[String]
    c <- ask(actorEjemplo7_3, "##" + f1 + "&" + f2 + "##").mapTo[String]
  } yield {
    c
  }
  future3 foreach { resultado => println(s"Resultado ejemplo7=${resultado}") }
}

La salida por consola de la ejecución del código anterior es la siguiente:

Mensaje a Actor7_2 Recibido en Actor
Mensaje a Actor7_1 Recibido en Actor
##Mensaje a Actor7_1 Recibido en Actor&Mensaje a Actor7_2 Recibido en Actor## Recibido en Actor
Resultado ejemplo7=##Mensaje a Actor7_1 Recibido en Actor&Mensaje a Actor7_2 Recibido en Actor## Recibido en Actor

Ejemplo 8: conversión de List[Future[A]] -> Future[List[A]]

Supongamos que tenemos una lista de operaciones Futuras del mismo tipo, en nuestro caso, Futuros cuya respuesta son números enteros; y, su procesamiento, puede ser transformado un un único Future. La solución consiste en emplear la función sequence la cual es la encargada de transformar muchos Future en uno único. Así, la solución se define de la siguiente forma:

def ejemplo8(): Unit = {
  val listaFutures: List[Future[Int]] = List(Future(1), Future(3), Future(5), Future(7))
  // Convertimos un List[Future[Int]] en Future[List[Int]] para trabajar con el Future.
  // Así, podemos trabajar con la List[Int]
  val futureList: Future[List[Int]] = Future.sequence(listaFutures)
  println(s"futureList=${futureList}")
  val suma: Future[Int] = futureList.map(_.sum)
  suma foreach{elem => println(s"Resultado ejemplo8=${suma}")}
}

La salida por consola de la ejecución del código anterior es la siguiente:

Resultado ejemplo8=Success(16)

Ejemplo 9: conversión de Future[List[A]] -> List[Future[A]]

Supongamos que tenemos un único Future y una lista de datos de un determinado tipo  que procesar y, su procesamiento, puede ser ejecutado por N Futuros. La solución consiste en emplear la función traverse. El código del ejemplo es el siguiente:

def ejemplo9(): Unit = {
  // Convertimos un Future[List[Int]] en List[Future[Int]] para trabajar con el Future.
  val futureList1 = Future.traverse((1 to 10).toList)(x => Future(x * 2 - 1))
  val resultadoFutureList1 = futureList1.map(_.sum)
  resultadoFutureList1 foreach {elem => println(s"Resultado1 de ejemplo9=${elem}")}
  val futureList2 = Future.traverse(List(1,3,5))(x => Future(x * 2 - 1))
  val resultadoFutureList2 = futureList2.map(_.sum)
  resultadoFutureList2 foreach {elem => println(s"Resultado2 de ejemplo9=${elem}")}
}

La salida por consola de la ejecución del código anterior es la siguiente:

Resultado2 de ejemplo9=15
Resultado1 de ejemplo9=100

Ejemplo 10: morfismos con Future, función fold

Supongamos que tenemos un ADT de tipo lista de futuros no bloqueantes y queremos realizar un morfismo sobre dicho ADT; el mecanismos para realizarlo, es utilizar la función fold. El siguiente snippet muestra un ejemplo representativo:

def ejemplo10(): Unit = {
  val listaFutures: List[Future[Int]] = List(Future(1), Future(3), Future(5), Future(7))
  val sumaListaFutures = Future.fold(listaFutures)(0)(_+_)
  sumaListaFutures onComplete{
    case Success(resultado) => println(s"Resultado ejemplo10=${resultado}")
    case Failure(error) => println(s"Error ejemplo10=${error}")
  }
}

Ejemplo 11: morfismos con Future, función reduce

La función reduce es como la función fold pero sin valor inicial.

def ejemplo11(): Unit = {
  val listaFutures: List[Future[Int]] = List(Future(1), Future(3), Future(5), Future(7))
  val futureSum: Future[Int] = Future.reduce(listaFutures)(_ + _)
  futureSum foreach { elem => println(s"Resultado ejemplo11=${futureSum}") }
}

La salida por consola de la ejecución del código anterior es la siguiente:

Resultado ejemplo11=Success(16)

Ejemplo 12: el primero que termine, se ejecuta; función firstCompletedOf

Supongamos que tenemos una lista de futuros en un ADT de tipo lista; y, a nivel de negocio, solo nos interesa el resultado del primer future que termina; en estos casos,  se emplea la función firstCompletedOf. El siguiente ejemplo muestra un ejemplo representativo.

def ejemplo12(): Unit = {
  val listaFutures: List[Future[Int]] = List(Future(1), Future(3), Future(5), Future(7))
  val futureFirst: Future[Int] = Future.firstCompletedOf(listaFutures)
  futureFirst foreach { elem => println(s"Resultado ejemplo12=${futureFirst} elem=${elem}") }
}

Una de las posibles salidas por consola de la ejecución del código anterior es la siguiente:

Resultado ejemplo12=Success(3) elem=3

Estos son los ejemplos que presento, si al lector interesado se le ocurre plantear otro ejemplo, o bien, plantear cualquier otra alternativa, estaré encantado de compartirlo.