Drop off koa support?

[pleerock]

Koa support adds limitation and increases maintenance costs.
It also makes some interfaces bad designed.
Just want to know how many koa users are there to understand if koa support worth all drawbacks it brings.

[MichalLytek]

Tell me if I'm wrong - koa was designed to provide async request handlers via generators (function*)? We have now async/await so we can use Express with async handlers, no more callback hell. I've read that it's easier to write middleware for request handling time logging but it's not a big deal comparing to Express.

I was already thinking about creating a framework based on routing-controllers codebase with support only for Express, with the working name TypeExpress but I thought it might not be fair even if routing-controllers is an open-source on MIT license. Maybe we could start a new project together rather than creating breaking changes here? We would have then free hands and could implements all new feature we discussed in other github issues without watching at backward compatibility 😉

[pleerock]

If you want more deep collaboration, I'll add you to typestack organization and give you relevant privileges. I'll move all projects: typedi, routing-controllers, class-validator, class-transformer there soon.

Im not yet afraid braking changes there, because there are not so many people use this library yet. Im far more afraid to make changes in typeorm because there are much more users.

What I want is to reduce maintenance costs, because open-source tooks so much time...

Koa support is good to gain more users, because some users want koa, some express.

I'll think more about this issue, but it was just a question, for me #106 is much more important because its much more maintenance pain there then with koa. Also I'll have a concept of models-controllers which I wanted to merge to routing-controllers, but its a bit specific and opinionated, you may not like this idea...

Of course there are also design-level considerations, however right now they are not so harmful.

[charsleysa]

Just adding my 2 cents.

I took a look at converting our Express apps to use Koa but decided against it because from my quick and dirty attempts at conversion I found the Koa ecosystem to have poor support for Typescript with many things missing or having incomplete .d.ts files.

In my opinion, since this a Typescript project and the Koa ecosystem seems to have poor support for Typescript, it will not be an issue to drop support for Koa in favor of reduced complexity and maintenance overheads.

[MichalLytek]

Im not yet afraid braking changes there, because there are not so many people use this library yet.

I'm not talking about breaking changes like deprecating controlerDirs in favor of controlers but huge changes in API with big codebase refactor. It's better to make routing-controllers and socket-controllers the legacy projects and move to a new project where we would have free hands on changes and implementing all new fancy things 😉 Like the people from express team created a koa project due to really big breaking changes in API that they were afraid that they piss on users with this changes and enormous migration work for their projects.

If you want more deep collaboration, I'll add you to typestack organization and give you relevant privileges.

It would be great! 😄

[idchlife]

I started using it with Koa, so... Express is better with routing-controllers? Since we have async/await, there is no more case that koa is superior?

[pleerock]

Im not koa fun, but looks like people are using it. Lets close this issue.

[NoNameProvided]

I think it's time to reconsider this issue, so I reopen this.

Since we have async/await, there is no more case that koa is superior?

As we have now async await support, we should reconsider dropping support for Koa before the 1.0 release.

A few things to consider: Express is almost 40x times more popular than Koa and it has excellent support from the community. It seems Koa has a smaller but more vocal user-base.

routing controller abstracts away the framework level anyway, so beside ctx I don't see any big differences while developing with routing-controllers.

