routing-controllers icon indicating copy to clipboard operation
routing-controllers copied to clipboard

feature: Cloudflare Workers support

Open promentol opened this issue 1 year ago • 5 comments

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?

promentol avatar Mar 04 '23 14:03 promentol

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.

attilaorosz avatar Mar 05 '23 18:03 attilaorosz

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

gayanhewa avatar Mar 05 '23 20:03 gayanhewa

There are 2 topics to discuss here:

  • having plug-in driver support
  • adding support for Cloudfare workers

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.)

NoNameProvided avatar Mar 08 '23 16:03 NoNameProvided

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.

rafaell-lycan avatar Apr 19 '23 10:04 rafaell-lycan

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.

NoNameProvided avatar Apr 20 '23 07:04 NoNameProvided