# Home Hi, I'm Alan. I'm a software engineer in the New York area. I like Scala, Typescript, and React. This website is just a collection of things I've tried to explain for myself or snippets of things I've worked on that may be helpful to other people. # Understanding Scala Options The option type can be a tricky pattern for new Scala developers to pick up. Most of that difficulty lies in using options practically in code as opposed to the concept itself -- and you will certainly be using it. While there are some Scala features that are mostly invisible to you (e.g. macros), options are ubiquitous in Scala code. Options are unavoidable in Scala if you're writing anything worth anything. As a concept, options are relatively simple and most new Scala developers can easily understand the motivation behind it -- but when the going gets rough and you're neck-deep in option, it's easy to find yourself thinking "why do we even use this anyway?" So let's start with the motivation behind options to keep our sights set straight. If you don't need to be convinced about options, you can skip this section. ## Motivation for Options If you've written in any language that doesn't use some form of the `Option` type (most languages), you've undoubtedly seen a `NullPointerException` or something similar pop up at runtime, e.g. the anxiety-inducing `Cannot read property '…' of undefined` in Javascript land. There's no guarantee that a variable references an actual value. From here on, I'll use "empty value" to mean the absence of a value instead of using one language-specific keyword like `null`, `undefined`, or `nil`. Let's consider a Javascript example: ```javascript function doStuff(thing) { thing.do(); } ``` What if `thing`'s value is an empty value? The world blows up. Okay, so that's an easy fix right? ```javascript function doStuff(thing) { if (thing !== null) { thing.do() } } ``` #### I'd rather not get into the rabbit hole of null/undefined checking in JavaScript, so this example will do. Not awful, right? But now do this for every one of your functions for each parameter and this proposition becomes drastically less appealing. But sometimes you actually *are* sure that the value exists, because maybe you already checked it earlier on. How can you be sure of that? What if you re-purpose this function or it starts being called from another location that doesn't actually do that empty value check? So to combat this, you resort to always doing these checks, often times needlessly. You could argue that code verbosity and tedious syntax is a solved issue through the use of an IDE or auto-completed code snippets. (I'd disagree, but that's beside the point). Then how about this less trivial issue: when writing a function, how do you signal to its callers that you might not actually have a value to return back i.e. you might be returning an empty value? An example might be a method that takes an array and tries to find some element -- if that element is not found, you'll likely return an empty value, but how does the caller know that? Some likely answers are 1. You find out the hard way--something breaks and then you make the change to your code 1. The method uses some other way of signalling this e.g. returning `-1` 1. You look through the documentation (if it exists) and read about it there At this point we can address the issue of calling methods that could return empty values or using parameters that could be empty values in two ways 1. Simply don't check for empty values (this is decidedly the wrong way) 1. Do a bunch of manual empty value checking yourself. You must contend with the possibility of empty values one way or the other or risk potentially catastrophic failure of your application. The secret third door here is to use options. If a reference may or may not have a value, you make its type an `Option` to signify as much (we'll get into the details of precisely how to do that later). Baking this feature into your language has a huge implication: all non-Option references are now *guaranteed to be non-empty* i.e. *defined*. This implicit consequence of using options may actually be more important than the use of options themselves. This means no more null-checking for parameters -- they're guaranteed to exist (though we still have the ability to accept potentially empty values). Conversely, if your function may not have any value to return, make the return type `Option` and the caller will be forced to deal with that possibility. This design makes it so that we're always explicit about when we will have to deal with the possibility of empty values. This let's you have one less issue you have to worry about so you can focus on all the other terrible bugs you write. ## Options Implemented #### I'm operating under the assumption that you have some basic knowledge of Scala and type parameters `Option[A]` is an *option of type* `A`--or an `A` *option*. You can think of `Option` as a container for some value. In a concrete example, `Option[Int]` is an option of *type Int*, or an *Int option*. If I say a variable `x` is of type `Option[Int]` you know that `x` may or may not actually have a value. `Option` is an abstract class so we can't create an instance of `Option` directly. We use one of its two implementations: `None` or `Some[A]`. It should be apparent what those two mean . `None` means a reference has no value i.e. `null`. `Some[A]` means a reference *does* have a value and the type of that value is `A`. Assigning variables a value of `None` is simple (`None` is a Scala `object` so we can use it like a normal value): `val x: Option[Int] = None`-- make a variable `x` and *explicitly define that it has no value*, which can be used anywhere where options of `Int`s are accepted. An alternative could be `Option.empty[Int]`, which does the same thing. You may have to use this alternative form when it's not clear to the compiler what `Option` type to infer. Let's do the same for `Some[A]`: `val y: Option[Int] = Some(42)`--make a variable *y* and say it has the value `42`, which can be used anywhere where options of `Int`s are accepted. The constructor for `Some` takes one value of the type your option is parameterized on--in this case `Int`. If you're interop'ing with Java, you can use the `Option` object's `apply` method to wrap a value in an option to prevent those nasty `null`s from invading Scala land: ```scala val a: Option[String] = Option("Hello, internet!") // > a = Some("Hello, internet!") val b: Option[String] = Option(null) // > b = None ``` ## Using Options So this is cool and all, but how do we do anything meaningful with these values? For example, we can't just add two `Option[Int]`s together, so how do we work with the actual underlying value in an option -- an `Int` in this case -- if it in fact has one? But first, since everyone loves an aside on frivolous things, let's talk about variable names. Typically you don't want to name your variables based on their types. For example, `nameString: String` is a bad variable name because it's superfluous --`name` is more appropriate and concise. However, when it comes to options I think it's useful, if not important, to name those variables with some identifier that lets you know that you'll have to deal with the possibility of an empty value. It signifies not just the *type* but how you should be *dealing with* this variable. Some examples I've seen range from `nameOption`, `nameOpt`, `nameO`. My go-to is `maybeName`. If you're looking for a great reason here, I don't have one. It's probably because that's how most option variables were named in the [codebase I worked](https://gemini.com/) on when I started using Scala and now I just use it out of habit. Feel free to use whatever variable naming scheme you like. While I'd highly recommend signifying your variable is an option in *some way*, it's certainly still acceptable to go without it e.g. `name: Option[String]`. Let's get back to more important stuff now. ### .get Maybe the simplest way to use an option is with a couple of convenient methods, `.isDefined` (or its inverse `.isEmpty`) and `.get`, which either returns the contained value for a `Some` or throws a `NoSuchElementException` (😱) if it's a `None`. ```scala val maybeNameA: Option[String] = Some("LeBron James 🐐") val maybeNameB: Option[String] = None if (maybeNameA.isDefined) println(maybeNameA.get) // > LeBron James 🐐 if (maybeNameB.isDefined) println(maybeNameB.get) // > doesn't print anything ``` Now that that's out of the way, let's be clear on never using `.get`. Ever. No seriously, *do not ever use* `.get` *on an option*. The most important reason is that you run the risk of throwing an exception where you don't expect it. In this example we're checking if the option is defined first, so the `.get` is technically safe here, but it's easy to forget to perform that check every time. Even if you *do* check if an option is defined every time before using it, this pattern is pretty clunky and gets tedious very quickly - and if you know anything about Scala developers, we hate repetitive tedious syntax. We can definitely write this in a more pleasing way, so there's basically no reason to ever use `.get`. ### Default values Another easy way to deal with options is to just use a default value if the option is empty. This is fairly straight-forward to do with the `.getOrElse` method. This is a pretty common method of handling options. ```scala def getName(maybeName: Option[String]): String = { maybeName.getOrElse("User has no name - sounds sketchy") } ``` Pretty simple, right? ### Pattern matching Pattern matching may be the closest analogue to our first example with `.get`. Just like pattern matching in general, using it on options allows you to easily take specific actions on all the different possibilities of values. ```scala def matchOnName(maybeName: Option[String]): String = { maybeName match { case None => "User has no name - sounds sketchy" case Some(name) => name } } ``` You can easily get the underlying value of the `Some` with pattern matching as shown above. ## Options as Collections Using options as if they were collections is probably more conceptually difficult for new Scala developers but it delivers on the promise of elegant, idiomatic Scala that you should expect. Think of options as collections with a maximum of one element -- so it's either an empty collection(`None`), or a collection with just one element whose type is the `A` in `Option[A]`. Now that we have this special type of collection that can only be one element long, what can we do with it? Basically everything that a collection can do, which is what makes this comparison so powerful. Let's take a look at some of the most common methods we use on a collection that we can also use on an option: `map`, `foreach`, `flatMap`, `flatten`, `fold`, `filter/filterNot`, and `collect`. We'll also cover `.getOrElse` a little more and a similar method, `.orElse`. ### .map We can apply a function to the value contained in an option with the use of map. This works just like in a collection where we go through each element and apply some function. In the case that the option is empty, it just gets mapped to an empty option -- just like mapping on an empty collection. ```scala val maybeInt: Option[Int] = Some(21) val maybeIntEmpty: Option[Int] = None maybeInt.map(x => x * 2) // Some(42) maybeIntEmpty.map(x => x *2) // None ``` ![Scala Option.map visualized as a collection](/files/-LtbK9BPsRLFzsMtVN78) While this is a perfectly suitable use for mapping with a transformative function, perhaps a more common use case is pulling out properties of a class that's wrapped in an option because it can get tedious quickly: ```scala case class Player(name: String, points: Int, height: Option[Double]) val maybePlayer: Option[Player] = Some(Player("Anthony Davis", 23, Some(2.08))) val maybeName: Option[String] = maybePlayer match { case None => None case Some(player) => Some(player.name) } ``` We can replace that whole match with a single map: ```scala val maybeName: Option[String] = maybePlayer.map(p => p.name) ``` We really only want to do something when `maybePlayer` has a value. Let's get into our options-as-collections mindset: mapping on an empty collection always gives back an empty collection--in the case of options, `None`s always map to `None`. `Some`s work exactly like you'd expect a normal collection to map, just with a maximum of one element. We apply the function `p => p.name` to each element of the "collection", so empty options stay as is, and non-empty options get the function applied to them and we get the result of the function application. If you know a little bit of Scala syntactic sugar, you know we can further reduce this down to `maybePlayer.map(_.name)` for some real clean, concise beauty. ### .getOrElse We can also use maps in conjunction with `.getOrElse` that we used before since mapping returns another option. ```scala val name: String = maybePlayer.map(_.name).getOrElse("No player") ``` Since `.map` returns an `Option`, we can chain on a `.getOrElse` which will evaluate to the person's name if `maybePlayer` is defined, or "No player" otherwise. ### .orElse A similar method is `.orElse`, which, lets us provide a default value (just like `.getOrElse`). However, instead of providing a default value of type `A` we provide one of type `Option[A]`. While `.getOrElse` lets us either extract the contained value or provide a default both of type `A`, `.orElse` gives us the still-contained original value or a completely different option as a default. We can easily chain on as many as we'd like to get us many different possibilities. For whatever reason, you'll often see `.orElse` called using infix notation, i.e. without a dot. ```scala val noValue: Option[String] = None val stillNoValue: Option[String] = None noValue orElse stillNoValue // Infix // > None noValue.orElse(stillNoValue) // Dot notation // > None noValue orElse stillNoValue getOrElse "I am something!" // Infix // > I am something! noValue.orElse(stillNoValue).getOrElse("I am something!") // Dot notation // > I am something! ``` The infix notation starts looking a little weird to me once you start chaining, so I personally avoid it . In general, I basically avoid infix notation entirely unless the operator is a symbol. ### .foreach `.foreach` works almost exactly like `.map` does (just like its collection-based equivalent) except it's only meant for performing some side-effect, i.e. returns `Unit`. If the option has a value, execute some function, otherwise do nothing. ```scala maybePlayer.foreach(p => println(p)) // or even simpler maybePlayer.foreach(println) ``` ### .flatMap and .flatten Just like in collections, flat mapping helps us avoid nesting values unnecessarily. If the function that we're using to map returns an option itself, it's probably best to use flat map to avoid something like `Option[Option[A]]`, which can quickly become a nuisance to use. Flatten should be straight-forward if you've ever used it on a collection: `.flatMap` is equivalent to `.map(...).flatten`. In our `Player` class, `height` could be missing, since it's an `Option[Double]`--flat mapping gives us a clean way to extract that data. ```scala val maybeKD: Option[Player] = Some(Player("Kevin Durant", 27, Some(2.06))) val maybeGiannis: Option[Player] = Some(Player("Giannis Antetokounmpo", 18, None)) // Using a normal map - Nasty! maybeKD.map(_.height) // Some(Some(2.06)) maybeGiannis.map(_.height) // Some(None) // Flat mapping - Clean! maybeKD.flatMap(_.height) // Some(2.06) maybeKD.map(_.height).flatten // Some(2.06) maybeGiannis.flatMap(_.height) // None val noPlayer: Option[Player] = None noPlayer.map(_.height) // None noPlayer.flatMap(_.height) // None ``` This also enables us to cleanly provide a default value as well. ```scala // Using a normal map - Nasty! maybeKD.map(_.height).getOrElse(0.0) // Some(2.06): Any maybeKD.map(_.height.getOrElse(0.0)).getOrElse(0.0) // 2.06: Double maybeGiannis.map(_.height).getOrElse(0.0) // None: Any maybeGiannis.map(_.height.getOrElse(0.0)).getOrElse(0.0) // 0.0: Double // Flat mapping - Clean! maybeKD.flatMap(_.height).getOrElse(0.0) // 2.06 maybeGiannis.flatMap(_.height).getOrElse(0.0) // None ``` Notice the bad type inference on the lines where we don't do `.getOrElse` in the function passed to `.map`. The compiler infers an `Any` because the resulting type when evaluating *just the map* is `Option[Option[Double]]`, so calling `.get` on it would give back `Option[Double]` and we're providing a `Double` as a default value. This forces us to also throw on a `.getOrElse` in the map to get type we want-- so use flat map instead! ### .fold Folding with options works almost identically to the `.map(...).getOrElse` pattern we saw before except in reverse order -- the default value comes first. Let's compare the two approaches: ```scala val maybePlayer: Option[Player] = Some(Player("Joel Embiid", 23, Some(2.13))) maybePlayer.map(_.name).getOrElse("No player") // "Joel Embiid" maybePlayer.fold("No player")(_.name) // "Joel Embiid" noPlayer.map(_.name).getOrElse("No player") // "No player" noPlayer.fold("No player")(_.name) // "No player" ``` They're visually similar and functionally identical. I tend to go the `.map` & `.getOrElse` route because its more intuitive to me to have the default value defined after. Whatever floats your boat here is fine. ### .filter and .filterNot These methods work the same as their collection-based counterparts. For `.filter`, if an element satisfies a predicate, it remains in, otherwise it gets filtered out . `.filterNot` simply inverts the predicate, as its name implies. Since there's only one "element" in an option, the predicate is only checked once. Filtering an option can make a `Some` turn into either a `Some` or `None`, but filtering on a `None` will always give back a `None`. ```scala val maybePlayer: Option[Player] = Some(Player("Russell Westbrook", 24, Some(1.90))) maybePlayer.filter(x => x.points > 20) // Some(maybePlayer) maybePlayer.filter(_.points > 30) // None maybePlayer.filterNot(_.points > 20) // None maybePlayer.filterNot(_.points > 30) // Some(maybePlayer) noPlayer.filter(_.points > 20) // None noPlayer.filterNot(_.points > 20) // None ``` ### .collect In my opinion, `.collect` on options is mostly not that useful. All operations you can do with a collect you could also do with a map. What separates them is that collect accepts a partial function whereas map accepts a plain function (which means it can also accept a partial function), and even then the implementation of collect on `Option` actually calls `lift` on the partial function, which converts it to a plain function. That implementation detail is actually the one thing that collect has over map -- you won't run into `MatchError`s with collect. ```scala val maybePlayer: Option[Player] = Some(Player("Chris Paul", 19, Some(1.83))) maybePlayer.map({ case p if p.points < 10 => "Low" case p if p.points > 30 => "High" }) // > MatchError! maybePlayer.collect({ case p if p.points < 10 => "Low" case p if p.points > 30 => "High" }) // > None ``` As you can see, both map and collect accept partial functions as parameters but collect is safe from match errors. That said, this would be a rare use case as I'd say most partial functions for a collect don't have a possibility for `MatchError`s anyway, so I typically find it of little utility. ## Boolean Helpers There are a few helpful methods that can concisely and idiomatically express common Boolean checks performed on options. Although these are technically still collection-like methods, I'd categorize them differently in my mental model because in the context of options they're more like convenient shorthands than collection methods. For each of these, I'll give you what the actual implementation for them is (they're extremely short) and explain it in plain English to try and help give you intuition on how to use them. I'll also provide some alternative ways to write the same expression to give you and understanding of situations where you might use them. ### .contains ```scala def contains[A1 >: A](elem: A1): Boolean = !isEmpty && this.get == elem ``` This implementation is extremely simple, right? An option *contains* element `elem` if the option is *not empty* **AND** the underlying value of the option is equal to `elem`. This explanation should allow you think up what the truth table looks like for this. If the option is empty (`None`) it can't contain anything! If you think of this expression in plain english you can easily tell what the evaluation should be by asking *does my option contain this value*? ```scala val dame: Player = Player("Damian Lillard", 23, Some(1.9)) val maybeDame: Option[Player] = Some(dame) // Contains maybeDame.contains(dame) // true // Longer alternatives // 1. maybeDame.map(_ == dame).getOrElse(false) // 2. maybeDame match { case Some(d) if d == dame => true case _ => false } // 3. maybeDame.collect({ case d if d == dame => true}).getOrElse(false) ``` Looking at the alternative forms, it's easy to see why we'd prefer `.contains`. These next two examples will use a variable `p`, which gets passed as an argument to the methods. `p` is a function `A => Boolean`, i.e. a function that accepts a value of your option's contained type, `A`, and returns a Boolean. It's `p` for predicate -- we're checking whether an element of type `A` *satisfies the predicate* `p`, which returns true or false accordingly. ### .exists ```scala def exists(p: A => Boolean): Boolean = !isEmpty && p(this.get) ``` Read this as: there *exists* a value in this option that satisfies the *predicate* `p`. If this looks familiar, it's because it's almost exactly the same as `.contains`. `. contains` is basically a specific case of `.exists` where the predicate is `this.get == elem`. ```scala val maybePlayer: Option[Player] = Some(Player("James Harden", 23, Some(1.96))) maybePlayer.exists(_.points > 20) // Alternatives maybePlayer.map(_.points > 20).getOrElse(false) ``` I won't list the other alternatives again since they're mostly the same as for `.contains`. This is a convenient and concise way to do simple Boolean checks on the underlying value of an option. ### .forall ```scala def forall(p: A => Boolean): Boolean = isEmpty || p(this.get) ``` Again, this implementation looks very familiar. The only difference this time is that empty options are acceptable to satisfy the predicate. Let's try to express this in plain english: *every value contained in this option satisfies the predicate* `p`. The key word here is *contained*, because an option that doesn't have any values (`None`) *doesn't have any values that need to satisfy the predicate*. This is expressed with the `||` in the implementation. An *empty option* **OR** a *contained value that satisfies the predicate* both make this evaluate to true. ```scala val maybePlayer: Option[Player] = Some(Player("Kyrie Irving", 22, Some(1.9))) maybePlayer.forall(_.name != "Wardell Curry") // true noPlayer.forall(_.name != "Wardell Curry") // true // Alternatives maybePlayer.map(_.name != "Wardell Curry").getOrElse(true) ``` You'll notice in the alternatives the only difference between this example and `.exists` is that we're using `.getOrElse(true)` instead of `.getOrElse(false)`. If cutting down on code verbosity is one of our goals, these Boolean helper methods certainly get us a step in that direction. ## Simplified Source Code In this section I'll provide a means what I think is an important way to understand Scala: looking directly at the source code. That can sound intimidating, but if you can cut to just the core logic of the code, you'll find it's actually quite simple. If you look at the [source for Options](https://github.com/scala/scala/blob/2.13.x/src/library/scala/Option.scala), it can be a little difficult to follow as you're trying to read past the comments looking for actual code. What I've done is stripped down the option code to just its barest, removing comments, annotations, even some keywords like `final`, and reorganized the methods into what I think are logical groupings to provide you with the cleanest, simplest version of the source without changing the core of it. Most of the type parameters shouldn't be difficult to follow, but the implicits in `.orNull` and `.flatten` aren't obvious, especially with the `<:<` operator. If you'd like a good explanation of how that implicit parameter works, I'd recommend [this excellent and thorough explanation](https://blog.bruchez.name/2015/11/generalized-type-constraints-in-scala.html). But if you just want to understand how options work, you can mostly ignore it. Here's my simplified version of `Option`: ```scala object Option { def apply[A](x: A): Option[A] = if (x == null) None else Some(x) def empty[A] : Option[A] = None } sealed abstract class Option[+A] { // Essential methods def isEmpty: Boolean // Abstract def get: A // Abstract // Idiomatic convenience def isDefined: Boolean = !isEmpty def nonEmpty = isDefined // Default helpers def getOrElse[B >: A](default: => B): B = if (isEmpty) default else this.get def orElse[B >: A](alternative: => Option[B]): Option[B] = if (isEmpty) alternative else this def orNull[A1 >: A](implicit ev: Null <:< A1): A1 = this getOrElse ev(null) // Collection-like methods def map[B](f: A => B): Option[B] = if (isEmpty) None else Some(f(this.get)) def fold[B](ifEmpty: => B)(f: A => B): B = if (isEmpty) ifEmpty else f(this.get) def flatMap[B](f: A => Option[B]): Option[B] = if (isEmpty) None else f(this.get) def flatten[B](implicit ev: A <:< Option[B]): Option[B] = if (isEmpty) None else ev(this.get) def filter(p: A => Boolean): Option[A] = if (isEmpty || p(this.get)) this else None def filterNot(p: A => Boolean): Option[A] = if (isEmpty || !p(this.get)) this else None def foreach[U](f: A => U): Unit = if (!isEmpty) f(this.get) def collect[B](pf: PartialFunction[A, B]): Option[B] = if (!isEmpty) pf.lift(this.get) else None // Boolean helpers def contains[A1 >: A](elem: A1): Boolean = !isEmpty && this.get == elem def exists(p: A => Boolean): Boolean = !isEmpty && p(this.get) def forall(p: A => Boolean): Boolean = isEmpty || p(this.get) // Conversions def iterator: Iterator[A] = if (isEmpty) collection.Iterator.empty else collection.Iterator.single(this.get) def toList: List[A] = if (isEmpty) List() else new ::(this.get, Nil) def toRight[X](left: => X): Either[X, A] = if (isEmpty) Left(left) else Right(this.get) def toLeft[X](right: => X): Either[A, X] = if (isEmpty) Right(right) else Left(this.get) } final case class Some[+A](value: A) extends Option[A] { def isEmpty = false def get = value } case object None extends Option[Nothing] { def isEmpty = true def get = throw new NoSuchElementException("None.get") // DANGEROUS!! } ``` ## Conclusions Options are an inextricable and ubiquitous feature of Scala so it's important you're fully comfortable using and understanding them. Using options is not an option (😎)-- consider it mandatory for writing Scala. I hope this guide helped you navigate these new waters if you're a newer Scala developer or gave you a little more intuition for something you've already been using. # FirebaseApp Client in Scala How to properly load the FirebaseAuth Java client in Scala While I was using the `FirebaseAuth` Java client, I was getting this error: `Execution exception[[IllegalStateException: FirebaseApp name [DEFAULT] already exists!]]` When my Play application reloaded itself, `FirebaseApp.initializeApp()` was getting called again from the application loader, which caused this error. I made a simple wrapper to handle this: ```scala import com.google.auth.oauth2.GoogleCredentials import com.google.firebase.{ FirebaseOptions, FirebaseApp } import scala.util.Try object FirebaseAppLoader { def apply(credentials: GoogleCredentials): FirebaseApp = { Try(FirebaseApp.getInstance()).toEither match { // App hasn't been initialized yet, so we initialize it case Left(_: IllegalStateException) => FirebaseApp.initializeApp( new FirebaseOptions.Builder() .setCredentials(credentials) .build ) // Reuse the already-initialized app case Right(app) => app // Some other exception occurred case Left(e) => throw e } } } ``` We simply just try to get the Firebase app instance (wrapped in a `Try`), and if it doesn't exist, we initialize it, which should happen just once. Using this wrapper is as simple as `val firebaseApp: FirebaseApp = FirebaseAppLoader(credentials)`. Or with macwire, `val firebaseApp: FirebaseApp = wireWith(FirebaseAppLoader(_))`. # Parsing certs/keys from Strings in Scala I found it surprisingly difficult to get a straight answer online about how to parse the text of an RSA key-pair or certificate into their corresponding Java objects. Here's a basic step-by-step of how to do that. (All of this should basically apply to Java as well). A full example is at the bottom. ### Create a factory what you're trying to decode. ```scala // For X.509 certificates val x509CertFactory: CertificateFactory = CertificateFactory.getInstance("X.509") // For RSA keys val rsaKeyFactory: KeyFactory = KeyFactory.getInstance("RSA") ``` ### Strip unnecessary characters. Remove new lines and header/footer tags. ```scala def stripCertText(certText: String): String = certText .stripMargin .replace("\n", "") .replace("-----BEGIN CERTIFICATE-----", "") .replace("-----END CERTIFICATE-----", "") def stripPrivateKeyText(keyText: String): String = keyText .stripMargin .replace("\n", "") .replace("-----BEGIN PRIVATE KEY-----", "") .replace("-----END PRIVATE KEY-----", "") def stripPublicKeyText(keyText: String): String = keyText .stripMargin .replace("\n", "") .replace("-----BEGIN PUBLIC KEY-----", "") .replace("-----END PUBLIC KEY-----", "") ``` {% hint style="info" %} The header/footer tag text may be different depending on what type of key you're decoding. {% endhint %} ### Decode base-64 ```scala val bytes = Base64.getDecoder.decode(strippedKeyText) ``` ### Generate certificate/key ```scala val x509Cert: X509Certificate = x509CertFactory .generateCertificate(new ByteArrayInputStream(certBytes)) .asInstanceOf[X509Certificate] // Needs to get cast because CertificateFactory is lame val rsaPublicKey: PublicKey = rsaKeyFactory.generatePublic(new X509EncodedKeySpec(bytes)) val rsaPrivateKey: PrivateKey = rsaKeyFactory.generatePrivate(new PKCS8EncodedKeySpec(bytes)) ``` {% hint style="info" %} Use the `EncodedKeySpec` based on the type of your keys. In this example, I used `X509EncodedKeySpec` for the public key and `PKCS8EncodedKeySpec` for the private key. The certificate factory just takes in a `ByteArrayInputStream`. {% endhint %} ### Full example for parsing a certificate: ```scala import java.io.ByteArrayInputStream import java.security.cert.{ CertificateFactory, X509Certificate } import java.util.Base64 val certText: String = "-----BEGIN CERTIFICATE-----\nMIIDHDCCAgSgAwIBAgIIW <...> IeilJ1C7Xtj+hKJEsk=-----END CERTIFICATE-----\n" val factory: CertificateFactory = CertificateFactory.getInstance("X.509") val strippedCertText: String = certText .stripMargin .replace("\n", "") .replace("-----BEGIN CERTIFICATE-----", "") .replace("-----END CERTIFICATE-----", "") val certBytes: Array[Byte] = Base64.getDecoder.decode(strippedCertText) val certByteArrayInputStream: ByteArrayInputStream = new ByteArrayInputStream(certBytes) val x509Cert: X509Certificate = factory.generateCertificate(certByteArrayInputStream).asInstanceOf[X509Certificate] ``` # ZIO Striped Locking My implementation of a striped lock using ZIO ## Background A striped lock is a concurrency mechanism that assigns locks to callers, which are divided into "stripes". Conceptually, it might be helpful to think of this as a map of a "key" type to "locks" e.g. `Map[Int, Lock]` where `Lock` is just some synchronization mechanism like a `Semaphore`. The type of the key can be anything. The idea is that any effects requesting a lock with equivalent keys will always run independently of each. While it *is* guaranteed that *equivalent* keys will *always* point to the same lock, it *is not* guaranteed that *non-equivalent* keys will *not* point to the same lock. Put simply, it means that there is a possibility that effects that are not required to run independently of each other could still be forced to do so. ## Motivation The reason you may want something like this (i.e. the reason I made it) is to guarantee atomicity of effects that could possibly work on the same resource. Consider the following example. You need to run a task that synchronizes an internal resource to an external system/API whenever it gets updated internally. There is no guarantee of an atomic transaction with the external system like there would be if you were just communicating with a relational database that supports transactions (in which case you could just rely on the database to guarantee atomicity). You would need to ensure only one such task is being executed at a time for any given internal resource. For example: 1. An update to resource with id `42` is made 2. Your system then starts executing a task to sync this internal resource to an external system (Task #1) 3. While that update task is running, another update to resource with id `42` is made, triggering a new task (Task #2). This task should await the completion of the already-running task (Task #1) before starting 4. Task #1 completes 5. Task #2 begins execution and later completes Technically, this could be trivially achieved by only letting one task for *any* resource run at a time, e.g. a simple queue of tasks or a semaphore with a single permit. However, that unnecessary blocks parallel runs of tasks that are non-competitive with each other. In the above example, consider that in step 3, an update to a resource with a *different* id is made – there would be no reason to await the completion of Task #1 in that case, so the execution should proceed as normal. The tradeoffs between multiple approaches is described well in the documentation for Google's Guava implementation of a striped lock: > The crudest way to \[associate a lock with an object] is to associate every key with the same lock, which results in the coarsest synchronization possible. On the other hand, you can associate every distinct key with a different lock, but this requires linear memory consumption and concurrency management for the system of locks itself, as new keys are discovered. > > `Striped` allows the programmer to select a number of locks, which are distributed between keys based on their hash code. This allows the programmer to dynamically select a tradeoff between concurrency and memory consumption, while retaining the key invariant that if `key1.equals(key2)`, then `striped.get(key1) == striped.get(key2)`. A single lock unnecessarily restricts concurrency, while one-lock-per-key is unnecessarily memory intensive, requires synchronization on the locking mechanism itself, and has essentially unbounded concurrency. The ~~porridge~~ locking mechanism that's *just right*, in this case, is a striped lock. ## Code Here's what the lock itself looks like: ```scala import zio._ import zio.Semaphore class StripedLock(private val locksRef: Ref[Vector[Semaphore]]) { def useLock[R, E, A](value: => Any)(effect: ZIO[R, E, A]): ZIO[R, E, A] = { for { locks <- locksRef.get lock <- ZIO.succeed(locks(value.hashCode().abs % locks.length)) res <- lock.withPermit(effect) } yield res } } object StripedLock { def make(size: Int = 1 << 10): UIO[StripedLock] = { for { semaphores <- UIO.foreach((0 until size).toVector)(_ => Semaphore.make(1)) ref <- Ref.make(semaphores) } yield new StripedLock(ref) } } ``` Here's a small example that demonstrates its usage: ```scala import zio._ import zio.console._ import zio.clock._ import zio.duration._ import zio.random._ object Main extends zio.App { def run(args: List[String]) = main.exitCode val main = { val Size = 10 val MinTime = 2 val MaxTime = 5 def getKey(id: Int): Int = id % 2 def longProcess(id: Int) = for { int <- nextIntBetween(MinTime, MaxTime) _ <- putStrLn(s"[${"+%02d".format(id)}] [${getKey(id)}] Starting – working for ${int}s ...") _ <- sleep(int.seconds) _ <- putStrLn(s"[${"-%02d".format(id)}] [${getKey(id)}] Complete") } yield () for { lock <- StripedLock.make() _ <- ZIO.foreachParN(Size)(0 until Size)(id => lock.useLock(getKey(id))(longProcess(id))) } yield () } } ``` There are `Size` "jobs" being executed all in parallel, with their keys being determined by `id % 2`, i.e. all odd numbers share one lock, and even numbers share another. We should expect that only one odd-numbered id and one even-numbered id job should run at a time. You can change the implementation of `getKey` to test other key collision scenarios. ## Don't sue me I can't guarantee that this approach is completely correct/efficient/etc. I still consider myself a novice ZIO user so maybe I did something totally wrong (let me know if I did!). I haven't done load testing so I can't speak to the scalability of this or the "correct" amount of locks to use for any given use case. `1024` "just seemed like the right thing to do" (there is a `1/1024` chance that a lock is shared between keys that didn't need to share one). #### Inspiration and References {% embed url="" %} {% embed url="" %} {% embed url="" %} # Option in Typescript Implementing an Option type in Typescript After working regularly with some of the features in Scala, it becomes difficult to go without them. Front end code is one of the places where this pain feels the worst. Options are one of those features that you really do miss when you're forced to be without them. As a sort of follow up to the last post, I decided to shoehorn Options into the web with Typescript. I'd been using React with Flow for a couple of years and really liked it. Having any level of type-saftey over vanilla JS was a big improvement. Recently, I finally decided to bite the bullet and give Typescript a shot after hearing so many good things about it. I have no doubt anymore that Typescript is superior to es6 + flow. It catches way more issues that flow doesn't and there's an overall higher level of confidence I have with Typescript that just isn't there with flow. Plus, the community seems more engaged and growing by the day. ## Options for the Front End I decided I had enough of dealing with `null` and `undefined` in front end code. I wrote a small library to implement an `Option` type in Typescript. It's based on the Scala code for `Option`--the simlarities should be clear on a visual inspection. You can find that library here: It's published to npm as well with the package name `@alanqthomas/option`. ## The Syntax Struggle The most difficult part of making this library was trying to get the usage mechanisms as close to Scala as possible. A major point of emphasis for me was trying to get rid of the tedious `new` operator. I scoured the internet in search of answers and I came out with the best hack I could find that still played nice with type parameters. The actual classes are suffixed with an underscore, there's a type alias to the class without the underscore, and then a factory function that spits out new instances, also without the underscore. ```typescript class Some_ { ... } type Some = Some_ function Some(value: T): Some { ... } ``` Type annotations in the IDE (VSCode) now show the types as `Some_` instead of just `Some`. It's a tradeoff I'm willing to make to have `Some(42)` instead of `new Some(42)`. I also implemented a pseudo-match statement that looks something like this: ```typescript const some = Some(42) const val = some.match({ some: x => x + 2, none: () => 0 }) ``` It uses an object with `some` and `none` keys as a parameter to mimic the syntax of a `match` in Scala. If anyone knows a better way to do this, *please* let me know. ## Type Safety For Everyone All in all, I'm pretty satisfied with how this small library turned out and I'm going to try more to put it through the ringer of real life code-writing to see if it stands up as well as I hope. I also have a mostly complete version of Scala's `Either` type in the works, but that'll have to wait for another post. # Redux Without Boilerplate Setting State in Redux Without Action Boilerplate Recently, I've been thinking a fair bit about Redux and front end application state management in general. I do really like Redux and I think it's changed the way a lot of us think about state management. That said, many people, myself included, complain about the verbosity and amount of boilerplate required to implement even the simplest of functionality. In this post I'll explore one method I've come up with to reduce some redux boilerplate. ## Disclaimer I want to be very clear before I begin that this idea is hot off the presses of my mind. That is to say I'm not entirely sure if this is a good pattern or what kind of issues this could create in a larger application. Unrelatedly, I'll be using Typescript for everything here. It's mostly inconsequential besides the last section regarding type safety. So with that out of the way, let's dive into it. ## Boilerplate Hell Consider the things we do in Redux that have a high LOC/functional simplicity ratio, in other words, things that make you say "I have to write so much to do something so simple". Making simple updates to Redux state is definitely up there in this regard. You need to make a new action type, an action creator, if you're using Typescript you may need to define a new type for the action, and finally, you need to add a new case to a reducer to handle the new action that combines the new value into the global state. This typically requires touching two or three separate files in addition to the component you're working in. On the other hand, setting local component state is extremely easy in React: ```javascript this.setState({ title: "Reducks" }) ``` ## Paring Down Our Code I think we can get (mostly) to the `this.setState` level of simplicity with a relatively small amount of code and a little bit of library help. I want to create a reducer that handles a single generalized action type that holds the path to the field we want to set and the value we want to set there. Let's look at an example to work with. This is a fairly basic reducer: ```typescript export type Post = { title: string, body: string } export interface PostState { post: Post } export const initialPostState: PostState = { post: { title: "Redux State is Cool", body: "We can change global state in Redux" } } export default (state: PostState = initialPostState, action: PostAction): PostState => { switch (action.type) { case actions.POST_SET_TITLE: const { title } = action.payload return { ...state, post: { ...state.post, title } } case actions.POST_SET_BODY: const { body } = action.payload return { ...state, post: { ...state.post, body } } default: return state } } ``` And a fairly standard way to plug it into our Redux store: ```typescript export type RootState = { posts: PostState } export const initialRootState: RootState = { posts: initialPostState } const reducers = combineReducers({ posts }) ``` Now we have `reducers`, which is a combined reducer that can handle all of our actions as. Of course, there would be other sub-reducers here besides just `posts`, but this is just for the sake of example. Now lets add a new action and a special action handler on our root-level reducer: ```typescript // action export enum GlobalActionType { GLOBAL_SET_STATE = "global/SET_STATE" } export const setGlobal = (path: string | string[], value: any) => ({ type: GlobalActionType.GLOBAL_SET_STATE, payload: { path, value } }) ... // reducer import dotProp from 'dot-prop-immutable' const sliceReducers = combineReducers({ posts }) export default (state: RootState = initialRootState, action: AnyAction): RootState => { switch (action.type) { case GlobalActionType.GLOBAL_SET_STATE: const { path, value } = action.payload return dotProp.set(state, path, value) default: return sliceReducers(state, action) } } ``` Now we have a new action that contains the path in the state tree to the value we want to set and the value we want to set it to, just like we mentioned before. Then we created a new reducer function that will act as our root reducer. It handles our one new action, otherwise it defers to the normal reducer created with `combineReducers`. This has to be done at the root-level reducer because we want it to have access to the full state tree. We can't just add it as another reducer we pass into `combineReducers` because then it would just have access to its own separate section of our global state tree. In our action handler, we use [dot-prop-immutable](https://github.com/debitoor/dot-prop-immutable) to handle the immutable state update, which is a great library to handle immutable updates of a deep state tree using a path string. It's as simple as it sounds. If we want to update `title` in `{ posts: { post: { title, body } } }`, we just do `dotProp.set("posts.post.title", "Our new value")`, and it handles updating the root object immutably. Let's look at how we can use this in a component. ``` ``` Just feed in the `setGlobal` action creator to your component just like you'd do with any action creator, i.e. through `connect` and `mapDispatchToProps`. And, well, that's it! We have an easy way to update *any* piece of your redux state tree without creating a new action type or creator for each one. At this point, we can actually get rid of our traditional action types, action creators, and reducers for our `posts`, since we can just set them both with `setGlobal`. Now, if referencing parts of your state tree with strings hurts you as much as it does me, then let's try to do better. I *am* using Typescript here after all. ## Type Safety We need to make a way to get the path to any value in our state tree in a type-safe manner. What's required to do this is an object that's a complete representation of our entire state tree. Luckily, we have `initialRooteState`, which has initial values for every piece of data in the root state tree. Ensure that every possible piece of state is defined in the object where it should be, even if it doesn't have some initial value because we need all the key names of every piece of state. We want to create a representation of our state object with all the same keys and where each key has a property that contains a string path to it. We can use Typescript's mapped types and some object traversal code for this. ```typescript interface StatePath { $p: string } type PathTransform = { [K in keyof T]: PathTransform & StatePath } function generatePaths(obj: T, prefix = ""): PathTransform { const keys: string[] = Object.keys(obj); const pathPrefix = prefix ? `${prefix}.` : ""; return keys.reduce((result, key) => { const path = `${pathPrefix}${key}` const val: any = (obj as any)[key] if (isObject(val)) { (result as any)[key] = { $p: path, ...generatePaths(val, path) } } else (result as any)[key] = { $p: path } return result; }, {} as PathTransform); } ``` I'm using `lodash`'s `isObject` function here, but you could just as easily implement this function yourself. `generatePath` recursively traverses the object and adds a property `$p` with the path to that key. I won't get into the technicals of how these types and function works--I'll leave that as an exercise for the reader. For example, this: ```javascript { posts: { post: { title: "" } } } ``` turns into this: ```javascript { posts: { $p: "posts", post: { $p: "posts.post", title: { $p: "posts.post.title" } } } } ``` ### I'm only using `$p` to cut down on the length of these references as much as possible. This saves 2 characters (two whole characters!!) over the word `path` So if we want the path to `title`, we can get it from our object of paths: `generatedPaths.posts.post.title.$p`. Now we get auto-completion and Typescript will let us know if we're referencing a key that doesn't exist. The great thing about this approach is that it's generated dynamically, so as long as we keep our initial state object in accordance with our actual state tree, we have type safety baked right in. I had originally considered an approach that would requiring running a script to generate this object of paths that would require a re-run every time the state tree changed *at all*. That would certainly be a huge pain. Let's look at an example of using this in a component: ``` import $p from '../redux/statePaths' ``` And just some proof that the auto-completion works for the haters 😎 ![Nested path autocompletion](/files/-LtbKSbReXOq_3oZVNnS) ## Examples I've put together [a small React project](https://github.com/alanqthomas/redux-set-global) illustrating everything I mentioned in this post. Hopefully it will put together any pieces together that I left out here so you can get a complete picture of what this implementation would look like. ## Looking Forward To be clear, there's nothing stopping us from simply using nested objects to define our state updates, just like we would with `this.setState` in a React component. The reason I chose to go with `dotProp` is that state trees tend to have more than a few levels of depth, so string paths with `dot-prop-immutable` seemed like the least verbose way to do it. There are some great improvements that could be made here with React hooks. It could cut down the boilerplate even further by not having to pass in `setGlobal` to `mapDispatchToProps`. Even futher, you could use hooks to cut down on boilerplate to *read* from Redux state too. I'll have to do some more digging into React hooks and see what I can come up with, but it looks like a promising future for boilerplate-less React & Redux. # Redux Middleware Explained How Does Redux Middleware Actually Work? Whether you're looking to add some customization to your Redux workflow or just looking to understand how Redux works a little better, it's great to know exactly what Redux is doing under the hood with middleware. I've been going down this rabbit hole trying to write my own Redux middleware so I thought I'd share my findings. Fortunately for us, Redux turns out to be fairly simple, so let's take a closer look at the Redux source code and try to figure out what's going on. I'll pull examples from the Redux source code and type definitions, but I'll be stripping it down for simplicity, mostly removing some error-handling and subscription management code (subscriptions aren't particularly relevant for us here). Let's start with the primitives and work our way up. *Examples are based on Redux `4.0.4`* ## What is an `Action`? ```typescript export interface Action { type: T } ``` Most strictly, an `Action` is an object with a field `type`. More usefully, an `Action` describes *what* change should be made to the application state. ## What is a `Reducer`? ```typescript export type Reducer = ( state: S | undefined, action: A ) => S ``` A `Reducer` is a function that, given an existing state and an `Action`, produces the state that should exist after the `Action` has been applied. If an `Action` describes *what* changes should be made, a `Reducer` describes *how* that change should be made. ## What is a `Store`? Very simply, it's just an object that provides us a way to get the current application state (`getState()`) and provides a `dispatch` function that allows us to send `Action`s to our `Reducer`s. A simplified interface would be something like this: ```typescript interface Store { dispatch: Dispatch getState(): S } ``` We create our Redux store using the `createStore` function, which, well, creates our `Store`. More importantly, it contains some important variables that will get used by functions like `dispatch`. ```javascript function createStore(reducer, preloadedState, enhancer) { ... let currentReducer = reducer let currentState = preloadedState let currentListeners = [] let nextListeners = currentListeners let isDispatching = false ... } ``` What's important is that `dispatch` and other functions are also created in `createStore`, meaning that these variables are closed over, i.e. `dispatch` will have access to these variables, and we'll see how it uses them next. ## What does `dispatch` actually do? I'll be honest, I was a little surprised at just how simple the `dispatch` function is when I first saw it (though I don't really know what I expected). You'll see that is uses those variables defined in `createStore` from before. Here's a stripped down version, showing just the meat of it: ```javascript function dispatch(action) { try { isDispatching = true currentState = currentReducer(currentState, action) } finally { isDispatching = false } return action ``` Well, that's about it. It reassigns `currentState` to the new application state the reducer spit out in response to an `Action`. Keep in mind, there is only *one* `Reducer` – don't let the variable name `currentReducer` throw you off. It's only "current", because of some functionality Redux provides for dynamically loading reducers that isn't relevant for us here. Speaking of which, how does Redux make all our different reducers act as one? ## How does Redux combine reducers? Redux provides the `combineReducers` function, which takes a object-map of sub-reducers and returns a single function, i.e. a `Reducer`, that invokes all of them. Here's a simplified version of `combineReducers`. ```javascript function combineReducers(reducers) { return (state = {}, action) => { let hasChanged = false const nextState = {} for (const reducerKey in reducers) { const reducer = reducers[reducerKey] const previousStateForKey = state[reducerKey] const nextStateForKey = reducer(previousStateForKey, action) nextState[key] = nextStateForKey hasChanged = hasChanged || nextStateForKey !== previousStateForKey } return hasChanged ? nextState : state } } ``` Again, just like `dispatch`, this is actually pretty simple. We go through all the sub-reducers we have, pass it existing state and the action, and collect all those results into a new state object. ## What does a Redux `Middleware` look like? Middleware is where this gets a little more complicated (which is why it was important to go over the building blocks!). Middleware allows us to add all sorts of functionality to Redux between the points when an action is first dispatched to when it's sent to the reducer. It also allows us to enhance the `dispatch` function to add to its capabilities. Let's examine all the relevant code. ### `MiddlewareAPI` ```typescript export interface MiddlewareAPI { dispatch: D getState(): S } ``` A `MiddlewareAPI` is what gives our middleware access to `dispatch` and a way to get the current state. Simple enough. ### `Middleware` ```typescript export interface Middleware< DispatchExt = {}, S = any, D extends Dispatch = Dispatch > { (api: MiddlewareAPI): ( next: Dispatch ) => (action: any) => any } ``` This type definition might be a little hard to follow, but notice that the last function in the signature just takes in an action, i.e. the same as `dispatch`. I think the best way to think about it is that every middleware is actually just a `dispatch` that has a handle to the *next* dispatch in the chain. So really, our middlewares are just custom `dispatch`s that handle the action in some way and then pass the action off to the next dispatch. You may need to stew on that for a minute and make sure you understand it. The reason this signature needs to be curried is that the custom `dispatch` we create needs access to the `MiddlewareAPI` and a handle to the next middleware/dispatch in our middleware chain. All that happens in `applyMiddleware`. ### `applyMiddleware` ```typescript export function applyMiddleware(...middlewares: Array): StoreEnhancer ``` Basic type definition. ```javascript export default function applyMiddleware(...middlewares) { return createStore => (...args) => { const store = createStore(...args) let dispatch const middlewareAPI = { getState: store.getState, dispatch: (...args) => dispatch(...args) } const chain = middlewares.map(middleware => middleware(middlewareAPI)) dispatch = compose(...chain)(store.dispatch) return { ...store, dispatch } } } ``` *I'm assuming you have a baseline understanding of curried functions in JavaScript here* I think a helpful way to conceptualize deeply curried functions is as just a single function with multiple 'layers' of parameters. The 'layers' get 'peeled off' when you apply a argument to it, which allows us to share common data between multiple curried functions. In this way, a `Middleware` is a curried function with three layers – an `APIMiddleware`, a `Dispatch`, and finally an `Action`. `applyMiddleware` 'peels off' two layers of our `Middleware`s, creating a single function that becomes our Redux Store's `dispatch`. To 'peel off' the first layer, we first create a `MiddlewareAPI` from our newly created store and give all our middlewares access to it with `middlewares.map(middleware => middleware(middlewareAPI))`. To 'peel off' the second layer, we chain our `Middleware`s together with the `compose` function. `compose` serially chains multiple functions together into a single function. It's actually not terribly complicated, but it's easier to understand by example: `compose(F, G, H)` turns into `(...args) => F(G(H(...args)))`. (Note that in this chain, the parameters that `H` accepts become the parameters that our newly created chain accepts.) Finally, we call this composed `Middleware` chain with the default `dispatch` from our store. With the second layer peeled off, now our `middlewares` are just normal `dispatch`s (`Action => any`) that have a handle to `next` i.e. the next `dispatch` in the chain. (That means we have to make sure our `Middleware` calls `next` at some point, or the dispatch won't make it to the end i.e. our `Reducer`!) I'll try my best to illustrate that process the best I can. ```javascript const chain = middlewares.map(middleware => middleware(middlewareAPI)) const composedChain = compose(...chain) dispatch = composedChain(store.dispatch) ``` Calling our composed chain with `store.dispatch` will make `store.dispatch` the final `dispatch` in the chain. Here's some pseudocode that outlines how that application would go. ```javascript H(store.dispatch): (action: Action) => { // custom stuff... store.dispatch(action) } G(H): (action: Action) => { // custom stuff... H(action) } F(G): (action: Action) => { // Our new Dispatch! // custom stuff... G(action) } ``` And now here's what our final `dispatch` will look like. This is, again, pseudocode to illustrate how the data flows, not the definitions of the functions. ```javascript (action: Action) => { F(action) -> // custom stuff G(action) -> // custom stuff H(action) -> // custom stuff store.dispatch(action) } ``` The final bit of `applyMiddleware` is returning our `store`, but with `dispatch` overridden to be our custom `dispatch`. ```javascript return { ...store, dispatch } ``` And finally, we've created our Redux store with our middleware applied! ## Try It Out I hope this look into Redux has given you what you need to start tinkering yourself. I did most of this research while figuring out how to create a [custom middleware of my own](https://alanqthomas.io). It's certainly within reach to try it yourself – maybe a logging framework, maybe a network call abstraction layer, maybe something even wilder. Go ahead and tinker with it and see what you can come up with.