You might say "Well, that's not a problem, just make those intermediate components that don't care about the connection polymorphic over MonadUnliftIO! Later, when composing the application, they will be injected a repository that does know about the ReaderT and the connection. Problem solved."
That's true, but what if I wanted those intermediate components to be as dumb as possible? Just plain records of functions in IO, no monad transformers, and no polymorphism over the monad, either?
As an alternative to ReaderT and/or polymorphism over the effect monad, I could try to implement some form of "thread-local" storage. 🤔 Some kind of map indexed by ThreadId which would be injected only into those components (like the repository) that require the request-scoped info.
Entries would be allocated / deallocated in the "hoistServer" callback, much like with the ReaderT solution.
Intermediate components could use IO for effects and remain blissfully innocent of the shenanigans.
The problem of course is that this solution would be less type-safe. If the repository expects an entry for the current ThreadId to exist in the map, and we forgot to set it earlier in the "hoistServer" callback, that would be a runtime error.
Add comment