dacz

dacz

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!

Showing Posts 13 to 4

BartOtten

BartOtten

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

dacz

dacz OP

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:

wolf4earth

wolf4earth

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
dacz

dacz OP

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

BartOtten

BartOtten

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.

dacz

dacz OP

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?

dacz

dacz OP

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!

BartOtten

BartOtten

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

BartOtten

BartOtten

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

dacz

dacz OP

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

Where Next? Top

Trending in Questions Top

katta
I having some trouble figuring out if I have set myself too strict of standards for my production server. Currently I can handle 75% of r...
New
achenet
Hello, I’m trying to build a basic Phoenix web-app, and I’d like to use Tailwind. However, when I launch mix phx.server, I get an error...
New
peck
Hi everyone. My team and I have been working on a fairly modest app based around video streaming and chat, but we’ve landed a customer t...
New
bradley
I really like the adapter patterns that ecto, nebulex, waffle, etc. use and would love find something similar for a key management servic...
New
unaware8150
Hello folks! So at work, we are seeing some situations where we have to define some “fixed” strings that are used across the codebase in...
New
Cxx-mlr
I’m working on a small exercise involving update_in/3, and I came up with this solution: data = %{ name: "Periodic Table", category:...
New
Alvinkariuki
How Can I Optimise Compile Time Dependencies I have been building an elixir application for about 2 years now. Many modules and files ha...
New

Other Trending Topics Top

GenericJam
Edit: 2026 May 15 - This post is archived. Mob is alive!! Main docs: mob v0.7.11 — Documentation A bit of explanation for the slightly c...
New
budgie
A little off-topic, but I feel like people here have a good head on their shoulders. I used to be quite good at making software. Was luc...
New
KristerV
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
mudasobwa
I fully migrated to my own harness from Anthropic/Gemini and I think it’s time to share it. Welcome DSH, the DeepSeek Harness, fully writ...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
juhalehtonen
There has been a thread to discuss the Stack Overflow Developer Survey on this forum every year since 2018, so here’s yet another one for...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews