DEV Community: David Geirola

Secret values in Scala

David Geirola — Tue, 13 Feb 2024 13:49:22 +0000

Preface

One of the most important topics in IT is surely the security, it's so complicated and intriguing that, either you love it or you hate it, but we can't help taking care of it. Nowadays, in a society based on computers and applications, crackers attacks are very concrete and dangerous.
In my opinion, when we talk about IT security, it is always better to overestimate the risk and have a large margin of tolerance.
The (hard) trade-off we have to make is that the solution is usable, has good performance, and is safe.

Often, it is not a single solution that makes something safe; it is the sum of several approaches that mitigate the risk.

History

It has been a while since I had my first idea for a library that would help developers securely manage secret values within their applications. Originally, I started with a very simple wrapper of String to avoid unwanted printing or logging of the secret value, then I created my own application toolkit where I added a dedicated module with a minimal version of the Secret type.

Step by step, iteration by iteration, I abandoned the toolkit module in favor of a dedicated library for handling secrets.
In this article, I want to briefly introduce you to my new library, explain how it works, and explain why you should use it in your projects.
As I just said, this is the latest iteration of this idea, not the final one, and since I am now releasing it as a standalone library, I hope to get feedback and ideas to make it even better.

Secret library github page
https://github.com/geirolz/secret

Read this interesting article which inspired my about this library
https://westonal.medium.com/protecting-strings-in-jvm-memory-84c365f8f01c

The problem of secrets in applications

I believe everyone who is reading this article already knows about these problems.
Just to be pragmatic, I'll use one of my favorite tools, a list:

Hard-coded secrets
Unwanted printing and logging of secrets value
Memory leaks due to cracker attacks (e.g. JVM Heap dump)

I will briefly review these 3 problems to give you a broader context and to share the ideas behind my library. If you are not interested in this part, you can skip to the end of the article for the introduction to the library, or you can look directly at the library page on github.

Hard-coded secrets

Below is an image explaining how secure it is to have one's datacenter fenced and guarded by armed guards, a thousand layers of software security, and hard-coded secrets.

There are several approaches to avoid this bad practice; I won't go through them in this article, but just to give you a tip, if you are using Kubernetes, you could use Secrets; similar to ConfigMaps but specifically intended to hold confidential data.

Then you can mount secrets as a volume, inject them as environment variables, or synchronously access the vault.

Let me know if you know more methods to solve this!

Printing and logging

Unfortunately, this problem doesn't have a definitive solution. Common sense and education prevent most of the cases, but we are humans, and we can easily get distracted.

A very simple solution would be wrapping the secret value overriding the toString method.

case class Secret(value: String) extends AnyVal:
  override toString: String = "** SECRET **"

Cool! But the following example could easily happen

case class Config(databasePass: Secret)
def initDb(pass: String): Unit = ???

//usage
val config: Config = ???
initDb(config.databasePass.value)

The problem is that the initDb method has full access to the secret value, and someone could unintentionally log or print it. The easy solution would be to pass the type Secret instead of the String.

While one improvement for the Secret type might be to make the API a little more difficult to use to force the user to think.

class Secret(value: String):
  override toString: String = "** SECRET **"
  def use[T](f: String => T): T = f(value)

This is not a solution; you can easily bypass it, but it makes it a little more difficult (sum of approaches).

If you do this, you deserve a firing letter :)

val pass: String = secretPass.use(identity)

Memory leaks

Ok, let's start with the assumption that if someone has access to your application environment, this is not the only problem you have, but surely we can make the lives of our friends crackers a bit harder.
Here we discuss the JVM heap dump attack, a common attack to steal secrets and sensible data from an application.

Basically, the attack consists of creating a snapshot of the JVM heap and analyzing it in order to find sensible information.

To work around this problem, we can use a kind of ByteBuffer called direct that allocates the data directly to the memory, outside the JVM heap.

ByteBuffer.allocateDirect(bytesCapacity)

The heap will only contain the memory addresses of the byte buffer.

To improve security a bit, we can also obfuscate the bytes we are allocating by using some strategies, the most common of which is the use of the xor operator.
Xor is simple, fast, and isomorphic. Xor is not secure because it is not a cryptographic algorithm, but it is sufficient if we add up all these tricks.

