Provide async implementation of API

I love the way SimpleDb.Net provides LINQ querying against SimpleDb. Thank you. I'd like to utilize the APIs in an asynchronous manner, though.

This might be best implemented in a separate project/DLL because when you start using async it ripples across your methods and APIs. So I'm thinking of copying the synchronous code into a new project in the solution, for example, 'Cucumber.SimpleDb.Async' and making it asynchronous.

Another option is to keep everything in the same project, add async methods to the interfaces where appropriate, e..g. ISimpleDbContext.SubmitChangesAsync(), and try to branch the async code without affecting the sync code. This would keep the solution structure simpler and provide everything in a single NuGet package.

Thoughts?

Thanks for providing this library,

Richard

[rexm]

Adding async support as a first-class citizen would be fantastic. I agree that it would be a fairly invasive change. But once it's done, all the synchronous calls could be replaced with wrappers around the async versions! And in general, async is even more important now than when I first started this project back in 2010. I'd definitely like to bring the async code back into the master once it's done.

I went ahead and created a dev-async branch to fork so we can reconcile it back more easily when it's ready.

I'll be happy to contribute to your async work as it progresses.

/Rex

[rexm]

How would you propose an async contract for IQueryable<T>?

Great! Thanks for adding me to the project. I'll push to the new branch you created.

How would you propose an async contract for IQueryable?

I'll have to research further, but I'm looking at:

Task-based Asynchronous Pattern support in EF. and IDbAsyncQueryProvider

I'll start with SubmitChangesAsync() :-) and then move to the more difficult async queryable stuff.

I'll be happy to contribute to your async work as it progresses

Thanks!

[rexm]

OK! We're at a good first stop. Having the implementations side-by-side is pretty helpful, in fact. Thank you Richard for putting in all this work.

We're currently on v2.x, and I think bringing async support up to the master could potentially be a 3.0 move. So defining what exactly 3.0 looks like and what we're aiming for...

As far as the shape of the solution, I see a few possibilities:

• Single interface with async-only operations
• Single interface with async and sync operations
• Separate sync and async interfaces
• Other options ??

Thinking aloud:

• Based on Lucian Wischik's guidance in his Async Libraries talk, simply blocking the calling thread while the underlying task completes asynchronously isn't a great idea.
• But, in my experience a lot of intermediate developers still find task-based programming and the async models in .NET to be intimidating. Unfortunately I don't know much about what kinds of developers are using this library or who might be using it in the future... I am wary of simply removing the more simplistic use path if it makes the barrier to entry higher for some devs.
• Don't want to discourage anyone from using async if they want to, or imply it's a second-class citizen in a chiefly sync library.

My questions:

• What are other libraries with similar goals currently doing? Are they keeping sync implementations? When should we start assuming task-based programming is part of the average .NET developer's toolkit?
• Would putting both operation types side-by-side on the same interface be too noisy?
• If we swap out the transport implementation under the hood based on which version of the operation is being invoked,
  • Can we still keep the rest of the stack unduplicated?
  • Are there any other challenges with that approach?
• Any other angles I'm totally missing?

What are other libraries with similar goals currently doing?
I don't really know the goals of the other libraries, but here are a few that I use:

HttpClient: Has only has async IO methods.

StackExchange.Redis: Has both sync and async IO methods. The author has written his own IO infrastructure at the socket level.

EntityFramework: Has both sync and async IO methds. The sync methods must remain there for backwards compatibility. This may be a consideration for SimpleDb.Net also.

When should we start assuming task-based programming is part of the average .NET developer's toolkit?

Even when I didn't understand async/await fully, I knew I could just call Task.Result when I wanted write my code in a synchronous manner. I think Task.Result is pretty simplistic and within reach of the average .NET developer.

Would putting both operation types side-by-side on the same interface be too noisy?

I typically see them side-by-side in Intellisense. In StackExchange.Redis the sync interface derives from the async interface: public interface IDatabase : IRedis, IDatabaseAsync

If we swap out the transport implementation under the hood based on which version of the operation is being invoked,

I'd have to dive into the code and try some things out, but my sense is that you'd have two separate code bases for sync and async because async is a virus that affects your whole call stack.