-
Notifications
You must be signed in to change notification settings - Fork 34
Description
Add async support for various methods such as HttpRequests, etc.
Detailed Description
The current DuoApi library is fully synchronous and relies on HttpWebRequest, StreamReader.ReadToEnd(), and other blocking operations. To better align with modern .NET applications, it would be hugely beneficial to provide async/await-friendly APIs using HttpClient and asynchronous methods such as:
• HttpClient.SendAsync()
• Stream.ReadAsync()
• response.Content.ReadAsStringAsync()
• Task.Delay() (instead of thread-blocking sleeps for backoff logic)
Specifically, it would be amazing to see the following methods updated with async counterparts:
- ApiCall()
- JSONApiCall()
- JSONPagingApiCall()
- And all internal HTTP request and retry logic (AttemptRetriableHttpRequest, etc.)
This would also make the code more maintainable going forward—since .NET 5+ and .NET 6+ heavily recommend HttpClient over HttpWebRequest for performance, security, and testability.
Use Case
Adding async support would:
- Enable non-blocking usage in ASP.NET Core apps (no thread pool starvation).
- Play nice with modern dependency-injected IHttpClientFactory.
- Avoid sync-over-async problems (deadlocks in UI or low-resource scenarios).
- Fit naturally in APIs, background services, and real-time scenarios.
- Provide future-proof performance with lower CPU usage in .NET.
In short: async is the new hotness, and it makes Duo’s integration faster and more reliable for all .NET devs.
Workarounds
Currently, to avoid blocking, developers have to wrap the synchronous methods in Task.Run to run them on thread pool threads. This workaround works, but:
- Consumes extra threads from the thread pool.
- Isn’t true async IO—it’s just a background thread wrapper.
- Can hurt scalability in high-volume scenarios.
- It’s an extra complexity we’d love to ditch!