Introduce Effect-TS #223
Description
I want to introduce effect and drastically rewrite large chunks of the codebase.
No seriously, hear me out. The project is still smol-ish, and has poor test coverage. Writing tests will surely uncover lots of bugs, and we already blow through the Sentry error budget every month. Shits leaky.
I recently explored a pet project with effect, starting from type-safe db access with Kysely and ending at a type safe generated client SDK. Effect let me wire that up with explicit dependency injection and type guarantees for emitted errors. That does a ton for clearly reacting to different potential error cases, for retries etc. it would ask us to more precisely describe the boundaries of our world, and force us to explicitly describe how to handle more of those situations.
Effect also comes with very good composition tools. One of our current challenges is with a disparate set of event handlers all providing their own guarantees. Many redundant checks happen each request because of the independent implementations. Effects composition tools (and general rigor it encourages) would help us to more narrowly define our event handlers, or groups of handlers.
There are a lot of tasks that I think become much clearer when viewed as subtasks of this larger "do it robustly and with effect" umbrella task. Issues like #185 or #163 where it feels like more flexible and reusable caching would benefit us, where some must persist to disk and others need to be warmed from the network. I more clearly understand how to provide that in an Effect world.