-
Notifications
You must be signed in to change notification settings - Fork 6
Description
Hi,
Could you please reconsider making your API’s async, ie.
Task GetAsync(string userId, string campaignKey);
Task SetAsync(UserStorageMap userStorageMap);
The current interface definition forces one to use sync-over-async hacks which is pure evil. (https://blog.stephencleary.com/2012/07/dont-block-on-async-code.html, https://docs.microsoft.com/en-us/archive/msdn-magazine/2013/march/async-await-best-practices-in-asynchronous-programming, https://tooslowexception.com/the-danger-of-asyncawait-and-result-in-one-picture/)
The argumentation on https://developers.vwo.com/reference#section-why-not-get-method-could-be-asynchronous is missing the reasons for why sync-over-async is very bad, leads to deadlocks and hampers scalability. (This might be okay in JS client side framework, but not in .NET server code.)
I know this is a breaking change, which have ripple effects in other parts of the packge, but currently this forces us to use bad Task.Run() hacks to get this working without deadlocks.