Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Immutable Web Apps

immutablewebapps.org

Post reply on HN
Print view View original

51–60 of 66 posts

Re: Immutable Web Apps

#51

Post by pscanf »

> The methodology is based on the principles of strictly separating:

> - Configuration from code.

> - Release tasks from build tasks.

I've built an open source product[1] that tries to address these same issues (and others). Configuration-at-build-time has especially been a pain point for my company, leading to Jenkinfile-s full of environment variables. I've also solved it by injecting a global (window.APP_CONFIG in my case) into the served index.html. It would be nice if a standard could emerge for this (I could definitely see adding support for window.env to my product).

I really like the idea of using absolute URIs for assets. Having relative URIs does indeed complicate routing quite a bit, and in fact to avoid having to specify the main URL of the application at build-time I had to implement some redirect magic, which you wouldn't have when porting the app to a "normal" static server like nginx or S3. I didn't find in the docs though, how would it work for resources linking other resources? For example, a css file loading an image via @url(...), or a js dynamically constructing the src of an img element. In the css case I guess you could hardwire the static assets URL at build time. The js case would be more tricky, but maybe it's just a practice to avoid.

[1] https://staticdeploy.io

Re: Immutable Web Apps

#52

Post by migueloller »

We do something similar to this but with server-side rendering. We build our apps with React, then we use React Router to match routes on the server and send down CSS and HTML as needed by the current route. Client-side environment variables are put on the window object by the rendered HTML, just like in this article. Then, once JavaScript kicks in, there’s no configuration “bundled” into it. The configuration is just parsed from the server’s HTML. The JavaScript bundle lives in a CDN and follows their definition of “static”.

This is basically 12-factor [1] though. For us, this was imperative to be able to do review apps on every merge request and promote those to production without having to re-run the build. We run the exact same Docker image that ran in CI, the environment is the only thing that changes.

[1] https://12factor.net

Re: Immutable Web Apps

#53

Post by Illniyar »

ams6110 wrote: post #36
Illniyar wrote: post #20

Earlier quoted context omitted.

"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…

You really can't control how long something stays in a browser cache. The user can clear it at any time. Mine are cleared every time I close the browser.

Like I said the header isn't to control how long something stays in the cache. It's to control how often the browser needs to check if the content changed.

Re: Immutable Web Apps

#54

Post by kodablah »

Twisol wrote: post #49
kodablah wrote: post #43

Earlier quoted context omitted.

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…

I understand the general note about caches not lasting forever, no longer referenced files, etc.

This response skipped over the most important question "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)?". Simply asked, is every generated JS file a static asset? Must the (indefinite) cache headers be present for every static asset be returned? So if I deploy a new static asset every hour via continuous deployment let's say, I must give it a new unique path? These questions apply to SPAs.

Re: Immutable Web Apps

#55

Post by kodablah »

merb wrote: post #50
kodablah wrote: post #30

I 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 newes…

> well actually when you host an SPA and you DO use lazy loading

This is not always true. Many times frameworks are so heavily leveraged and the site-specific code so minimal on small SPAs that it is reasonable to have a single packed-and-minimized JS file. And it still may change frequently.

Re: Immutable Web Apps

#56

Post by Twisol »

kodablah wrote: post #54
Twisol wrote: post #49

Earlier quoted context omitted.

> 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…

I understand the general note about caches not lasting forever, no longer referenced files, etc. This response skipped over the most important question "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)?". Simply asked, is every generated JS file a static asset? Must the (indefinite) cache headers be present for every static asset be returned? S…

If I were to build an application 100% in the style of the article, my answer to all three questions would be "yes". But I'd probably opt to version at the level of a whole deployment, rather than at the level of each file. There's a case for versioning non-build static assets separately, but I'd rather version all of the output of a build process together.

Re: Immutable Web Apps

#58

Post by 21 »

apexalpha wrote: post #26

This has been a very interesting read. I've been wanting to build a single page personal website as a means of learning. I'm not a star in webdev so I have a lot of hours ahead of me. I might actually deploy it like this, why not? If anyone has any good book or other resources to get started in building a website like this for people who already have back-end and programming experience but lack html, css, js etc.. pl…

This article is great in explaining why modern javascript development is so complicated, with so many tools (webpack, babel, ...), and why it all makes sense:

https://medium.com/the-node-js-collection/modern-javascript-...

Re: Immutable Web Apps

#59

Post by pixl97 »

kodablah wrote: post #54
Twisol wrote: post #49

Earlier quoted context omitted.

> 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…

I understand the general note about caches not lasting forever, no longer referenced files, etc. This response skipped over the most important question "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)?". Simply asked, is every generated JS file a static asset? Must the (indefinite) cache headers be present for every static asset be returned? S…

>So if I deploy a new static asset every hour via continuous deployment let's say, I must give it a new unique path?

I would answer yes to that. More specifically, if an old cached component could reference the new file and break, then the old component should never know about the new content.

Re: Immutable Web Apps

#60

Post by merb »

kodablah wrote: post #55
merb wrote: post #50

Earlier quoted context omitted.

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 newes…

> well actually when you host an SPA and you DO use lazy loading This is not always true. Many times frameworks are so heavily leveraged and the site-specific code so minimal on small SPAs that it is reasonable to have a single packed-and-minimized JS file. And it still may change frequently.

yeah as said, only when you do, but on angular you probably need to do. however I had good luck with vuejs which basically was relativly small. I also tend to do lazy loading pdfjs or something really big.
Post reply on HN