search

typestack / routing-controllers

Create structured, declarative and beautifully organized class-based controllers with heavy decorators usage in Express / Koa using TypeScript and Routing Controllers Framework.
MIT License
4.42k stars 394 forks source link

feature: Cloudflare Workers support #1054

Open promentol opened 1 year ago

promentol commented 1 year ago

Description

We are using Cloudflare Workers for our applications, which doesn't support node api. This package is allowing to build clean high quality code with less bugs, the benefits are incredible. I was wondering if you have a plans to support Edge runtimes like Cloudflare Workers or Deno and etc.

Proposed solution

There are similar frameworks to Express.js like Itty Router or Hono.js. I guess all we need is to add corresponding driver in drivers folder. Do you plan to support it? Or are you open for Pull Requests?

attilaorosz commented 1 year ago

I'll be honest, this would be really good but we are having issues supporting koa already. If we keep adding drivers to the package without the core maintainers actually using those (knowing that the people who requested them will not be around to support them) we will end up with a lot of unmaintained parts of the codebase. I would rather separate it into different packages as plugins, then the community would be able to add the drivers they want. Unfortunately, this requires a complete overhaul but I'm not against that for v1 anyway.

Tagging @NoNameProvided for opinion.

gayanhewa commented 1 year ago

I'll be honest, this would be really good but we are having issues supporting koa already. If we keep adding drivers to the package without the core maintainers actually using those (knowing that the people who requested them will not be around to support them) we will end up with a lot of unmaintained parts of the codebase. I would rather separate it into different packages as plugins, then the community would be able to add the drivers they want. Unfortunately, this requires a complete overhaul but I'm not against that for v1 anyway.

Tagging @NoNameProvided for opinion.

This makes sense 💯 , however, we would need to make some refactoring to make the drivers more pluggable in nature. A good starting point would be to extract the existing drivers into packages and then use them as pluggable drivers which would assist the community to understand how to add custom drivers.

Other related issues https://github.com/typestack/routing-controllers/issues/272 https://github.com/typestack/routing-controllers/issues/273 https://github.com/typestack/routing-controllers/issues/595 https://github.com/typestack/routing-controllers/pull/214

NoNameProvided commented 1 year ago

There are 2 topics to discuss here:

For driver support, I would rather go in the opposite direction. Abstracting away the underlying framework and having a single supported built-in driver. This is now Express for us later it can be switched to something else (eg: Fastify).

About adding support for Cloudflare Workers: I have no strong opinion on this as I lack the experience with the technology, but I do think traditional NodeJS frameworks and new edge computing not goes well together. To support both you need to get the lowest common denominator which will result in sub-par performance and ergonomics for both.

One good example is startup time. In edge computing, you want to optimize for startup time because you start a new worker for each request, while it's not a priority for a traditional NodeJS app.

Said this, I think the most optimal path to work with workers is to re-implement the desired ergonomics from our lib and other decorator-based API frameworks in a new project. (For example, this is what we did for Azure functions in an internal project.)

rafaell-lycan commented 1 year ago

Hey @NoNameProvided, I saw a conversation about having a plug-in/driver support at https://github.com/typestack/routing-controllers/issues/272 by @MichalLytek

Do you have any ideas when an Alpha could be released?

Some breaking changes will happen, but overall, the lib can also decrease its size by simply using Express as its default driver and having the ability to swap to whatever supporter driver later.

NoNameProvided commented 1 year ago

As I mentioned in my above comment, personally I am against it. To support plug-in drivers we can only use the lowest common denominator of each package. I believe a higher integration with a single driver is the way to go.