Once finished with the secret byte buffer, you can overwrite the value with 0 and cancel the pointer to avoid unnecessary leaks. Secrets are usually used at startup to build connectors or instances; there is no need to keep them in memory forever unnecessarily.

Secret library

Well, I've created a library called Secret (very creative) that implements what you just read in a type named Secret.
It supports direct byte buffers, xor-ed values (all primitive types), secure destruction, map and flatMap.
With the special type DeferredSeret you can define a secret that is acquired and then destroyed whenever it is accessed (for example, a remote call to get the value from a vault).

It has integration modules for cats-effect, pureconfig, ciris and Typesafe Config

You can also extend it by defining a custom algorithm to use instead of xor (default). Check the documentation if you are interested.

As I wrote in the README, Secret library does its best to avoid leaking information in memory and in the code, BUT an attack is always possible, and I don't give any certainties or guarantees about security using this library; you use it at your own risk. The code is open-sourced; you can check the implementation and make your decision consciously. I'll do my best to improve the security and documentation of this project.

Let me know what you think about this article and this project! Comments, feedback, PRs, and discussions are welcome.
If you like the library, please consider leaving a star on Github to support it!

Rules evaluation in Scala with Erules and Cats

David Geirola — Mon, 13 Nov 2023 11:15:50 +0000

Introduction to Erules Library: A Practical Guide

Erules is a lightweight, simple, and functional Scala library for rule evaluation. In this article, we will explore how to use this library to define and evaluate rules efficiently. Follow step-by-step for a detailed and hands-on understanding of use cases.

What is Erules?

Erules is a library that provides a rule evaluation engine in Scala. It is designed to be straightforward, typed, and functional, leveraging the power of Cats core. With Erules, you can define rules clearly and evaluate them on various data types concisely.

Step 1: Import the Library

To get started, add Erules as a dependency to your Scala project. You can do this in the build.sbt file with the following declaration:

libraryDependencies += "com.github.geirolz" %% "erules-core" % "0.1.0"

Make sure to check the Maven page for the latest version.

Step 2: Define Data Classes

Before defining rules, declare the data classes on which you want to apply them. For example:

case class Country(value: String)
case class Age(value: Int)

case class Citizenship(country: Country)
case class Person(name: String, lastName: String, age: Age, citizenship: Citizenship)

Step 3: Write Rules

Now you can start defining the rules you want to apply to the data.
Each Rule must have a unique name and can be:

Pure: a pure function that takes a value and returns a RuleVerdict
Effectful: a function that takes a value and returns a F[RuleVerdict] where F is a monad.

There are several ways to define a rule:

apply: defines a complete rule from T to F[RuleVerdict] ( or Id for Pure Rules)
matchOrIgnore: defines a partial function from T to F[RuleVerdict] ( or Id for Pure Rules). If the function is not defined for the input value, the rule is ignored.
const: defines a rule that always returns the same RuleVerdict (e.g. Allow or Deny)
failed: defines a rule that always fails with an exception
assert: defines a rule from T to F[Boolean] ( or Id for Pure Rules) and returns Allow for true or Deny for false
assertNot: defines a rule from T to F[Boolean] ( or Id for Pure Rules) and returns Allow for false or Deny for true
fromBooleanF: defines a rule from T to F[Boolean] ( or Id for Pure Rules) where you can specify the behavior for true and false values.

For instance, let's say you want to check if a person is an adult and has UK citizenship:

import erules.Rule
import erules.PureRule
import erules.RuleVerdict.*
import cats.data.NonEmptyList

val checkCitizenship: PureRule[Citizenship] =
  Rule("Check UK citizenship") {
    case Citizenship(Country("UK")) => Allow.withoutReasons
    case _ => Deny.because("Only UK citizenship is allowed!")
  }

val checkAdultAge: PureRule[Age] =
  Rule("Check Age >= 18") {
    case a: Age if a.value >= 18 => Allow.withoutReasons
    case _ => Deny.because("Only >= 18 age are allowed!")
  }

val allPersonRules: NonEmptyList[PureRule[Person]] = NonEmptyList.of(
  checkCitizenship.targetInfo("citizenship").contramap(_.citizenship),
  checkAdultAge.targetInfo("age").contramap(_.age)
)

