Breeze Web API components should support async
Both the Web API and EF 6 support async. All Breeze .NET server components should support async signatures and perhaps should deprecate the synchronous signatures.
I haven't seen any movement here in a couple of years. Was an async API ever added?
Brent Mcsharry commented
The use case I have for async is not in the save, but on the BeforeSaveEntitiesDelegate. The new user has a field for a url, and I am sending off a HEAD request as part of the validations to check the site exists. To synchronously wait a thread for a web request does not seem optimal.
as an aside, Should this thread be moved from BreezeJs to BreezeSharp feature suggestions?
@ThomasMueller We are aligned.
I absolutely agree. All I'm saying is that there need not be "a lively debate about whether there is any actual advantage to making async calls to a database." The answer, of course, is that in some cases there is an advantage, while in others there is not. Exploring which cases belong in which bucket could be valuable, but there are undeniably cases for both.
My company uses Breeze with Azure SQL Database, and we will almost certainly use elastic database pools when the feature leaves preview, so I am biased toward solutions that support scaling.
I don't think it's a silly at all.
First, it's an observation ... an observation that calls attention to the "silver bullet" affliction which pervades the developer community. Who wouldn't want to know if going async helps or hurts performance under what scenarios?
Second, it's not an argument against adding the async signature. We need to do add an async API and will add it so that you, the developer, have a choice.
Third, it is an argument for retaining the sync API, again, so developers have a choice.
Fourth, while there *may* be relational dbs that scale, they are not many and not many breeze-using companies can/will run their databases in Amazon RDS any time soon (if ever).
WE WILL add an async API. I'm just calling attention to an important caveat.
That seems like a pretty silly argument. There may be cases where async support would not improve performance, but there are absolutely cases where it would. And some relational databases (Azure's new elastic databases, for example) are easily scaled.
AdminAdmin (Admin, Breeze.js) commented
No news yet. BTW, there is a lively debate about whether there is any actual advantage to making async calls to a database. The argument against is that a RDB is not easily scaled and is often the bottle neck. Throwing even more requests at the RDB could create more trouble and wouldn't actually improve overall application throughput. Be careful what you wish for.
Bjørn Isaksen commented
Any news on when we can expect this ? :)
@Thomas - appreciate your perseverance. We will do it ... because the community wants it ... not just because I dropped it in the "ideas" box ;-) It's really only a matter of when.
Thanks as always for the thoughtful comments, Ward. I will definitely look into creating our own async wrapper around SaveChanges so we can perform some of the operations asynchronously. The workflow was just one example; we also perform other async-friendly operations such as logging that use the saveMap and keyMappings arguments.
But you're exactly right -- while async support would be a wonderful enhancement, its absence is not a blocking issue (at least for us). I fully appreciate that this is no small undertaking, and I will carry on happily using Breeze without it! Then again, this was your idea in the first place. ;-)
@Thomas - That is a compelling case.
Not sure that you absolutely need `AfterSaveEntities` for this purpose. You can always wrap the entire business of saving **in your own async `SaveChanges` method** and call into the `ContextProvider` synchronously from inside that wrapper. Then, when `ContextProvider.SaveChanges` returns (synchronously), you can call `await WorkflowInvoker.InvokeAsync()`.
My point is that you probably don't have to invoke the WF at all from inside `AfterSaveEntities`. You only really need `AfterSaveEntities` if you want to manipulate the raw ingredients of the `SaveResult` before they are produced, perhaps within a distributed transaction.
BUT, you really shouldn't have to think about all this. You should have the async signatures for
* `BuildJsonMetadata` // need an async `GetMetadata` too
* `BeforeSaveEntities` // but NOT `BeforeSaveEntity ... keep that synchronous
* `BeforeSaveEntitiesDelegate` // but NOT `BeforeSaveEntityDelegate ... keep that synchronous
* `BeginTransaction` ???
May have to think about async key generation too.
You see that this is not a trivial evolution, especially when you know that we have to write the async tests to go with this substantial API expansion.
It would be nice to have async support simply because we are accessing the database. But it becomes more important when we want to perform other actions from Breeze controllers. For example, we use AfterSaveEntitiesDelegate to invoke a WF workflow. We have to use WorkflowInvoker.Invoke() rather than InvokeAsync() because (unless I am missing something) there is no way to go async all the way down.
Based on <http://blog.stephencleary.com/2014/02/synchronous-and-asynchronous-delegate.html>, I believe AfterSaveEntitiesDelegate would need to become Func<Dictionary<Type, List<EntityInfo>>, List<KeyMapping>, Task> to support async.
I think @giles may have a use case but I don't understand it well enough. Perhaps he (or others) can help me grasp why lack of async support is a blocking issue.
Not yet. We have a few more important items in the queue that are ahead of it.
While I really do want us to support async Web API, if we're honest about it, this is a performance enhancement that delivers value only when you have a lot of people hitting the server. Much as I want to believe that a Breeze app is running into such scaling problems, I lack the evidence for it at this time.
If you have can give me some evidence or make the case for escalating this feature, we'd sure like to hear about it.
I'll try to find out where it is in the schedule
Hi Ward, any updates on this one?
@Giles - while I heartily agree that we should write an async version of these components soon, it is pretty cheeky of you to claim that WE broke your code when it was YOU who changed your code to be incompatible with Breeze. ;-)
Giles Bradshaw commented
My need for it is because I have extended my entity framework contexts (to make use of their change detection to broadcast changes) in such a way that changes must be saved asynchronously. So breeze not saving changes asynchronously broke my code.
Giles Bradshaw commented
This would be gr8!
Nothing yet. It's on our list but we have nothing to show yet.