Routing / other questions
pnico opened this issue · comments
Is your feature request related to a problem? Please describe.
This is something I would probably put in a Discussions item or a Discord channel if those were available, let me know if there's a better place for questions like this.
While the filesystem-based routing is elegant and kinda neat, I wonder about a few things:
- How would we cleanly do a versioned API with this ? i.e.
/api/v1/something,/api/v2/somethingetc., where v2 might share a lot of code with v1 with some changes? Or is this just not something that fits with the 'workers' paradigm? - Some routing systems allow regular expressions to parse a path segment. Would this be possible with the filesystem routing or is it just something to avoid completely?
- For both routing and discovery of workers (needing folder names starting with underscore, etc.), I wonder if it might be better to have a way to plug in alternative ways to do both of these things and just have the filesystem be a convenient default for those who like it. Any thoughts?
Then another thing that's unrelated to routing..
- What does the story look like for things like websockets, could there be a similar approach to what's in development for http requests? It seems like socket support in WASI may take a while to land. If it was available, for example in python, would it be possible to just use urllib?
Describe the solution you'd like
(Just curious, no solutions necessary 😄)
Describe alternatives you've considered
No response
Additional context
No response
Hello @pnico,
Sorry for the long delay here! I was out and couldn't reply before 😄. Let me reopen this issue, so we can discuss about it and create any new issue.
This is something I would probably put in a Discussions item or a Discord channel if those were available, let me know if there's a better place for questions like this.
We have discussed this in the past, but never created a Discord or other channel. About Discussions, do you mean GitHub discussions? We were thinking on enabling that option.
- How would we cleanly do a versioned API with this ? i.e. /api/v1/something, /api/v2/something etc., where v2 might share a lot of code with v1 with some changes? Or is this just not something that fits with the 'workers' paradigm?
In general, this would depend on the programming language ecosystem. The workers could be a source code (like JavaScript) or a compiled module (like Rust). For compiled languages, the source code project structure is out of Wasm Workers Server as it expects to run the compiled modules. That approach provides flexibility about how you share code between different workers.
The same principles applies to some interpreted languages like JavaScript. You can have a source project that outputs a set of workers using bundling and transpiling techniques. Note this is required when using libraries as wws doesn't support JavaScript modules yet. In other cases like Python, you can mount libraries and share code between multiple workers.
In general, the workers model focuses on single and small units that are deployed individually. The tooling ensures you get a single file (either a single source code file or a compiled module) that you deploy to a platform. Wasm Workers Server goes a bit further there and allows you to define an entire application but routing multiple workers from a given folder.
We are still defining the shape of this. To help us, what are the kind of applications you have mind?
- Some routing systems allow regular expressions to parse a path segment. Would this be possible with the filesystem routing or is it just something to avoid completely?
- For both routing and discovery of workers (needing folder names starting with underscore, etc.), I wonder if it might be better to have a way to plug in alternative ways to do both of these things and just have the filesystem be a convenient default for those who like it. Any thoughts?
These are good points. Filesystem routing is quite convenient, but it has its limitations. One option we were thinking here is the ability to set the URL and contraints around it in the associated configuration file. If wws detects an URL section in the worker config file, it will ignore the filename and define the route based on it.
Another option could be to define a top level wws configuration file. In this file, you may define project-wise configurations like "routes". Currently, we do have a file call .wws.toml but it's more a lock file for dependencies than a project configuration.
Giving these two options, what would you prefer?
What does the story look like for things like websockets, could there be a similar approach to what's in development for http requests? It seems like socket support in WASI may take a while to land. If it was available, for example in python, would it be possible to just use urllib?
This is something I would love to research more. I believe it's too early to provide a response for this, but it will give it a thought :)
Thank you for your questions and interest and sorry for the delay!
IMO, I would prefer a route config file rather than a top level one.
Multiple config files could allow you to add other parameters in the future (like a scheduled job)
IMO, I would prefer a route config file rather than a top level one.
Multiple config files could allow you to add other parameters in the future (like a scheduled job)
+1. Cron-jobs are something we have in mind and yes, you would need to use individual config files :)