N.B. Importing even the erules-generic you can use a macro to auto-generate the target info using the contramapTarget method.
contramapTarget applies contramap and derives the target info by the contramap parameter.
The contramap parameter must be inline and have the following form: _.bar.foo.test.

Step 4: Use the Evaluation Engine

Now that you've defined the rules, you can use the evaluation engine to check them.
You can run the engine in two ways:

denyAllNotAllowed: to deny all is not explicitly allowed.
allowAllNotDenied: to allow all is not explicitly denied.

Moreover, you can choose to run the engine in a pure way( with pure rules ) or in a monadic way (e.g. IO) using:

seqEvalPure: to run the engine in a pure way with pure rules.
seqEval: to sequentially run the engine in a monadic way.
parEval: to parallel run the engine in a monadic way.
parEvalN: to parallel run the engine in a monadic way with a fixed parallelism level.

For example:

import erules.*
import erules.implicits.*
import cats.Id
import cats.effect.IO
import cats.effect.unsafe.implicits.*

val person: Person = Person("John", "Doe", Age(25), Citizenship(Country("UK")))

val result: IO[EngineResult[Person]] =
  RulesEngine
    .withRules[Id, Person](allPersonRules)
    .denyAllNotAllowed[IO]
    .map(_.seqEvalPure(person))

result.unsafeRunSync().asReport[String]

Conclusion

Erules provides a powerful yet simple way to define and evaluate rules in Scala. By following these steps, you can integrate Erules into your projects for efficient and type-safe rule evaluation.

For more details, check out the Erules GitHub Repository.

I would love to receive feedback, so if you want to let me know what you think of this library!

Semantic of a functional app in Scala

David Geirola — Mon, 19 Jun 2023 22:17:12 +0000

Introduction

Functional applications offer numerous benefits in modern software development. They enhance testability, modularity, and composability, leading to more maintainable and scalable codebases. In this article, we'll explore the syntax and semantics of functional applications and introduce the app-toolkit library—a powerful tool for building functional applications more efficiently.

Syntax and Semantic of an App

At its core, an app can be represented as a function that takes an input (I) and produces an output (O). By incorporating side effects, we extend this representation to I => F[O], where F[_] denotes the ability to handle side effects.

Resources

To build an app, we rely on resources such as app information, input arguments, a logger, and configuration settings.

With this concept in mind, we can merge these resources with the input (I) since the only input we have are the app arguments, resulting in:

(AppInfo, F[Config], Args, F[Logger], F[OtherResources]) => F[O].

Dependencies

Dependencies represent application-specific services and repositories used in the app's logic.

Combining resources and dependencies, we arrive at:

(AppInfo, F[Config], Args, F[Logger], F[OtherResources]) => (AppInfo, Config, Args, Logger, OtherResources, F[Dependencies]) => F[O].

Because we need resources to build the dependencies and we need dependencies to build the app logic.
Dependencies also includes the resources.

Provided services

Now, let's imagine that given all the resources and dependencies, we can define a list of tasks to run in parallel (including never-terminating tasks like an HTTP server).

Thus, the final definition of the app logic F[O] is actually the result of the parallel execution of all the provided services, which are expressed as:

AppDependencies => F[List[Any]]

Giving an example a service that provide an HTTP server is just a single never-ending task app.

An app that provide an HTTP server and consume from a Kafka topic is 2 parallel tasks app.

Flattening

We have zoomed inside the app's semantics to better understand its parts, but in the end, the app can be typed as:

F[Unit] or F[ExitCode]

Since the output of the app must be delivered through the provided services, the output will always be Unit or ExitCode.

The app consists of multiple steps:

Loading resources
Building dependencies
App logic: executing parallel tasks

App-toolkit

https://github.com/geirolz/toolkit

App-toolkit is a lightweight and functional non-intrusive library for building typed and declarative Scala applications with managed resources and dependencies. It has been developed with the aforementioned concepts in mind. It provides a nice syntax for defining and building applications, and it manages the resources, allowing you to focus on the important parts of the application.

Here's an example:

import cats.effect.{ExitCode, IO, IOApp}
import com.geirolz.app.toolkit.App
import com.geirolz.app.toolkit.logger.ToolkitLogger
import com.geirolz.app.toolkit.error.*

