I have been a staunch advocate of never blocking on async code. I felt it was always better to use a synchronous API than to run the less efficient state machine generated by the compiler even if there is no chance of deadlock.
But in the specific case of System.Net.HttpClient
with code that cannot go async all the way down (like a console app), isn't it better to take advantage of the connection caching of HttpClient than to use something like WebRequest that must negotiate the TCP session on each invocation?
I'm starting to think the benefits of re-using HttpClient, even if you block with .Result
, outweigh the reasons for using a synchronous API instead.
This is assuming of course that the HttpClient is a shared instance, would be re-used and is operating in a context-free environment like a console app or asp.net core.