11–20 of 66 posts
Setting such long expiry times on the cache also sounds like a great way to pollute browser caches with obsolete resources.
Shouldn't this be called "Immutable Resources" rather than immutable web apps? Sure with JS the resources make up the app, but that index.html is still mutable, so no much different from an "index.php?section=whatever". Setting such long expiry times on the cache also sounds like a great way to pollute browser caches with obsolete resources.
I agree with your first complaint however. This seems like an over-complicated way of assuring that browser caches don't bite you.
Earlier quoted context omitted.
Here's an example where it can be done in Angular: https://www.jvandemo.com/how-to-use-environment-variables-to... . Not exactly the same as shell environment variables, of course. And you may disagree about exposing the `enableDebug` flag as a runtime config there. Still it is doable, in a sort of roundabout way, using the browser as the environment.
Ah, indeed. If you count "open dev shell, manually edit globally exposed variables so that it will affect only my browser" then yes, you can have that as runtime configuration.
In a world of continuous deployment, one persons configuration is another persons code.
Back in University, in the beginning of the 90’s, a teacher explained us that separating configuration from code was a good practice because you don’t have to recompile your code to make several tests.
I guess it still is the case !
Also: other than index.html, it's worth putting hashes in every filename. Though you will surely run into problems when the app is updated but users are running old versions so make sure you build with that in mind. I.E. you want to be able to reload at any time without consequence, and you probably want to do it automatically when you can't find a chunk. That last part is tricky if you map all 404s to index.html :)
> All of the leading application frameworks (Angular CLI, Create React App, Ember CLI, Vue CLI 3) recommend defining environment values at compile time. This practice requires that the static assets are generated for each environment and regenerated for any change to an environment. As a backend developer that relies heavily on environment variables for configuration, I was surprised that runtime configuration is not…
The application I'm currently working on has a separate configuration project, more for application options for one client deployment vs. another at a feature level, as well as any customized localization/strings. Beyond this, there is are release variables generated that are also injected. Namely the endpoints for login/logout/user-management/api. The application itself doesn't handle authentication, it validates a token/key with the api endpoint. Other configuration options are loaded from the api endpoint on application startup.
The application itself will be loaded with the strings for the application and a small spinner and load-check. If the browser doesn't have JS or meet minimum requirements (ES2017 async function support), it will load another screen acknowledging as much. It will then verify the authentication token, load other parameters from the API/Database and proceed to client-side application routing/runtime.
It isn't particularly difficult to setup. Initially I had a complimentary server-side that would deliver the environment options at runtime. That was changed in order to facilitate static deployments of the application.
Shouldn't this be called "Immutable Resources" rather than immutable web apps? Sure with JS the resources make up the app, but that index.html is still mutable, so no much different from an "index.php?section=whatever". Setting such long expiry times on the cache also sounds like a great way to pollute browser caches with obsolete resources.
Browsers have to worry about cache pollution already, I'm sure existing heuristics are more than capable of handling this use case. I agree with your first complaint however. This seems like an over-complicated way of assuring that browser caches don't bite you.
Shouldn't this be called "Immutable Resources" rather than immutable web apps? Sure with JS the resources make up the app, but that index.html is still mutable, so no much different from an "index.php?section=whatever". Setting such long expiry times on the cache also sounds like a great way to pollute browser caches with obsolete resources.
Setting "forever" caching is standard practice for web development for many years. The browser doesn't really cache these forever - it is merely a hint to the browser that the resource won't change and you don't have to check it again.
In fact, the more resources you can put with such caching the better both for you and the browser's speed.