Subdomain matching as well as url/path?

[tedkornish]

Hey there! Is it possible to check for and proxy a request subdomain match as well as a match to a specific path? I've got my grunt server command set to open app.lvh.me:9000 - with lvh.me redirecting to localhost - and I'm querying a rails API on localhost:3000 at api.lvh.me:9000.

The goal is to redirect api.lvh.me:9000 to localhost:3000.

Is this functionality included right now? If not, I'd be happy to build it in and submit a pull request.

Cheers!

[drewzboto]

Can you expand on this a bit more? I'm not sure why you need a proxy specifically for this scenario.

Can you fill in the blanks.... So you have:
api.lvh.me:9000 --> localhost:3000 for XHR requests on / context
app.lvh.me:9000 --> localhost:? for ? requests on ? context

I assume both are setup for local development as entries in your hosts file pointing to localhost.

This plugin predominantly was built to run a dev proxy to bypass cross-origin problems for browser-based applications. If you're running your application on app.lvh.me and able to call api's on api.lvh.me, you already have cross-origin solved (via CORS or JSONP?). So i don't really see the use case behind your request. But curious to hear about what you are doing....

[tedkornish]

Sure.

Let's say I'm writing a web application modularized into a back-end API and a front end Javascript MVC framework. In order to let each part perform optimally, I split them into two separately-hosted components - so rather than serving HTML and JavaScript from the back end app, I serve the front end from Amazon Cloudfront. And by not serving anything except for a pure JSON API on the back end, it's faster, easier to maintain, and I get better value out of the server capabilities I'm paying for. I can then use Amazon's Route 53 DNS service to route the back end to the '.api' subdomain of whichever domain I'm using in production, and the '.app' subdomain to the Cloudfront distribution containing the assets for my web app. That's in production.

If I have two local servers running in development - one on app.lvh.me:9000 (lvh.me being an alias for localhost:9000), which is a Yeoman Grunt server taking care of CSS preprocessing, autoreload, Coffeescript compilation, that sort of thing - and my back end API running on lvh.me:3000 (aka localhost:3000), I want to port requests from api.lvh.me:9000 to localhost:3000...because in production, requests which go from the .api subdomain will hit the API anyways.

The idea is to keep production and development as similar as possible. If I make all my api requests from the front end by taking the current URL and replacing 'app' with 'api' or something like that, it routes like this:

• Production: app.examplehost.com --> api.examplehost.com, which is routed to my back end, wherever it's hosted
• Development: app.lvh.me:9000 --> api.lvh.me:9000 --> (thru the grunt server middleware) --> lvh.me:3000, which is my API running locally

CORS isn't an issue because I have access to both the front and back ends - I can just set the back end to allow cross-origin requests from lvh.me, localhost, and the domain I'll be using production. This is just a convenience thing for development.

Make sense? Subdomain routing through middleware lets developers host components separately, but develop with them together. I, for one, see many benefits to this separation of concerns.

I'd be happy to submit a pull request - I wrote my own middleware for this after I submitted this issue, and it turns out it's as simple as checking the req.headers.host property for a string or regular expression instead of the request path. The user could then turn on subdomain checking (rather than path checking) via a boolean called checkSubdomain or something. If that boolean was true, the context provided by the user would be matched against req.headers.host instead of req.path before deciding to forward the HTTP request to a different port.

[drewzboto]

Sounds good. happy to take a PR for this. Before getting to far into it, can you propose what the configuration of the proxy would look like?

[drewzboto]

hey @tedkornish, just wanted to poke you and see if you've had a chance to think a bit more about this one?

[keithjgrant]

I need this functionality, too, so I'll have a PR for you before long. I've got it supporting two types of config structures:

First, specify the context as an object with domain:path as the key:values:

connect: {
...
    proxies: [{
        context: { 'subdomain.localhost': '/context/path' },
        host: 'www.whatever.com'
    }]
}

or you can apply one domain or subdomain to all proxies in the server block:

connect: {
...
    server2: {
        domain: 'subdomain.localhost',
        proxies: [{
            context: '/context/path',
            host: 'www.whatever.com'
        }]
    }
}

In both cases, the domain matches the beginning of the requested domain, so 'subdomain.localhost' above would match requests to 'subdomain.localhost.com'.

Thoughts?

[keithjgrant]

...or even better, a coworker just suggested the context be a function that is passed the request as a parameter and returns true in the case of a match. That would allow a lot of flexibility.

proxies: [{
    context: function (req) {
        return req.headers.host.lastIndexOf('subdomain.localhost') === 0;
    }
    host: 'www.whatever.com'
}]