Decoupling Frontend Architectures: Nx + Private Registry Approach

Hadi Zare Irani — Thu, 30 Oct 2025 06:27:44 +0000

What do you know about Nx? Based on the introduction in the Nx documentation:

Nx is a powerful, open-source, technology-agnostic build platform designed to efficiently manage codebases of any scale.

Actually, you can implement a Monorepo platform, but that could be implemented as a micro-frontend platform based on the Module Federation feature. So, I don't want to teach Nx this here. I’d like to share a real problem I faced in one of my projects.

Imagine you have a project with a main dashboard and many small shared libraries and features. For example, you have a Layout with a Sidebar, a Navbar, a Settings page, and a Home page. These components are specific to this platform. Additionally, you have several shared features, including authentication, a Reports page, a User Settings page, and Design systems, among others.

At first, you think about Monorepo architecture, and it's a good solution, but it's not enough. We have to use those shared features in several projects. Actually, we're not an online platform; we're a B2B platform, and we try to implement a platform for each customer.

It was a technical challenge for me, and I had to solve this as a senior front-end developer. The core issue when mixing frameworks is Module Federation. While MF allows one framework (like Angular) to load a module built with another (like React), it still requires the module to be built in a way that the host can consume it, and often relies on sharing core dependencies. Let's check my approach.

My solution: Decoupled Build with a Private Registry

I used a private package registry and Polyrepo to publish/consume internally within my company's network. Actually, this uses Nx's ability to manage projects independently.
1- Separate Repositories for Frameworks

I created a dedicated Nx workspace/repo for my main applications as a host, and a smaller Nx workspace for each micro-frontend module or shared library.

2- Establish a Private Package Registry

I was working on a secure app so that I couldn't use public services. I should set up a self-hosted, private NPM registry within my secured network. I found these two options:

Verdaccio: Lightweight, easy to set up.
Nexus Repository OSS: Robust, enterprise-grade solution.

3- Publish from Remote Repositories

In each remote repository, I would configure the Nx build to not just create a Module Federation remote, but also bundle and publish the module as a deployable NPM package, because our host apps could be implemented with any frameworks and libraries.
The host apps (Angular or React) only need to interact with the private registry:

// angular-host-app/package.json
"dependencies": {
  // ... other dependencies
  "@my-org/dashboard-feature": "1.0.0"
}

Updating dependencies is so simple, I just need to publish a new version (e.g., 2.0.0) from the remote repo to the private NPM registry (e.g., Verdaccio), and update the version in the host app's package.json.

I used this solution 2 years ago; maybe we have many approaches to implement a platform like this now. I tried to explain my approach, and this article provides a comprehensive view. I didn't want to enter too technical explanations.

If you’re a front-end developer dealing with multiple client projects or multi-framework setups, this approach might help you.

Do We Still Need SCSS?

Hadi Zare Irani — Fri, 26 Sep 2025 09:47:05 +0000

The CSS has had a lot of changes in the last few years. We don't create it like we did in 2010 or earlier. Browsers, Hardware, and tools have undergone big changes. Modern Frameworks showed up, and the Internet has become a popular tool in human society. We implement our apps for a lot of devices with different screen sizes, and they must work (in fact, it's a delicious headache). So, CSS is a part of our life as a Frontend developer. We tried writing CSS with a preprocessor like SCSS and LESS, because they follow the goal:

Writing a clean CSS faster than before

But now I have a question:

Do We Still Need a Preprocessor like SCSS?

I have spent my time bringing an answer to this question, and I want to share it with you. Let’s break it down.

What Modern CSS Can Do

Nesting: Native CSS nesting is here. SCSS is no longer the only way to write nested selectors.

Variables (CSS Custom Properties): Unlike SCSS variables, CSS variables are dynamic at runtime.

Cascade Layers & @import Replacement: This solves the “CSS specificity war” and makes imports more powerful than in SCSS.

Container Queries & Subgrid: Imagine you have a card component with an image, title, and description. You want the text layout to adapt based on the card’s width, not the whole page width.

Color Functions in CSS:

color-mix(): mix two colors.

lab(), lch(), oklab(): define colors in perceptually uniform color spaces.

Why this matters:

Easier to create accessible, harmonious color palettes.
Colors look consistent across browsers and devices.
You can dynamically adjust colors in CSS without a preprocessor (no SCSS needed).

Where SCSS Still Wins

SCSS also has advantages, and they are so useful:

Mixin and Functions: You can write reusable logic with them, and they don't have in pure CSS
You can split CSS into small, maintainable chunks. It makes file management easy.
Loops, conditionals, and calculations are useful SCSS features.

My Take as a Frontend Dev

Modern CSS can replace most of SCSS features, but SCSS is becoming more niche. We have a big problem here:

Browsers support.

Browsers don't support some of the modern CSS features yet, and this creates a problem for large-scale, international, and enterprise projects. Because, all users don't update their Browsers, and we are facing different users and devices. We must anticipate and meet the needs of most users.

After that, in the large-scale projects, we need to use advanced logic like loops or complex mixins. Maybe we can handle it with CSS, but SCSS has good support for doing them, and it's a fact.

I don't say you must remove SCSS from your development life and implement your project with modern CSS, because:

SCSS isn't dead.

Just like jQuery, still useful, but not the default choice anymore.

What do you think? Are you still using SCSS, or have you moved fully to native CSS?