discussion: Drop Koa support

[NoNameProvided]

PLEASE READ THE WHOLE DESCRIPTION

Hey there! You probably get there because you see a warning in your routing-controller project what uses Koa as a driver. The reason for warning you is because we consider dropping support for Koa in favor of Express to have better abstraction abilities and make future features possible.

The outcome of dropping support is depends on the insights taken from this thread so please comment if you have anything to share and it was not mentioned before. We are interested in every question and insights so please leave yours.

Rules

Do

• tell your use-case what cannot be achieved with Express
• tell your use-case what needs modifications to be achieved with Express
• add one use-case per comment
• "thumb up" (👍 ) use-cases what affect you as well instead of reposting them
• share your general thoughts about possible issues or wins.

Don't

• do not comment about losing Context because it will be reimplemented for Express
• comment things like "Please don't remove" without use-cases
• do not repost already posted things

[pleerock]

At the moment Im against dropping KOA. Its already implemented and bring not-so-much overhead and maintenance costs to drop it right now. If we need some feature that can be implemented in express but cannot be in KOA, then go ahead and implement it in express without implementing it in koa. We already had such practices. Express will always be at first place in this framework.

If people say yes or no in this issue it won't be so matter, because 95% users of the library don't read what is going on in its github issues. Arguments are the same as I wrote in #107 - we can't hurt exist koa users so much plus we can't add new drivers like in #272

[MichalLytek]

Maintaining two drivers means that we need to do 2x more work when implementing new feature. So it takes 3x more time because we use an know express, not koa, so we have to read the docs to see where it is located in context and how to achieve something. And I bet that only a few percent of users use koa in not abstracted version (they need access to ctx to make things not possible in routing-controllers way), so it makes no sense for us, contributors to put so much work to gain so small effect. Even community contribution focus on express and we forget about the koa-fixes, like in #233.

Dropping support for koa doesn't mean that we remove the code from repository and forget about koa, closing all koa-related issue. We would put this part only in maintenance mode, so we will be only fixing things like issue #240, not developing new features or enhancements.

Because we are planing to go big 1.0.0 release with lib name chaining, we could use this opportunity to kinda fork the routing-controllers, but in the same repo (just other branch) with the same user base (depreciation notice on npm install) and backward compatible API, but developed only for express. So we could focus on creating decorator features for the rest of missing express methods and use cases.

we can't add new drivers like in #272

But do we need new drivers? We already have custom features like interceptors and authorization checker, so we are going further in the way of being standalone framework, not just a bag of decorators helpers like it was 2 years ago. We just need to fill missing gaps in use-cases like streaming file or dynamic headers, so we can have everything abstracted away with no need for bare ctx or req/res.

And I think that actually we could even go further, as @AnimaMundi said - "Personally I actually like the idea of dropping both Koa and Express in favour of packages like find-my-way and connect since it will give you the most flexibility in developing routing-controllers and not being reliant on the API of express or koa, or both."
So we have only connect middlewares compatibility (they work with pure node.js) for body-parser, multer, compression, cors, jwt and other things. But we would handle the stack on our own, together with new interceptors and authchecker, using our custom or fast 3rd party router, so we could really slim down the codebase and make it a lot faster and easier for developing features.

[pleerock]

In my opinion next step for routing-controllers for being a standalone framework is not to use any other routers or frameworks at all. This is something I planned from the beginning - use express/koa/something else community wants and later write its own router/engine/framework once this library will be bigger, more popular and can provide everything users need without using express or something else. Time when we can dictate people to use routing-controllers because it already have everything and they don't need express or something else. But this time did not come yet. For now we need to gain more users who prefer koa over express, express over koa, fastify over express. JavaScript world is very dynamic and people have different preferences. I know some people hate express and use koa and use routing-controllers with koa, lot of people hate express because of its IBM owning and they think its not well maintained anymore. Some people prefer express over koa or fastify because they need something stable and really well-proven. Some people prefer fastify because its more modern and fast. I know its impossible to satisfy them all, but we can satisfy without really high costs a majority - those who wants to use express or koa.

