Environment Variables
💎 FABs are designed with the needs of modern frontend applications in mind. That is, we understand that your frontend may run in several different environments, with variables needing to have particular values injected for each one. For example:
- Different API URLs for staging/testing/production backends
- API keys for third-party services might be different
(switching between testing/live payment integrations, for instance) - Features may be turned on or off depending on environment
To support this, every time your FAB is executed, the current environment variables are injected as the settings object:
export default ({ Router }) => {
Router.on('/api/:route(.*)', ({ params, settings }) => {
return fetch(`https://${settings.API_URL}/${params.route}`)
})
}
A FAB will default to passing in the production environment variables, plus any overrides that are defined by the hosting platform. For Linc, that process is done in a dedicated Environments tab on the Site config:
This defines a STAGING environment that will be available through Linc's environment-specific Preview URLs (like https://example-repo-[FAB_ID]-staging.linc-preview.sh/). For more information, see the Linc docs.
Bundling Production Settings
One of the most important things to remember about working with Environment Variables and FABs is that production settings must be bundled into the FAB itself. This is what enables a FAB to be truly portable—you can upload a FAB to any hosting platform (with the right adapter) and it can serve production traffic. That means that whether you want to host your own FAB, wrap it up in a Lambda@Edge or Cloudflare Worker, it can always serve production traffic because it has everything it needs in the bundle itself.
In practice, that's done using a production-settings.json file that your FAB compiler (e.g. @fab/static) will include into your bundle.
Exposing Settings to the Frontend
The FAB specfication only defines one place that the settings object is injected: the server-side render method. It's up to the the particular bundler to pass that through to the client-side JavaScript, but its recommended to follow the example set by @fab/static and provide a FAB_SETTINGS global variable in the HTML as it's sent to the client.