Split SPA in two apps

Learn
1

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!

2

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.

3

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:

4

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.

5

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

1 Like
6

Ouch, that sucks. But thank you!

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

7

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

8

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

    # 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
    gzip
    rewrite / {
        r (.*)
        to {1} /
    }
}
9

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