DEV Community: Pranav Kale

One Copy to Rule Them All: Sharing Third-Party Libraries in Nx Micro Frontends

Pranav Kale — Sun, 31 Aug 2025 14:09:37 +0000

When building Angular micro frontends (MFEs), one of the biggest challenges is managing third-party libraries.

Frameworks like @angular/core, UI kits like @angular/material, state management tools like @ngrx/store, and utility libraries like lodash often end up repeated across multiple MFEs. Without proper sharing, each app bundles its own copy, leading to heavier builds and more complex dependency management.

Nx with Webpack Module Federation gives us an elegant solution: shared singleton libraries.

The Problem

Imagine three MFEs: Dashboard, Reports, and Admin.
Each one depends on:

@angular/core
@ngrx/store
lodash

If every app bundles its own versions, you risk:

Duplicate dependencies inflating bundle size
Version conflicts if apps don’t align
Debugging headaches from mismatched library behavior

The Solution: Shared Singletons

Nx allows you to configure libraries as singletons in your webpack.config.js:

const { withModuleFederation } = require('@nrwl/angular/module-federation');

module.exports = withModuleFederation({
  name: 'dashboard',
  exposes: {
    './Module': './apps/dashboard/src/app/remote-entry/entry.module.ts',
  },
  shared: {
    '@angular/core': { singleton: true, strictVersion: true, requiredVersion: '17.0.0' },
    '@angular/common': { singleton: true, strictVersion: true, requiredVersion: '17.0.0' },
    '@angular/router': { singleton: true, strictVersion: true, requiredVersion: '17.0.0' },
    '@ngrx/store': { singleton: true, strictVersion: true },
    'lodash': { singleton: true },
  },
});

What these options mean

singleton: true → Ensures only one instance of the library exists across all MFEs.
strictVersion: true → Enforces the same version everywhere, avoiding subtle runtime bugs.
requiredVersion: 'x.y.z' → Pins the version you expect, giving better control over updates.

Advantages of Shared Libraries

Consistency Across MFEs Every micro frontend uses the same version of Angular, NgRx, or lodash. No more “works here but not there” surprises.
Simpler Maintenance Updates to third-party libraries happen in one place. Teams don’t need to manually align versions across MFEs.
Reduced Complexity Shared singletons eliminate issues like multiple Angular injectors or conflicting NgRx stores.
Smoother Developer Experience With Nx, libraries are defined once and reused everywhere, making project setup faster and less error-prone.

Conclusion

By configuring third-party libraries as shared singletons, Nx makes micro frontends more consistent, maintainable, and reliable. Instead of juggling multiple versions of Angular or duplicating libraries, your MFEs behave like parts of one cohesive system.

Mastering API Pagination: Methods, Scenarios, and Best Practices

Pranav Kale — Thu, 31 Jul 2025 17:22:35 +0000

APIs often return data in bulk—be it products, transactions, logs, or posts. However, returning all records in one go can be disastrous for performance and usability. That's where API Pagination comes in.

In this blog, we’ll explore what pagination is, why it matters, the common strategies (with pros, cons, and examples) and best practices for implementation.

🚨 The Problem: Large Data Sets

Imagine an e-commerce app retrieving 1 million products or a social platform loading 10 years of user activity at once. Returning such massive datasets:

Increases memory and CPU usage on the server
Slows down API response time
Causes timeouts or crashes on the client
Eats up network bandwidth unnecessarily

Pagination helps mitigate this by allowing the client to fetch data in manageable chunks.

📦 Common Use Cases

Infinite scrolling (e.g., Twitter feed)
Search results (e.g., e-commerce filters)
Log viewers (e.g., admin dashboards)
Reports and analytics over large time spans

🧭 How Clients Specify Data Chunks

Clients typically specify:

Page size: Number of items per page (e.g., 10, 50, 100)
Page or offset: Which chunk of data they want (e.g., page 3 or offset 100)
Cursor or key: A unique pointer to continue from where the last call ended

⚙️ Pagination Methods: Pros, Cons & Complexity

1. Offset & Limit Pagination

Description:

Client provides a numeric offset (start index) and limit (number of records).

Example:
GET /products?offset=100&limit=20

Pros:

Simple to implement
Easy for clients to understand

Cons:

Expensive for large offsets (e.g., offset=100000)
Data inconsistencies if new records are added or removed during paging

Complexity:

🔹 Low (but O(N) DB scan for large offsets)

2. Page-Based Pagination

Description:

Uses page and pageSize instead of numeric offsets.

Example:

GET /products?page=5&pageSize=50

Pros:

Human-readable page numbers
Works well for small, stable datasets

Cons:

Suffers from same issues as offset-based (performance & consistency)

Complexity:

🔹 Low

3. Cursor-Based Pagination (a.k.a. Seek Pagination)

Description:

Uses a unique, immutable field (e.g., id, createdAt) to fetch the next set.

Example:

GET /messages?cursor=8756&limit=20

Pros:

Efficient for large datasets
Consistent even with concurrent updates

Cons:

Harder to implement and debug
Requires indexed and sortable fields

Complexity:

🔸 Medium to High

4. Time-Based Pagination

Description:

Fetches records created before/after a certain timestamp.

Example:

GET /logs?start=2025-01-01T00:00:00Z&end=2025-01-02T00:00:00Z

Pros:

Great for time-series data (logs, events)
Easy to cache and archive

Cons:

Can miss or duplicate records with identical timestamps

Complexity:

🔸 Medium

5. Keyset Pagination

Description:

Uses sorted, indexed keys (e.g., id) to get the next page.

Example:

GET /orders?after_id=1050&limit=20

Pros:

High performance for deep pagination
Resilient to data changes

Cons:

Doesn’t allow jumping to arbitrary pages
Can’t handle unsorted or composite keys easily

Complexity:

🔸 Medium

6. Hybrid Pagination

Description:

Combines techniques like offset + cursor or cursor + timestamp.

Example:
GET /comments?after=1000&createdBefore=2025-01-01&limit=50

Pros:

Flexible and powerful
Can balance performance with UX needs

Cons:

Most complex to implement
Can confuse API consumers

Complexity:

🔶 High

🛠 Best Practices for Implementing Pagination

Use default limits: Always cap the number of records returned (limit=100 max).
Return metadata: Include fields like totalCount, nextPage, hasMore, or nextCursor in the response.
Document your API: Clearly explain supported pagination styles in your API docs.
Index your sort fields: Especially for cursor or keyset pagination.
Avoid offset for large data: Cursor/keyset is better for scale and consistency.
Consistent sorting: Always sort by a unique, stable column (e.g., id, createdAt) to prevent duplicates or missing data.
Make pagination optional: But enforce it with sane defaults if not specified.

🧠 Conclusion

Pagination isn’t just about breaking data into pages—it’s about balancing performance, usability, and consistency.

Method	Use When	Scale	Complexity
Offset & Limit	Small datasets, admin UI	❌ Poor	🔹 Low
Page-Based	User-friendly UX	❌ Poor	🔹 Low
Cursor-Based	Large lists, scrolling	✅ High	🔸 Med-High
Time-Based	Logs, metrics	✅ Medium	🔸 Medium
Keyset	Large ordered data	✅ High	🔸 Medium
Hybrid	Complex/UX + performance	✅ High	🔶 High

Choose wisely based on your use case, and always test performance at scale.

Understanding Angular View Encapsulation: Types and How It Works Behind the Scenes

Pranav Kale — Sat, 21 Jun 2025 07:53:09 +0000

When building large-scale Angular applications, one challenge frontend developers often face is style leakage. That is, styles defined in one component affecting elements in another unintentionally. Angular provides a powerful solution to this problem through View Encapsulation.

In this blog, we'll explore:

What is View Encapsulation?
The types Angular offers
How Angular implements it internally
A detailed look at how default encapsulation prevents style leakage
A conclusion to wrap things up

What is View Encapsulation?

View Encapsulation in Angular controls whether the styles defined in a component affect only that component or bleed into other components.

It ensures that each component’s styles are scoped in a way that keeps them isolated unless explicitly made global.

Types of View Encapsulation