Dropping Koa would allow us to go forward faster. There is not a lot of us contributors (and it seems none of us use Koa on every day basis) and we already see issues coming from approved PR-s which break entire Koa apps due to us not spotting the issue before merge. (ref #240)

I think we have a lot of opportunity with routing-controllers but we should focus and build on one framework. So I vote to drop support for Koa in favor of Express.

When we should drop it? For sure we would need some research but before 1.0. If we release 1.0 with Koa that is a long term commitment. If we decide this is open for discussion we need to do some research to see exactly what changes needed by Koa users to convert their projects to Express.

Also I would create a patch release to warn users on every startup if they are Koa users to make their voice here.

Thoughts @pleerock and @19majkel94?

[MichalLytek]

Short answer: hell yeah! 😄

Looong answer:
Koa is great if you use it as your main framework. So you work with koa-router, use ctx in every action, have async/await even on middleware level, etc. like in old days before routing-controllers 😆
However using koa with this framework reduce almost all of the prons in most of situations - you can only
have benefits of ctx with things you can't do right now, like sending streams, which might be more comfortable than express req/res API. But you also got it cons like much smaller support due to low popularity and a lack of some specific, not so popular middlewares. I think that some people use koa with routing-controllers because it's easy to migrate their pure-koa app to the routing-controller based rather than switching two frameworks and big refactor.

We had big plans for release 1.0, like lib renaming, and things to do before it, like all breaking changes in API to make it more stable in the future, together with big refactor (as we are recently only adding new lines of codes with features so there is a lot of mess in codebase). So my idea is quite brave and revolutionary 😆

First, of course, is droping off koa support. This will allow us to reduce maintaning cost as we don't have so many contributors, so we could implements new features faster and easier. We would get rid of drivers abstraction and introduce express typings in codebase to help in development. But focusing only on express is a really big breaking change. Mixing together that we want to release big version 1.0 and change the library name, honestly, it should be the really new library. But to don't make it as drastic and won't loose all users and github starts, we could just put routing-controllers 0.7 in maintenance mode and fix only critical bugs (no new feature/enhancements) and it would be on routing-controllers branch on the repo. Then new version would be under new name on master branch on the renamed repository but we would place the info in readme with redirect to the old branch with docs for older version with koa support. We would also put info about new version in the old docs and also display info on console for express users (detect express driver and development mode, show info on start? or only as deprecated note on npm install?). All this just to make this smooth transition but with no complain or issue from koa users "why new version doesn't work?", etc.

My proposal of the new name is TypeExpress. We already have TypeORM and TypeDI, so we would keep consistency that great maches with TypeStack organization 😉

[pleerock]

As I already told Im not fan of koa, but there are users who use routing-controllers with koa. Its easy to discuss it here between us, maintainers, simply because those users dont know about our discussion here. Once we do it we will have tons of complains from users. And we will get complains over time because people dont update their dependencies quickly.

If we do "TypeExpress" lets say (or even routing-controllers 1.0.0 without koa) then what will happen with routing-controllers itself (with koa and express)? Who is going to maintain it for koa users? Looks like nobody and thats not a good news for those users. Also if we create "TypeExpress" then what to do with #272 ? Looks like we won't support new drivers in this case?

[nathanosdev]

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.

[NoNameProvided]

@pleerock

As I already told Im not fan of koa

Ok, so we agree about that we should drop it 😄

As I already told Im not fan of koa, but there are users who use routing-controllers with koa. Its
easy to discuss it here between us, maintainers, simply because those users dont know about our discussion here.

As I wrote:

Also I would create a patch release to warn users on every startup if they are Koa users to make their voice here.

This way they can see a big yellow warning to come and make their voice.

then what will happen with routing-controllers itself (with koa and express)? Who is going to maintain it for koa users?

Like in other project, we put it in extended maintenance mode and do security fixes only.

Also if we create "TypeExpress" then what to do with #272 ? Looks like we won't support new drivers in this case?

Thats a router not a driver, right?

Looks like we won't support new drivers in this case?

We wont give the users to select their drivers, but we can swap it under the hood if we found something better. We will be able to do it because it's abstracted away from the users.

thats not a good news for those users.

Well, having features shipping less frequently is worse than having to support your driver when 90% of its abstracted away anyway.

The question here is where we want to take routing-controllers? Keeping it as an abstraction level with multiple bindings and making the development a continuous balancing to find the least harming compromise for new features between drivers. Or we want to create a framework, which you install, read the docs and happy with.

We have abstracted away the 90% of things. Context is the only Koa thing we would lost but implementing a Context feature for Express is still easier than supporting multiple drivers. (We already discussed creating it anyay see #256 (comment) second part of my comment).

@AnimaMundi

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.

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]

I will close this for contributors and create a new issue for discussion with our users (#273). This way we can keep the discussion small here about the insights they give in the other issue.

@AnimaMundi if you would repost your insights there that would be nice. Thanks.

[pleerock]

If this is locked now then lets close it

[NoNameProvided]

Well we should update it with the conclusion from #273.

[MichalLytek]

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.

He was talking about throwing out the koa and express, don't expose the driver (req/res/ctx), internally use what we want (find-my-way/custom router) and only maintain compatibility with connect middlewares. And it makes more sense than sticking to koa/express as we provide enough abstraction and want to make it as fast as it can be.