zio and refilling a cache

zio and refilling a cache In some small web app server projects I sometimes need to cache some data to reduce latency and the impact of queries on a “weak” backend database. We can use alot of clever caching tools but sometimes I just need something quick and dirty. If you are using ZIO-style services, you may want the cache to be independent of other services and maintain the cache internally to the service environment. There are many ways to cache remote data, for example, you could also use ZQuery or the newer ZCache. Let’s assume that we want to do something simple: case class PeopleCache ( byId : Map [ UUID , Person ] = Map ( ) , last : LocalDateTime = LocalDateTime . now ( ) ) object PeopleCache : def createFromList ( people : List [ Person ] ) = ? ? ? trait Service : def search ( qstring : String ) : IO [ Exception , Option [ Person ] val live = ? ? ? class PeopleServiceImpl ( cache : RefM [ PeopleCache ] , db

scala3 + zio + dotty-cps-async field report

scala3 + zio + dotty-cps-async I’ve put multiple, small but “smart”, LOB applications into production based on scala and zio. Recently, I also did that with a scala3+zio project. Because of the amount of twisty, async logic, scala3 and zio made it easy for the key blocking and tackling areas. What I like about scala3: Fewer braces. This seems to make a huge difference in code comprehension. Reading code I wrote just yesterday is easier than with the less-braces model. I don’t know why but it just works. Macros, types, extensions, improved type inference: I do not use alot of arcane scala features in my code (libraries have at it!). I have noticed I write less types, macros from other packages seem more useful and I seem to write alot less boilerplate cade. What I like about zio: I still like all the things I liked about zio, large list. Most importantly, it takes care of most of my needs for solving my problems without going outside the system and having

zio quick read: Extracting the executor for a service

zio quick read: Extracting the executor for a service Let’s say you have the need to obtain an Executor from the default zio runtime and use it to create a service. Let’s assume you have a simple function to make your service. This function has no zio knowledge. def mkService ( executor : java . util . concurrent . Executor ) : MyService = ? ? ? Let’s say that you want to use the zio default runtime executor. For example, your service needs to use a specific Executor to power HttpClient –the new async http client in java 11. Otherwise, HttpClient uses a common, shared thread pool which may or may not be what you want. The executor is in the ZIO environment and we want to create a layer so that MyService is in the environment R , the environment, for all effects in the program. We need to pull the executor out the environment and add the derived service as a layer. Here’s the code (this is the hard way): type MyEnv = Has [ MyService ] val resources

1 line exception handling (scala.util.control.Exception) and functional programming, tie-in to zio

1 line exception handling (scala.util.control.Exception) and functional programming, tie-in to zio I’ve been using scala3/dotty for awhile and am in the process of converting around 25 of my libraries to the new syntax and compiler. That’s another story. As I am converting code in my own libraries, I remember transcribing a small number of zio-sql functions and types into dotty/scala3 to see if I would like the optional brace syntax. For that test, I used different exception handling constructs than just try-catch . I was thinking about zio-sql today because of some activity related to that project. It prompted me to write up this thought since I had not blogged in awhile. The scala.util.control.Exception class has been around for awhile but may not be widely used. Typically when you encounter an error, you throw an exception. If you are not using a functional programming (FP) style you are most likely letting the exception propagate up, up, and up! In contrast

dotty+scala.js+async: interesting options

dotty+scala.js+async: interesting options With the soon-to-be-released dotty 3.0.0-M1 (2020 Q4) and scala.js support rapidly improving (thanks @sjrd and team!), we can soon use scala.js with dotty. One area that has always been interesting to watch is the development of language constructs for managing effects such as Future for scala and async/await for javascript. Many languages have async/await support. scala 2.13.3 came out with -Xasync support that allows async { await(...) } like syntax. This “desugaring” can be used in combination with existing syntax such standard for-comprehensions or monadic style (chained function calls). Hence, there are 3 approaches. Working with javascript types, especially Promises, has always been problematic. For example, typescript 4.x recently introduced refinements so that Promise typing was better. Even dedicated languages such as typescript have had typing issues :-) Directly manipulating js.Promise s is important for fro

runtime start stop times for zio effects

runtime start stop times for zio effects Sometimes you need to collect the start and stop times for an effect running. For example, if the effect represents a job, you may want to record the job start and stop times in a database for analysis. zio has a .timed combinator that provides you a duration, but if you need to also add the start and stop time, .timed is not quiet right. Fortunately, we can add a few zip’ish combinators and get what we need. I use scala.js js.Date in the code below but substitute in your own date function as appropriate: /** Capture run stats including start and stop datetime. Once you have used the * timing result via `flatMap{ case (start,stop,delta,exit) => ... }`, use * `ZIO.done(exit)` to push the exit value back into an effect if desired. */ def timeRun [ R , E , A ] ( effect : ZIO [ R , E , A ] ) : ZIO [ R with zio . clock . Clock , Nothing , ( js . Date , js . Date , zio . duration . Duration ,

zio streams + scala.js: example of designing a streaming db API

zio streams + scala.js: example of designing a streaming db API nodejs has a streams API. However, if you are using zio with scala.js, you may want to use zstreams. To use zstreams, you will need to adapt your APIs. The content below was inspired by a recent zio stream Itamar training video: While scala.js is used below on nodejs, as always, scala.js has such good conformance to scala that you cannot really tell its javascript except for the use of javascript APIs. The example below adapts a javascript streaming API to scala.js and zio’s zstreams. It makes certain tradeoffs to reduce implementation time to a few minutes (the time it takes to write a blog). Generally, since its javascript, we don’t need to worry about parallelism. Ideally, we would write something whose pattern could be moved over to the jvm or another platform where parallelism is possible. Here are some good resources on zio streams: zio manual: ht