Async Controller Actions about embedio HOT 8 CLOSED

All responses are already wrapped in async/await pattern. Your controller actions are all asynchronous:)

Please forgive the brevity and typos. Message sent from a mobile device.

From: Samanmailto:[email protected]
Sent: ‎5/‎13/‎2015 2:34 PM
To: unosquare/embediomailto:[email protected]
Subject: [embedio] Async Controller Actions (#13)

Since the controller actions are not tasks I wonder if you have another general notion on how to wait for I/O code in action to complete? Currently I'm using task.wait() for a task to complete, which doesn't seem to be 100% working, I need to debug a few cases yet. However can I declare actions as Tasks?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13.

from embedio.

I was going through a few options and also saw uhttpsharp controller demo which declares actions as public Task<IControllerResponse> ... which I found a little less confusion and this would also allow to use straight the await keyword in the action without any task.wait() or similar technique.

Still I might be wrong, but just looking at it seems to be a benefit.

from embedio.

@srad I created a branch (https://github.com/unosquare/embedio/tree/AsyncREST) where you can define await Task<bool> ... methods. Check if this is a better approach please.

@mariodivece What do you think of this branch?

from embedio.

BTW check the sample at file https://github.com/unosquare/embedio/blob/AsyncREST/Unosquare.Labs.EmbedIO.Samples/RestApiSample.cs

from embedio.

That is pretty cool.
What do you think of returning a response object/result like uhttpsharp does instead of bool?

Because without event looking at a controller I would pretty much expect the signature to be something like public Task<IControllerResponse> ActionBla() returning something like Response.Render(HttpResponseCode.Ok, null);

from embedio.

The approach is different, our REST method returns a boolean just to indicate if the request was handled and the method must write the Response's output using for example context.JsonResponse.

In the other hand, uhttpsharp is returning an interface where they can put any call to another class to write the content. It's pretty much the same, but Embedio is simpler. If you wish you can add these extra layers, but I really find it unnecessary.

Embedio REST Method -> call context.JsonResponse(object) -> return true
uhttpsharp -> call Response.Render(ok, object) -> Create RenderResponse Object -> Render View -> return Response to Context

from embedio.

I think I understand now that you go for less abstraction (which is not necessarily the same as simplicity), because I find uhttpsharp's approach semantically clearer, because it's more explicit.
The bool in the signature just bugs me, it's straight a question-mark looking at it. ;)

from embedio.

I merged the Async branch to master. Since we are not implementing return an interface in REST methods, I'm closing this issue now.

from embedio.