[deleted]
Immutable Web Apps
41–50 of 66 posts
Re: Immutable Web Apps
#42That was an educational read, and gave me a good idea of an efficient strategy for deploying static web sites/apps.
I wonder how this could work with server-side rendered apps or pages?
EDIT: Aha, since index.html (only) is dynamically generated and can be populated with pre-rendered state and content.
Re: Immutable Web Apps
#43I wish there was some "why" > Static assets must be hosted at locations that are unique and independent of the web application environment(s) Why? Meaning a different domain or is path enough? What are "static assets" compared to every other file served by a web server? I assume meaning will never ever change, so images are not "static assets"? What if I name them by what they are and commit to changing the name when…
> Static assets must be hosted at locations that are unique and independent of the web application environment(s) > Why? Broadly, for the same reason that separating content, structure, and style is considered a good idea. (We can debate separately about whether HTML/CSS/JS applied this principle appropriately.) From another angle, this is just another way of saying that static assets should not depend directly on th…
Can you clarify, if I add a JS line to my file, I should version that JS file as a never-ever-changing static asset to be cached? It is a build artifact. And if I make a change daily (or more frequently w/ CD), have 365 of those versions (i.e. maybe versioned as date or hash)? Or should I start embedding that frequently changing JS in the pages that need it, thereby duplicating content, just to avoid breaking the rule that all build artifacts are static assets and all static assets are immutable?
Re: Immutable Web Apps
#44I wish there was some "why" > Static assets must be hosted at locations that are unique and independent of the web application environment(s) Why? Meaning a different domain or is path enough? What are "static assets" compared to every other file served by a web server? I assume meaning will never ever change, so images are not "static assets"? What if I name them by what they are and commit to changing the name when…
> So, static assets are only immutable when they don't have anything environment specific. Oh, and static assets always don't have anything environment specific. If I understand correctly, the immutability of a particular asset is what makes it a "static" asset.
Ah, that would make more sense. So not generated mutable files aren't necessarily static assets? The wording is a bit confusing, because when one reads "Static assets are the files [...] that are generated from a build of a web application codebase" they rightfully assume "the files that are generated" means "all generated files".
Re: Immutable Web Apps
#45A couple of weeks ago, I demonstrated a blog configuration for a client that was both immutable and serverless -- but you could change the design and add/modify/delete blog entries, of course. I did a video showing off the web-app side. I'm probably going to do another one showing off the server-side stuff. It was fun to do. The various pieces of tech are all now coming together nicely.
I'd watch those videos if you care to share them
Re: Immutable Web Apps
#46A couple of weeks ago, I demonstrated a blog configuration for a client that was both immutable and serverless -- but you could change the design and add/modify/delete blog entries, of course. I did a video showing off the web-app side. I'm probably going to do another one showing off the server-side stuff. It was fun to do. The various pieces of tech are all now coming together nicely.
I'd watch those videos if you care to share them
Here you go. https://www.youtube.com/watch?v=XUjfD55SMxc
There's an AWS piece not mentioned here. Basically there's a way to hook GitHub and AWS together such that when you check items in, your website auto-updates using Amazon's SW and CDN tech. (I didn't cover that because it was outside the scope the question I was answering.)
Re: Immutable Web Apps
#47I think it comes down to:
Make index.html the starting point, that pulls in the immutable web app, and configures it, (usually with a single endpoint URL that it would typically need).
Seams reasonable to me. I'm normally pessimistic about things like this (specifically the 12 factor app which is hopelessly one-sided to specific environments IMHO). But this is actually a useful and captured quite gracefully.
It would be nice to see some examples in each of the mentioned frameworks, and hopefully example webpack configuration specifically (since it is often used across all of them).
Re: Immutable Web Apps
#48yep, more or less how approach it.
1. build js,css,img assets
2. upload assets to CDN under unique urls (at build time, for any build that may or may not produce a deployable container)
3. build docker container with server that serves dynamic html referencing those assets
4. deploy said container
Main advantages for me:
1. easy to rollback
2. graceful rollover, all assets any deployed container can reference will always exist, even if multiple versions are deployed at the same time during deployment
3. immutable === cacheable forever
4. CDN always "warm"
Re: Immutable Web Apps
#49Earlier quoted context omitted.
> Static assets must be hosted at locations that are unique and independent of the web application environment(s) > Why? Broadly, for the same reason that separating content, structure, and style is considered a good idea. (We can debate separately about whether HTML/CSS/JS applied this principle appropriately.) From another angle, this is just another way of saying that static assets should not depend directly on th…
Can you clarify, if I add a JS line to my file, I should version that JS file as a never-ever-changing static asset to be cached? It is a build artifact. And if I make a change daily (or more frequently w/ CD), have 365 of those versions (i.e. maybe versioned as date or hash)? Or should I start embedding that frequently changing JS in the pages that need it, thereby duplicating content, just to avoid breaking the rul…
> Can you clarify, if I add a JS line to my file, I should version that JS file as a never-ever-changing static asset to be cached?
It only has to be cached as long as there exist deployments that need to reference it. But as long as there exist references to it, the content at the referenced address should not change. So yes, you should version that file -- or that deployment as a whole, if you'd rather not get that fine-grained -- but it only has to be "never-ever-changing" up to the point that nobody's observing it anymore.
If you only officially maintain one version, you'd want to keep the one prior for the sake of smooth deployment. Just document your support policy so downstream consumers aren't surprised (and they should be able to pin to an `index.html` address, generally, whose contents _are_ allowed to change over time.)
> Or should I start embedding that frequently changing JS in the pages that need it, thereby duplicating content, just to avoid breaking the rule that all build artifacts are static assets and all static assets are immutable?
Well, the article is about SPAs, so there's only one page by fiat. But in the general case (MPAs?), there would be a question about why that specific piece of JS must change so frequently, and whether that constitutes a dependency on the environment that can therefore be factored into the top-level.
Re: Immutable Web Apps
#50I wish there was some "why" > Static assets must be hosted at locations that are unique and independent of the web application environment(s) Why? Meaning a different domain or is path enough? What are "static assets" compared to every other file served by a web server? I assume meaning will never ever change, so images are not "static assets"? What if I name them by what they are and commit to changing the name when…
well actually when you host an SPA and you DO use lazy loading (which you probably need to do on angular, because of sizing, etc...)
than you will run into problem if you don't put all assets into a second webserver that will hold all assets (i.e. all versions).
if you try to deploy these assets directly with your normal application than you will probably run into serious trouble when users that do not have the newest version will try to download these lazy loaded stuff.