0

I am using AddHttpClient and AddResilienceHandler to create and configure HttpClient in HostBuilder that will inject the httpclient in my other projects to handle specific http requests to different websites.

My question is should AddResilienceHandler in the startup code? Some resilience methods are more website specific, like DelayGenerator in AddRetry. Normally such logics are specified in the child projects per website as an example.

Now with AddResilienceHandler, we are shifting the logics to the startup method. Wouldn't it make startup method too complex to code and manage? Surely the child project owners have better idea how to configure and handle retry etc, not the caller of such projects in the startup method.

If we need to config 10+ httpClient with different resilience handlers, startup method will be huge.

In additional, how to access logger in AddResilienceHandler?

Improve this question
3
  • Why don't create IServiceCollection extension methods inside each client project to allow them register whatever HttpClient they need (either resilience handler decorated or pure)? Commented Jul 29, 2024 at 13:43
  • 1
    @PeterCsala yes that is what I ended up with doing. But how to enforce this extension to be called in the start up code for guy wiring up the start up project? Commented Jul 31, 2024 at 9:57
  • As far as I know you can't enforce to implement it and call it. But you can use reflection to call all AddClientSpecificHttpClient methods if you restrict the extension methods' name. Commented Jul 31, 2024 at 20:18

1 Answer 1

Reset to default
0

It's hard to answer that without introducing an opinion on the matter. It mostly depends on the environment you are working with, but in the end it's still up to you to decide. In some cases, it will be beneficial to have HttpClients resilience options set globally. Especially when you are already using startup code for pre-configuring named HttpClients. If you worry about the size of such configuration, just decouple the common pieces, use extension methods and add test coverage.

I'd say the worst you can do here is mix up the two. Have some resilience done deep in the bowels of infrastructure code and some done high up on the DI setup level. That would be a quick way to create a maintenance nightmare. So, no matter how good or bad you think your approach is, above all at least stay consistent. Eventually, if you find a particular approach not working for you, don't just switch to an alternative approach from now on, rework the old code as well. Stay consistent on the codebase level.

In my experience, I've found that pre-configuring HttpClients on the DI level was confusing my coworkers. Even though, I could explain that base address for a particular API client is being set in startup, I'd still receive questions about it during code review. It is hard to disagree that HttpClient configured in such a way is more difficult to comprehend in comparison to HttpClient that is configured just after it is created.

So, as an alternative to having resilience handlers set in startup, you can opt for a common HTTP client that works with abstracted resilience handler, so a specific API-oriented implementation can decide on its own what resilience level is desired and supply resilience options of their choice (such as none).

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Thanks for the comments. I am thinking maybe this start up configuration approach is more to accomplish microservice architecture? Agree that mixing up the configuration is multiple places is a bad approach, need to be more consistent.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.