So I'll prefer to stay with current routing-controller strategy on drivers until it get real popularity to be able to dictate its own rules on what users must use.

[MichalLytek]

So it looks like we have to go to 1.0.0 with current state of art with drivers and start promotion to gain more users and think about standalone framework next year.
But ok, so can we focus on developing features e.g. for express and just wait for user's complaining about it's not supported in koa? We would see how many people use it and community could contribute with aplying changes to koa too 😉

l can take care of fastify driver but I think that at first we have to refactor the drivers API as we now violate DRY rule many times. We should check what action driver should map (send file/json/text, apply header, extract params from req, etc) and move as much logic as it's possible to base driver.

[pleerock]

okay you wrote what I just wrote in issue about new driver. Looks like we understand each other now. Yes I agree with what you said - we can watch koa activity and we must refactor drivers and make them DRY. Thats correct I wanted to do it a long time ago

[nathanosdev]

Reposting here by request.

"I started a project using routing-controllers and koa but actually changed to Express when I seen this issue. The project was small enough to be fair but it literally took me 5 minutes to do it so it shows how far you are actually abstracting away from the underlying frameworks with routing-controllers.

Personally I actually like the idea of dropping both Koa and Express in favour of packages like find-my-way and connect since it will give you the most flexibility in developing routing-controllers and not being reliant on the API of express or koa, or both.

Just my two cents."

It's different to use a routing library than to use a full driver. With introducing an API for drivers and make plugins for express and koa we will get into the same situation. Where we are forced to maintain multiple code-bases for much less users that the overall user base of routing-controllers. So I am against making a plugin system for drivers. We should abstract it and keep it under the hood.

@NoNameProvided To clarify on this, I didn't mean a plugin system. I was talking about the same abstraction that you are. Using smaller more specific packages (like connect and find-my-way) instead of bigger frameworks (express and koa) under the hood would allow you guys (the contributors) the most flexibility in developing your API for routing controllers because you are not restricted by any single framework.

We have abstracted away the 90% of things

My opinion is why not complete the abstraction and just take away the last 10% and have your own framework with no visibility to the underlying packages. Users that have already built applications with Express or Koa might not be happy at first, but I personally think in the long run that those users will benefit from a flexible API that does not rely on union of multiple drivers or plugins. Of course, new users will know no difference.

[NoNameProvided]

@AnimaMundi thanks for weighting and for the clarification!

This is something I planned from the beginning - use express/koa/something else community wants and later write its own router/engine/framework once this library will be bigger

@pleerock doesn't matter how well it is executed it will break things. So why do you want to make this change when the lib has big audience and it will cause a lot more trouble than with a small user-base.

The right time to make the hard decisions is while the community is small. Event if we loose some user I would imagine it would be 10x more if we do this in the mature stage of the project.

My strongest opinion still:

We have abstracted away the 90% of things

Lets finish that 10% and drop support for some stuff, but in change we get infinite possibilities as we can do whatever we want under the hood.

[pleerock]

The right time to make the hard decisions is while the community is small. Event if we loose some user I would imagine it would be 10x more if we do this in the mature stage of the project.

it will be another project with another name, we will introduce this project to exist users and if they like it they will use it. Thats all. Right now we need to get a name, then having a name will help us to bring them into anther projects and libraries. But to get users right now we need to do what they want right now.

Then what are those 10% things that you must implement in express but have issues with those in koa? I don't think you'll have a big list there.

[MichalLytek]

People use koa/express only as a fallback for things not possible in routing-controllers way, like returning 201 created with link on POST action. If we support large codebase of middlewares (thanks to connect) and fill the gapps that force people to use bare req/res, we can remove express and koa from routing-controllers 2.0.

However, without disabling @Req, @Res and @Ctx, we won't hear users question how to do their use cases so we won't cover those cases. We have to listen and fix, and right now users silently fallback to express/koa.

To make the transition smoother, after dissabling koa/express exposing, we could expose pure node.js request and response object to make people option for temporary workaround until we cover their use case.

[github-actions]

Stale issue message