object Main extends IOApp {
  override def run(args: List[String]): IO[ExitCode] =
    App[IO]
      .withInfo(
        SimpleAppInfo.string(
          name = "app-toolkit",
          version = "0.0.1",
          scalaVersion = "2.13.10",
          sbtVersion = "1.8.0"
        )
      )
      .withLogger(ToolkitLogger.console[IO](_))
      .withConfigLoader(_ => IO.pure(Config("localhost", 8080)))
      .dependsOn(AppDependencyServices.resource(_))
      .provideOne(deps =>
        // Kafka consumer
        deps.dependencies.kafkaConsumer
          .consumeFrom("test-topic")
          .evalTap(record => deps.logger.info(s"Received record $record"))
          .compile
          .drain
      )
      .beforeRun(_.logger.info("CUSTOM PRE-RUN"))
      .onFinalize(_.logger.info("CUSTOM END"))
      .run(args)
}

Conclusions

In this article, we explored the syntax and semantics of functional applications. We viewed applications as functions with inputs and outputs, considering side effects with the F[_] type.

Resources and dependencies played crucial roles in building and executing these applications. We also introduced the app-toolkit, a lightweight and functional library that simplifies the development of typed and declarative Scala applications.

By leveraging functional programming principles and tools like app-toolkit, developers can create scalable and reliable applications. Understanding the syntax and semantics of functional applications empowers developers to deliver high-quality user experiences.

Compile-time safe models separation in Scala

David Geirola — Sun, 12 Dec 2021 22:28:29 +0000

https://github.com/geirolz/scope

Every code architecture relies on developers common sense and accuracy, erring is human, in some cases, the compiler can help us

Overview

Let's take a persistence layer as an example.
You don't want that the Entity class model, used in the persistence layer, is used in the domain or even worse as REST contract. You want to separate those concepts using different models for each layer.

Mapper approach

To achieve this you need a Mapper to convert the model from one scope to another and vice-versa(when needed).

This Mapper can be done using a separated object, or better, defining a method into the companion object of the model, keeping the domain model clean.



//persistence
case class UserEntity(id: Long, name: String)
object UserEntity {
  def toDomain(entity: UserEntity) : User = ???
}

//domain
case class User(id: Long, name: String)

//endpoint
case class UserContract(id: Long, name: String)
object UserContract{
  def fromDomain(user: User) : UserContract = ???
}

Advantages

It's trivial

Problems

Bad composability (especially when the mapper is effectful)
No guarantee that the users will use the mappers in the right scope

Functional approach with Kleisli

From a functional programming point of view, this mapper is a simple morphism A => B, that becomes A => F[B] if we want allowing effects.

This is a Kleisli[F, A, B].

So, let's improve our above solution using Kleisli.



//persistence
object UserEntity {
  val toDomain: Kleisli[Id, UserEntity, User] = ???
}

//endpoint
object UserContract{
  val fromDomain: Kleisli[Id, User, UserContract] = ???
}

Advantages

Composability, even with effects is simpler

Problems

No guarantee that the users will use the mappers in the right scope

Functional approach with Scope

https://github.com/geirolz/scope

Scope is a lightweight library to enforce the model layer separation at compile-time.
To do this, Scope simply verify the presence of an implicit Scope that corresponds to the Scope of the mapper.

So, there are two main actor in scope:

ModelMapperK a type class to define a scoped model mapper
TypedScopeContext a type to describe an available scope
ScopeContext a type to describe an available untyped scope
Scope an ADT to define available scopes

For pure mappers, there is ModelMapper[S <: Scope, A, B] which is a type alias to ModelMapperK[Id, S <: Scope, A, B]

If there isn't the required ScopeContext instance in the class | object scope the compilation fails.

Since there can't be more than one implicit instance for type in the scala scope (class, object, etc...) the compilation fails in the case of multiple ScopeContext defined.

Definition



//persistence
object UserEntity {    
    implicit val userEntityToDomain: ModelMapper[Scope.Persistence, UserEntity, User] =
      ModelMapper.scoped[Scope.Persistence](userEntity => ???)
}

