Tide: Add support for routing on subdomains

[AlecDivito]

Feature Request

Not all of the url routing is complete. I'm just wondering if support for routing on subdomains could be added into the framework.

Detailed Description

Add new methods to the router.rs and server.rs to support users to route on subdomains as well. An example of the resulting api I am thinking of would look like so:

let mut app = tide::new();
app.on_subdomain(":sub1.:sub2.:sub3").at("/").with(validate_subdomain).all(handle_user);

Context

I have an application that can have multiple tenets that can upload content to the server and would like to configure my webserver to be able to route on subdomains. This will benefit other users of tide who want to add the same functionality to their own application.

Possible Implementation

I haven't dove into the code base that much but i would assume that I would need to add functionality to server.rs and router.rs. I know this maybe a big addition so I wouldn't mind taking a chance and implementing it and putting in a PR.

Just wondering if this project is also interested in adding support for it and want to start a discussion.

[yoshuawuyts]

We had a bit of a chat about this earlier today, I think this is a fairly promising direction. Earlier art for subdomain routing includes:

• koa-sub-domain
• Rails subdomain routing (official docs)

The Rails subrouting API seems quite interesting; if we were to translate that to Tide it could look like:

let mut app = tide::new();
app.subdomain("blog").at("/").get(|_| async { Ok("welcome to my blog") });
app.listen("localhost:8080").await?;

I'm leaning towards app.subdomain rather than abbreviating it as app.sub to prevent confusion with app.nest. Also we should only add subdomain to Server but not Route. Because subdomains feel like they should be declared at the root of the app, not nested within routes. As such we should perhaps also guard that when nesting apps we disallow subdomains on the app we're nesting.

---

That's my opinion, @jbr had some different ideas that I'm hoping he'll share!

[AlecDivito]

Happy to hear the advice. I really enjoyed looking into the Rails subdomain routing and have an approach I think would work. I liked your proposal and I think the API design should look like the following:

let mut app = tide::new();
app.subdomain("example").at("/").get(|_| async { Ok("example subdomain") });
app.subdomain("portal").with(authentication).at("/").get(|_| async { Ok("Secure portal") });
app.subdomain(":user.blog").at("/").get(|req| async { Ok(req.param::<String>("user").unwrap()) });
app.listen("example.com").await?;

You may have noticed but I am making one prediction which is that the user treats their apex domain as their base url. I'm not sure 100% sure of a good way to allow the user to state the base url.

In terms of the design of additional code needed, I believe it would be best to do the same thing that route-recognizer is doing and by having a Router container around the Route struct. I propose wrapping a Subdomain struct around a Namespace container:

struct Server<State> {
    ...
    namespace: Namespace<State>;
    ...
}

struct Namespace<State> {
    router: SubdomainRouter<Subdomain<State>>
}

struct Subdomain<State> {
    subdomain: String,
    router: Router<State>,
    middleware: Vec<Arc<dyn Middleware<State>>>,
}

The SubdomainRouter<T> would just be like route-recognizer but dumber.

I wouldn't mind hearing your thoughts about this this design. I am working on an implementation and hopping for it to be finished soon.