Skip to content
This repository has been archived by the owner on Aug 31, 2024. It is now read-only.

Replace middleware with external modules #30

Open
doug-wade opened this issue Sep 2, 2017 · 6 comments
Open

Replace middleware with external modules #30

doug-wade opened this issue Sep 2, 2017 · 6 comments

Comments

@doug-wade
Copy link
Collaborator

In #19 (comment), @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.

@nickserv
Copy link
Member

nickserv commented Sep 3, 2017

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

@nickserv
Copy link
Member

nickserv commented Sep 3, 2017

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

@nfantone
Copy link
Member

nfantone commented Sep 3, 2017

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?

@nickserv
Copy link
Member

nickserv commented Sep 3, 2017

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.

@nickserv
Copy link
Member

nickserv commented Sep 4, 2017

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.

@nickserv
Copy link
Member

nickserv commented Sep 6, 2017

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.

@nickserv nickserv removed this from the Blockers milestone Sep 6, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants