AtFINN.no we run adiverse and distributed infra, with a constant stream of deployments that's only been interrupted when we moved data centersin the middle of the night.

To make it possible for each team to own their part of the page (for example the Recommendations team owns the feed of "Anbefalinger" on the front page) and deploy updates and changes anytime they want we developedPodium. Podium answers the question "how can we update a snippet of shared html everywhere at once without restricting the server stack" by composing pages over HTTP. The benefits of a distributed frontend system are many, but it came with a challenging cost: if two page fragments use the same dependency, how do we ensure it's only ever downloaded once?

We builtAsset Pipe to solve bundling for distributed systems. When a layout is starting up it figures out what assets each fragment needs, concatinates them, and sends them to our asset pipe server. When it's done bundling it'll create an optimized file for the js and another for the css, serving them on hashed URLs that are guaranteed to be unique:

<linkhref="https://static.finncdn.no/_podium-assets/caeb0dc97f9e53242615f218cdb35b6ddb426e69b2803bc2e91e22e8a84a29d5.css"media="all"type="text/css"rel="stylesheet"><scriptsrc="https://static.finncdn.no/_podium-assets/2a920eeee4c178549a1e1ca23869c55571750ddce280a16e4f8f07e0629539db.js"crossorigindefer></script>

The downside to this approach by "bundling as a service" is that bundling is a slow process and it's become a huge bottleneck. If a page fragment is deploying a new update it triggers bundling on each layout using it, causing a cascade of bundling processes starting up. We were also unhappy with the performance tradeoff by creating one hashed asset per layout that bundles everything. When a user moves from layout A to B ideally react shouldn't be redownloaded on layout B for example.

We decided to set out to replace Asset Pipe and explored different concepts to find the optimal trade-offs. It turns out that building a CDN asset service that is designed for ESM cache heuristics, HTTP2 and ESM Import Maps is a really good idea. We call this solutionEik.
It lets us publish assets to the CDN in a similar way as you would to npm, allowing assets to always be ready ahead-of-time for the page fragments that'll use them, with stable and immutable URLs. Making deployments as well as rollbacks fast as no bundling/rebundling is necessary.
The server part wasn't all we needed, we also had to create plugins for the bundlers people are using (rollup, esbuild, we're still waiting for webpack to supportlibraryTarget: "module" before we can add support there).

Many of our teams are used to the "bundling as a service" flow and don't have any bundler setup locally for their JSX or babel syntax. That's why we started looking at microbundle and saw it fit most of our needs, except that it didn't let us add custom rollup plugins andwe needed to make a fork.