Phoenix: Feature request: Routing sockets based on host

[fredr]

In plug, we can route requests based on host

forward "/", host: "api.", to: MyApp.API.Router

We are using phoenix together with absinthe to build our GraphQL api:s. We host different schemas on different subdomains, and we are now looking into GraphQL subscriptions. But it seems sockets are only routable on path and not host.

[josevalim]

We support it too: https://github.com/phoenixframework/phoenix/blob/98d1931e221690c270936cdf1150b21c88ea6621/lib/phoenix/router.ex#L599-L600

:)

[josevalim]

Ah, maybe we don't support it on forward? What if you put forward inside a scope? Please verify and then let us know or close the issue accordingly. :)

[fredr]

I meant it was not supported for socket, aka this is not possible:

socket "/ws", host: "api.", MyApp.API.Socket
socket "/ws", host: "internal.", MyApp.InternalAPI.Socket

But I did not consider that I could use scope in the router. I thought socket were only possible to route in the Phoenix.Endpoint.

But I guess you mean I could do this in a Phoenix.Router?

scope host: "api." do
   socket "/ws", MyApp.API.Socket
end

I'll test it out!

[josevalim]

I see. Please try it out and let us know.

[fredr]

Ok, I've done a little testing, and I didn't find a way to route sockets on anything else than path.

If I'm not missing anything obvious, the only place I can route sockets, is in a Phoenix.Endpoint, and not from a Phoenix.Router. And the socket does only take a path: https://hexdocs.pm/phoenix/Phoenix.Endpoint.html#socket/2

In our current setup, we have one Phoenix.Endpoint, and inside there we have plugs that, based on host, runs different Phoenix.Router.

So, we only have one Endpoint, and listen to one port, but serve different routers based on host.

We could also change our setup to either expose several endpoints over different ports or route everything based on path and then let nginx do the host magic. But I would prefer not to have to do that.

[josevalim]

Agreed. We should support this feature.

[chrismccord]

After putting together this feature #2737 , it exposed some unforeseen complexity and issues that require a bigger refactor than we thought. I'd still like to support this feature, but it will need to happen along with your transport refactor which is still TBD, so closing for now. Thanks!