Fork me on GitHub
#re-frame
<
2020-05-17
>
Jakob Durstberger08:05:21

I have an API key that I don’t want to commit to my source control. What is the best way to “inject” values at compile time? Ideally different values for dev and prod builds. I could find anything in the re-frame and shadow-cljs docs. I found https://shadow-cljs.github.io/docs/UsersGuide.html#closure-defines but they seem also to be static in the config files.

thheller08:05:41

but I generally recommend keeping "runtime configuration" out of the build completely and instead actually configure it at runtime

thheller08:05:23

eg. you set <script>_APP_CONFIG = {key: "foo"};</script> in your HTML and access it via js/window.MY_APP_CONFIG.key in your code

thheller08:05:42

many different ways to go about this

Jakob Durstberger09:05:06

Sorry I think I am being slow. > eg. you set <script>http://window.MYAPPCONFIG = {key: “foo”};</script> in your HTML Doesn’t that require me to put it into my repo again?

Jakob Durstberger09:05:36

--config-merge seems to be something I can do on my build server with env variables. Do you recommend against doing that?

thheller09:05:10

sorry I was assuming you have some server-side that generates the HTML

Jakob Durstberger09:05:07

No sorry, so far I am working on a plain old client-side SPA

thheller09:05:29

if you really want to turn it into a compile time constant then you can. either --config-merge or env vars work

thheller09:05:48

you can also load the config dynamically at runtime if you don't want to put it into the HTML

thheller09:05:09

as I said ... many different ways to go about this. don't know enough about your app to know what would work for you.

Jakob Durstberger09:05:50

Yeah, maybe a bit more context is useful. I want to write a little authenticated multi collaborator ToDo app, but I want to make it open source. Therefore I don’t want to commit my authentication pool Ids (Using AWS Cognito) to the repository. But ideally provide a simple step on how anyone could create their own user pool and set their ids.

thheller09:05:01

well I would still put it into the HTML that way I think

thheller09:05:45

eg. you create an index.sample.html with some instruction on what to do with it to create the "real" index.html

Jakob Durstberger09:05:02

Alright, I did that with my config.js file and it works like a charm. Thank you so much 🙂

thheller09:05:03

and just don't put your index.html into the repo?

thheller09:05:41

or you put it into an env var, it is up to you really

thheller09:05:53

I generally advise to keep runtime configuration out of the build

👍 1
thheller09:05:57

and this is runtime configuration

Jakob Durstberger09:05:49

Nice, I like that. I could also make the script it’s own file and provide a sample. Then it should be relatively easy to provide the real file on a build server. Thank you for your help, I’ll see how I get on 🙂

👍 1
Jag Gunawardana16:05:39

I do something similar to the above, but implement it differently so that I have something that works in dev (local machine) and other envs. Have a file in the public dir called parms.json with all the config in a json map. When developing (I use shadow-cljs, but will work with anything) I do a GET /params.json to get runtime params . When I build for test/staging/prod (same docker for each) I have nginx serving my cljs app, and I have a section in the nginx.conf that uses envsubst to serve the same structure as params.json, but for the environment. That way I let env vars drive things.