search

koajs / koala

[SEEKING MAINTAINER] An HTTP/2 and ES6 Module-ready Koa Suite
MIT License
319 stars 28 forks source link

Replace middleware with external modules #30

Open doug-wade opened 6 years ago

doug-wade commented 6 years ago

In https://github.com/koajs/koala/issues/19#issuecomment-324023866, @nfantone suggested we replace the middlewares here can be replaced with external npm modules, which would reduce the amount of code we need to maintain.

nickmccurdy commented 6 years ago

Should this be a blocker or is it just a long term convenience thing?

nickmccurdy commented 6 years ago

Perhaps I misunderstood the discussion in #19, should we do this before working on Koa 2 support?

nfantone commented 6 years ago

I believe that should be the way forward. I'm open to other ideas, though. Why write and maintain what are, essentially, custom Koa middlewares which are already available as shippable npm modules out there?

nickmccurdy commented 6 years ago

Great point, this seems to be easier for both the short and long term. I'll add this to the new Blockers milestone before Koa 2 support.

nickmccurdy commented 6 years ago

I feel like we should switch to a more modular API, especially if we're including third party middleware by default. Right now we have a top level koala function import that behaves the same as koa, but with extra middleware and other stuff included, making it difficult to include only part of Koala, especially if you want to use an alternative to one of the built in middlewares. I was thinking about turning it into a subclass of Koa 2's top level import, but that has the same issues. If we avoid wrapping around Koa, we could also make it easier to provide more opinionated middlewares like routing by default, since they would be easier to replace with alternatives.

The express-generator style solution to this problem is to provide a code generator that outputs an app that depends on the framework directly. Instead of this, we could provide a code generator with a template that depends on Koala (which would still wrap Koa) and have it depend on a few third party middlewares like express-generator does. We could also make an official Yeoman generator if we want to avoid reinventing the wheel with the code generator. Alternatively we could still wrap Koa but provide a list of middlewares that could be overridden, though I don't think this is ideal because many projects overriding middlewares would have unused dependencies.

nickmccurdy commented 6 years ago

Based on the progress in #17 I feel like this doesn't need to be a blocker anymore so we can focus on Koa 2 (though I'd still like to fix it at some point). Feel free to add the milestone back if you disagree.