The curious case of Module Federation and how do we write tests for federated applications.
If you haven't heard by now — Module Federation is a way to simply
import() other modules/files between independently compiled and deployed bundles at runtime.
Possibilities are endless, especially after working with it for over a year. Before there was even an npm release, it was in production, installing directly from a branch on GitHub. It’s immensely more powerful then most think
With this new at-runtime orchestration and code sharing, a big question loomed.
How on earth will I test this?
Over a year later…
It’s the tag manager and third party code in general.
I can get an app to load and finish in 2 seconds. But with all the vendor code, the reality is usually a 2–3 additional seconds. There’s not much room for improvement left within the JS app itself.
There’s two Passions I have. Architecture and performance
I refused to accept that It could not be improved by engineering, without getting…
There’s lots of advice, but it seems to taper off when it comes to advanced performance tactics. I’ve read the articles, but it’s either too vague, too broad, or just basic stuff I have already done. Where are the more advanced articles on performance, most importantly — why are we not combining tech and talking about a stacked implementation?
This has been my real-world experience, tools, or tactics I've used. I like web performance and am a little obsessed. These ideas can be a little quirky or abstract, there are probably better ways to handle perf.
With that said…
Advanced implementation tactics to attach a startup sequence to micro-frontend applications designed using Module Federation.
I’ll get this out the way right from the start, something that’s been requested hundreds of times now. You can set
webpack_public_path dynamically (not hardcoded in the webpack config) with startup code, but there are easier solutions now built into webpack 💯 for dynamic public paths. Startup code has more advanced possibilities, but for the sake of introduction- I’m demonstrating a manual method that uses the startup code pattern. I’ll develop some better examples soon which demonstrate complex integrations.
In the context of…
Beta 17 has been out for a week or so. It packs a powerful punch. Despite the power that’s been introduced in the latest release. We are far from completion.
Module Federation is just getting started.
Some Major work went into this release. Rewritten Externals Plugin, Changes to how webpack runtime works, Changes to the webpack graph, changes to chunking systems, and the startup sequence of webpack. …
Stitching two independent bundles into one single page application, at runtime
A short and sweet guide to using Module Federation on two independently deployed web apps, so that they can work like a monolith. Sharing code between themselves at runtime.
We’re going to federate two independent, very basic little react apps.
What we have started out is a bare-bones React app, hosted on port
// app1 - running on localhost:3001
import React from "react";
const App = () => (
export default App;
3002 we have another single page application…
A scalable solution to sharing code between independent applications has never been convenient, and near impossible at scale. The closest we had was externals or DLLPlugin, forcing centralized dependency on a external file. It was a hassle to share code, the separate applications were not truly standalone and usually, a limited number of dependencies are shared. Moreover, sharing actual feature code or components between separately bundled applications is unfeasible, unproductive, and unprofitable.
Update: This project is being rewritten and will be incorporated into Webpack 5!
This article describes how I wrote a Webpack plugin that imports chunks from other Webpack bundles at runtime. It is part of a larger series on micro-frontend applications and techniques for managing them.
The article is low level in some places, and it’s intended to document the journey of developing tools for interleaving. I will write higher level articles focused around using the tool, providing code samples and use cases.
High Performance Configuration for JetBrains IDEs [IntelliJ, WebStorm, etc..]
Once you step into the realm of multi-project development, large scale dev, or just have to have like 6 IDE’s open. You really start to feel a performance hit on JetBrains IDEs.
This configuration aims to give at least 10x performance increases across the board.
The recommended way of changing the JVM options in the recent product versions is from the Help | Edit Custom VM Options menu. …
This article is part of a series on micro-frontend applications and techniques for managing them.
Read the next one here
We are making some big changes to frontend architecture. Check out our progress on Webpack Module Federation:
This tutorial will discuss how to decouple your frontend from a monolith and begin migrating to micro frontend architecture immediately. This was one of my past projects
Let us assume there’s a Monolithic codebase. This monolith uses one of the backend templating engines or systems (ex. EJS or ERB), jQuery, and it has no real considerations for frontend — or worse, it comes…