Routing-controllers: 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)
• [x] drop off koa support, use express for now (yaaaai @NoNameProvided and @19majkel94)
• [x] positionate this library as a framework (yaaaai @19majkel94)
• [x] ~but it will not be super-opinionated framework, it still provides flexibility~. No, it will be opinionated
• [x] move this repository into typestack organization
• [ ] develop a site (like typeorm has)
• [ ] buy a domain
• [x] include all dependencies user needs (express, body-parser, @types, etc.)
• [x] 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.

[umidbekk]

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 😄

[pleerock]

Cool, glad that you have tried graphql too. I see your work is a bit different in some aspects. Please take a look how I implemented things, I need some feedback what I haven't covered from typical graphql app. Once you take a look we can discuss pros and cons of different implementations

[MichalLytek]

I see your work is a bit different in some aspects.

I am trying to cover the most annoying Typescript-GraphQL thing that is the schema<-->interfaces synchronization and duplication.
The most tough part (reflection/metadata) is done, however some stuffs like enum/unions are missing now but it shouldn't be so hard 😃

[MichalLytek]

Please take a look how I implemented things,

Looks like you've took the approach just like nest.js:
https://docs.nestjs.com/graphql/resolvers-map

But routing-controllers graphql would also need support for exceptions, middlewares, interceptors and other features too, like the REST-based version. Or maybe it's already working but just doesn't presented in the example :wink:

[pleerock]

I am trying to cover the most annoying Typescript-GraphQL thing that is the schema<-->interfaces synchronization and duplication.
The most tough part (reflection/metadata) is done, however some stuffs like enum/unions are missing now but it shouldn't be so hard

there are some issues I currently see with such approach, we can discuss in gitter if you want.

Looks like you've took the approach just like nest.js:
https://docs.nestjs.com/graphql/resolvers-map

I don't know how it works in nestjs. Also looks like link is broken.

But routing-controllers graphql would also need support for exceptions, middlewares, interceptors and other features too. Or maybe it's already working but just doesn't presented in the example 😉

No I haven't reach that part yet

[MichalLytek]

I don't know how it works in nestjs.

Nest.js is ours biggest competitor, it has 5 times more stars 😝

here are some issues I currently see with such approach, we can discuss in gitter if you want.

I would love to, here is the link:
https://gitter.im/type-graphql/Lobby

[laukaichung]

@pleerock Do you have a new example about routing controller + graphql? The example has been removed. https://github.com/pleerock/routing-controllers/tree/typestack/new-test/functional/graphql

[pleerock]

@stonecold123 https://github.com/vesper-framework/vesper

[github-actions[bot]]

Stale issue message

[jotamorais]

I've created a new issue with a few suggestions and pinned in each repo - would be great to get your thoughts on it

https://github.com/typestack/routing-controllers/issues/579

[NoNameProvided]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.