"Rerouting"/changing resolved request

[Refzlund]

The idea is to use SvelteKit as a tool for routing, and thus, rerouting based on a specific request.

For instance having
domain.com/path... route to /path...
and subdomain.domain.com/path... to /subdomain/path...

I tried changing the request in server-hooks.ts as well as the URL, but couldn't make it work. Any ideas on this?

[teemingc]

Sounds like something you would have to configure in .htaccess or whatever configuration on your server.
Unless you have two different SvelteKit apps living at both of those URLs?

If you have one SvelteKit app at subdomain.domain.com you could point to the other SvelteKit app at domain.com such as:

const subdomain = 'subdomain'

/** @type {import('@sveltejs/kit').Handle} */
export async function handle({ event, resolve }) {
        // redirect subdomain.domain.com/to domain.com/subdomain/
	if (event.url.host.startsWith(subdomain)) {
	        // change subdomain.domain.com to domain.com
                event.url.host.replace(subdomain, '');
                
                // change /path to /subdomain/path
		event.url.pathname = `/${subdomain}` + event.url.pathname;
		
		return Response.redirect(event.url, 302);
	}

	const response = await resolve(event);
	return response;
}

[Refzlund]

It makes sense in that it's probably not possible anymore. I did it before v.27x and it broke, so I was hoping someone smarter than I knew a way around it. The current approach at the current stage is probably to just apply some kind of rewrites at whatever host or service is being used.

The redirection is a nice approach, but I guess you'd be left with subdomain.domain.com/subdomain no?

It just hit me, that if what I am asking for existed, it would probably look like docs/advanced-routing#matching but at a group level in the root directory of routes. Having a matching strategy based on the hostname.

Anywhoo thanks for your input!

[Refzlund]

I just wanted to add, that what we do currently is having

organisation.domain.com which will show pages regarding a specific organisation. It's set up so it connects to the database of that organisation based on the subdomain.

And for domain.com it just ends on landing-page.

Then our routes look like

(organisation)
    page.svelte
    layout.svelte
(homepage)
    page.svelte
    layout.svelte
+page.svelte
+layout.svelte

We use event.locals.organisationId to determine whether an organisation exists. It is send to the LayoutData and PageData, and they will then load the correct page/layout component.

What I dislike about the approach, is that, if ever any route collide, then we would have to copy that route outside the groups, and have it reference the correct components like above, but at deeper levels.

The reason we do it inside SvelteKit, is the connection to the databases. When they land on org.domain.com, we look in our primary database for that organisation identifier (org). If it exists, we populate event.locals.orgDb with the correct database. So when the request resolves, it will be using the database corresponding to that specific organisation.

[teemingc]

The redirection is a nice approach, but I guess you'd be left with subdomain.domain.com/subdomain no?

It should be changing the host from subdomain.domain.com to domain.com too, but I'm not sure how to test that.

(organisation)
   page.svelte
   layout.svelte
(homepage)
   page.svelte
   layout.svelte
+page.svelte
+layout.svelte

It looks like you should be using parameters instead of group layouts for this.
Thus, any page under src/routes/[org]/... would fetch from the correct database based on the params (whatever params.org equals to in the load function).

Then, you could add parameter matching such as [org=orgId] to check that the organisation exists, otherwise returning a 404.

// src/params/orgId.js
/** @type {import('@sveltejs/kit').ParamMatcher} */
export function match(param) {
  // check primary database if org exists
  // then return true or false
}

The issue is the param matcher doesn't have access to event.locals so it can't pass data to the load function. Maybe it should? Otherwise, matching this in the server hook might still be the best bet.

[Refzlund]

It is a valid point to direct users by domain.com/org/...

The difference I make is that subdomains defines a confined space of navigation, while routed paths are a single cluster of an actors roam. Another part is the feeling of premium and ownership - as the URL is easier to remember when they're in the front, rather than dead center.

Take

domain.com/someorg/admin/users/edit/621920ofd6021

Against

someorg.domain.com/admin/users/edit/621920ofd6021

From a user-perspective, you might never leave someorg. We have our customers, the organisations, and the users for said organisations.

These end-users might be more tempted to head to the URL

domain.com/ rather than domain.com/someorg

So the someorg.domain.com confines the users to said space. As when they want to visit that organisation page, they type the organisation name, and not the mid-level domain-name.

And I do not necessarily agree to the idea of splitting code based on DNS servers. So the rewrite solution does suggest, that we split our code. Then you have to think about monorepos for re-usable components. It's just (to me anyways), more complexity than it needs to be.

That's why we do stick to subdomains, even if it means avoiding routes that collide. Ex. domain.com/adm (instead of /admin), and org.domain.com/admin

* Edit: rewriting does not suggest code-splitting. I was thinking about routing specific DNS rules to subdomains, which would have to be directed to another project, that would lead to splitting code. However, not all services provide rewriting, and I don't think (in our case) Vercel rewrites work with SvelteKit as I have tested it before.

[teemingc]

Ah, my bad. I mistakenly thought the idea was to redirect from the subdomain to the domain.

That's why we do stick to subdomains, even if it means avoiding routes that collide. Ex. domain.com/adm (instead of /admin), and org.domain.com/admin

Can you further explain what the issue is with the route collision?

Am I correct in understanding that the features are the same for each org, but fetches data from a different db based on the subdomain? So you could:

1. Have a root +layout.server.ts file that sets the correct database based on url.host.
2. The same /admin page for domain.com and subdomain.domain.com but it loads the correct content because of the previous step.