2

I'm working on a relatively thin front-end web application that talks to an API. Depending on where this front-end application is served from (CI server, staging server, production server, etc.) I want it to be configured to talk to a different API server.

We're not really a web shop, so we're all inexperienced with this. Our normal approach (for back-end services) is to configure this stuff through environment variables. In this case, however, the entire frontend is just a bunch of ECMAScript files served up by nginx and executed entirely in the users browser, meaning they (obviously) don't have access to the server environment.

Solutions we have considered but are unsure of:

  1. We could, I suppose, set up a path in nginx that simply serves the values of environment variables. This feels weird and makes the frontend application dependent on the specific web server and the configuration used to serve it, which doesn't sit exactly right with me. On the other hand, it's good in the sense that it fulfills the expectations we generally have on applications depending on environment variables.

  2. We could differentiate between environments at build time, build slightly different versions of the frontend application for different environments. A drawback of this is that multiplexing builds on environment feels like a slippery slope I don't want to get near.

  3. We could try to deploy an environment configuration file along with the application into a generic environment, and download that by including it in a script tag in index.html, for example. This would allow us to keep building single binaries, but we need some additional logic to deploy the right thing. If a goal is to keep deployments of new versions as simple and similar as possible ("just copy the files to the server"), this is counter to that.

  4. (Which I just thought of as I wrote this): The nginx server that serves the frontend could also have a location that redirects to the correct API based on environment variables – but again, this introduces logic/complexity in a place where we're not used to having it.

Despite everything, I'm leaning towards option 3, but I'd like to hear the opinion of more experienced people.

How is this normally handled? What other options are there?


Edit: I should be clear that we don't want to serve the frontend application from anything other than a plain web server like nginx. I gather it's common to serve the frontend application files from something like node.js, but this is out of the question in order to maintain a small-ish set of moving parts.

1 Answer 1

2

4 is good if you have your application begin behind reverse proxy like cloudfront you can configure /api/* to go to your backend. Cloudfront brings other advantages like https and caching.

3 is probably best for your scenario. Just put a step in your pipeline where you transform your index.html (jsdom is good for this) the advantage of using script tags is they are valid HTML so they play nice with local development servers(as opposed to other placeholders)

As for 2 I agree that you do not want to build multiple times.

1 is probably the easiest deployment-wise (but not best) but it is annoying to do an extra Ajax request everything you have to call the backend.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.