single-spa VS nx

Micro-frontend has always aroused my curiosity: I wanted to understand how they work, how to build them, what their pros and cons are. In 2018, inspired by this topic, I tried to build something similar to single-spa in one of the pet projects. At that time, there was no Webpack Module Federation (WMF), and Webpack itself seemed inconvenient. The choice fell on ESBuild and importmap. Browser support for importmap at the time was mostly on paper or with special flags in browsers. For this reason, I used a polyfill. But, surprisingly, everything worked and even in several projects.

We will cover some of the popular frameworks and libraries available, and guide you through setting up a microfrontend architecture using Single-Spa.

In the next article, we will explore the tools and technologies for building microfrontends, including a step-by-step guide to setting up a microfrontend architecture using Single-Spa.

Official Website

At JupiterOne, we've made a significant transition from a monolithic frontend to a distributed frontend architecture using microfrontends, powered by (single-spa-react)[https://single-spa.js.org/]. This architectural shift has brought many benefits, such as lazy loading sections of the app and accelerating our development cycle. However, like any significant change, it has also come with its set of challenges.

Single-SPA Framework - One of the most popular choices. It has a large community behind it and offers robust routing and lifecycle management for microapps. Ref - https://single-spa.js.org/

Joel Denning is the visionary behind single-spa, boasting profound insights into the true mechanics of the web and is, in my view, a pioneer in micro frontend architecture. I highly recommend checking the single-spa website and his YouTube channel. While the videos might appear dated at first glance, rest assured, Joel is ahead of his time, and the content remains incredibly relevant today.

You got me curious and I found that single spa is something new to me - if I read https://github.com/single-spa/single-spa then I reckon you can use Svelte(Kit) in such framework - like you can use angular etc

I’ve actually done that “web components as the interoperability layer”!

It was this old angular 1.8 app with new features being written in angular-hybrid-ized angular 8. Ripping out angular-hybrid and separating the angular 1.8 routes from the modern angular routes was difficult, but now they were totally separate.

The only thing linking them together was an object with some RXJS streams in it for state, and a little in-house wrapper “app” who just loaded one component or another depending on the URL and a hash of routes for config. (I’d probably use SingleSPA [1] now. Same thing really.)

We could deploy them separately since the build just ends up being another JS file somewhere that just gets included with a script tag at runtime. No version bumping! No big mega build!

We started replacing the remaining “old” routes 1 by 1 with a “new” counter part. That was the easiest part, and went at a pace devs were comfortable with (fast enough) and business folk could tolerate. (modular enough to not HAVE to be done all at once)

Last I checked, the angular 1.8 stuff is gone years ago. :)

[1] https://single-spa.js.org/

Nx Documentation: https://nx.dev/ - Official documentation for the Nx build system.

🏗️ The Umi's plugin system and API is quite interesting. You can do a lot with that. The approach is quite common for dev tools and in this case resembles both Vite and Nx with their extensibility and community orientation. There's a huge ecosystem of plugins of all sorts, and you can always complement them with your own (which is quite important for sophisticated enterprise development). I'd assume you could build pretty decent metaframework mechanisms with this flexible approach. At least, as I mentioned already, you have a bunch of thoughtful building blocks for that.

Nx is our choice for managing the project's monorepo structure. It provides powerful tools for scaling our development process, ensuring code reusability, and maintaining consistency across different parts of the application. With Nx, we can efficiently manage multiple projects within the EczEase ecosystem, from the main web application to potential mobile apps and backend services.

Hello! I used to like NX a lot. It was a monorepo for all my projects—different brands and clients in one place. It worked well, but it didn’t suit me. Most of my projects are single Angular apps. So, I stopped using one big NX repo and made separate projects instead. Here’s why I prefer it.

The project is using Nx workspace + PNPM for package management

Then there’s the tooling. Micro-frontends aren’t as plug-and-play as a monolith yet. You’ll likely need custom build pipelines, deployment scripts, and a solid CI/CD setup. Tools like Nx can help here—its monorepo approach is a lifesaver for managing multiple micro-frontends in one cohesive workspace. Their micro-frontend guide is worth a peek if you’re curious.

Nx (sponsored the Lightning Talks)

Caching and sharing artifacts is usually the main culprit. My company has been using https://nx.dev/ for that. It works locally as well and CI and it just works.

Our NX is pointed to store artifacts in GHA, but our GHA scripts don't do any caching directly, it is all handled by NX. It works so well I would even consider pulling a nodejs environment to run it in non-nodejs projects (although I haven't tried, probably would run into some problems).

It is somewhat heavy on configuration, but it just moves the complexity from CI configuration to NX configuration (which is nicer IMO). Our CI pipelines are super fast if you don't hit one of one of our slow compilling parts of the codebase.

It is quite interesting is that your local dev environment can pull the cached items there were build from previous CI ran-jobs or other devs. We have some native C++ dependencies that are kind of a pain to build locally, our dev machines can pull the built binaries built by other devs (since all devs and CI also share the same cache-artifacts storage). So it makes developing locally a lot easier as well, I don't even remember last time I had to build the native C++ stuff myself since I don't work on it.

An efficient work environment is the key to rapid development and testing. Many of us have heard stories about how it takes days or even weeks to set up a work environment at a new job or project. I am not exception! To avoid such situations, I decided to think through the structure and configuration in advance. The main idea was to make everything reproducible and easy to use. Since the goal was to develop a plugin for nx.dev, I started by creating a new workspace via create-nx-workspace. I used the test application to experiment with SSR, and therefore created a plugin template using @nx/plugin:plugin. Additionally, I generated two applications and one library via NX generators. As a result, the project structure looked like this: