Router based on host

Phoenix Forum Questions / Help
,
1

I’m building an app that would handle request for bare domain as well as for subdomains. Each subdomain is client space.

I have very different requirements for bare domain routing and for subdomain routing (same paths with very different functions). So I want to split router in two, one for root and one for subdomains (all subdomains have the same routing).

After researching I arrived to using forward function in the main router to forward to my plug:

defmodule AppWeb.Plugs.RouterSelector do
  @behaviour Plug

  @domain_init AppWeb.RouterDomain.init([])
  @root_init AppWeb.RouterRoot.init([])

  @impl true
  def init(opts), do: opts

  @impl true
  def call(%Plug.Conn{} = conn, _opts) do
    if conn.assigns.has_domain do
      AppWeb.RouterDomain.call(conn, @domain_init)
    else
      AppWeb.RouterRoot.call(conn, @root_init)
    end
    |> Plug.Conn.halt()
  end
end

Each of the routers called in this plug are “regular ones”.

I’m not sure if that is the right way to do it. And another thing that puzzles me it that I needed to add this |> Plug.Conn.halt() at the end of if block. Without it it told me about double rendering (I expected that the normal router called here will halt the request once done).

Is it the correct way to do it? And why (if) is there the explicit halt?

Thanks!

2

Usually for things like this I use nginx in front. Actually, I always use nginx in front.

1 Like
3

Seems you should be able to define two pipelines with different plugs and two scopes using these different pipelines (and even different controllers).

2 Likes
4

Yes, I usually use Caddy in production. But because of the service (and it’s variants) I cannot rely on some rewriting on the proxy.

5

Yes, I have common pipelines in the basic router (that contains the forward) and then I some specific pipelines on each router (root or domain). According to basic tests it works. I did not include source of the Root and Domain routers here, they are pretty standard (I mean specific pipelines, but nothing unusual).

Just wonder if the RouterSelector is ok way how to do it and not sure about that halt (might be a signal that something is wrong).

6

My question was more directed at: why not use 1 router with 2 scopes? :slight_smile:

7

Aa for the halt:

Halt stops the pipeline from proceeding following plugs. It does not halt the request.

So we are in pipeline land. Which clears things up.

Even though a sub phoenix router will send a response to finish the user request (after it halts), the parent plug pipeline that called the phoenix router does not receive that halt instruction; only the response.

So without the explicit halt in the router selector plug, the plug pipeline in the toplevel router will continue to run. Causing the double render error.

This is why the parent router selector plug must also send a halt.

So in lists:
Subrouter pipeline
Plug a
Plug b
Plug render < halt and return conn

Toplevel router pipeline
Plug a
Plug b
Plug RouterSelelector. < halt and return conn
Plug render # it conn reaches me I am second render

1 Like
8

ahaaa. So this halt has to be there because RouterSelector is a Plug? If so this was the missing piece I did not know (together with the fact that halt halts the plugs and not requests.

Thank you!

9

How could I specify scope according to the host value from conn? I know that there is :host option in scope but it says that I can specify domains or prefixes. But my problem is that I need one scope for domain.com and other for *.domain.com. And the subdomains are added dynamically - so I cannot list all there.

Did I mis something in the scope options how to do it?

10

You could have one with hosts: topdomain.com and one scope without hosts set which is a catchall (the hosts field is converted to _ in the route match pattern)

Make sure the toplevel goes first.

Ps. Hosts should be a list of binaries, mobile editing is…less than ideal.

3 Likes
11

Ah, true! I missed that possibility. Thank you!

12

We have to do something similar at work. What we ended up doing is instead of having the Router as the final plug in our Endpoint we have a plug which chooses the correct router based on the hostname. Something akin to this:

plug Shared.RouteByDomain, %{
  "example1.com" => Example1Router,
  "example2.com" => Example2Router
}

And the call/2 looks like this:

def call(conn, routers) do
  with {:ok, domain} <- fetch_domain(conn),
       {:ok, router} <- fetch_router(routers, domain) do
    conn
    |> Conn.assign(:domain, domain)
    |> router.call([])
  else
    # some error handling
  end
end
1 Like
13

Thanks @wolf4earth . This is basically what I’m doing on the beginning with RouterSelector (but not replacing original router, but calling my router selector from the router). I’m curious - you are not calling halt after that? I needed to do so and as @BartOtten explained to me, that it is correct to have it there in my case. But maybe it was because I used forward (and effectively be in pipeline land to use his words). I’m still a beginner trying to wrap my head around it :slight_smile:

14

You use a second router, and so risk a second render which (see previous example). That’s the difference.