Javascript frontend configuration at runtime
Asked Answered
S

1

6

I have a vue.js SPA which I want to deploy on different servers without recompiling the frontend for each deploy. The SPA connects to a backend, with a url yet unknown to the spa. Is there a way I can dynamically tell the frontend at runtime where the backend is?

Many articles and forum threads suggest to just use different config files for different environments and build them in at build time, but that is not an option for me because I simply don't know where the frontend/backend will be deployed when building it.

EDIT: The project is an open source project, so I can't really make an assumption about how people will deploy it. I've always kind of "assumed" it would be deployed on a seperate sub domain, with the frontend being reachable at / and the backend with a proxy at /api because that's how I set up my server. However, I've seen people deploying the api at a totally different sub domain (sometimes even with different ports) than the frontend or on a sub path or even a mixture between the two.

Things I've considered so far:

  1. Putting the config in a conf.js which would then expose the backend url via window.config.backendUrl or similar and load that file in my index.html from a <script> tag
  2. Slightly similar to 1.: Put the config in a config.json and making a fetch request to it once the application loaded, then exposing the result of it in window.config.backendUrl
  3. Inserting a <script>window.config.backendUrl = 'http://api.example.com'</script> in my index.html.
  4. Serving the frontend with a custom made web server (based on express or similar) which parses either env or a different config file and then creates the <script> tag from 3. dynamically
  5. Always "assuming" where the backend will be with some kind of list to work up, like "First look at /api then at ./api then at api.current-host.com etc."
  6. Bundling the frontend with the backend - that way I would always "know" where the backend relative to the frontend is.

Yet all of theses options seem to me a bit hacky, I think there has to be a better way.

My favourite is the third option because it is the best trade off between configurability and performance IMHO.

Sacellum answered 24/2, 2020 at 18:19 Comment(3)
How are you deploying the frontend? Depending on your configuration, another viable solution would be to use a proxy (you always point to api.mysite.com and it calls the proper backend), or a custom DNS (you always point to api.mysite.com and it returns the correct IP address).Coaming
The frontend is deployed with a standard web server, think nginx or apache. Its supposed to be only a bunch of static files you throw on a server somewhere.Sacellum
I've clarified the initial question a bit more about the environment this will be deployed to.Sacellum
S
3

If I was in the same situation I would have considered the following 2 approaches:

  1. Deploying a JSON file with the same name but with different contents - so the frontend can always fetch its configuration by making AJAX call to /config.json but this file will depend on where you deploy and will be generated during the deployment step

  2. Using a single API endpoint with a fixed/constant URL (completely separate from your backends) - so that frontend always calls this API endpoint to get its configuration at startup and the actual URL of the corresponding backend for its further operation.

Basically (2) is just the dynamic version of the static configuration in (1).

Spiritoso answered 24/2, 2020 at 18:43 Comment(2)
I like that approach, however it would require the whole spa to wait until that request is done. Which in itself is okay, but not ideal imho. What are the differences to the first and second approach in my initial question?Sacellum
Your first approach requires rebuilding of the SPA. Your second approach is the same as my first - with the exception of window.config expose. Yes, the SPA will have to wait until it fetches the config - but this is the tradeoff that you are making in order to avoid rebuilding on each deploy. If you can afford this rebuilding step - then each variant of the SPA will instantly know its backendUrl.Spiritoso

© 2022 - 2024 — McMap. All rights reserved.