Providing custom request resolvers in a fiber (or scope)?
effectquery✅Solved!
I'm attempting to (re)build a job processor using Effect where each job is a request for <Data> from <Provider>. Ive got 30+ providers that while all sharing the same interface (eg getData(identifier: string): Data` all need a custom implementation to retrieve <Data>. My approach has been to define getData as a Request, and create a RequestResolver variant for each of my providers. With the idea being that when I spin up my workers (workers are crated per provider for separation of workloads) and inject the appropriate RequestResolver for the getData Request that my worker will make.
However, I'm running into a wall with the injection piece. I thought using Layers (and having a bunch of different create<Provider>Layer() functions I could tie the correct resolver implementation to a worker through a provider configuration object. But I think what I've learned is that you can't us a Layer to inject RequestResolvers -- rather you can only use it to inject service implementations. I'm not sure if Im on the wrong track entirely or if it's just a matter of some additional wiring to get things working.
The pattern I'm closest too, if I were to course correct, I think would be to drop the Request/RequestResolver aspect and go the route of defining/treating getData purely as a service, in which case I could easily get custom implementations injected via layers for my workers. However, I'm keen on sticking with the Request/RequestResolver paradigm because I have the opportunity to make use of batching lookups in some of my provider implementations and would like be able to batch requests across the number of concurrent workers that might be handling workloads for those particular providers.
Can anyone confirm if providing custom request resolvers is a viable approach, or if I need to go another route?
However, I'm running into a wall with the injection piece. I thought using Layers (and having a bunch of different create<Provider>Layer() functions I could tie the correct resolver implementation to a worker through a provider configuration object. But I think what I've learned is that you can't us a Layer to inject RequestResolvers -- rather you can only use it to inject service implementations. I'm not sure if Im on the wrong track entirely or if it's just a matter of some additional wiring to get things working.
The pattern I'm closest too, if I were to course correct, I think would be to drop the Request/RequestResolver aspect and go the route of defining/treating getData purely as a service, in which case I could easily get custom implementations injected via layers for my workers. However, I'm keen on sticking with the Request/RequestResolver paradigm because I have the opportunity to make use of batching lookups in some of my provider implementations and would like be able to batch requests across the number of concurrent workers that might be handling workloads for those particular providers.
Can anyone confirm if providing custom request resolvers is a viable approach, or if I need to go another route?
Was this page helpful?
