-
Notifications
You must be signed in to change notification settings - Fork 394
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature: Cloudflare Workers support #1054
Comments
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. 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. |
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.) |
Hey @NoNameProvided, I saw a conversation about having a plug-in/driver support at #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. |
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. |
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?
The text was updated successfully, but these errors were encountered: