Use AsyncLocalStorage as a Dependency Injection mechanism.

[avillega]

Describe the problem you are facing

In the resonate sdk there are some interfaces that can be defined by the user or that change its implementation based on the environment it is running on, for example, the store can be a local store when running local only or a remote store when using the Resonate server. These interfaces are defined as Options of the Resonate instances as well as options of each invocation and its children. A lot of the time we have to thread the implementations of these interfaces over many layers of abstraction which kind of breaks the purpose of the abstraction itself, is verbose and error prone.

Describe the solution you'd like

We could use the AsyncLocalStorage API to store the implementations of these interfaces. We have a very clear entry point into an async context which is the call to resonate.run, in this function we could create the AsyncLocalStorage for the async context storing all the implementations of the interfaces for a specific run. This will allow us to have a cleaner internal api as well as making sure that each abstraction layer knows and is concerned about its specific task. This approach still as flexible as the current implementation and allows the users and ourselves to use different implementations of the core interface as needed.

The basic API for AsyncLocalStorage is supported by all major runtimes, node, deno, bun. How ever it is not supported out of the box on the browser. we might need to add a polyfill or something alike if want to support the browser use case.

Note that this solution adds no dependencies except if try to find a polyfill. That we could also implement ourselves on top of the localstorage browser api.

Alternatives you've considered

• Instead of using the AsyncLocalStorage, we could use our Context class to store all the same information. The current way our Contextis implemented wont allow our "context store" pass the invocation abstraction layer. To change that we would need to invert the control of the Context, making the invocation the holder of the Context. This would be a significant re architecture of our platform which could also change the way the sdk has to be used. For example, would it still makes sense to have the Context be the object that has the run method in it?
• Have our own implementation of something similar to AsyncLocalStorage that we can query based on a function name and version and make it Globally accessible. This approach could work, but we have to be careful to make sure we use the right function and version in the specific places. This alternative also breaks our abstraction layers given that a lower layer like the PromiseStore will now have to know and be concerned about more information about the invocation and the call graph that it currently is.