Angular provides three strategies via the ViewEncapsulation enum in @angular/core:

Emulated (Default):
How it works: Angular emulates Shadow DOM behavior by preprocessing and scoping CSS at runtime.
Style isolation: Yes
Shadow DOM usage: No
ShadowDom:
How it works: Uses the browser’s native Shadow DOM API to encapsulate styles and DOM.
Style isolation: Yes
Shadow DOM usage: Yes (native)
None:
How it works: No encapsulation at all. Styles are global.
Style isolation: No
Shadow DOM usage: No

How Angular Emulates Encapsulation Internally (Emulated ViewEncapsulation)

The Emulated mode is the default and most commonly used strategy in Angular. Here's how Angular ensures that styles do not leak out or leak in:

1. Component-specific Attributes
When a component is compiled, Angular generates a unique attribute for each component. For example, app-root might become:

<app-root _nghost-c0>
  <div class="box" _ngcontent-c0>...</div>
</app-root>

Here:

_nghost-c0 is added to the host element (the component tag).
_ngcontent-c0 is added to all the child elements inside the component template.

These attribute markers are not for the developer to use but for Angular’s style scoping mechanism.

2. Scoped Styles
Angular compiles your CSS and rewrites selectors to include the attribute selectors generated earlier. For example:

Original component CSS:

.box {
  background-color: red;
}

Compiled and rewritten CSS:

.box[_ngcontent-c0] {
  background-color: red;
}

This means:

Styles apply only to elements inside the component template with _ngcontent-c0.
Styles from other components with different _ngcontent- IDs won’t apply here.

This ensures style encapsulation without needing Shadow DOM support in the browser.

ShadowDom ViewEncapsulation

If you opt for ViewEncapsulation.ShadowDom, Angular will attach the component’s template to the browser’s native Shadow DOM. Styles are automatically scoped by the browser, and there's no need for attribute selectors like _ngcontent-c0.

This method offers true encapsulation, but not all browsers support every Shadow DOM feature, and global styles (e.g., fonts or themes) might not penetrate the shadow tree easily.

None ViewEncapsulation

Using ViewEncapsulation.None is like writing global CSS. Angular adds no scoping mechanism. This can be useful for styling third-party content or defining global themes, but it’s risky in large applications due to the potential for conflicts.

Conclusion

Angular’s View Encapsulation is a powerful concept that helps maintain clean, modular, and predictable component styles. Understanding the three types—Emulated, ShadowDom, and None—enables you to pick the right approach for your use case.

Most projects can safely rely on Emulated, which strikes a balance between compatibility and style isolation by cleverly adding generated attribute selectors to scope styles.

By understanding how Angular rewrites your styles under the hood, you can write more predictable, maintainable CSS—and avoid those frustrating "why is this style leaking?" moments.

Avoiding Production Disasters with npm ci: The Key to Stable Deployments

Pranav Kale — Sun, 09 Feb 2025 07:39:30 +0000

Introduction

Managing dependencies in JavaScript projects is a critical task, and npm (Node Package Manager) provides robust tools to handle versioning effectively. Developers often face issues with inconsistent dependencies across environments, leading to unexpected bugs and compatibility problems. This is where npm versioning and the npm ci command come into play.

In this blog, we will explore npm versioning, the significance of package.json and package-lock.json, and how npm ci ensures consistent installations. We'll also discuss a real-world scenario where npm ci saved the day.

Understanding npm Versioning

package.json and Semantic Versioning (SemVer)

Every Node.js project includes a package.json file, which lists dependencies along with their version numbers. These versions follow Semantic Versioning (SemVer), which consists of three numbers:

MAJOR.MINOR.PATCH

MAJOR : Incompatible changes (e.g., breaking changes).
MINOR : Backward-compatible new features.
PATCH : Backward-compatible bug fixes.

Version Ranges in package.json

In package.json, dependency versions can be defined using different symbols:

Tilde (~): Accepts only PATCH updates.
Caret (^): Accepts MINOR and PATCH updates.
Fixed version: Ensures an exact version.

While these flexible ranges help in staying up to date, they can sometimes introduce inconsistencies between development and production environments.

