support koa as well as express

[leemhenson]

Hi Giulio

What do you think about supporting multiple server libs? We use http://koajs.com/ rather than express, but their apis are very similar. I've done a simple split via Conn, ExpressConn and KoaConn. The tests all pass but I haven't actually run it in anger yet. I wanted to post it up here to get any feedback you might have.

[gcanti]

Hi!

What do you think about supporting multiple server libs?

It would be really nice, let me read the code carefully and then I'll post some comments

[gcanti]

@leemhenson This is awesome. Basically, excluding the router, you can migrate from express to koa (or the other way around) just by swapping the toRequestHandler function, right?

[gcanti]

I was thinking.. MiddlewareTask.toRequestHandler looks useless now that we have a toRequestHandler function is each adapter, and it just calls eval on the middleware, what if we get rid of it?

[gcanti]

Oh wait, expanding on toRequestHandler there's a problem: each adapter has a hard dependency on MiddlewareTask, we should try to remove it (you are free to write your interpreter, for example one that uses bluebird or funfix's Future under the hood instead of Promise)

[gcanti]

expanding on toRequestHandler there's a problem

@leemhenson I propose to

• remove toRequestHandler from MiddlewareTask and from each adapter
• add the corresponding code to the examples, where we have both a concrete instance of MiddlewareMonad and a specific target (express or koa)
• tackle this problem in a following PR

[leemhenson]

I've made those changes. I agree with the toRequestHandler changes, it was just a load of indirection for no real gain.

[gcanti]

@leemhenson Thanks! Last thing before merging, could you please move the examples out of src? Perhaps a top level folder examples?

[leemhenson]

I've tidied up a smidge more.

[gcanti]

@leemhenson Released in the next channel if you want to try it out

npm i hyper-ts@next # v0.2.0-dev.20180126