diff options
Diffstat (limited to 'wiki/dev/configuring-browser-apps.md')
| -rw-r--r-- | wiki/dev/configuring-browser-apps.md | 42 |
1 files changed, 33 insertions, 9 deletions
diff --git a/wiki/dev/configuring-browser-apps.md b/wiki/dev/configuring-browser-apps.md index 0c8c09b..8bba0b2 100644 --- a/wiki/dev/configuring-browser-apps.md +++ b/wiki/dev/configuring-browser-apps.md @@ -6,8 +6,15 @@ browser apps/single page apps this year. I have some thoughts on configuration. ## Why Bother * Centralize environment-dependent facts to simplify management & testing -* Make it easy to manage app secrets. (“Secrets”? What this means in a browser app is a bit different.) -* Keep config data & secrets out of app's source control +* Make it easy to manage app secrets. + + [@wlonk](https://twitter.com/wlonk) adds: + + > “Secrets”? What this means in a browser app is a bit different. + + Which is unpleasantly true. In a freestanding browser app, a “secret” is only as secret as your users and their network connections choose to make it, i.e., not very secret at all. Maybe that should read “make it easy to manage app _tokens_ and _identities_,” instead. + +* Keep config data & API tokens out of app's source control * Integration point for external config sources (Aerobatic, Heroku, etc) * The forces described in [12 Factor App: Dependencies](http://12factor.net/dependencies) and, to a lesser extent, [12 @@ -42,13 +49,30 @@ There are a few ways to get configuration into the app. * Easy to consume: it's just globals, so `window.appConfig.foo` will read them. * This requires some discipline to use well. * Have to generate a script to set them. - * This can be a `<script>window.appConfig = {some json}</script>` tag or a standalone config script loaded with `<script src="/config.js">` - * Generating config scripts sets a minimum level of complexity for the deployment process: you either need a server to generate the script at request time, or a preprocessing step at deployment time. - * It's code generation, which is easy to do badly. This is probably safe: - - var config = `<script>window.appConfig = ${JSON.stringify(appConfig)};</script>`; - - Good luck proving it. + * This can be a `<script>window.appConfig = {some json}</script>` tag or a + standalone config script loaded with `<script src="/config.js">` + * Generating config scripts sets a minimum level of complexity for the + deployment process: you either need a server to generate the script at + request time, or a preprocessing step at deployment time. + + * It's code generation, which is easy to do badly. I had originally + proposed using `JSON.stringify` to generate a Javascript object literal, + but this fails for any config values with `</script>` in them. That may + be an unlikely edge case, but that only makes it a nastier trap for + administrators. + + [There are more edge + cases](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify). + I strongly suspect that a hazard-free implementation requires a + full-blown JS source generator. I had a look at building something out of + [escodegen](https://github.com/estools/escodegen) and + [estemplate](https://github.com/estools/estemplate), but + + 1. `escodegen`'s node version [doesn't generate browser-safe + code](https://github.com/estools/escodegen/issues/298), so string literals + with `</script>` or `</head>` in them still break the page, and + 2. converting javascript values into parse trees to feed to `estemplate` + is some seriously tedious code. ### Data Attributes and Link Elements |