//endpoint
object UserContract {    
    implicit val userToUserContract: ModelMapper[Scope.Endpoint, User, UserContract] =
      ModelMapper.scoped[Scope.Endpoint](user => ???)
}

Usage



//persistence
implicit val scopeCtx: TypedScopeContext[Scope.Persistence] = 
  ScopeContext.of[Scope.Persistence]

val userEntity : UserEntity = ???
val user: User = userEntity.scoped.as[User]


//endpoint
implicit val scopeCtx: TypedScopeContext[Scope.Endpoint] = 
  ScopeContext.of[Scope.Endpoint]

val user : User = ???
val userContract: UserContract = user.scoped.as[UserContract]

If you don't want to explicitly declare the implicit variable for the scope you can simply extend the trait InScope passing the scope type



//persistence

object MyPersistence extends InScope[Scope.Persistence] {

  val userEntity : UserEntity = ???

  val user: User = userEntity.scoped.as[User]

}

//endpoint

object MyEndpoint extends InScope[Scope.Endpoint] {

  val user : User = ???

  val userContract: UserContract = user.scoped.as[UserContract]

}

Advantages

Composability, even with effects is simpler
Compile-time check that the users are using the mappers in the right scope

Problems

No guarantee that the user correctly maps the scope, this reduces the problems. The scopes are less than mappers

Conclusions

Scope doesn't totally resolve the problem, but for sure can help offering one more tool to have a clean and structured code.

Database migrations in Scala

David Geirola — Tue, 02 Nov 2021 08:12:19 +0000

https://github.com/geirolz/fly4s

The most famous library to handle database migrations in Java is for sure Flyway.
It works very well and the community edition has a lot of features as well.

Problem

Flyway APIs are written in the standard OOP paradigm, so throwing exceptions, manually managing resources, etc...

Solution

Fly4s is a lightweight, simple and functional wrapper for Flyway.
The aim of Fly4s is straightforward, wrapping the Flyway APIs in order to guarantee referential transparency, pureness, resource handling and type safety. To achieve this goal, Fly4s use the typelevel libraries cats and cats-effect.

Getting started

The first step, import the Fly4s library in our SBT project.
So, add the dependency in your build.sbt file.
Fly4s depends on Flyway, so we'll have access to Flyway as well

(check the GitHub repo for the latest version)

libraryDependencies += "com.github.geirolz" %% "fly4s-core" % "0.0.4"

Migrations files

As the plain Flyway, we have to create a folder that will contain our migrations scripts, often in resources/db.

In this folder, we have to put all our migration. We can have:

For this example, we are going to use a simple baseline migration to add a table to our database schema.

Baseline migrations are versioned and executed only when needed. The version is retrieved from the script file name.

So in this case, V001__create_user_table.sql, the version will be 001(remember the double underscore after V).

Here we have our first migration(for MySQL database)

resources/db/V001__create_user_table.sql

CREATE TABLE `user` (
    `id` bigint(20) NOT NULL AUTO_INCREMENT PRIMARY KEY,
    `name` varchar(30) NOT NULL,
    `surname` varchar(30) NOT NULL
);

Defining database configuration (optional)

A good practice is to create a case class to handle the database configuration(this combined with PureConfig or other config libraries makes your app very robust from the configuration point of view)

Let's create a simple case class to achieve this.

case class DatabaseConfig(
  url: String,
  user: Option[String],
  password: Option[Array[Char]],
  migrationsTable: String,
  migrationsLocations: List[String]
)

N.B. apart from the common fields such url, user and password we'll use: migrationsTable to define the Flyway table name(used to store the migration status) and migrationsLocations to specify a list of the folders that contain our migration scripts.

Instantiating Fly4s

Ok so, now we have all our migration scripts in our folder(resources/db), we have Fly4s as a dependency of our project, and we have a case class that will contain the database configuration.

To instantiate Fly4s we can use make to create a new DataSource(under the hood) starting from the parameters or makeFor in order to create it for an already existent DataSource(for example from Doobie HikariDataSource).
make and makeFor method returns a Resource type class that when released/interrupted safely close the DataSource connection.

In both make and makeFor methods, we can specify the parameter config. Fly4sConfig is a trivial wrapper for flyway Configuration but instead of having a builder, we have a case class.

