Support the contradictive "more than one page for the SPA"

[Spiralis]

I need an application that behaves like this:

When the site is installed I want the first user that accesses it to be redirected to /setup. Then when the user is done with the setup, the site is open for the public, on the root folder /.

Now, I can do this today, either all in on application or as two separate applications. But, in the first example it would mean that the /setup components would be delivered to the end-users as a part of the normal app too, even though they would never ever be needed. Which is obviously a bit unfortunate performance wise (memory and initial load).

The other way around is also possible, but then having the first application modify the second be a bit more cumbersome. Not to mention that two sites would both need to be installed by the "owner".

So, to avoid this it would be better if the setup and main app were indeed two totally independent client applications. At the same time it would be very preferable that they shared the same backend code, as the very nature of /setup would be to setup the configs and to initialize the DB.

I could make them as one and then when setup is done have it "delete" itself. However, this seems excessive. Also, that means that webpack would need to rebundle the app, and for production that doesn't sound like a good idea.

Maybe instead something like this would be better:

1. Keep everything in one app
2. Build two (+) different webpack bundles for the client. In my example "setup" and "main"
3. Setup two (+) routes. One for /setup and one for /. The first loads the setup.js bundle and the latter the main.js bundle. (The global css and scripts could probably stay the same.)
4. The different client apps would set window.location manually when they need to navigate to different SPA apps, so that the server will send the application (at least I think that is the way to do it).

The above means that we could have multiple pages handled by the same backend.

I can for example envision three different SPAs in my app: /setup, /admin and / (the normal user site).

• Does anyone have any experience with something similar?
• Have anyone had similar needs?
• Does anyone know about any other way to solve this?

[arjendeblok]

I have slightly the same issue. For a client I have a number of administrative sites, a public site and a private member site. All of them are accessable via the same URL.
I use the full .NET framework there and I create virtual directories in IIS. All sites uses the same web API, which is a separate Web application.

When using .NET core you could create 3 different ASP.NET Core applications for setup, admin and the normal site and a single back-end web API and let in run on Kestrel. Then you could setup a web server in front (reverse proxy) that routes the public URL to the different web applications. You could IIS or Node for that purpose. So /api routes to the Web API, /setup routes to the setup web application.

[Spiralis]

I was thinking about that as a solution. It just feels excessive to have three totally separate applications for this, especially since they are all very related.

My hopes were that it would be possible/trivial to set this up in one and the same application instead. I mean, setting up webpack to do three different sites seems possible. And, setting up routes in the backend to handle the other two separately should also be doable. I was just hoping that I weren't the first one to try something like that :).

[SteveSandersonMS]

You can absolutely have as many separate SPA-type apps served by the same ASP.NET Core site as you want. Just put them in separate directories, give them separate Webpack configs, and build separate bundles from them. They can be completely independent.

As far as the server-side routing is concerned, it will be easiest if you route separate directories to them (e.g., /subapp1 and /subapp2) rather than having one appear to be in a subdirectory of the other.