4 ms·
When you say that a background task should be made into a RESTful API call, I assume you mean that instead of spinning up a local thread to do the work you shou
by mullr 13y ago
When you say that a background task should be made into a RESTful API call, I assume you mean that instead of spinning up a local thread to do the work you should defer it to another service. Certainly you can do that, but async/await is still relevant in that case.
The key question is: while said REST call is happening, what is the caller doing? Normally, he's sitting there and blocking his thread until the call finishes (i.e. consuming one thread from the connection thread pool). With async/await, the thread is released back into the thread pool until the result is ready, then it picks up where it left off.
So anything where you might want to deal with background operations that take a long time (including network / db / filesystem access, i.e. most applications that aren't pure functions) in a connection-oriented system can greatly benefit from async/await. Even if it's just a regular desktop app, it appears to be a useful mechanism for coordinating different background tasks.
- d4nt 13y agoYour point is a good one. Without wanting to get too deep into a design for some hypothetical system, I guess I was thinking that I'd either try and modify the current request such that it can return something to its caller (e.g. Render a web page saying "Loading..." with a setTimeout call in it). Or use .NET's HTTP request library which has a delegate callback option that lets you get on with other stuff.
- jbrechtel 13y agoOne benefit to something like async/await is letting you get on with other stuff without having to murk up your code with callbacks/delegates which read more like GOTOs than async/await.
- potatolicious 13y agoThe problem with delegate/callback patterns with API calls is that you end up having to preserve a lot of state manually, which can be an error-prone process. Any metadata associated with a request must be persisted (and then read back) in painstakingly manual fashion with a delegate pattern, whereas with async (or closures, or...) this information is trivially available on your stack. The nice thing about async vs. typical closures is that it neatly avoids a lot of nested scopes.
- vpeters25 13y agoI was going to say the same thing. As a specific example I am currently working on a web application with multiple, complex views requiring several dropdowns. We noticed a dramatic speedup in these views when we refactored the controller to retrieve data for dropdowns using async/await.