How do I add async responses

[drekka]

Hi, I'm trying to use HummingBird in a project and I want to add a asynchronous response to a path. ie. To generate the HBResponse I need to execute something asynchronously first. But my problem is that

server.router.on(path, method: .GET) { request -> EVentLoopFuture<HBResponseGenerator> in
    let promise = eventLoop.makePromise(of: NetworkResponse.self)

    // Do some magic here....

    return promise.futureResult
}

returns a HBREsponseGenerator which has a synchronous function when I need to call something with a signature like func doAsyncThing(completion: (HBResponse) -> Void). I can't use await/aync because I'm working with iOS12 as a base so I'm trying to figure out how to run async code to generate a HBResponse.

Can you give me an example of how to do this

[adam-fowler]

Your async handler has to return something that conforms to HBResponseGenerator. eg String, ByteBuffer, HBResponseEncodable. Does your NetworkResponse conform to HBResponseEncodable? With that your route should be

server.router.get(path) { request -> NetworkResponse in 
    let response = try await generateNetworkResponse()
    return response
}

Here are some examples of Swift Concurrency being used with Hummingbird https://github.com/hummingbird-project/hummingbird-examples/blob/main/todos-dynamodb-async/Sources/App/Controllers/TodoController.swift

[adam-fowler]

I'm going to convert this to a discussion

[drekka]

HI. I worked it out looking at the Image server example. The important thing is that this code has to be iOS12 compatible so I had to leave
things like async/await out of the equation.

In the server setup code I added this route:

// 3 things are passed into this code
// * The HTTP method to watch for.
// * The path to watch for.
// * A `responseType` (enum) which defines what to generate. This is passed a completion closure  
// which is passed a `APIResponse` containing the generated response status code, body, etc. This allows
// `responseType` to execute async code.
server.router.on(path, method: method) { request -> EventLoopFuture<APIResponse> in
    let promise = request.eventLoop.makePromise(of: APIResponse.self)
    responseType.generate(for: request) { response in
        promise.succeed(response)
    }
    return promise.futureResult
}

Then I added an extension to APIResponse so that it can act as a HBResponseGenerator:

extension APIResponse: HBResponseGenerator {

    public func response(from request: HBRequest) throws -> HBResponse {

        var hbHeaders: HTTPHeaders = [:]
        headers?.forEach { hbHeaders.replaceOrAdd(name: $0, value: $1) }

        var hbBody = HBResponseBody.empty
        if let body = body {
            let buffer = request.allocator.buffer(bytes: body)
            hbBody = .byteBuffer(buffer)
        }
        return HBResponse(status: statusCode, headers: hbHeaders, body: hbBody)
    }
}

It took some head scratching but it appears to work (Still getting everything running so I'm sure I'll have to tweak something yet).

I think it would be useful for developers to have a on(...) function that wraps up the future code so developers just need to supply their unique functionality. Something like this:

// This Is untested. I'm just typing it here as I think about it :-)
@discardableResult public func on<Output: HBResponseGenerator>(
    _ path: String,
    method: HTTPMethod = .GET,
    options: HBRouterMethodOptions = [],
    use closure: @escaping (HBRequest, EventLoopPromise<Output>) -> Void {

    self.on(path, method: method) { request -> EventLoopFuture<Output> in
        let promise = request.eventLoop.makePromise(of: Output.self)
        closure(request, promise)
        return promise.futureResult
}

[adam-fowler]

Hummingbird makes the assumption that most NIO based APIs, return an EventLoopFuture<>, which in general is the case as this allows them to be chained together. If you need to create a promise the creation of it should really be internal to your API.

Regarding the HBResponseGenerator it looks like you are trying to convert from your own HTTP response type and the method you have used looks correct. You could instead just return a HBResponse or EventLoopFuture<HBResponse> from your route. But extending APIResponse hides all this code from your routes.