val dbConfig: DatabaseConfig = ???
val fly4sRes: Resource[IO, Fly4s] = Fly4s.make[IO](
  url                 = dbConfig.url,
  user                = dbConfig.user,
  password            = dbConfig.password,
  config = Fly4sConfig(
    table     = dbConfig.migrationsTable,
    locations = Location.of(dbConfig.migrationsLocations)
  )
)

Using Fly4s

Ok, we have done with the configuration!
We are ready to migrate our database schema with the power of Flyway and the safety of Functional Programming!

We can use use or evalMap from Resource to safely access to the Fly4s instance. In case we have multiple Resources in our application probably evalMap allow us to better combine them using and release them all together at the same time.

We can create a simple utility method to do this

  private def migrateDb(
    dbConfig: DatabaseConfig
  ): Resource[IO, Unit] =
    Fly4s.make[IO](
      url                 = dbConfig.url,
      user                = dbConfig.user,
      password            = dbConfig.password,
      config = Fly4sConfig(
        table     = dbConfig.migrationsTable,
        locations = Location.of(dbConfig.migrationsLocations)
    )
   ).evalMap(fly4s =>
        for {
          _               <- logger.debug(s"Applying migration for ${dbConfig.name}")
          migrationResult <- fly4s.validateAndMigrate[IO].result
          _ <- logger.info(
            s" Applied ${migrationResult.migrationsExecuted} migrations to ${dbConfig.name} database"
          )
        } yield ()
      )

Conclusions

We have done it! So, to recap, we have:

Created a folder under resources to put our migrations(db)
Imported Fly4s as a dependency in our project
Created a configuration case class to describe our database configuration
Instantiated a Fly4s instance creating a new DataSource
Migrated our database using validateAndMigrate
At the application shutdown/interruption Resource(from cats-effect) will safely release the DataSource

With a few lines, we have migrated our database safely handling the connection and the configuration.

As flyway, Fly4s provides multiple methods such as:

validateAndMigrate
migrate
undo
validate
clean
info
baseline
repair

Useful links

https://github.com/geirolz/fly4s
https://flywaydb.org/documentation
https://typelevel.org/cats/
https://typelevel.org/cats-effect/
https://pureconfig.github.io/

"Type Disjunctions" in Scala

David Geirola — Wed, 06 Nov 2019 15:37:35 +0000

Hi guys,

Today i'd like to talk about Type Disjunctions (Union Type) in Scala.

As we all know this feature is not available in Scala yet but i'd like to share with you my solution about a case i've had this week working on my library.

I'm writing a FP library to edit and work easily with XML in Scala, it's based on standard scala-xml library and Cats. You can check this library on github at: https://github.com/geirolz/advxml

Case

I've defined a new type alias named ValidatedEx

    type ValidatedEx[+T] = ValidatedNel[Throwable, T] // = Validated[NonEmptyList[E], A]

I wanted to add new methods on this type using extension methods, one of these was a method named "transform" with the aim to convert ValidatedEx instance into F[_].

Must have:

One single method, the user should not have the burden to choose the right method depending on the case.
Use Cats instances, i don't want to reinventing the wheel.

First solution [Failed]

Using an implicit monad error in order to convert ValidatedEx to F[_], pattern matching over the instance, invoking pure or raiseError depending on the case and the game is done!

    implicit class ValidatedExOps[A](validated: ValidatedEx[A]) {
        def transform[F[_]](implicit F: MonadError[F, NonEmptyList[Throwable]]): F[A] =
          validated match {
            case Valid(a)   => F.pure(a)
            case Invalid(e) => F.raiseError(e)
          }
      }

Yea! It works! But...i can't use standard monads error provided by cats...

This wont compile because in the scope is not present an implicit instance of MonadError[Try, NonEmptyList[Throwable]] and cats provides only MonadError[Try, Throwable].

      import cats.instances.try_._
      val value: ValidatedEx[String] = Valid("TEST")
      //No implicit found for parameter F:MonadError[Try, NonEmptyList[Throwable]] 
      val tryValue: Try[String] = value.transform[Try]

I don't want to create a new monad error for each type, my library must work with cats!

Second solution [Failed]

