Docker and Base URIs - Best practices
What’s the issue?
Nowadays plenty of frontend code is being created using an [SSG] which is great. There a multiple ways of deploying such code and one of these is [Docker]. Typically everything is fine when you are deploying the frontend code using a root path such as
https://app.mydomain.org
However that’s not to the liking of everyone as some people prefer to use a base uri such as
https://mydomain.org/app
Unfortunately the latter option is often problematic especially in a [Docker] context as URLs need to be rewritten for this to work (there are plenty of varying possibilities depending on your actual deployment scenario). And it’s likely that this won’t even work properly. Let’s say you have a website with actual assets which means that the pages (the actual responses) of your app might contain stuff like this:
<script src="/static/hash.js"/>
The browser would in turn create a request like this to load that resource:
GET https://mydomain.org/static/hash.js
Obviously this will fail as the correct reference would be
GET https://mydomain.org/app/static/hash.js
In order to get this to work you must either alter the response data which would be crazy or you need to create your own [Docker] image containing containing the app with a base uri already set when compiling the [SSG] (fortunately supported by all popular web frameworks). Though this might be working people end up with custom [Docker] images for this simple purpose.
What’s the solution?
The solution should be a best practice for frontend developers to always include a base uri. All references in the generated code would look like this:
<script src="/myapp/static/hash.js"/>
This generic practice would address all needs:
- Root path based deployments: Just strip the base uri which can be easily done with rewrite rules.
- A deployment using a different base uri. For instance /frog/ instead of /myapp/ this equally means that the prefix just has to be replaced using rewrite rules.
- For everyone else can use the base uri as is.