feature: support running the app under a base URL

[delocalizer]

Is your feature request related to a problem? Please describe.

Related issue: #3356

I would like to host REMS under a non-root URL e.g. https://my.domain/app1/ so that I may use path-based routing to gather related services under the same domain. This greatly simplifies sso and other shared origin requirements.

My reading and experiments lead me to think that currently I can't do this because REMS is a single-page app that doesn't support a non-base URL configuration. I have tried reverse proxy config in front but it is not sufficient because using e.g. nginx sub_filter or Apache mod_proxy_html can only rewrite paths that appear explicitly in responses and not the application paths dynamically generated in script.

Describe the solution you'd like

I would like a configuration point base-url that defaults to / but can be changed to something else e.g. /app1/, so that the REMS application paths are all relative to that base URL.

Describe alternatives you've considered

I have tried a reverse proxy. The best I can get REMS to work with is a proxy to a different port and/or subdomain, but not a new base path.

Additional context
Thanks for creating and maintaining REMS. It's a great product.

[meericsc]

Hi,
thank you for the suggestion and feedback! We don't currently have plans to implement something like this as it would require quite many changes, but we’ll keep it in mind for the future. We also welcome contributions and would be happy to hear more about your REMS use cases.

[delocalizer]

Thanks @meericsc ; I don't have experience in clj or single page apps but I will take a run at a PR. Can you very briefly describe the changes you think that will be required in which components? Just a single sentence description for each would be great, e.g.

1. add config point to context in file x
2. update the resource urls in file y
3. update API urls in file z
   ...
   It doesn't have to be 100% correct deep analysis, just a rough sketch for me to take away, write some tests and get started.

A follow-up question — looking at the current codebase it seems there is some code around root-path and app-context, and from the commit history these were once more widely used throughout; was this a feature that was planned but never fully implemented, or did it get dropped at some point?

[Macroz]

Thanks @meericsc ; I don't have experience in clj or single page apps but I will take a run at a PR. Can you very briefly describe the changes you think that will be required in which components? Just a single sentence description for each would be great, e.g.
...
A follow-up question — looking at the current codebase it seems there is some code around root-path and app-context, and from the commit history these were once more widely used throughout; was this a feature that was planned but never fully implemented, or did it get dropped at some point?

Here is a rough overview.

This is actually a REMS 2, and originally REMS 2 was a server-side application, not a single-page app. Then all the URLs were generated in the backend, so there were likely also more references to root-path and context. REMS 2 was originally also run on Tomcat server, because that was the only one that supported AJP protocol, which Haka authentication required. These days REMS 2 is a modern single-page app (SPA) and most URLs are created in the front-end, i.e. the web app.

The problem is multifaceted. First of all the backend, which does less URL manipulation, must be updated to respond to basically all requests within the new "app path context" and not any others (to not require a separate router in front of REMS). Then the larger part of the problem is in the front-end URL routes and generating URLs.

• Basically at least places where :public-url is used, should potentially handle something like :app-path. It should also define whether the app path is in addition to the public URL.
• The backend for the front-end routes must all support this. Many do redirects after logging in. (see Compojure routes e.g. defroutes in handler.clj)
• The API routes must all support that the API is not at the root /api (see compojure-api routes in api.clj)
• The single-page app routes must all support this. Possibly Accountant "interceptor" could handle removing the app path from the path and then just re-use the existing route definitions. (see Secretary and Accountant in app.cljs
• There are many places within the front-end *.cljs files where a URL is produced or manipulated, and these should either be changed to use relative URLs or generate (using config) a proper URL including app path.
• The tests should test this new feature, likely using browser tests.

It could be worth it to just try it out and report findings, but I think the road is going to be quite long and bumpy, unfortunately.

[delocalizer]

Thank you @Macroz for the background and detailed description. I'll have a go at this.