SDK should provide async methods for async operations

[martincostello]

As noted in #51, the SDK does not follow accepted best practices in its use of async/await.

Specifically, the use of Task.Run() to make async calls "fire-and-forget" here:

https://github.com/optimizely/csharp-sdk/blob/17a0271a1f46a9639fbf6275da58891db13f8b9c/OptimizelySDK/Event/Dispatcher/HttpClientEventDispatcher45.cs#L78

At the expense of "returning to the caller immediately", this spawns new tasks to perform the HTTP calls.

A better approach would be to add asynchronous methods to the API, say by introducing a new async version of IOptimizely that the Optimizely class could also implement for integrators to opt into using. This would allow integrators to decide whether to make async tasks fire-and-forget or not, as well as allow CancellationTokens to be flowed to the underlying HttpClient calls where appropriate.

From looking at the code, the calls this flowing of async would apply to are those below:

https://github.com/optimizely/csharp-sdk/blob/17a0271a1f46a9639fbf6275da58891db13f8b9c/OptimizelySDK/Optimizely.cs#L200

https://github.com/optimizely/csharp-sdk/blob/17a0271a1f46a9639fbf6275da58891db13f8b9c/OptimizelySDK/Optimizely.cs#L263

https://github.com/optimizely/csharp-sdk/blob/17a0271a1f46a9639fbf6275da58891db13f8b9c/OptimizelySDK/Optimizely.cs#L376

https://github.com/optimizely/csharp-sdk/blob/17a0271a1f46a9639fbf6275da58891db13f8b9c/OptimizelySDK/Optimizely.cs#L564

Such changes would allow the SDK to be "async all the way down".

[alexsaves]

We'll investigate this suggestion and get back to you!

[TimButterfield]

@alexsaves Any update on this? This continues to be a problem for anyone trying to use the Optimizely sdk from an AWS lambda (for example)? I wrote a blog post about the issues I experienced here and I know a new client of mine is looking at adopting both AWS Lambda and Optimizely using C#.

[mikechu-optimizely]

Hi All,

I'm working through our unresolved C# Issues here and wondering if this is still something pertinent?

Thanks for any updates you all have.

[martincostello]

Yes it is.

[mikechu-optimizely]

Thanks @martincostello.

I've added a spike (FSSDK-8702 for ref) to our pipeline. Sorry that this got dropped so long ago.

My initial thought is that this might take some careful planning and be incorporated after our effort to modernize the SDK early next year.

[mikechu-optimizely]

FSSDK-8702 is still in our active backlog. We have a large feature release in the works, then we can work to modernize the SDK. Thanks for the patience.

[mikechu-optimizely]

We still have the Jira item in our backlog, but it's included in our Q3 Maintenance epic. Thanks for hanging in there.

I am 🤔 hard about the right approach. I'd love to modernize the entire stack, but @martincostello 's route of adding *Async() methods may be the faster solution and provide a stepping stone to the later framework upgrade.

[mikechu-optimizely]

We have planned for QY4 to modernize this SDK.

We want to republish to support multi-version .NET Core and Framework. At the same time we're looking to convert to Task based async/await throughout the stack.

We've moved this Jira item to that epic to ensure we accomplish this goal.