Use Koa instead of Express

[kherock]

I've contributed enough to this project to know it decently well and I think it could benefit pretty massively from async/await and Koa's support for processing the response body after middleware is run.

I'm just opening this issue seeking an opinion on potentially including a Babel build pipeline if I were to write for Koa 2. However it looks like Travis is only doing tests for Node >= 6, so Koa 1 would also work fine if we want to avoid Babel. This isn't intended to be just changes for the sake of using newer features; it really should make things a lot more readable and approachable for adding new features such as versioning.

[n1ru4l]

Hey there!

First of all I love koa and async/await.
I also noticed that the code base is quite messy and not optimal.

We also should support all LTS node versions.
if we would do this could use koa 2 with generator functions (http://node.green/#ES2015-functions-generators). Once LTS for 6 is dropped we could easily change those to async functions.

I think a babel build step would be a bit of an overkill 🤔

What do you think @leontastic? I would definitely love to see this, however I do not have all the time to convert/rewrite the application.

[kherock]

I'd be down to do most of it, I haven't been too strapped for time.

Node 4 supports most of the important ES2015 features (nvm spread and rest params are pretty useful, and its EOL is in April) including generators so I think it would be reasonable to target v6 and use either Koa 1 or Koa 2 with the deprecation warnings disabled.

[leontastic]

Code is very messy. I want to refactor it myself but I also haven't found the bandwidth to do so.

Not opposed to using Koa or Babel at all. I think introducing a build step is a worthy trade-off to allow us to take advantage of next-gen syntax features. As long as we keep the build config simple, so it doesn't introduce maintenance headaches down the road.

[kherock]

Even if we go the Babel route, I recently realized that it isn't entirely feasible since a large portion of the Koa 2 ecosystem expects Node.js 7.6+, which means that we'd have to choose what dependencies we use carefully. We'd need to depend on versions written for Koa 1.x and we'd only be able to update once Node 6 exits LTS.

I think it's reasonable just to write for Koa 1 for now bearing in mind that it will need to be adapted for Koa 2 later. If you do it right it's pretty painless, I've done it for a much larger project than this when it got bumped up to Node 8.

[n1ru4l]

What parts of koa 2 couldn't we use? Also I think babel would be overkill.

[kherock]

I just checked and it looks like most of the important ones are safe (koa, koa-compose, and koa-router) so we'd probably actually be fine. I also kind of agree that Babel is overkill since the only feature we actually need is async/await.

[leontastic]

Could just use Promise.coroutine from Bluebird to get async/await-like syntax without needing a babel transform. I'd love to introduce Bluebird anyway to convert async logic to promises.

[n1ru4l]

Koa supports generator function as a async await replacement.

[kherock]

Promise.coroutine is essentially the main export of co which comes with Koa. I think we should be able to get by without involving Bluebird.