Routing / other questions

[pnico]

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/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?
• 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

[Angelmmiguel]

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!

[mtt-artis]

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)

[Angelmmiguel]

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

[mtt-artis]

I would also add that you can not declare the same route twice with file based routing.

[pnico]

Thanks for changing this to a discussion, I feel less self-conscious about it now 😂
I don't have any types of applications in mind, I've only ever worked on REST/GraphQL type things and never anything in the "workers" model outside of maybe some cloud function-type things, I have no idea what would be best for a real production use case. I was just curious to play around with this for learning, but maybe there's some overlap where some "real" users would want a more traditional routing config, even if the point is just to have a small number of endpoints in a project and deploy one file.

• Same route twice: this is allowed by some and prevented by other 'traditional' routing frameworks, this could be dealt with
• Code sharing: eh, it still seems like being locked to the filesystem routing might make you need to split source files up more than you would normally need to in order to share code. maybe not a big deal though

[Angelmmiguel]

Hahaha you don't need to worry about sharing your questions / suggestions. We are always looking for feedback about how to continue growing the project 😄. The fact that you tried it and shared your feedback is really valuable. Thank you!

there's some overlap where some "real" users would want a more traditional routing config, even if the point is just to have a small number of endpoints in a project and deploy one file.

Yes, filesystem routing could be a bit tricky at the beginning. Regarding managing multiple endpoints with a single worker, you're totally right. Fortunately, @mtt-artis contributed the catch-all feature, which will be available in the next release (v1.6.0).

This feature allows you to define workers that captures multiples URLs using the [...path].js format. You can even have folders / subfolders adding this pattern. These workers have the lower priority vs fixed or dynamic routes (like [id].js).

It still seems like being locked to the filesystem routing might make you need to split source files up more than you would normally need to in order to share code. maybe not a big deal though

I didn't think on this angle about code-sharing. I always considered having external libraries that you load in different workers / build them. However, I see also the value on having a single worker that has its own routing logic inside.

[Angelmmiguel]

As a summary, workers with internal routing logic is already covered by the catch-all routes. You can define a worker that captures multiple URLs and manage the different paths internally. Those workers work as "micro apps", so you load them in a specific endpoint and delegate the routing.

For now, wws will continue using filesystem routing as the default, although the explicit route configuration is also possible. I believe it could be confusing to mix both in a single project, but I see the value of an explicit configuration, so you can even reply to multiple endpoints instead of a single one:

version = "1"
name = "users-api"
urls = ["/api/[version]/users/"]