In a previous post I’ve shown how to use ZIO environments to provide your program with dependencies, or modules. While using environments at the customer I’m currently working for, we found out that the logic to get a database session object using a module would run over and again. This makes sense, since a ZIO[R, E, A] is a prescribed way of getting an A, and the result is not cached. Our application was reading configuration files and creating SQL sessions on every module call, while the resulting object was obviously constructed from the same underlying values. There are multiple ways to solve this:
ZIO is a type-safe, composable library for asynchronous and concurrent programming in Scala (from: The ZIO github). The library copes with functional IO, like many Functional Programming libraries do. The added value of ZIO is that the
ZIO[R, E, A] type-constructor
(the main IO monad of the library) acts as an IO monad, an error handling monad, and a reader monad. A functional programming style often needs a combination of these three types to cope with the most common problems when creating an application:
ZIO is a type-safe, composable library for asynchronous and concurrent programming in Scala (from: The ZIO github). The ZIO framework provides your program as immutable and pure values, which are very simple to properly unit test. But how can you run an integration test to see if your application starts up properly?