Immutable Web Apps

Rate this content
Bookmark

Resolving dependencies when they are all bundled together is easy. Resolving dependencies when they are in being loaded via script tags is much more challenging. The goal of this talk is to explain how Meltwater handles dependency resolution when building native Web Component based applications that rely on packages published by many different teams.

Andy Desmarais
Andy Desmarais
20 min
20 Jun, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Today's Talk discusses immutable web apps and their benefits, such as faster loading times and easy version tracking. The use of Universal Module Definition (UMD) style bundling allows for flexible dependency management and gradual upgrades. Tools like Webpack and Rollup provide ways to reference UMDs in bundles and automate dependency configuration. Arborist and YAML files help resolve dependency trees and handle conflicts, while the Orchard CLI tool automates dependency ordering. Internal and external dependencies can be initialized and managed effectively for optimal performance.

Available in Español: Aplicaciones Web Inmutables

1. Introduction to Immutable Web Apps

Short description:

Today we're going to talk about immutable web apps and dependencies. We had a problem with dependencies at Meltwater, so we needed to find a way to unbundle them and share them effectively. Immutable web apps allow us to build once and deploy many times, with environment variables outside the bundle. This ensures that the assets can be maximally cached, resulting in faster loading times. It also provides easy version tracking and rollbacks.

How's it going JS Nation? Today we're going to talk about immutable web apps and dependencies. First, I'm Andy Damaris, you can find me on pretty much all the social medias at Teradox and my website is teradox.tech.

What we're going to cover today is, we're going to start with the problem. There was a problem that we were having at Meltwater and then we'll move on to immutable web apps, what they are and why we're using them, dependencies without bundling them, referencing those dependencies and then last we're going to talk about how we or those dependencies successfully.

So, what's the problem? Well, the problem was dependencies. We had a lot of them and they were being created by internal teams for libraries that we could use on a regular basis for things like authentication or companies lookups or users lookups and each of these things was beginning to compound the amount of duplicated JavaScript that was being bundled together with all of the different applications we were shipping. So, we needed to figure out a way to unbundle these dependencies and allow them to be shared more effectively between the many applications that were using them.

So, immutable web apps were an important part of that journey, so we're going to cover those first. The basic philosophy of immutable web apps is that you want to build them once and deploy them many times. There are some really specific fundamentals that we need to accomplish in order to be an immutable web application. The first one is all of our environment variables need to be outside of the bundle. This allows our bundles to be built one time per version and be immutable for that specific version. They'll never change after the first time they're built. It also means that we need to deploy them to a URL where the version that we just built is included as a part of that URL. So we want that fully qualified URL to have our version number in it somewhere.

Now, what benefits does this really buy us? There's a bunch. The first is that when we're testing in staging and we're testing in production, they're using the exact same assets. The only difference will be the configuration that's changed between the two. This means that all of our assets can also be maximally cached. They can be cached for a full year in fact, which is the current browser maximum. There's a huge benefit to our customers for that. They only ever need to round-trip for that specific version of that specific asset once. And after that, it's on their local disk cache, saving huge amounts of time for secondary and tertiary loads of the site. We never have to worry about them having to go back to origin constantly for these large assets at times. The other things that get included with this are you always know which versions are deployed because your index.html page makes it very plain. Look at your script tag. What version's in the URL? That's the version you're dealing with. It also means that rollbacks are now really trivial. We're just flipping back from one specific version of a set of assets to another script tag. Another specific version of a set of assets.

2. Immutable Web Apps and Dependencies

Short description:

If you're a consumer, chances are good you already have the previous version of assets in your disk cache. The index page is the focal point for immediate changes. We break things down into three thought processes: static web hosting, delivering static assets using script tags, and APIs. To hit the API, we use a configuration block in the script tag. We have a lot of dependencies, so we need tooling to fix the problem. The first tool is UMDs, the Universal Module Definition style of bundling.

And if you're a consumer already, chances are good you already have that previous version of assets in your disk cache ready to go. So you won't even have to pay download costs again for it.

So we've talked about all of our assets but what about the index page? Well, the index page is the one part of an immutable web app that you don't cache. It's our focal point for where all of our changes are allowed to show up immediately.

So we like to break things down into three different thought processes. You don't have to break it down this way. It's just an exercise in a way to think of things. So the first piece is just our static web hosting. It hosts our index HTML page. That index HTML page is pretty static. There's not a whole lot of dynamic nature to it. And it dictates the versions of all of the static assets that we're going to deliver. Those static assets are then delivered using script tags. And those script tags use the fully versioned URL that we were talking about. In this case, version 1.2.3 to be able to deliver those assets.

