angular-microfrontend VS nx

You can find the source code that we are going to use in this repo

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:

Nx Documentation Vite Documentation Webpack Module Federation Micro-Frontend Architecture

Just use react.... That's what I do - it is so much easier than trying to fight with Next.js.

I have a large application and I use next.js for the landing pages (landing, tos, privacy, blog, login, etc..) - but for the core application after login, I just use vanilla react with react router. For me I keep these as separate applications as I don't want to load the entire app just for the landing page or login box.

Every time I need to work in the nextjs part of the app I always run into problems and have to read the docs and troubleshoot, sift through which part of the docs apply to my setup versus the app router.

If your entire application needs to be indexed as a static site (e.g. content based versus a web application), then vanilla react isn't a good fit - so it depends on your needs.

Unrelated - but shout out to https://nx.dev. I always prefer using this for all of my projects - made it super easy to have my node backend, react frontend, nextjs landing page, chrome extension, cron jobs, etc.. all in the same codebase where I can share code between all of them via non-publishable libraries.

Nx Documentation

However, the potential for future improvements make it a promising approach for large-scale monorepos. As the Nx team works on supporting TypeScript better (see Nx 2025 roadmap), we can expect progress in this area.