Asynchronous

[elliottminns]

Asynchronous

[tanner0101]

I like this idea. I'd like to continue to support the current interface, though. I think the async response is less common.

Possibly a Route.getAsync() or Route.get().async() API would work.

[elliottminns]

It should be possible to support both, without having different interfaces defined, using function overloading.

// Sync
Router.post("") { request in
    return Response()
}

// Async
Router.post("") { request, response in 
    response.send()
}

[tanner0101]

I'm not at a computer right now to see if Swift would complain about the params to the closure not matching. But I know it will complain if the closure doesn't return a Response..

Possibly an AsyncResponse object could be returned with a closure inside.

[tanner0101]

@elliottminns Just saw the note about function overloading. You're right. I think that would work.

[elliottminns]

Awesome, I'll get started on this on my fork.

[elliottminns]

I've managed to implement this however with one caveat. I get this build error for using my old sync methods now, such as

Route.get("/") { request in
    let view = try View(path: "Views/index.html")
    return view
}

/Project/Sources/main.swift:9:1: error: ambiguous use of 'get(_:closure:)'
Route.get("/") { request in
^
Vapor.Route:4:23: note: found this candidate
    public class func get(path: String, closure: Vapor.Route.Type.Closure)
                      ^
Vapor.Route:5:23: note: found this candidate
    public class func get(path: String, closure: Vapor.Route.Type.ResponseClosure)
                      ^
<unknown>:0: error: build had 1 command failures

It seems that while the async method works fine, the interface for the sync method is now too ambiguous for the compiler. This can be solved by explicitly defined which closure type it is, however this does take away from the cleanliness of the original interface and will be breaking for any current code:

Route.get("/") { (request) -> ResponseConvertible in
    let view = try View(path: "Views/index.html")
    return view
}   

It may be cleaner therefore to instead add a Route.async.get() or Route.getAsync() method instead to preserve the original interface.

Let me know your thoughts

[tanner0101]

Can you create a pull request with the changes?

[tanner0101]

6b033df fixes this.