From 4da1dc74954fafe4d21841892bafc955a37ac805 Mon Sep 17 00:00:00 2001 From: muqiuhan Date: Tue, 27 May 2025 06:06:45 +0000 Subject: deploy: 74a1d57ead41454de540829cd6de5ba1f5702bd6 --- .../Dealing-with-complex-dependency-injection-in-FSharp/index.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to '2024/10/18/Dealing-with-complex-dependency-injection-in-FSharp') diff --git a/2024/10/18/Dealing-with-complex-dependency-injection-in-FSharp/index.html b/2024/10/18/Dealing-with-complex-dependency-injection-in-FSharp/index.html index 0516c6bd..eb1d0c53 100644 --- a/2024/10/18/Dealing-with-complex-dependency-injection-in-FSharp/index.html +++ b/2024/10/18/Dealing-with-complex-dependency-injection-in-FSharp/index.html @@ -227,7 +227,7 @@
  • Maybe aside of the logger we may be needing a separate telemetry mechanism to count number of incoming request or password validation failures? That means another parameter.
  • Salt generation is pseudo-random process - it we want our function to be deterministic, we should probably parametrize it over explicitly passed Random as well.
    • -

    As you see, what seemed to be simple task at the beginning can quickly blow up out of proportion. As the number of arguments grows, the more nasty our wiring code eventually becomes. Quite common pattern is to hide all of that nastiness under the carpet a.k.a. composition root. However this doesn’t have to be the case.

    +

    As you see, what seemed to be simple task at the beginning can quickly blow up out of proportion. As the number of arguments grows, the more nasty our wiring code eventually becomes. Quite common pattern is to hide all of that nastiness under the carpet a.k.a. composition root. However this doesn’t have to be the case.

    Below we’ll cover another approach for dealing with dependencies - inspired by Scala ZIO library - using incremental steps, from first principles to monadic bindings.

    Managing dependencies beyond partial application

    Let’s start from how our code from above will eventually look like at the end of this step:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    let changePass env = fun req -> task {
        let! user = Db.fetchUser env req.UserId
        if user.Hash = bcrypt user.Salt req.OldPass then
            let salt = Random.bytes env 32
            do! Db.updateUser env { user with Salt = salt; Hash = bcrypt salt req.NewPass }
            Log.info env "Changed password for user %i" user.Id
            return Ok ()
        else 
            Log.error env "Password change unauthorized: user %i" user.Id
            return Error "Old password is invalid"
    }
    @@ -255,8 +255,8 @@
  • It doesn’t impose specific restrictions on libraries and frameworks.

    • Now we could as well stop here - IMHO this approach is already good and useful for most cases. We can also try to push it further. As you’ve seen, our code now requires quite a lot of env passing around. Could we do something about this? It turns out that yes, we could.

    -

    Reader monad

    Before we continue: what we’re going to cover now is less useful in terms of current state of F# ecosystem for the reasons I’ll mention later.

    -

    The pattern we’ll use here is known as a Reader Monad. While it’s useful in certain situations, it’s not widely used - IMO it’s fault lies in the name itself, which somehow managed to sound both borderline meaningless and scary in ears of many developers.

    +

    Reader monad

    Before we continue: what we’re going to cover now is less useful in terms of current state of F# ecosystem for the reasons I’ll mention later.

    +

    The pattern we’ll use here is known as a Reader Monad. While it’s useful in certain situations, it’s not widely used - IMO it’s fault lies in the name itself, which somehow managed to sound both borderline meaningless and scary in ears of many developers.

    The rest of this blog post will be introduction to this style in F#, however focused solely around problem of dependency management - we’ll ignore other aspects of monads.

    We’ll going to reuse our environment type from above, but now encode it directly into another type we’ll call Effect. Since I’ve mentioned that our pattern has M-word in it, you can safely assume that our handler’s logic will be defined as a lazy sequence of steps to be executed (sounds almost like async/await). In F# we’ll sugar them by using custom computation expression (I’m going to call it effect { ... }) returning our effect type, which we’ll define as:

    1
    [<Struct>] type Effect<'env, 'out> = Effect of ('env -> 'out)
    -- cgit v1.2.3