Hostname must be specified at docker container build-time rather than run-time #21
Description
Why is this a problem?
With the current configuration of the TeleView component applications, each instance of TeleView must know the host name while the docker images are built. ThIS requires that all teleview docker images be built with specific hostname, preventing the project from being distributed on as a pre-built image on the GitHub Container Repository or DockerHub. This adds an extra step for configuration that does not otherwise add any value; having to build TeleView on every host is a hack, not an intended design feature.
What is causing this issue?
The problem is in a single TeleView component application, tvapp which uses a NEXT.js (link to the relevant NEXT.js documentation for the App paradigm used by teleview) to build the production website. Like all modern websites, when tvapp is compiled a certain number of static files that are generated at build-time, these static files run code on the client browser and tell the browser how the format the HTML it receives from a web-server. Like many web frameworks, NEXT.JS is focused on serving the dynamic HTML content and only does static file serving as courtesy. Many larger websites serve static content through content distribution networks (CDN), systems that specialize in serving static files.
NEXT.JS is setup to allow us to serve static files from an arbitrary host at runtime. The conflict occurs because TeleView is required to serve at subsdirectory of an arbitrary host (hostname.com/sudirectory/ -> site.simonsobs.org/teleview/). When using the tool to serve the static files generated at build-time, we now need to specify the assetPrefix = site.simonsobs.org/teleview/ at build-time, which disables the dynamic hosting of build-time assets. This is all configured in tvapp/next.config.js, see the variables basePath and assetPrefix, see the NEXT.JS documentation for basePath and assetPrefix.
What Solutions have been considered?
Simply, this is an Asset Management problem that is causing this issue. We could address how the assets are served to resolve this issue.
Collect the static assets at build-time from NEXT.js and serve at a default location.
The other primary TeleView application, tvapi written in the Django framework, does not serve static files at all. We can use this as an example of how to get around the built-in tools for the NEXT.js tvapp. Just like the the tvapi, we can collect all the static files generated by tvapp at build time. Then we can make a docker volume to share the static assets between the docker images of the tvapp and the image of the NGINX server. This is done using the docker compose file in this repository. This would also require updating the NGINX config file nginx/nginx-setup.config and then adding the new URL path to tvapp config tvapp/next.config.js
Should we be serving static files from the site-computer?
The site computer is really far away and has limited resources like bandwidth. Should it even be used for serving static assets? Ideally no, this is a waste of resources. However, a system that is too complicated to manage can be an burden on the staff that maintain this website.
The only thing the must be served on the site computer is the dynamically generated HTML for teleview that contains the website's document structure, data from the mongoDB server, and links to static assets. To see how TeleView tvapp webpages is loaded: Go to the TeleView Website, using Google Chrome right click on the page and select inspect, then navigate to the Network tab, then click the box that disable cache. Then you can reload the page to see the network waterfall plot for how TeleView sends your browser the data to build the webpage. The first item fetched is the only one that the site computer needs to send, the rest are all static files with scripts, images, and formatting instructions.
.
From the waterfall diagram you can see the cascaded fetching of static assets doubles the loading time for the TeleView webpage. However, the load time get faster once the static files are cached by your browser. So loading time extended only for the initial load time, and the first load after the static files are updated.
However, we can reduce these loading time by simply serving the static assets on another persistent network. A $5 a month virtual machine on Amazon Web Services could serve these files. This frees resources from the site computer and makes a faster website. However, there is the added complication of serving a website with files from two locations. This is a standard in many websites, but it is a complication that should carefully considered as it does require more knowledge to maintain.