package-lock.json: Locking Dependencies

The package-lock.json file ensures exact versions of dependencies and their sub-dependencies are locked. This prevents issues where different team members or CI/CD pipelines might install slightly different versions of packages due to SemVer rules.

What is npm ci, and Why is it Important?

npm install: Installs dependencies based on package.json, potentially updating package-lock.json.
npm ci: Stands for "clean install." It removes node_modules and installs exact versions from package-lock.json, ensuring consistency across environments.

Real-World Scenario Where npm ci Helped

Problem: Production Outage Due to Dependency Mismatch

A team was maintaining a large enterprise web application that relied heavily on dynamic data tables using AG Grid. Their package.json included the following dependencies:

{
  "dependencies": {
    "ag-grid-angular": "^28.2.0",
    "ag-grid-community": "^28.2.0"
  }
}

During deployment, npm install was used instead of npm ci, which resulted in a minor version upgrade to AG Grid 28.2.3 in production. However, this update introduced a breaking change in how grid rendering was handled, causing all tables across the application to break. As a result:

Users couldn't view or interact with tabular data.
Critical business workflows were disrupted.
Customer support received numerous complaints, impacting the company’s reputation.

Solution: Implementing npm ci

To prevent such issues in the future, the team switched to npm ci in their CI/CD pipeline. This ensured that:

Only exact versions from package-lock.json were installed, preventing unexpected upgrades.
Production and development environments used identical dependencies, ensuring consistency.
Builds were predictable, reducing deployment risks.
Deployment times improved, as npm ci performs a clean install more efficiently than npm install.

Outcome

After implementing npm ci, the team ensured that future deployments used only tested dependency versions, preventing surprise breaking changes. The production environment remained stable, and the AG Grid tables continued functioning as expected.

Conclusion

Understanding npm versioning and leveraging npm ci can significantly improve dependency management. While npm install is useful for development, npm ci is the best choice for CI/CD pipelines, ensuring strict version control and eliminating unpredictable bugs.

By using npm ci, teams can achieve reliable builds, faster deployments, and consistent environments, ultimately saving time and avoiding production issues.

Best Features of Nx for Angular Projects

Pranav Kale — Sat, 08 Feb 2025 15:24:41 +0000

Nx is a powerful build system and monorepo tool that enhances Angular development by providing improved performance, modularity, and developer experience. Below are some of its best features:

Monorepo Support

Nx allows you to manage multiple Angular applications and libraries within a single repository. This is useful for:

Code sharing across apps
Enforcing consistent coding standards.
Simplifying dependency management.

npx create-nx-workspace@latest my-org --preset=angular

Code Generation & Scaffolding

Nx provides built-in generators to quickly scaffold components, services, modules, and libraries.

nx generate @nrwl/angular:component my-component --project=my-app

Incremental Builds & Affected Commands

Nx speeds up builds by running tasks only on changed projects instead of the entire repository.

nx affected:build
nx affected:test

This ensures only modified applications and libraries are built or tested, saving time in CI/CD pipelines.

Project Graph Visualization

Nx provides a dependency graph to visualize how different applications and libraries interact.

nx graph

This helps in understanding dependencies and optimizing the project structure.

Module Federation for Micro Frontends
Nx simplifies Micro Frontend (MFE) implementation with Webpack’s Module Federation.

nx generate @nrwl/angular:host shell --remotes=app1,app2

This sets up an Angular MFE architecture with a shell app and remote apps.

Enforce Coding Standards with ESLint & Prettier
Nx integrates ESLint and Prettier, ensuring uniform coding styles and preventing bad practices.

nx lint my-app

This runs ESLint on the my-app project.

Testing with Jest & Cypress
Nx replaces Karma and Jasmine with Jest (for unit testing) and Cypress (for end-to-end testing).

nx test my-app
nx e2e my-app-e2e

Jest runs tests faster with better reporting, while Cypress provides end-to-end UI testing capabilities.

Conclusion
Nx makes Angular development more efficient with features like incremental builds, modular architecture, dependency constraints, and testing enhancements. By leveraging these capabilities, teams can improve performance, maintainability, and collaboration in large-scale projects.