question: future of routing-controllers

[pleerock]

Im planning to return to active contribution on this library for the whole December from the next week (I threw off all my December's typeorm tasks on @AlexMesser's head). What I am planning to do:

• rename library
• make routing-controllers legacy library (yaaaai @19majkel94)
• drop off koa support, use express for now (yaaaai @NoNameProvided and @19majkel94)
• positionate this library as a framework (yaaaai @19majkel94)
• but it will not be super-opinionated framework, it still provides flexibility. No, it will be opinionated
• move this repository into typestack organization
• develop a site (like typeorm has)
• buy a domain
• include all dependencies user needs (express, body-parser, @types, etc.)
• include typedi library as dependency (but still provide ability to setup inversify)
• merge socket-controllers and model-controllers into this library
• close as much opened issues as possible
• do refactoring, especially refactor ugly testing part
• add graphql support

Also once I finish with those tasks Im planning to:

• switch to class-transformer, close issues in there
• switch to class-validator and close all issues in there, merge class-validator and class-sanitizer into a single package
• finish with typestack library design proposal and implement it

[MichalLytek]

rename library
drop off koa support, use express for now
move this repository into typestack organization with a new name

Here we welcome TypeExpress 😄
Along with TypeORM and TypeDI 😀

[pleerock]

haha are you serious? I thought to name it with the name of some fruit haha

[MichalLytek]

I would add to this new release the case of all-in-one change:

• middlewares signature (access to metadata)
• after middlewares (no calling next())
• error middlewares (support class-based extending the default error handler, new signature)

Basically #256 #152 #144 #312 and others 😄

It should be the drastic change in API but with more powerful features. I will try to describe the base draft in the weekend 😉

[NoNameProvided]

It should be the drastic change in API but with more powerful features. I will try to describe the base draft in the weekend 😉

Ping me on Gitter when you are doing it. I have so many ideas as well!!! just no time. 😭 But I am trying hard to fix the management issues in my life 😄

[timc13]

Why drop koa support? 😭 I was just looking into starting up a project with koa2 + routing-controllers + typeorm.

[pleerock]

Because there is no point using it. The only point of using koa over express is when you write vanillajs you have a better syntax with async/await/generators. Routing-controllers provides its own syntax on how you define your routes using classes and decorators, so the only point of using koa over express vanish

[alexproca]

In the sense of "positionate this library as a framework" maybe a cli will speed up the addoption. With the name TypeExpress it would be:

te create controller Home
te add route '/kitchen' Home

[NoNameProvided]

Yes, that is planned feature with the name of TypesStack if I am correct.

[abinici]

By prefixing this project-name with Type this project will be connected to the family of other great TS-projects, such as TypeORM. Other name suggestions could be TypeAPI or TypeREST.

[NoNameProvided]

Other name suggestions could be TypeAPI or TypeREST.

I am sure most of the projects developed with routing-controllers is a rest API, but not all. With these names, we would indicate it only should be used for building rest APIs what we don't want to.

[avocadowastaken]

I'm big fan of SpringMVC and I like how they separated their tooling https://docs.spring.io/spring/docs/current/spring-framework-reference/index.html.

What about npm namespace: Something like @typestack + module

For example:

• @typestack/core - typedi, class-transformer, class-sanitizer, class-validator, microframework
• @typestack/orm - typeorm
• @typestack/routing - routing-controllers
• @typestack/ws - socket-controllers

[NoNameProvided]

Yeah, I thought about moving under the @typestack namespace also.

@typestack/routing - routing-controllers

We want to position routing-controllers more like a framework in the future so@typestack/routing is not a good name for it.

@typestack/orm - typeorm

I dont think we should give up the TypeORM brand, as it's a standalone ORM not tied closely to routing-controllers. It just has a first-class support because of pleerock.

[pleerock]

Im not planning to do a module/namespace based approach, at least not in the first version. I have pushed some changes into the typestack branch. I just started, but few important things I already made:

• refactored a bit, more on the way
• no more koa
• added graphql support
• removed some stuff that is going to be re-implemented
• added scope-based DI (controller and dependencies per request)
• included all possible dependencies to make it complete, out-of-the-box framework, now its much more opinionated with typedi, typeorm, graphql in the box, but user still can choose use or not to use typeorm or something else / graphql or rest.

After long-time negation I found graphql is very good after actually trying it and tried to refactor my big projects from routing-controllers+rest to routing-controllers+graphql and result was amazing in all aspects - developer productivity, performance, simplicity, codebase reduction, etc. I want graphql to be same major part of routing-controllers just as current rest-approach is. For those who are interested in how graphql application is going to look like with routing-controllers checkout this example. @Urigo as someone who convinced me to use graphql please checkout this example.

I need more help from the community to speed things up. The biggest things anyone can help are: website, new documentation and test coverage refactoring.

[MichalLytek]

After long-time negation I found graphql is very good after actually trying it and tried to refactor my big projects from routing-controllers+rest to routing-controllers+graphql and result was amazing in all aspects - developer productivity, performance, simplicity, codebase reduction, etc. I want graphql to be same major part of routing-controllers just as current rest-approach is. For those who are interested in how graphql application is going to look like with routing-controllers checkout this example. @Urigo as someone who convinced me to use graphql please checkout this example.

So may you want to check this out? 😉
https://github.com/19majkel94/type-graphql

But please don't merge my super-advanced reflection&schema generation technology into routing-controllers 😥 I want to have my own framework with a lot of github stars and to be a famous developer 😄