Using natural transformation!

      implicit class ValidatedExOps[A](validated: ValidatedEx[A]) {
        def transform[F[_]](implicit F: ValidatedEx ~> F): F[A] = F(validated)
      }

      import cats.instances.try_._
      val value: ValidatedEx[String] = Valid("TEST")
      //No implicit found for parameter F:ValidatedEx ~> F
      val tryValue: Try[String] = value.transform[Try]

Here we go again, this solution require ad-hoc implementations of FunctionK for each type and i don't want to reinventing the wheel.

Third solution [Success]

I want have just one method, keep all possibilities open and substantially have two MonadError in the signature but only one is required. This smell like an union type!

Let's define "union types" using Either with a very easy solution.

      type \/[+A, +B]           = Either[A, B]
      type MonadEx[F[_]]        = MonadError[F, Throwable]
      type MonadNelEx[F[_]]     = MonadError[F, NonEmptyList[Throwable]]

      implicit class ValidatedExOps[A](validated: ValidatedEx[A]) {
        def transform[F[_]](implicit F: MonadEx[F] \/ MonadNelEx[F]): F[A] =
          F match {
            case Left(m) =>
              validated match {
                case Valid(value) => m.pure(value)
                //AggregatedException is a my own class that just collapse multiple exceptions into one 
                case Invalid(exs) => m.raiseError(new AggregatedException(exs.toList))
              }
            case Right(m) =>
              validated match {
                case Valid(value) => m.pure(value)
                case Invalid(exs) => m.raiseError(exs)
              }
          }
      }

But...still fail, obviously there isn't an implicit instance for Either[MonadEx[F], MonadNelEx[F]]

      import cats.instances.try_._
      val value: ValidatedEx[String] = Valid("TEST")
      //No implicit found for parameter F:Either[MonadEx[F], MonadNelEx[F]]
      val tryValue: Try[String] = value.transform[Try]

Let's wrap what cats provides, let's "intercept" monads error provided in the scope and wrap them into Either.

      implicit def monadExLeftDsj[F[_]]
        (implicit F: MonadEx[F]): MonadEx[F] \/ MonadNelEx[F] = Left(F)
      implicit def monadNelExRightDsj[F[_]]
        (implicit F: MonadNelEx[F]): MonadEx[F] \/ MonadNelEx[F] = Right(F)

And for a more generic solution we can write:

      //for explicit values
      implicit def aLeftDsj[A](v: A): A \/ * = Left(v)
      implicit def bRightDsj[B](v: B): * \/ B = Right(v)

      //for implicit values
      implicit def aLeftDsj[A](implicit v: A): A \/ * = Left(v)
      implicit def bRightDsj[B](implicit v: B): * \/ B = Right(v)

Done! It works!

I know that this solution isn't perfect and beautiful, i hate implicit conversions, and i also know that union types are coming but in the meantime this is a simple solution to partially bypass this scala loss for a specific case like mine.

Tell me what do you think about this solution :)

Edit XML in Scala in a FP way

David Geirola — Wed, 14 Aug 2019 18:51:27 +0000

Hi guys , i'm new here and this in my first post!

I'm here because i'd like to share with you a small project i realized for my company due the difficulties and boilerplates found using Scala XML library's API.

I hope that someone can contribute to it.

Github: https://github.com/geirolz/advxml

Features:

Append, Remove, Replace XML nodes
Edit node's attributes
Read XML handling optionality and mandatory nodes and attributes
Convert XML into Object and viceversa
Normalize XML
Convert Java Document to Scala NodeSeq

Example:

import com.github.geirolz.advxml.all._
import scala.xml._
import scala.util._


//import MonadError instance for Try
import cats.instances.try_._

val doc: Elem =
<Persons>
 <Person Name="Mimmo">
  <Cars>
   <Car Brand="Fiat"/>
  </Cars>
 </Person>
</Persons>


val rule = $(_ \ "Person" \ "Cars")
 ==> Append(<Car Brand="Lamborghini"/>)
 ==> Append(<Car Brand="Ferrari"/>)
 ==> Append(<Car Brand="Bmw"/>)


val result: Try[NodeSeq] = doc.transform[Try](rule)

I hope this small project can help someone in desperation with Scala XML library

Let me know what you think about it :)