Then we also have our APIs, and our APIs could be on a different server, could be on the same server. But we dictate which API we're going to hit by that configuration block you're seeing in the script tag. That configuration block tells our application where we should go to hit that API and what the route should be, removing that environment variable from our JavaScript code.

So I've lost over immutable web apps pretty quickly here. There's some more nuance, a lot more detail that you could dig into. And if that's something that's interesting to you, please check out immutablewebapps.org.

So now let's dig back into the main crux of what we're talking about, which is dependencies. We have a lot of them. They're being used by a lot of different applications. So how do we fix that problem? Well, we're going to need some tooling to do this successfully. The first little bit of tooling we're going to use is UMDs. They're a specific type of bundle that we'll dig into. And then we're going to talk about HiMyNameIs, a tool for helping us discover dependency names. And then we'll talk about Orchard, which is really our tool for ordering those dependencies. So the first tool I want to discuss is UMDs, the Universal Module Definition style of bundling.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

pnpm – a Fast, Disk Space Efficient Package Manager for JavaScript
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
pnpm – a Fast, Disk Space Efficient Package Manager for JavaScript
You will learn about one of the most popular package managers for JavaScript and its advantages over npm and Yarn.A brief history of JavaScript package managersThe isolated node_modules structure created pnpmWhat makes pnpm so fastWhat makes pnpm disk space efficientMonorepo supportManaging Node.js versions with pnpm
Yarn 4 - Modern Package Management
JSNation 2022JSNation 2022
28 min
Yarn 4 - Modern Package Management
Top Content
Yarn 4 is the next major release of your favourite JavaScript package manager, with a focus on performance, security, and developer experience. All through this talk we'll go over its new features, major changes, and share our long-term plans for the project.If you only heard about Yarn without trying it yet, if you're not sure why people make such a fuss over package managers, if you wonder how your package manager can make your work simpler and safer, this is the perfect talk for you!
The Good, The Bad, and The Web Components
JSNation 2023JSNation 2023
29 min
The Good, The Bad, and The Web Components
Top Content
There has been no shortage of both fair and unfair criticism toward Web Components from a wide range of folks that build for the web, including but not limited to JavaScript Framework authors in supposed competition with the platform. In this talk I'll show you how to navigate and simplify the multifaceted landscape of web components, satisfying common criticisms and showing how you can Use the Platform most effectively today.
It's Time to De-Fragment the Web
React Day Berlin 2022React Day Berlin 2022
34 min
It's Time to De-Fragment the Web
Top Content
Over the past few years, the number of web frameworks available to us has exploded. In some ways, the breadth of choice is a clear win for our ecosystem. However, for many of us, it also comes with harsh drawbacks: - Have you ever used a popular open-sourced component built for framework A, and wished it existed in framework B? What about a design system library? - Does your company have frontends built in different frameworks, and your web teams are frustrated about the wasted hours needed to achieve a consistent design system? - Does your team build SDKs for web frameworks, and must manually re-write them for each framework? The solution to all 3 of these problems exists today. To fully understand it, we must first examine today’s web frameworks, re-think what a component should look like, and introduce a new Intermediate Representation of our components. This is what we have done at Builder.io when we created Mitosis, and we’re excited to share it with everyone.
Web Components, Lit and Santa 🎅
JSNation Live 2021JSNation Live 2021
28 min
Web Components, Lit and Santa 🎅
Get started with Web Components – enabling you to define new HTML elements that work everywhere regular HTML does. This talk will focus on Lit, a suite from Google that helps you create WCs with features you'd expect like data-binding and declarative definitions. It'll also cover how we've used them to build one of the web's jolliest sites, Google's Santa Tracker 🎅
Authoring HTML in a JavaScript World
React Summit US 2023React Summit US 2023
21 min
Authoring HTML in a JavaScript World
 In this talk, Tony shows how an authoring and semantic HTML-first approach to JSX template work leads to more readable, maintainable, and accessible UI components. He demonstrates how to think through implementing a UI prototype in a semantic way, authoring HTML before visuals. He shows how accessible markup improves performance, reduces DOM size, minimizes time spent on CSS, and reduces cognitive load not only for developers, but also for all our users, no matter how they consume our sites and applications.

Workshops on related topic

Web Components in Action
JSNation Live 2021JSNation Live 2021
184 min
Web Components in Action
Workshop
Joren Broekema
Alex Korzhikov
2 authors
The workshop extends JavaScript programming language knowledge, overviews general software design patterns. It is focused on Web Components standards and technologies built on top of them, like Lit-HTML and Lit-Element. We also practice writing Web Components both with native JavaScript and using Lit-Element. In the end we overview key tooling to develop an application - open-wc.