Split SPA in two apps

I am developing a SPA which has an admin section that I would like to separate from the rest of the application. It gets a bit messy with nested views/pages and mixed anonymous users and authenticated users. Plus that there is lots of code downloaded to the client which in the most part is never used.

I have successfully created two apps that coexist in the same codebase which lets me share code between the two apps. I created a secondary index.html under admin-folder which points out my admin.main module. Parcel is compiling both apps just by adding a second path to my other html file. All is good, BUT! now when I test the application in the browser I have to type in http://localhost:1234/admin/index.html or http://localhost:1234/index.html to hit my apps. The address used to be http://localhost:1234/#/.

The expected address to my apps would have been http://localhost:1234/#/ and http://localhost:1234/admin/#/.

Can someone help me?

Ps, thank you to users on Slack that helped me come this far!

What happens if you access http://localhost:1234/#/ ?

This looks like a server settings issue. Elm is not involved in serving the content in any way.

I think I get a 404 or something similar. In any case I get a Chrome error page.

Den tors 26 dec. 2019 07:49Peter Damoc via Elm elm_lang@discoursemail.com skrev:

Yes, I can confirm that I get a 404 on http://localhost:1234/#/.

I can also add that when I go to http://localhost:1234/index.html and then click on an internal link the address becomes this http://localhost:1234/index.html#/camp/IYhbaGQZWpTOE0rjHWyR.

It looks like this is limitation of parcel. It is even mentioned in the getting started doc.

1 Like

Ouch, that sucks. But thank you!

I guess I can live with that during development and hope that firebase serves it the right way.

I think you can configure a local nginx instance as a reverse proxy and have it do the proper thing.

As mentioned before you can configure your server to handle this for you.
In my company we recently configured to Caddy to handle this exact situation.
You can use a Caddyfile like this in your production or staging environment:

# https://caddyserver.com/tutorial/caddyfile
# The first line of the Caddyfile is always the address of the site to serve
*/admin {
    # https://caddyserver.com/docs/root
    # A relative root path is relative to the current working directory.
    root admin-build

    # https://caddyserver.com/docs/tls
    # disable automatic HTTPS if there is a proxy server in front handling this for you
    tls off

    # https://caddyserver.com/docs/gzip
    # Note that, even without the gzip directive, Caddy will serve .gz (gzip) or .br (brotli)
    # compressed files if they already exist on disk and the client supports that encoding.

    # https://caddyserver.com/docs/rewrite
    # rewrite [not] from to...
    # - not: if specified, will invert the pattern and matching logic
    # - from: is the exact path to match or a regular expression to match
    # - to: is a space-separated list of destination paths to rewrite to (the resource to respond with);
    #   it will try each destination in sequence until the first one that exists on disk in the site root
    rewrite / {
        r (.*)
        to {1} /

* {
    root standard-build
    tls off
    rewrite / {
        r (.*)
        to {1} /

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.