Use remix with wildcard subdomain

[lgraubner]

Hi!

I'm thinking about building an application which uses one subdomain per user. So for example my app has one main domain, where it shows a simple landingpage, register, login etc. If the app is accessed with a subdomain (which is tied to an user) it should show different content, both public and also a authentication required area.

I made some shallow tests and it seems to work just fine. The authenticated part is the same for every user, just with a subdomain as additional identifier. Routing between domain/subdomains happens only via redirect in loader and not client side.

Are there any downsides I'm missing?

[a-type]

Hi @lgraubner , would you mind sharing some more details about your explorations? I'm considering using Remix for an app which allows branded subdomains and I'm interested in how you approached it. Is there a difference between the way the app renders on mainsite.com/ vs user.mainsite.com/, and if so, how did you include the logic to differentiate those within the app?

I'm specifically looking to do a subdomain system where someone.mainsite.com/x is equivalent to mainsite.com/someone/x for any nested x. I'm having some trouble wrapping my head around doing that with filesystem routing. It feels like I'll end up having to include two parallel identical route trees in all of my route modules...

routes/
|__ $username/
|    |__ x.tsx  <-- matches mainsite.com/someone/x
|__ x.tsx <-- matches someone.mainsite.com/x

This doesn't seem practical at all client-side. Really feels like some server middleware is in order.

Of course Remix does seem to expose plenty of opportunities to modify server behavior. I'm going to explore some more and see... entry.server.tsx looks promising, in particular.

[a-type]

For an example of how this is achieved in Next, see their middleware concept. Middleware is pretty much what I was looking for as I was exploring this feature. An explanation of how it's used is included in Vercel's platform starter kit.

It seems to me like this should be achievable in Remix in a similar manner - either as a middleware layer which rewrites route matching information before the server renders the page, or as something higher up which changes the path passed to Remix to render (as I did with my Vercel function example above). The latter is more limited as it's platform-dependent and can't run in development mode.

Just dropping this in the discussion as a reference implementation. I think the way Next does it is quite nice as it encapsulates the entire multi-tenancy logic into middleware and doesn't leak it into the actual routing.

Edit: further investigation in Remix source seems to point to a middleware not being possible at the Remix runtime level for this. Remix processes route matching before it calls into entry.server.ts, so you can't intercept and rewrite the URL at that layer. Any implementation of multi-tenancy through routing middleware will have to happen at the platform layer before calling into Remix.

[prsnnami]

@a-type did you end up finding a solution for this. I was also just looking into remix for our multi-tenant app and it seems remix doesn't play well with the concept with filesystem routing and lack of a middleware.

[a-type]

Nope, for this and a few other reasons I switched back to Next, although I still think Remix does a lot of things better and easier. Hope it evolves to reach these use cases over time!

[kiliman]

Just remember that Remix does server-side routing for the initial page. Subsequent navigations are handled by React Router client-side. So URL rewriting on the server is not possible in Remix, as the URL in the browser must match the routes being processed on the client.

So your loaders will have to check the host header to see what content/layout to render.

[shawnmclean]

Damn, seems I have to stick to nextjs then, I really wanted to use remix on fly.