DEV Community: Leo Lanese

The Age of AI Isn't About Replacement. It's About Relevance

Leo Lanese — Thu, 05 Mar 2026 20:02:02 +0000

Let me ask you something:
Are you afraid AI is going to take your job?

If you are... I get it. The headlines are loud. The demos are wild. It feels like everything we know about building software is changing overnight.

But here's what I've learned after watching this shift up close:

The Age of AI isn't about replacement. It's about relevance.

Artificial intelligence has shifted from novelty to necessity. Every industry is feeling the tremor: faster production, automated workflows, and tools that can generate in seconds what once took hours.

The professionals who thrive in this new era aren't the ones who fear automation. They're the ones who understand what AI is and what it isn't. They know that while AI can accelerate execution, it cannot define purpose, context, or meaning. That's where human judgment becomes more valuable than ever.

AI doesn't change what we build. It changes how we work.

What AI Actually Changes

AI transforms the nature of work in three major ways:

Repetition becomes automated. Tasks that are mechanical, predictable, or pattern-based are now handled by machines.
Speed becomes a commodity. Producing something quickly is no longer a differentiator, everyone has access to the same tools.
Expertise becomes the premium. The ability to define the right problem, shape the right direction, and evaluate the right outcome becomes the real value.
AI Allows Us to Elevate and Accelerate. Software Engineers are not just coders. AI provides a way to delegate execution so we can start making higher-level decisions. It frees us to focus on architecture, strategy, security, creativity and innovation, not just syntax.

When the "how" becomes easy, the "why" and "what" become priceless.

The New Value Proposition: Sell the Destination

In a world where AI can generate drafts, designs, and data at scale, the competitive edge lies in:

Clarity of vision: knowing what should be built.
Strategic judgment: understanding what matters and what does't.
Creative insight: shaping ideas that resonate, differentiate, and endure.
Experience: recognising patterns, mistakes, previous battles, and opportunities AI can't see.

Clients don't pay for the hours. They pay for the outcome. They pay for the ability to navigate complexity, make decisions, and craft meaning.

AI is the engine, but you are the driver.

A Conversation That Captures the Moment

This simple exchange illustrates the mindset shift happening across industries:

The client said, we can do this with AI.
That's great. Me too.
So you are not worry AI is taking your job?
Nope.
AI doesn't replace expertise.
It replace repetition.
Still need a strategist to define the goal, orchestrate and judge the results.
So, what's the move?
Sell the destination, not the effort. Lets the robot do the busy work.
You charge for knowing what to build, not just how to build it.
You are selling Creativity. Experience. Judgment.

Why This Matters Now (probably more than ever)

As AI becomes more accessible, the gap widens between those who use it as a shortcut and those who use it as a force multiplier. The latter group will lead the next decade of innovation.

The question isn't "Will AI take my job?"
The question is "How much more valuable can I become when AI handles the repetitive parts?"

Keynotes

AI isn't about replacement, it allows us to elevate and accelerate by shifting value from execution to strategic judgment.

Become the pilot who defines purpose—because AI is the engine, but you are the one who decides where to go. Sell the destination, not the effort.

💯 Thanks!

🔘 linkedin: @LeoLanese

🔘 Twitter: @LeoLanese

🔘 DEV.to: Blog

🔘 Questions / Suggestion / Recommendation: developer@leolanese.com

AI is the Sous‑Chef, Not the Chef

Leo Lanese — Wed, 11 Feb 2026 09:26:27 +0000

Explaining AI to My Son: From Michelin Chefs to Ratatouille

Today I was having my cup of tea, my son open the door of the living room and asked me a simple question that opens a very big door:
"What is AI?"

It's one of those moments where you want to give an answer that's true, but also something a child can actually understand. So we started talking about chefs.

I told him that AI can be a bit like a Michelin‑star restaurant run by a master chef, someone who has mastered thousands of recipes, techniques, and flavours. A chef like that can create incredible dishes because they've learned from years of experience.

He liked that idea.
Then I added something even more familiar to him: Ratatouille.

In the movie, Remy the "smart" rat isn't magic. He doesn't replace the human Alfredo Linguini the chef. Instead, he helps, guides, and elevate the chef. Linguini still chooses what to cook, tastes the food, decides what's right and even innovate about a better solution.

That's how I explained AI.
AI is like having an smarty-panties Remy in the kitchen of your mind.
In the movie, Remy doesn't replace the human chef.

He helps.
He guides.
He adds skill
He offer ideas, shortcuts, and knowledge.
He speed up the work.

It cannot offer intention.
It cannot test the real flavor.
It cannot replace the passion and spark that makes something yours.
It cannot "feel the meaning behind the dish".

Passion, creativity, innovation, and purpose still come from the expert chef.

AI is a tool, a powerful one, but it needs a human mind and a human heart to direct it. Just like Remy needs Linguini, AI needs us to decide what we're trying to create, what is this "meaning" behind the dish to make it "unique".

Some people worry that using AI is "bad" or that it "replaces chef creativity". But when you frame it the right way, it becomes clear that AI is a tool, not a threat. It is A helper, an enhancer, not a replacement.

Just like in Ratatouille, the magic happens when human intention and guidance meet skill and knowledge. AI doesn't replace human creativity, it amplifies it.

💯 Thanks!

Now, don't be an stranger. Let's stay in touch!

🔘 linkedin: @LeoLanese

🔘 Twitter: @LeoLanese

🔘 DEV.to: Blog

🔘 Questions / Suggestion / Recommendation: developer@leolanese.com

The Miner and the Jeweler: Why AI Code Isn't Production-Ready

Leo Lanese — Sat, 07 Feb 2026 17:10:30 +0000

Keep hearing voices claiming that AI is replacing Devs, and as we discuss befor in my previous article:

The Great Compression: Why AI isn't Replacing Developers, It's Refining Them

AI-Generated Code, right now, is a Raw Diamond, Not a Finished Ring. Not a Finished pollished ring that is going to direcly represent your brand reputation to the customers in the market.

LLM's doesn't produce fully "ready for production" code, it produces "ready for refinement" code.

The Miner (LLM's) does the brutal, foundational work:

Finds the raw material: It scrapes through terabytes of code (the digital earth) to identify patterns, syntax, and logic.
Extracts the valuable ore: It can produce code snippets, functions, even whole files that are often structurally correct and address the stated problem.
Roughs out a shape: It can create a basic, functional version of what you asked for the equivalent of a roughly cut stone.

But a "Ready for Production" ring requires a master jeweler (the human senior developers):

Design & Intent: The miner didn't conceive of the ring's design, its purpose, or how it fits into a larger collection (the software architecture). The years of experience does.
Precision Cutting & Polishing: The raw code is full of flaws.
Edge Cases: It doesn't handle unexpected inputs or errors gracefully.
UI/UX: May be not trendy and sharp as expected
Innovation: May be working "fine" but not following trends or adding innovation and "human-touch"
Security: It might introduce vulnerabilities (SQL injection, insecure defaults).
Performance: It's rarely optimized for efficiency or scalability.
Integration: It doesn't know how to fit neatly into your existing codebase, APIs, and CI/CD pipelines.
Setting & Context: The code must be "set" into its environment.
Business Logic: Does it actually fulfill the complex, often unstated, business rules?
Maintainability: Is it readable, documented, and follow team conventions?
Testing: It lacks comprehensive unit, integration, and end-to-end tests.

The Perfect Workflow is a Collaboration:

The real power is in combining the scale and speed of the miner with the expertise and judgment of the jeweler: A "Centaur-Developer"

The Developer (Jeweler) says: "I need a function that securely authenticates a user via OAuth and returns a profile."
LLM's (Miner) provides: A large, rough block of code with the basic OAuth flow, HTTP calls, and data parsing—saving hours of boilerplate writing.
The Developer then: Refines it, adds input validation, error handling, logs, integrates it with the specific auth library, writes tests, and ensures it follows security protocols.

Conclusion:

This evolution won't replace the expert, it will augment and elevate their work.** The most successful developers and companies will be those who master this new partnership, using AI to amplify their creativity and strategic impact.

Right now, LLM's doesn't produce fully "ready for production" code, it produces "ready for refinement" code.

They are an immensely powerful tool that drastically accelerates the initial phases of development, but the final responsibility for the "add-value" UI/UX, craftsmanship, security, and fit, for turning the raw diamond into a finished fashing ring remains firmly, with the human expert.

This distintive "add-value" is precisely what will create lasting differentiation and quality for companies in the long run.

💯 Thanks!

Now, don't be an stranger. Let's stay in touch!

🔘 linkedin: @LeoLanese

🔘 Twitter: @LeoLanese

🔘 DEV.to: Blog

🔘 Questions / Suggestion / Recommendation: developer@leolanese.com

The Great Compression: Why AI isn't Replacing Developers, It's Refining Them

Leo Lanese — Wed, 04 Feb 2026 15:30:00 +0000

There is a loud, recurring narrative that AI is coming for the software engineer's job.

Link: Former Google CEO just revealed AI's scary timeline
In this clip, Schmidt discusses the "San Francisco Consensus", the belief that within a year, AI will replace the vast majority of programmers as we know them. He points to "recursive self-improvement," where computers are now generating 10–20% of their own code.

But let's talk about the reality on the ground.

There's a difference between AI does lots of the coding work and AI makes programmers irrelevant. Right now, it's closer to the first than the second. The real shift isn't AI replacing Developers but about compressing work. Because, if you look at the actual workflow in modern Deveveloper shops, the reality is far more surgical. We are currently witnessing a massive shift in the industry, but it isn't an "obsolescence" event, it is a "compression" event.

1. Augmentation vs. Replacement
Right now, we are firmly in the era of AI doing the "grunt work." AI handles the boilerplate, the unit-tests, e2e, and the repetitive syntax that used to consume hours.

The Myth: AI writes the app while the human watches.
The Reality: AI is a high-speed power tool. It "amplifies" the output of the person holding it, but it still requires an architect to ensure the structure is sound.

2. The End of the "Easy Cash" Era
For the last decade, the high demand for code led to an influx of people entering the field strictly for the "high" salaries, often lacking a background, foundational interest in engineering or the "passion for resolving problems".

When AI can generate (almost) functional code in seconds, the value of a Developer who just "follows instructions for a paycheck" drops to near zero.

The Problem-Solver: Sees AI as a lever to solve bigger, more complex problems.
The Paycheck-Seeker: Finds themselves competed against by a tool that is cheaper, faster, and doesn't mind repetitive tasks.

3. The "Compression" Effect
As AI amplifies productivity, the "middle" of the market starts to squeeze. When one senior engineer can produce the output of three due to AI assistance, the need for a large army of less-specialised "task-runners" diminishes.

We are moving toward a world where specialisation and passion are the only true moats. If you aren't curious about how things work under the hood, AI will eventually automate your role.

4. The Power of "Zooming Out" control
Being a "Centaur" Engineer means you no longer have to spend hours buried in the deatils of basic algorithms. You can "zoom out" to see the bigger picture. Because the AI manages the low-level execution, the engineer is free to focus on systemic efficiency:

Understanding the "How": You aren't just writing lines; you are understanding how the entire system breathes and scales.
Elevated Problem Solving: You spend your energy on architecture and high-level logic—ensuring the solution is elegant and efficient, rather than just "functional".
Efficiency over Effort: The goal is no longer "hours spent coding," but the quality and performance of the final architecture.

5. Multiple hats in the same eco-system:
A Software Engineer has never been just a "coder", In fact, writing code is often the simplest part of the job. and in the AI era, this is more true than ever. We are well-rounded professionals who must navigate a complex ecosystem. Being a Centaur Engineer means having the versatility to wear multiple hats throughout the product lifecycle:

The Architect: Designing systems that are scalable and maintainable.
The Product Designer: Understanding UX and human behaviour to reduce friction.
The Mentor & Communicator: Using soft skills to bridge the gap between stakeholders and the codebase.
The Leader & Conflict resolver: Elevating the team through leadership, code reviews, deal with conflicts, and shared standards.
The Business Strategist (ROI Guardian): This is about looking at the CRO and KPIs. You ensure that every line of code serves a material business purpose and isn't just "tech for tech’s sake."

AI isn't making programmers irrelevant; it's making perfunctory programming irrelevant eventually.

The "easy cash" entry point is vanishing. The future belongs to the "Passion, eager to learn and curious Enginners". The "Centaur Enginners" (AI Body and Human Head). Those who use AI to compress months of work into weeks, zooming out to focus their human intellect on the "why" and the systemic efficiency, rather than just the "how".

💯 Thanks!

Now, don't be an stranger. Let's stay in touch!

🔘 linkedin: LeoLanese

🔘 X / Twitter: @LeoLanese

🔘 DEV.to: dev.to/leolanese

🔘 Blog: leolanese.com/blog

🔘 Questions / Suggestion / Recommendation: developer@leolanese.com

The Operator's Manual: Navigating Angular Signals from v17.3 to v21

Leo Lanese — Sun, 04 Jan 2026 21:02:24 +0000

The Operator's Manual: Navigating Angular Signals from v17.3 to v21

A Comprehensive Guide to the Evolution of Reactivity in Angular

Version 1.0

Chapter 1: The Foundation (Angular 17.3) – Completing the Component API
- 1.1 Signal-Based Components: The Full Toolkit
- 1.2 Operating with output() and RxJS Interop
Chapter 2: Stabilization and Architecture (Angular 18–20) – Production Readiness
- 2.1 From Preview to Prime Time: Graduating to Stable
- 2.2 The Signal-Powered Service Pattern
- 2.3 Enabling the Zoneless Future
Chapter 3: The New Frontier (Angular 21 Experimental) – The Signal Ecosystem
- 3.1 Introducing Signal Forms: A Paradigm Shift
- 3.2 Advanced Operations: Async Data and Linked State
Chapter 4: The Operator's Field Guide – Best Practices & Migration
- 4.1 Core Principles of Signal-Based Code
- 4.2 Upgrading Your Machinery: The Migration Path
- 4.3 Migration Checklist: A Step-by-Step Guide
- 4.4 Adopt signal components: Replace async pipes with direct signal calls
- 4.5 Refactor services from BehaviorSubject to signals
Conclusion: A New Era of Angular Reactivity
References

Welcome, operator. You've been handed the keys to a machine that has undergone a profound transformation. What began as a new reactive primitive in Angular has evolved into a fully integrated system that redefines how we build, manage, and think about application state. This manual is your guide to mastering the evolution of Angular Signals, from the foundational APIs in version 17.3 to the experimental frontiers of version 21. Prepare to recalibrate your understanding of reactivity.

Chapter 1: The Foundation (Angular 17.3) – Completing the Component API

Our journey begins with Angular 17.3, a release that delivered the final piece of the puzzle for creating fully decorator-less, signal-based components. This version marked the moment when the core mechanics for component communication were fully realised in the new signal paradigm.

1.1 Signal-Based Components: The Full Toolkit

Prior to 17.3, the Angular team had already provided signal-based alternatives for inputs (input()) and queries (viewChild()). However, component outputs still relied on the traditional @Output() decorator with EventEmitter.

Angular 17.3 completed this set by introducing the output() function. This allowed developers to author components where all public-facing APIs, inputs, outputs, and queries, were defined as functions, creating a consistent and decorator-free experience. As noted by the Angular team, this was about creating conceptual alignment with the other new signal-based APIs.

1.2 Operating with `output()` and RxJS Interop

The new output() function provides a lightweight, RxJS-independent way to emit events. While EventEmitter extended RxJS’s Subject, the new OutputEmitterRef returned by output() is a simpler, purpose-built primitive.

The transition from decorator-based outputs to function-based outputs streamlines component definitions and reduces dependency on RxJS for basic eventing.

// Before: Angular <17.3
import { Component, Output, EventEmitter } from '@angular/core';

@Component({...})
export class LegacyButtonComponent {
  @Output() clicked = new EventEmitter<void>();

  onClick() {
    this.clicked.emit();
  }
}

// After: Angular 17.3+
import { Component, output } from '@angular/core';

@Component({...})
export class SignalButtonComponent {
  clicked = output<void>();

  onClick() {
    this.clicked.emit();
  }
}

Crucially, the Angular team provided a bridge for the vast ecosystem of RxJS-based code. The @angular/core/rxjs-interop package was enhanced with outputFromObservable() and outputToObservable(). These utilities allow you to convert an RxJS stream into a component output and vice-versa, ensuring a smooth, incremental migration path without requiring a full rewrite of existing reactive logic.

Chapter 2: Stabilization and Architecture (Angular 18–20) – Production Readiness

The period between Angular 18 and 20 was about hardening the new signal APIs and establishing new architectural patterns. What was once experimental became the recommended, stable foundation for modern Angular applications.

2.1 From Preview to Prime Time: Graduating to Stable

Throughout versions 18, 19, and 20, the core signal APIs, including input(), model() for 2-way binding, and signal-based queries like viewChild() and contentChildren(), graduated from developer preview to stable. According to the official Angular roadmap, v20 marked the milestone where all fundamental reactivity primitives were considered stable. This was the green light for enterprises and large-scale projects to adopt signals with confidence, knowing the API surface was reliable and supported for the long term.

2.2 The Signal-Powered Service Pattern

With stable signals, a powerful new architectural pattern emerged for state management. Instead of relying on RxJS BehaviorSubject in services, developers began adopting a "signal-in-a-service" approach. This pattern involves:

A private, writable signal (e.g., _items = signal([])) to hold the state.
Public, readonly or computed signals to expose state and derived values (e.g., items = this._items.asReadonly(), total = computed(() => ...)).
Public methods to orchestrate state changes via set() or update().

This architecture creates a clean, unidirectional data flow where the service is the single source of truth. Consumers can react to state changes without being able to mutate it directly. This pattern dramatically simplifies state management, improves testability due to the synchronous nature of signals, and eliminates boilerplate associated with RxJS subjects and subscriptions.

2.3 Enabling the Zoneless Future

The ultimate purpose of Signals extends beyond simplifying state management; it's the key to unlocking a zoneless Angular. Traditional Angular uses Zone.js to automatically trigger change detection in response to any async operation. While convenient, this can be inefficient.

Signals provide a granular dependency graph. When a signal's value changes, Angular knows precisely which components or computed values depend on it and updates only them. This fine-grained reactivity makes Zone.js unnecessary. As of Angular v20.2, zoneless mode became stable, and with Angular v21, it is the default for new applications. This results in smaller bundle sizes, better performance, and more predictable application behavior.

Demo example:
https://github.com/leolanese/Angular-Zoneless-Signals

Chapter 3: The New Frontier (Angular 21 Experimental) – The Signal Ecosystem

With the core primitives stable, Angular 21 began exploring the next evolution: a rich ecosystem of signal-based tools that tackle some of the most complex areas of web development. These features, though experimental, offer a glimpse into a future where reactivity is seamlessly integrated into every part of the framework.

3.1 Introducing Signal Forms: A Paradigm Shift

Perhaps the most anticipated feature is the new Signal Forms API, available experimentally in Angular 21 via @angular/forms/signals. It represents a fundamental rethinking of form handling, moving away from the boilerplate-heavy Reactive Forms.

Signal Forms flip the script: instead of building a form structure to match your data, you start with your data model and let the form derive itself reactively.

The core principles are:

Model-First Approach: You define your form's state as a signal, then create the form by passing it to the form() function.

// Define the data model as a signal
user = signal({ firstName: '', email: '' });

// Create the form from the model
profileForm = form(this.user, (path) => [
  // ... validation rules
]);

Declarative Validation: Validation rules are defined as functions within the form's schema. This includes built-in validators (required, minLength, email), conditional validation (using a when property), and powerful cross-field validation. This replaces the imperative logic of adding/removing validators in traditional forms.
Simplified Template Binding: The old formControlName is replaced by a new field directive, creating a direct, type-safe link between the template and the form field signal.
Built-in Submission Handling: The submit() helper function manages the submission process, automatically handling loading states (submitting()) and server-side errors, which can be mapped directly back to form fields.

This new API promises to drastically reduce boilerplate, improve type safety, and make complex validation logic far more intuitive and maintainable.

3.2 Advanced Operations: Async Data and Linked State

Alongside forms, Angular introduced other advanced signal-based tools:

The Resource API: The experimental resource and rxResource functions provide a declarative way to handle asynchronous data fetching. A resource automatically re-fetches data when its dependent signals (params) change and provides built-in signals for tracking loading, error, and value states. This eliminates manual subscription management and loading flags for API calls.
linkedSignal(): This is an advanced primitive for niche scenarios. Unlike a read-only computed() signal, a linkedSignal is writable. It derives its initial value from a source signal but can also be updated manually. This is useful for cases like a dropdown selection that should reset when its options change, but still allow the user to make a manual selection.

Chapter 4: The Operator's Field Guide – Best Practices & Migration

Mastering a new system requires understanding its rules of engagement. This chapter provides the essential principles and a strategic plan for upgrading your existing machinery.

4.1 Core Principles of Signal-Based Code

Adhering to these best practices will ensure your signal-based applications are performant, predictable, and maintainable.

Use computed() for Derived State: This is the most critical rule. If you are calculating a value based on one or more other signals, always use computed(). Avoid using effect() to set another signal, as this is an anti-pattern that can lead to performance issues and unexpected behavior.
Use effect() for Side Effects Only: Effects are the bridge to the non-signal world. Use them for tasks like logging, syncing to localStorage, or custom DOM manipulation. Remember that effects run asynchronously.
Keep State Flat: Avoid nesting signals within other signals or deep within objects. A flat state structure is easier to track and leads to more efficient change detection.

4.2 Upgrading Your Machinery & migrate: The Migration Path

# Migrate @Input() to signal inputs
ng generate @angular/core:signal-input-migration

# Migrate @Output() to signal outputs
ng generate @angular/core:signal-output-migration

# Migrate @ViewChild/@ContentChild queries
ng generate @angular/core:signal-queries-migration

ng generate @angular/core:signal-input-migration

ng generate @angular/core:signal-output-migration

ng generate @angular/core:signal-queries-migration

4.3 Incrementally Migrate to Signal Forms:

For new features or during refactoring, adopt the experimental Signal Forms API. Start with simple forms and gradually tackle more complex ones.

Identify a form using traditional Reactive Forms.
Define a signal for your data model: user = signal({name:'',email:''});
Create the signal form: profileForm = form(this.user, ...);
Update the template to use the [field] directive instead of formControlName.
Replace imperative validation logic with declarative rules inside the form() function.

4.4 Adopt signal components: Replace async pipes with direct signal calls.

4.5 Refactor services from BehaviorSubject to signals

Conclusion: A New Era of Angular Reactivity

The journey from Angular 17.3 to 21 reveals a clear trajectory. Signals have evolved from a promising state primitive into the central nervous system of Angular's reactivity model. They have simplified component authoring, redefined state management architecture, unlocked a zoneless future, and are now poised to revolutionize form handling.

As an operator of this modern framework, your mandate is clear: embrace this new model. By understanding its principles and leveraging its powerful ecosystem, you can build applications that are not only faster and more efficient but also simpler to write, easier to debug, and ready for the future of the web. The machinery is in your hands. Operate it with confidence.

References

What's new in Angular 17.3 – by Gergely Szerovay

A detailed walkthrough of Angular 17.3 features including the new output() API, RxJS interop helpers (outputFromObservable, outputToObservable), HostAttributeToken, and TypeScript 5.4 support.
Angular Signal-Based Architecture: Building a Smarter Shopping Cart

Practical guide to refactoring state-heavy features using the "signal-in-a-service" pattern for cleaner, more testable, and performant applications.
Angular Signal-Based Forms: Why They're About to Change Everything You Know About Form Handling

An early look at the experimental Signal Forms API in Angular 21, highlighting its model-first design, declarative validation, and improved developer ergonomics.
Reactive Angular: Loading Data with the Resource API

Introduces the experimental resource and httpResource primitives for managing async data streams with built-in signals for loading, error, and value states.
Dependent state with linkedSignal – Angular Official Guide

Documentation on linkedSignal(), a writable computed-like signal that resets when its source changes—ideal for dynamic UI controls like dependent dropdowns.
Angular Signals Effect(): Why 90% of Developers Use It Wrong

Clarifies common anti-patterns with effect() and emphasizes its correct use strictly for side effects (e.g., logging, localStorage, DOM mutations).
Angular Roadmap – Official Angular.dev

The canonical source for Angular’s strategic priorities, including status updates on Signals, zoneless Angular, Signal Forms, HMR, testing tooling, and future explorations.
Meet Angular's new output() API – Angular Blog

Official announcement of the output() function in Angular 17.3, explaining its type safety, alignment with signal inputs, and RxJS interop via outputFromObservable() and outputToObservable().
Angular v21 Goes Zoneless by Default: What Changes, Why It’s Faster, and How To

In-depth analysis of zoneless change detection becoming the default in Angular v21—covering performance gains, bundle size reduction, migration steps, and gotchas.

Let's connect!

Linkedin: LeoLanese
Twitter: @LeoLanese
Blog: Dev.to
Contact: developer@leolanese.com

Signals & JS Event Loop: Rethinking Angular Reactive Sync

Leo Lanese — Mon, 08 Sep 2025 16:14:35 +0000

🟩 Signal definition

Signals are synchronous reactive primitives containers, that hold an immutable single value

🟩 Signals & Immutability

Signals are immutable, but the value they hold is not

Signals in Angular are reactive primitives. Once you create a signal using signal(initialValue), that signal instance doesn't change. You don't replace the signal with another one; you update its internal state using the methods set() or update().

🟩🟩 Immutability with signals means:
🔸 The reference to the signal doesn't change.
🔸 It encapsulates its reactive behavior and dependencies.
🔸 Reactivity is predictable and traceable because the structure doesn’t change over time

If the value of the Signal is a reference object (eg. an object or array) you can still modify that reference without calling the set() or update(). In practice, this means the absolute value of the Signal can change without alerting all the consumers of the Signal.

🟩 Signal mutate immutability

🚨 Signals are immutable containers, but if the value they hold is a reference (like an object or array), that reference can be mutated directly, which bypasses Angular reactivity system.

const user = signal({ name: 'Alice', age: 30 });

user().name = 'Bob';  // BAD 

user.set({ ...user(), name: 'Bob' }); // GOOD

const users = signal<User[]>([
  { id: 1, name: 'Alice', age: 30 },
  { id: 2, name: 'Bob', age: 25 },
  { id: 3, name: 'Carol', age: 35 },
])

// Update a user’s name immutably
users.set(users().map(user =>
  user.id === 2 ? { ...user, name: 'Robert' } : user
))

//  Add a new user immutably
users.set([
  ...users(),
  { id: 4, name: 'Dave', age: 28 }
]);

// 3. Remove a user immutably
users.set(users().filter(user => user.id !== 1))

🟩 Angular Change-Detection & Signals

Angular is transitioning to fine-grained reactivity. Because with default change detection, there is no way for Angular to know exactly what has changed on the page, so that is why we cannot make any "assumptions" about what happened, and we need to check everything.

Signals are all about enabling very fine-grained updates to the DOM that are just not possible with the current change detection systems that we have available.

Simply put, a signal is a reactive primitive that represents a value and that allows us to granular change that same value in a controlled way and track its changes over time.

🟩 JS Event-Loop and Signal

Event-loop is critical for Angular reactivity and performance

🟩🟩 Angular Change Detection & ZoneJS

Zone.js Hooks: Zone.js patches both micro-and macrotask APIs so that every async callback (Observable emission included) triggers change detection.
Microtask Checkpoint: Angular waits for the microtask queue to drain before running change detection, ensuring all Promise and Observable-driven state changes are applied consistently.

event loop → microtask drained → Zone.js → Angular runs change detection cycle

🟩🟩 Where Signals Change the Story

Signals break the blanket dependency on event loop + Zone.js

Signals step in by breaking the blanket dependency on the event loop + ZoneJS. Instead of waiting for any microtask to finish, a Signal knows exactly which pieces of state are "watched" by which consumers.

"Blanket dependency" means Angular was completely dependent on the event loop + Zone.js for every single change detection cycle.

When a signal changes, Angular doesn't need to run global change detection. It updates only the components (or computed values) that directly depend on that signal.

This avoids unnecessary trips through the entire component tree every time the event loop drains.

console.log("Start");

setTimeout(() => {
  console.log("Timeout callback fired");
  stateSignal.set("timeout update");
}, 0);

Promise.resolve().then(() => {
  console.log("Promise callback fired");
  stateSignal.set("promise update");
});

console.log("End");

🔸 Without Signals (Traditional Angular):

Start
End
Promise callback fired
→ 🔍 Change Detection (WHOLE APP CHECKED)
Timeout callback fired
→ 🔍 Change Detection (WHOLE APP CHECKED)

🔸 with signals:

Start
End
Promise callback fired
→ 🎯 Signal updated (ONLY DEPENDENT COMPONENTS)
Timeout callback fired
→ 🎯 Signal updated (ONLY DEPENDENT COMPONENTS)

Signals let Angular ride on top of the event loop without being bound to Zone.js heavy blanket strategy. They reduce unnecessary CD cycles by updating only what is truly reactive.

🟩 Angular has 4 "kind" of signals and Angular Change Detection cycle

🔸 WritableSignal = read & write state. Trigger CD when: set, update, mutate. created by: signal()
🔸 Signal = read-only state. No trigger CD (doesn’t mark the component as dirty) created by: .asReadonly()
🔸 ComputeSignal = Pure functions of other signals. No side effects (Never modify state (e.g., no set(), API calls, or DOM updates)). Signal that get from other signal. No trigger CD (not directly). created by: computed()
🔸 LinkedSignal() (experimental) = Hybrid: Starts as a computed signal (pure, memoized, lazy), but allows dynamic switching of its source signal. It's read-only and reactive, but the source can be writable.

// WritableSignal
const ws = signal(0);  // WritableSignal<number>

const currentValue = ws(); // ✅ READ OPERATION (NO CD TRIGGER)

// WRITE OPERATIONS (TRIGGER CD)
ws.set(5);            // 🚨 Replaces value → TRIGGER CD
ws.update(v => v + 1); // 🚨 Derives new value → TRIGGER CD
ws.mutate(obj => obj.prop = 1); // 🚨 In-place mutation → TRIGGER CD (if ws holds an object)

// Signal
const ros = ws.asReadonly();  // Signal<number> (read-only)

// READ OPERATION (NO CD TRIGGER)
const currentValue = ros(); // ✅ Reads value → No CD

// ATTEMPTED WRITES (BLOCKED)
ros.set(5);      // 🚨 Compile-time error (TypeScript protects you)
ros.update(...); // 🚨 Compile-time error

// ComputedSignal 
const double = computed(() => ws() * 2); // ComputedSignal<number>

// ✅ Read (no CD trigger, but reacts to ws() changes)
console.log(double()); // 10 (if ws() is 5)

// 🚨 Write Attempts (Blocked)
double.set(20); // ❌ TS Error: No 'set' method

// LinkedSignal
const base = signal(2);
const linked = linkedSignal({
  source: () => base() * 2,
  computation: (val) => val + 1,
});

linked.set(10); // can override

🟩 Angular Signal Types & Change Detection Behavior

This table summarizes the four core types of Angular Signals and how they interact with change detection.

Signal Type	Writable	Derived	Triggers CD	Created By
WritableSignal	✅	❌	✅	`signal()`
Readonly Signal	❌	❌	❌	`.asReadonly()`
ComputedSignal	❌	✅	❌ (indirect)	`computed()`
LinkedSignal	✅	✅	✅	`linkedSignal()`

🟩 Take away notes

WritableSignal: Mutable state container. Triggers change detection on .set(), .update(), or .mutate().
Readonly Signal: Exposes state without allowing mutation. Does not trigger change detection.
ComputedSignal: Derived from other signals using pure functions. Angular tracks reads during render; does not directly trigger CD.
LinkedSignal: Hybrid signal — behaves like a computed signal but can also be written to. Triggers change detection on write.

Use this table to guide architectural decisions when designing reactive state in Angular with Signals.

🟩 When to use which

signal() - WritableSignal ❌ Pure, Can have side effects. You need to modify the value (set, update, mutate) ❌ Lazy, updates eagerly. ❌ Memorized ✅ Trigger CD directly, on write (set, update, mutate)

🔸 Think of it as: a plain reactive variable. Typical use: component-local state that changes often: flags

const count = signal(0);
count.set(1);

signal.asReadonly() - asReadOnly() ✅ Pure, read-only ✅ Lazy ✅ Memorized ❌ Triggers CD directly, but ✅ indirectly when the underlying writable changes.

🔸Typically for Local component or service state (eg. form inputs, API responses, expose state from service)

const writable = signal(42);
const readonly = writable.asReadonly();

computed() – pure derived from other signal ✅ Pure, read-only derived from signals. ✅ Lazy, Angular only recalculates when you read it ✅ Memorized ❌ Triggers CD directly, but ✅ indirectly when the underlying writable changes. 🔸 Typical use: derived, reactive values that are always deterministic. Formatting, filtering, or combining signals. 🔸 Great when your value is purely reactive

fullName = computed(() => firstName() + ' ' + lastName())

LinkedSignal() - read-only reactive mirror signal ✅ Pure (read-only mirror) ✅ Lazy ✅ Memorized ❌ Triggers CD directly, but ✅ indirectly when the underlying writable changes. 🔸It takes a source signal and returns a new signal that mirrors it. 🔸 Writable behaviour comes only from the sources, not the linkedSignal itself. 🔸 Use anywhere you need a signal that can change its dependency at runtime, like theming

linkedSignal({ source, computation }).

🟩 Observables & Signals: A real analogy

If you're like me, coming from RxJS and reactive programming in Angular, this analogy helped things click quicker:

Think of Observables like a water pipe: once you connect (subscribe), you start getting the flow. Signals are more like a glass of water, always present, always filled with the latest value. When the value changes, it's like someone replaced the water, and everything watching it gets notified instantly.

In UI terms, Observables stream events, Signals reflect state. Making it visible, so we can react granularly to what is, not just what is emitted.

🟩 More about Angular Signals:
🔸 Angular Reactive Forms with Signals (Angular 17+) and Signal-Based Forms (Angular 21+)
https://github.com/leolanese/Angular-Signal-ReactiveForms

🔸 Angular 20 BehaviorSubjects to Signals

🔸 Angular 20 Modern Forms Strategies and trends

🔸 Angular 20 Forms Performance Fetch Search and Filtering

🔸 Angular 20 API Observable and Signal

🔸 Angular 19 Component Communication

🔸 Angular 19 Zoneless signals

🔸 Angular 19 API Signal

🔸 Angular 19 Signals Theme

🔸 Angular 17 Signals Shopping Cart

💯 Thanks!

Hey, don't be an stranger. Let's stay in touch!

🔘 Portfolio: www.leolanese.com

🔘 Linkedin: LeoLanese

🔘 Twitter: @LeoLanese

🔘 DEV.to: Tech Blog

🔘 Questions / Suggestion / Recommendation: developer@leolanese.com

NestJS Performance

Leo Lanese — Fri, 07 Feb 2025 17:36:21 +0000

Unlock Peak Performance for Your NestJS Application: A Comprehensive Guide [UPDATED: 09/02/2025]

Are you struggling with slow response times, high resource usage, or scalability issues in your NestJS application? What if you could fix 80% of your performance problems by optimising just 20% of your code?

Welcome to the ultimate guide to supercharging your NestJS app! Here, we'll dive into actionable strategies, from identifying bottlenecks using the Pareto Principle to leveraging cutting-edge techniques.

Why This Matters?

Performance optimisation isn't just about speed, it's about delivering a seamless user experience, reducing costs, and ensuring your application can scale effortlessly. By focusing on the most impactful areas, you can achieve dramatic improvements without wasting time on low-priority fixes.

Technique

Identify Bottlenecks using Pareto Principle (80/20 Rule)
NodeJS version upgrade
Enable HTTP/3 or HTTP/2
NestJS logger performance
Buffering logs improvement
Request-Scoped injection - @Injectable({ scope: Scope.REQUEST })
Use Fastify instead ExpressJS
Use NodeJS compression middleware
Caching Strategies types
1. In-Memory Caching = "CacheModule.register({"
2. Redis-based Caching (Distributed) = CacheModule.reguster({ store: redisStore,
3. Browser HTTP Caching with Headers - 'Cache-Control':
4. Proxy Caching
5. Db Query Caching
6. Caching environment variables at runtime = ConfigModule()
7. Caching storage cache-manager
8. Caching Server Side External API Calls to Reduce Latency
9. Redis CacheInterceptor Global implementation
10. HTTP caching with @CacheKey and @CacheTTL
11. Cache busting
Db schema synchronise
Define to the Module Class which repository to use
Use Lazy-loading:route-based lazy loading + Dynamic module loading
Use Compression
Database Query Optimisation
1. Minimise the Number of Queries
2. Use ORM Frameworks with Streaming Capabilities
3. Reduce the Amount of Data Fetched
4. Leverage Database Indexing
5. Avoid N+1 Query Problem
6. Caching query results
Implement WebWorkers - WW
Implement WebSockets - WS
Implement true Load balancing across multiple servers = NodeJS Clustering -> Cloud-based Load Balancer + Reverse Proxy
1. NodeJS Clustering
2. Cloud-based Load Balancer
3. Reverse Proxy
Choose the most appropriate Dependency Injection Library
API Architecture performance:
1. API Composition pattern (efficient Microservice Communication)
2. API caching
3. Reverse Proxy
Choose the most appropriate Dependency Injection Library
API Architecture performance:
1. API Composition pattern (efficient Microservice Communication)
2. API caching
Metric for insights
Documenting your API
Adding Swagger annotations to DTOs and entities
Metric for insights
Documenting your API
Adding Swagger annotations to DTOs and entities
Recomendations

Explanation

Pareto Principle (80/20)

80/20 rule, is a powerful concept that can significantly improve efficiency and effectiveness in software development
Identify bottlenecks using profiling tools (e.g., Jaeger, Zipkin, ClinicJS) and prioritize critical optimisations

-- Where to look:

Database Layer: Check Slow queries, connection pooling, caching.
API Endpoints: High response times, unoptimized middleware, lack of caching.
CPU-Intensive Operations: Heavy computation, unoptimized libraries, lack of offloading.
Memory Usage: Memory leaks, large data structures.
Third-Party Integrations: Slow API calls, unoptimized libraries, lack of caching.
Event Loop Latency: Synchronous operations, unoptimized loops.
Logging and Monitoring: Excessive logging, lack of monitoring.
Deployment and Infrastructure: Resource limits, lack of scaling, unoptimised Docker images.

NodeJS version upgrade

One of the performance wins I could achieve was by simply upgrading, the runtime version from 16 to 18, if even possible to 20 while making little to no changes to NestJS code

This will, quickly, improved Performance: V8 Engine Updates Optimised Garbage Collection
TypeORM: Can indeed benefit from the performance improvements introduced in NodeJS 20+, especially when handling large datasets or complex queries:
Native ECMAScript Modules (ESM) Support: This can lead to cleaner code, improved tree-shaking, and potentially better performance.
Performance Improvements in newer V8 engine: This can lead to faster execution of TypeORM's query-building logic and data manipulation operations
Data Fetching Strategies:
When dealing with large datasets, consider optimising the data-fetching strategies with TypeORM:
Pagination: We can set limit the number of records retrieved in a single query.
Selective Fetching: Retrieve only the necessary fields instead of entire entities.
Batching: When fetching related entities, use batching to reduce the number of queries executed.

To fully leverage these improvements, ensure the application is updated to use NodeJS 20+ and review the TypeORM configuration and database design. Regular profiling and performance testing will help identify bottlenecks and ensure your application scales efficiently with large datasets.

Enable HTTP/3 or HTTP/2
Multiplexing:
In HTTP/1.1, only one request can be processed at a time per connection (head-of-line blocking), meaning subsequent requests must wait until the first one is completed. With HTTP/2, multiple streams can be opened, allowing the server to send multiple responses at once without waiting for previous requests to finish
Improved Resource Loading:
Simultaneous loading of resources improves the overall time it takes for a page to become interactive.

Fallback to HTTP/2: While HTTP/3 is preferable, if a client or network does not support HTTP/3, your server should fall back to HTTP/2

If your server and infrastructure (like Azure) support HTTP/3, it's recommended to utilize it, as it generally offers better performance and user experience than HTTP/1.1

Ensure that your Azure App Service is configured with a valid SSL certificate. This is necessary because HTTP/2 requires a secure connection (HTTPS)

NestJS logger performance

NestJS comes with a default logger (Logger class) which internally writes logs to process.stdout and process.stderr.
This can affect performance in NodeJS applications, including NestJS, particularly because most I/O operations are asynchronously, but process.stdout and process.stderr are synchronous in certain conditions, which can block the event loop producing perfomance issues.

In brief: Most I/O operations in NodeJS are asynchronous, allowing the event loop to remain non-blocking. However, process.stdout + process.stderr can behave synchronously under certain conditions, such as when their output is redirected (e.g., piped to a file), potentially blocking the event loop and impacting performance.

import { Logger } from '@nestjs/common';

const logger = new Logger('AppModule');
logger.log('This is a log message');

Alternatives:

-- Winston logger:

Winston logger will write logs asynchronously, which significantly improves performance by not blocking the event loop during I/O operations.

npm install @nestjs/winston winston

Buffering logs improvement

All logs will be buffered until the custom logger is attached

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import { Logger } from 'nestjs-pino';

async function bootstrap() {
  const app = await NestFactory.create(AppModule, { bufferLogs: true });
  app.useLogger(app.get(Logger));

  await app.listen(3000);
}

bootstrap();

Request-Scoped injection - @Injectable({ scope: Scope.REQUEST })

is a design pattern used in Dependency Injection (DI) frameworks like NestJS, where a service is instantiated once per incoming request

BENEFICIAL Request-Scoped Injection -- Isolation = more safe -- Concurrency Safety = no risk of shared mutable state -- Lifecycle Management = simplify memory management

Although it all sounds quite intimidating, a properly designed application that leverages request-scoped providers should not slow down by more than ~5% latency-wise.

NO BENEFITIAL Transactional Services: Logging or Metrics Collection

Increased Resource Consumption: Each request creates a new instance of the service, which can lead to increased memory usag

Performance Impact: The overhead of instantiating services for each request can impact performance

While Nest tries to cache as much metadata as possible, it will still have to create an instance of your class on each request. This approach means that I will be instantiating a new instance SomeBrokenLoggingService for each request, that would impact my application performance

While this is useful for isolating, it adds "significant overhead" since each request requires creating, managing, and destroying service instances.

In NestJS, you can define a service as request-scoped, meaning a new instance of the service is created for every request. This Negatively impact performance because it creates a new instance of the service for every incoming request

@Injectable({ scope: Scope.REQUEST })
export class SomeBrokenLoggingService {
  // A new instance will be created for every request
  constructor(@Inject(REQUEST) private request: Request) {}
}

Alternative Approaches
use Async Local Storage (ALS):
AsyncLocalStorage is a NodeJS API that allows you to store and retrieve context for the duration of a specific request, making it ideal for tracking request-specific data like correlation IDs without creating new service instances.

import { AsyncLocalStorage } from 'async_hooks';

const asyncLocalStorage = new AsyncLocalStorage();

app.use((req, res, next) => {
  asyncLocalStorage.run(new Map(), () => {
    // Set UserID for the request
    asyncLocalStorage.getStore().set('UserId', generateUserId());
    next();
  });
});

// Retrieve UserId ID within a service
const UserId = asyncLocalStorage.getStore().get('UserId');

LINK
https://docs.nestjs.com/fundamentals/injection-scopes#performance

Use Fastify instead ExpressJS

NestJS comes by default with Express platform, but it can be easily switched to Fastify, and the documentation did a great job explaining it on the "Performance (Fastify)" page

Fastify is a fast and low memory overhead web framework for NodeJS, built with a focus on high performance and low memory usage.

While ExpressJS remains the default option for most NestJS applications, Fastify offers superior performance, lower memory usage, and built-in features like JSON schema validation and logging.

Why Low-memory overhead: Processes requests faster than many other frameworks (like Express) due to its low-overhead design: Fastify is known for using less memory than Express, which is important in environments with constrained resources or applications that handle a high number of concurrent requests.

Built-in Logging:
Fastify has built-in high-performance logging using the pino logger. Logging is asynchronous by default, reducing the performance hit caused by I/O operations, something ExpressJS does not handle as efficiently without additional configuration.

Async/Await First:
Fastify is designed around async/await, making it more modern and easier to use in newer JavaScript/TypeScript projects, Express does not.

npm install @nestjs/platform-fastify fastify

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import {
  FastifyAdapter,
  NestFastifyApplication,
} from '@nestjs/platform-fastify';

async function bootstrap() {
  const app = await NestFactory.create<NestFastifyApplication>(
    AppModule,
    new FastifyAdapter(),
  );
  await app.listen(3000);
}
bootstrap();

LINK NestJS Performance: Fastify https://docs.nestjs.com/techniques/performance#performance-fastify

Avoiding NestJS performance bottlenecks
https://medium.com/@Fcmam5/avoiding-nestjs-performance-bottlenecks-78fa2bc66372

Optimize Your NestJS App Performance With These Practices
https://www.brilworks.com/blog/optimize-your-nest-js-app-performance-with-these-practices/

Use NodeJS compression middleware

The compression package helps to compress HTTP responses, which can significantly improve performance, particularly for large files such as HTML, CSS, and JS

Compress will help to maintain minimal data transfer during client interactions reducing the payload

With compression enabled, responses from your NestJS App will be compressed before they are sent to the client, reducing the amount of data that needs to be transferred over the network and improving performance.

Now, by default, the compression() middleware will use the gzip compression algorithm. You can also pass in options to customize the behavior of the middleware, such as the threshold at which responses will be compressed, using the following syntax:

app.use(compression({
    threshold: 512 // set the threshold to 512 bytes
}));

npm i --save compression

// This setup will compress responses sent from both your Angular and NestJS API
import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import * as compression from 'compression';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  // Enable compression middleware
  app.use(compression());

  await app.listen(3000);
}
bootstrap();

Caching Strategies

NodeJS itself DOESNT provide built-in caching mechanisms (but it can be built), fortunately NestJS does provide CacheModule

1. In-Memory Caching = `CacheModule.register({`

Like Post-it notes on your computer screen, it's quick to write and read, but disappears when you shut down

Stores cache data in memory, local to the current instance of the application.

NestJS provides a built-in CacheModule, which can be configured for in-memory caching using libraries like node-cache or redis for distributed caching.

import { CacheModule, Module } from '@nestjs/common';

@Module({
  imports: [
    CacheModule.register({
      ttl: 5, // seconds
      max: 10, // maximum number of items in cache
    }),
  ],
})
export class AppModule {}

2. Redis-based Caching (Distributed) = CacheModule.register({ store: redisStore,

Provides distributed caching, ideal for scalable applications behind load balancers.

to persist the cache across multiple instances or services

import { CacheModule, Module } from '@nestjs/common';
import * as redisStore from 'cache-manager-redis-store';

@Module({
  imports: [
    CacheModule.register({
      store: redisStore,
      host: 'localhost',
      port: 6379,
      ttl: 600, // seconds
    }),
  ],
})
export class AppModule {}

3. Browser HTTP Caching with Headers - 'Cache-Control':

import { Controller, Get, Res } from '@nestjs/common';
import { Response } from 'express';

@Controller('products')
export class ProductsController {
  @Get()
  findAll(@Res() response: Response) {
    // Setting HTTP cache headers
    response.set({
      'Cache-Control': 'public, max-age=3600', // cache for 1 hour
    });
    response.send({ products: [...] });
  }
}

4. Proxy Caching

Caches requests and responses at the proxy level to reduce the load on the server and speed up response times.

Caching can also be handled at the reverse proxy level

The reverse proxy caches responses and serves them from its cache to improve performance.

5. Db Query Caching

More like a pocket notebook, this type of cache is stored in the database and is a bit more permanent

TypeORM can cache database queries to reduce the load on your database server

Caches the results of frequently queried database data to minimise database load.

const cachedResults = await this.productRepository.find({
  cache: true,
});

6. Caching environment variables at runtime = ConfigModule()

If we have a lot of frequent accesses to environment variables, we want to optimise the retrival of configuration data

In a NestJS application, environment variables are commonly accessed through the ConfigService, which is used to retrieve configuration settings such as database credentials, API keys, and other sensitive information. Since accessing process.env can be relatively slow when done repeatedly, enabling caching can improve performance.

Improved Performance: Reduces the overhead of accessing environment variables multiple times, which can lead to performance bottlenecks.

import { ConfigModule } from '@nestjs/config';

@Module({
  imports: [
    ConfigModule.forRoot({
      cache: true, // Enable caching for better performance
    }),
  ],
})
export class AppModule {}

LINK
https://docs.nestjs.com/techniques/configuration#cache-environment-variables
1. Caching storage cache-manager

This cache manager offers a unified interface that supports various cache storage providers beyond just the default in-memory option.

import { Module } from '@nestjs/common';
import { CacheModule } from '@nestjs/cache-manager';
import { AppController } from './app.controller';

@Module({
  imports: [CacheModule.register()], // enable in-memory caching
  controllers: [AppController],
})

export class AppModule {}

npm install @nestjs/cache-manager cache-manager

LINK
https://docs.nestjs.com/techniques/caching

8. Caching Server Side External API Calls to Reduce Latency

Cache external API responses to reduce response times and API call frequency, improving performance.

We can significantly reduce latency and improve overall performance: In-Memory Caching with NodeJS: cache-manager, node-cache, redis, etc

npm install @nestjs/cache-manager cache-manager
npm install cache-manager-redis-store --save # Only if using Redis
npm install redis --save # Redis client

@Module({
  imports: [
    CacheModule.register({
      ttl: 60, // Time to live in seconds
      max: 100, // Maximum number of items in cache
    }),
    HttpModule, // Import HttpModule to make HTTP requests
  ],
  providers: [AppService],
})

@Injectable()
export class AppService {
  constructor(private readonly httpService: HttpService) {}
  @Cacheable({ key: 'externalApi' }) // Use caching for this method
  async getExternalData(): Promise<any> {
    const response = await firstValueFrom(this.httpService.get('https://api.example.com/data'));
    return response.data;
  }

9. Redis CacheInterceptor Global implementation

: Think of this as taking a screenshot of a web page to quickly look at it later without reloading the entire thing

NestJS's built-in CacheInterceptor allows automatic caching of responses based on decorators or globally for all requests.

11. HTTP caching with @CacheKey and @CacheTTL

NestJS also provides decorators such as @CacheKey() and @CacheTTL() that offer more granular
control over caching at the method level. These can be particularly useful for caching the results of
specific API calls.

import { Controller, Get } from '@nestjs/common';
import { CacheKey, CacheTTL } from '@nestjs/common';
@Controller('data')
export class DataController {
 @Get()
 @CacheKey('my-custom-key')
 @CacheTTL(300)
  findAll() {
    return this.dataService.findAll();
 }
}

• @CacheKey: Assigns a custom key to the cached response, which can be useful when you
need to cache similar data under different contexts
• @CacheTTL: Overrides the default TTL, allowing you to specify how long the result of this
specific method should be cached
This level of control ensures that only the most critical data is cached, reducing unnecessary cache
pollution and ensuring that your cache is as effective as possible.

12. Cache busting

Caching is powerful, but stale data can be a significant drawback if not managed properly. Cache
busting refers to the process of invalidating or refreshing the cache when the underlying data changes.
In NestJS, you can manually clear the cache when necessary using the CacheManager service:

import { CacheService } from '@nestjs/common';
@Injectable()
export class MyService {
 constructor(private cacheManager: CacheService) {}
 async updateData() {
 // Update data logic
Profiling and load testing 529
 await this.cacheManager.del('my-custom-key');
 }
}

This method removes the cached data associated with the specified key, ensuring that the next request
retrieves fresh data. Using cache-busting strategies ensures that your users always receive up-to-date information without
sacrificing the performance benefits of caching.

database schema synchronise

database schema should be auto created on every application launch

synchronise ensures that out TypeORM entitites will be sync with the DB every time we run our App

This is GREAT for development, BUT disable this on Production!

   TypeOrmModule.forRoot({
      type: 'postgres',
      host: 'localhost',
      port: 5432,
      username: 'postgres',
      password: 'password',
      database: 'postgres',
      autoLoadEntities: true,
      synchronize: true, // disable in Prod
    }),

// test postgres
psql -U postgres -d postgres

[Nest] 18032  - 27/09/2024, 16:04:39     LOG [InstanceLoader] TypeOrmModule dependencies initialized +181ms
...
[Nest] 18032  - 27/09/2024, 16:04:39     LOG [InstanceLoader] TypeOrmCoreModule dependencies initialized +127ms

Define to the Module Class which repository to use

Define to the Module Class which repository to use

We need to specify to the Module class, we are working which repository to use in the current scope (the product module's scope).

By doing so, we are telling the ProductModule module which repository we need for this scope.
NestJS does this to avoid having to load all the repositories present in the project, which would impact
the app's overall performance

// products/products.module.ts
@Module({
 imports: [TypeOrmModule.forFeature([Product]), CommonModule],
 // ...
)}
export class ProductsModule {}

Use Lazy-loading:route-based lazy loading + Dynamic module loading

Lazy loading is a powerful design pattern that delays the initialization of resources until they are actually needed. Then it will be cache and any consecutive invocation will be very fast

Rather than loading all objects at once, it allows the application to load the necessary data.

Routing Level: lazyModuleLoader route-based lazy loading

LOading a Module from RouterModule

import { Module } from '@nestjs/common';
import { RouterModule } from '@nestjs/core';

@Module({
  imports: [
    RouterModule.register([
      {
        path: 'lazy',
        loadChildren: () => import('./lazy/lazy.module').then(m => m.LazyModule),
      },
    ]),
    // other imports
  ],
  // controllers, providers
})
export class AppModule {}

Dynamic module loading within a service

// app.controller.ts
import { Controller, Get } from '@nestjs/common';
import { LazyModuleLoader } from '@nestjs/core';
import { ReportsModule } from './reports/reports.module';
import { ReportsService } from './reports/reports.service';

@Controller()
export class AppController {
  constructor(private readonly lazyModuleLoader: LazyModuleLoader) {}

  @Get()
  async getLazyReport(): Promise<string> {
    // use console.time() and console.timeEnd() 
    //to get the initialization time of ReportsModule
    console.time();
    const moduleRef = await this.lazyModuleLoader.load(() => ReportsModule);
    const reportsService = moduleRef.get(ReportsService);
    console.timeEnd();
    return reportsService.getReport();
  }
}

-LINK
https://docs.nestjs.com/fundamentals/lazy-loading-modules
https://medium.com/@Abdelrahman_Rezk/lazy-loading-in-nestjs-boosting-performance-and-efficiency-2c6350a6ab84
https://blog.devgenius.io/mastering-lazy-loading-in-nestjs-enhancing-application-performance-863612abaea0

Database Query Optimisation

Optimize database queries effectively

1. Minimize the Number of Queries: Problem: If you make multiple small queries to the database for each part of your logic, you can introduce performance bottlenecks. Each query adds network latency, processing overhead, and can overwhelm the database with many individual requests.

SOLUTION:
Use Batch Queries:
Instead of making multiple separate queries, you can batch them together. This reduces the round trips between your server and the database.

For example, in NestJS using TypeORM, you can retrieve all the required data in a single query using joins or relations, rather than multiple separate queries.

// TypeORM
const usersWithPosts = await this.userRepository.find({
  relations: ['posts'], // Fetches users along with their related posts in a single query
});

2. Use ORM Streaming Capabilities:

Problem: When dealing with large datasets, retrieving all data at once can overwhelm both the server's memory and the database. Loading huge result sets in one go can slow down the system significantly.

SOLUTION:
TypeORM can help: Use streaming to fetch data in chunks or pagination to limit number of resuts or cursor-based fetching to load data incrementally

3. Reduce the Amount of Data Fetched:

Problem:
Fetching all columns or related data when you only need a subset can unnecessarily overhead the database and increase the response time.

Solution:
Fetch only the necessary data
Retrieve only the necessary fields or rows using selective querying

For example, if you only need a user's name and email, don't fetch the entire user object.

// TypeORM
const userNames = await this.userRepository.find({
  select: ['name', 'email'], // Fetch only the fields you need
});

4. Leverage Database Indexing:

Problem:
When the database has to scan all rows in a table to find matching results (a full table scan), performance decreases significantly, especially with large datasets.

Solution:
Leverage indexing
Use indexes to make querying faster by creating indexes on columns that are frequently used in WHERE clauses or joins. Indexes allow the database to find matching rows faster without scanning the entire table.

5. Avoid N+1 Query Problem:

PROBLEM
The N+1 query problem happends when you first fetch a list of entities (eg N users), and then for each user, you make an additional query to fetch related data (eg their posts). This results in N+1 total queries, leading to performance issues and increases load times

SOLUTION:
Avoid the N+1 query problem by using eager loading or joins to retrieve related data in a single query, reducing the number of queries. We can use TypeORM to do these.

// TypeORM
// Instead of fetching users first and then fetching posts in separate queries
const usersWithPosts = await this.userRepository.find({
  relations: ['posts'], // Fetch users and their posts in one query
});

6. Caching query results

Temporarily storing the results of expensive database queries, and later Serve Cached Results

Handling Malicious Request Data

-- Validate DTO

NestJS automaticly validate, whitelist and STOP DTOs requests

npm i class-validator class-transformer

// main.ts
app.useGlobalPipes(new ValidationPipe());

// .dt.ts
// validate
import {IsString} from 'class-validator';

export class CreateCoffeeDto {
  @IsString()
    readonly name: string;

  @IsString()  
    readonly brand: string;

  @IsString({ each: true })
    readonly flavors: string[];
}

-- whitelist

// main.ts
// whitelist
  app.useGlobalPipes(new ValidationPipe(
    {whitelist: true,}
  ));

-- forbidNonWhiteListed

// main/ts
app.useGlobalPipes(new ValidationPipe(
    {
        whitelist: true,
        forbidNonWhitelisted: true,
    }
));

-- PartialType

Avoid redundant CRUD code

npm i @nestjs/mapped-types

// udpate.dto.ts
import {PartialType} from '@nestjs/mapped-types'
import {CreateCoffeeDto} from '../create-cofee.dto/create-cofee.dto'

export class UpdateDto extends PartialType(CreateCoffeeDto) {}

Implement WebWorkers - WW

web workers enable multitasking and can run without interfering with the main event loop.

Web Workers are a way to run scripts in a separate thread from the main thread of a web application.

NestJS provides built-in support for Web Workers through the worker_threads module that comes with NodeJS

Web workers can be a powerful tool for improving the performance and scalability of web applications, especially for long-running or computationally-intensive tasks

// worker.js
const { parentPort } = require('worker_threads');

parentPort.on('message', (message) => {
  console.log(`Worker thread received message: ${message}`);
  parentPort.postMessage(`Worker thread received message: ${message}`);
});

// app.controller.ts
// This will start the NestJS application and create a new worker thread to the root endpoint
import { Controller, Get } from '@nestjs/common';
import { Worker } from 'worker_threads';

@Controller()

export class AppController {
  @Get()
  async getHello(): Promise<string> {
    return new Promise((resolve) => {
      const worker = new Worker('./../worker.js');
      worker.on('message', (message) => {
        console.log(`Main thread received message: ${message}`);
        resolve(message);
      });
      worker.postMessage('Hello from main thread!');
    });
  }
}

Implement WebSockets - WS

NestJS provides a built-in module, "@nestjs/platform-socket.io", for Socket.IO-based applications

We can create real-time-communication, WebSocket gateways, handle events, and manage connections directly within your NestJS application. It handles the underlying Socket.IO implementation, making it easier to work with real-time data.

Implement true Load balancing across multiple servers

from native but basic NodeJS Clustering -> true: Cloud-based Load Balancer + Reverse Proxy

Load balancing is a technique of evenly distributing incoming network traffic among multiple servers to prevent any single server from becoming overloaded

-- 1. NodeJS Clustering

Although not a full load balancer, NodeJS itself provides a way to distribute requests across multiple processes using the clustering module. NestJS, being built on top of NodeJS, supports this natively.

NodeJS clustering can help implement load balancing, but it operates in a more limited capacity compared to traditional load balancers

--- Distribution limitation

As requests come in a new instance is created and assigned to different worker, helping to utilise CPU cores efficiently. This is limited to the resources of a single machine. It CANNOT distribute requests "across multiple servers or containers" for a true load balancing across multiple servers we need: Cloud-based Load Balancer + Reverse Proxy

--- 2. Clouds Load Balancers

Cloud load balancers often come with built-in scalability features and can easily handle failover and health checks.

Combining (Azure) Cloud Load Balancers + Reverse Proxy = is a common and effective approach to managing traffic in cloud-based applications. This architecture can help you achieve a scalable, reliable, and performant application.

--- 3. Reverse Proxy

A common approach it to use a reverse proxy in your NestJS application with ExpressJS, you can implement load balancing effectively

npm install --save @nestjs/platform-express http-proxy-middleware

// The reverse proxy is mounted on the /api path, so any incoming requests to /api will be forwarded to one of the upstream servers.
import { NestFactory } from '@nestjs/core';
import { ExpressAdapter } from '@nestjs/platform-express';
import { AppModule } from './app.module';
import * as express from 'express';
import { createProxyMiddleware } from 'http-proxy-middleware';

async function bootstrap() {
  const server = express();
  const app = await NestFactory.create(
    AppModule,
    new ExpressAdapter(server)
  );

  const servers = [
    { target: '<http://localhost:3001>' },
    { target: '<http://localhost:3002>' }
  ];

  servers.forEach(server => {
    server.use('/api', createProxyMiddleware({
      target: server.target,
      changeOrigin: true,
      pathRewrite: { '^/api': '' }
    }));
  });

  await app.listen(3000);
}

bootstrap();

// Start the reverse proxy server:
node server.js

// Start the upstream servers:
// This will start two upstream servers on ports 3001 and 3002.
// That's it. You now have a reverse proxy load balancer that will distribute incoming traffic across multiple servers using ExpressJS in NestJS.
node server1.js
node server2.js

Choose the most appropriate Dependency Injection Library

NestJS provides built-in support for dependency injection (DI), however, you can look beyond in-build options and use other DI libraries.
There are several popular DI libraries that are compatible with NestJS, including: InversifyJS, Awilix, TypeDI, tsyringe

Conclusion:

Fastest Option: tsyringe is likely the fastest due to its lightweight design and simplicity, making it ideal for performance-critical applications.
Balanced Performance and Features: Awilix is also very fast and strikes a good balance between simplicity and the features it offers.
For Advanced DI Needs: If you need more flexibility and advanced DI features, InversifyJS and TypeDI are great choices, though they come with slightly more overhead.
If raw performance is your top priority, tsyringe would be the best choice

API Architecture performance

-- 1. API Composition pattern (efficient Microservice Communication)

We have a high latency because of multiple network calls being made from client, to get the data from different backend services. This Pattern is particularly helpful when you are dealing with multiple microservices that need to be composed into a single API response.

Esentially API Composer acts as a gateway or orchestrator that manages and distributes requests to different API services, especially in microservice architectures.

-- 2. API caching using Redis

Using Redis for API Caching in NestJS

CacheModule.register({
  store: redisStore,
  host: 'your-redis-hostname.redis.cache.windows.net',
  port: 6380, // default SSL port for Azure Redis
  password: 'your-redis-access-key',
  ttl: 300, // seconds
  db: 0,
  ssl: true, // Enable SSL for Azure Redis
}),

Metric for insights

Consider the following metrics to get useful insights on your application's state:

• Logging and monitoring: Keep an eye on your application metrics. Tools such as Grafana and Prometheus can give you insights that are crucial for scaling.
• Performance metrics: Response times, error rates, and other key performance indicators (KPIs) should be monitored to understand how well your application is scaling.
• Monitor with NestJS DevTools and profilers: Use NestJS DevTools or integrated APM solutions, such as Jaeger or Zipkin, to monitor the performance of your services. These tools can provide insights into inter-service communication, response times, and bottlenecks

// visualize real-time performance metrics and identify areas where communication delays are occurring
npm install --save @nestjs/terminus @nestjs/devtool

Documenting your API

--- Key components of effective API documentation

Overview of the API: Start with a high-level overview of what the API does, its main features,
and its potential use cases.

• Authentication and authorization: Clearly explain how clients should authenticate and authorise with your API. Include any keys or tokens they might need.
• Endpoint descriptions: Each endpoint should be thoroughly documented with its purpose, URI, required headers, request and response formats, and any query or path parameters.
• Error codes and messages: Document common error responses and what they mean to help users troubleshoot issues.
• Examples and use cases: Provide practical examples of requests and responses. Real-world scenarios or use cases can significantly enhance understanding.

Adding Swagger annotations to DTOs and entities

To enhance your API documentation using Swagger in NestJS, you can use the @ApiProperty decorator from the @nestjs/swagger package. This decorator allows you to add metadata to your DTOs (Data Transfer Objects) and entities, making your API documentation more descriptive and user-friendly

--- Key Benefits of Using Swagger Annotations:
• Improved API Documentation: Clearly describe your API endpoints, request/response structures, and expected behavior.
• Interactive Testing: Swagger UI allows developers to test API endpoints directly from the documentation
• Consistency: Ensures that your API documentation stays in sync with your codebase.
• Onboarding: Makes it easier for new developers to understand and use your API

// Install @nestjs/swagger
npm install @nestjs/swagger

// Add Swagger Decorators to DTOs
export class CreateUserDto {
  @ApiProperty({
    description: 'The email address of the user',
    example: 'user@example.com',
  })
  @IsEmail()
  email: string;

  @ApiProperty({
    description: 'The password of the user',
    example: 'password123',
    minLength: 8,
  })
  @IsString()
  @MinLength(8)
  password: string;

  @ApiProperty({
    description: 'The full name of the user',
    example: 'John Doe',
    required: false,
  })
  @IsString()
  fullName?: string;
}

// Add Swagger Decorators to Entities
@Entity()
export class User {
  @ApiProperty({
    description: 'The unique identifier of the user',
    example: 1,
  })
  @PrimaryGeneratedColumn()
  id: number;

  @ApiProperty({
    description: 'email address of the user',
    example: 'user@example.com',
  })
  @Column()
  email: string;

  @ApiProperty({
    description: 'The full name of the user',
    example: 'John Doe',
  })
  @Column()
  fullName: string;

  @ApiProperty({
    description: 'The date the user was created',
    example: '2023-10-01T12:00:00Z',
  })
  @Column()
  createdAt: Date;
}

// Document API Endpoints in Controllers
@ApiTags('users') // Groups endpoints under "users" in Swagger UI
@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Post()
  @ApiOperation({ summary: 'Create a new user' })
  @ApiBody({ type: CreateUserDto })
  @ApiResponse({
    status: 201,
    description: 'The user has been successfully created.',
    type: User,
  })
  @ApiResponse({ status: 400, description: 'Bad Request.' })
  async create(@Body() createUserDto: CreateUserDto): Promise<User> {
    return this.usersService.create(createUserDto);
  }

  @Get(':id')
  @ApiOperation({ summary: 'Get a user by ID' })
  @ApiParam({ name: 'id', description: 'User ID', example: 1 })
  @ApiResponse({
    status: 200,
    description: 'The user has been successfully retrieved.',
    type: User,
  })
  @ApiResponse({ status: 404, description: 'User not found.' })
  async findOne(@Param('id') id: number): Promise<User> {
    return this.usersService.findOne(id);
  }
}

// main.ts
// Swagger configuration
import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import { SwaggerModule, DocumentBuilder } from '@nestjs/swagger';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  // Swagger configuration
  const config = new DocumentBuilder()
    .setTitle('User Management API')
    .setDescription('API for managing users')
    .setVersion('1.0')
    .addTag('users')
    .build();
  const document = SwaggerModule.createDocument(app, config);
  SwaggerModule.setup('api', app, document);

  await app.listen(3000);
}
bootstrap();

Recomendations

Last but no least, I recommend you to read the great book: Scalable Application Development with NestJS, by (Pacifique Linjanaja)

💯 Thanks!

Now, don't be an stranger. Let's stay in touch!

🔘 gitroll: LeoLanese

🔘 Linkedin: LeoLanese

🔘 Twitter: @LeoLanese

🔘 Portfolio: www.leolanese.com

🔘 DEV.to: dev.to/leolanese

🔘 Blog: leolanese.com/blog

🔘 Questions / Suggestions / Recommendations: `developer@leolanese.com` email me: developer@leolanese.com

Engineering in the AI age

Leo Lanese — Mon, 27 Jan 2025 11:07:54 +0000

As a software developer with over 15 years of experience, I can appreciate the tangible benefits of AI. From Googling errors, to browsing Stack Overflow, Reddit threads, and more, we now have AI-powered IDE assistants that help resolve issues across a vast range of programming languages and paradigms—seemingly without limits.

Having an IDE "assistant" that advises you in real-time on strategies to choose, paths to follow, and best practices to adhere to is a game-changer. However, there's a catch: AI, while incredibly helpful, can sometimes suggest too many things. Its capacity is enormous, and it often provides solutions too quickly, leaving us with little time to process the ideas before blindly accepting them.

The Challenge of Too Many Suggestions

While having numerous suggestions is great and saves time, it can also be overwhelming. If you don't fully understand why these suggestions are being made, how can you decide which option is the best? You risk ending up with a "blind solution" code that you don't fully comprehend or control. This lack of understanding can escalate into deploying solutions that operate in the "unknown zone," where the scope and impact of our changes are unclear.

The Issue of Quick Suggestions

Quick suggestions are fantastic, especially at first. After all, our goal is to solve problems efficiently. However, the danger lies in skipping the critical steps of understanding the problem, comprehending the solution, and learning from the resolution. Without this process, you're not truly learning you are just finding "quick fixes". Over time, this can lead to a lack of growth and a "AI dependency" to do the thinking for (or over) us.

Conclusion

In the past, developers would deeply think, investigate previous similar solutions, and debate the best approaches before settling on a well-voted or widely accepted answer.

Today, we often assume that AI will immediately provide the best solution without requiring our own investigation or critical thinking. Consequently, generating a long term dependency.

AI is, with no doubt, here to stay, and as software developers, we must adapt and evolve to thrive in this new modern AI-driven era.

However, we must also remain "mindful and curious". As, while AI can be an incredible tool, it should complement our skills and knowledge—not replace them. The key is to strike a balance: leveraging AI's power while ensuring "we maintain control, deepen our understanding, and continue to grow as developers". By doing so, we can harness the benefits of AI without losing the "critical thinking" and "problem-solving skills" that define great software engineering.

💯 Thanks!

Now, don't be an stranger. Let's stay in touch!

🔘 Linkedin: LeoLanese

🔘 X/Twitter: @LeoLanese

🔘 Portfolio: www.leolanese.com

🔘 DEV.to: dev.to/leolanese

🔘 Blog: leolanese.

Angular (17+) Signals Theme

Leo Lanese — Tue, 13 Feb 2024 12:20:53 +0000

Angular Signal as Reactive theme

Signals Rule! Re-imagine Dynamic Theming with Angular Signals
Dynamic Themes, Simplified: The Power of Angular Signals. Upgrade easily your theming game to Reactive Style Changes with Angular Signals
Simplify and Enhance Your Styling: Go Reactive with Angular Signals. Boost Theme Flexibility: Leverage Angular Signals for Dynamic Styling

Goal

Streamlined Service: Leveraging Angular Signals, we simplified our service by employing the signal function to create a theme signal, eliminating the necessity for a BehaviorSubject.
Reactive Theme Switching: Within the component, we now have direct access to the theme through the signal. This guarantees that our component template promptly responds to any changes in the theme.
Coordinated State Access: Using themeService.themeSignal(), we can directly retrieve the current theme, ensuring seamless synchronization of the theme state throughout the application.

Demo

Angular Signal Theme

Code (Github)

Angular Signal Theme

💯 Thanks!

Now, don't be an stranger. Let's stay in touch!

🔘 Linkedin: LeoLanese

🔘 Twitter: @LeoLanese

🔘 Portfolio: www.leolanese.com

🔘 DEV.to: dev.to/leolanese

🔘 Blog: leolanese.com/blog

🔘 Questions / Suggestion / Recommendation: developer@leolanese.com

Pull-Request Etiquette

Leo Lanese — Fri, 09 Feb 2024 16:46:45 +0000

Compendium of the best non-written code-review (Pull-Request or Merge-Request) etiquette rules

These rules encourage a collaborative and constructive approach to reviewing code within a team. The guidelines provide a helpful framework for effective communication during the code review process.

[Updated 14/02/2025]

Pull-Request structure

It is (highly) recommended to have one PR per commit Either squash your commits to a single commit or Amend the last commit every time you add a new commit.
Pull requests are not the place for (very) long architecture discussions: Focus on what's important.
Keep it simple: Small ticket = Small Pull-Requests.
Having tools like SonarQube, TSLint, Prettier, hooks, etc also helps to speed up PR/MR. These are tools to encourage best practices and security code that are already agreed to be used.

Pull-Request manners

Ownership of code: No one owns the code; the Company does.
Every pull request is an opportunity to share knowledge and demonstrate practical skills. Approach it with humility and openness to discussion.
Ask questions; don't make demands.
Conflicts are part of the job and will always exist: Solve conflicts as a Team. Avoid Ego.
Having tools like SonarQube, TSLint, Prettier, hooks, etc also helps to speed up PR/MR. These are tools to encourage best practices and security code that are already agreed to be used.
Explain your reasons with examples to simplify the suggested idea in advance while offering ways to simplify or improve.
Respond to every comment, be agile and pro-active, more importantly, look for a quick positive resolution.

Pull-Request persons envolved

We are all reviewers; we are invited to review, and we should and must act proactively.
Don't make it a teaching session.
Don't make it a blaming game.
Don't be too serious. Pull requests are an open "short" discussion with your team members.
Avoid passive-aggressive comments, always keep positive.
Don't use sarcasm, be polite and avoid using derogatory terms.
Be humble. Humility it is crucial in both submitting and reviewing code
Be grateful for the reviewer's suggestions. ("Nice Spotted! I'll make that change.")
Be understanding. Communication online (like using Slack) is complex, GitLab PR line is even harder.
Code reviewers should provide feedback, not to be a gatekeeper.

Pull-Request Conflicts

Your PR review is not about you.
Always keep in mind: assume the best intention from the reviewer's comments.
If the discussion on the pull-request is becoming long and doesn’t seem helpful for others, it is better to resolve it in-person, or in a different line, and close it with a summary on the pull-request.
Acknowledgment of Difficulty: Be aware of how hard it is to convey emotion online and how easy it is to misinterpret feedback. If a review seems aggressive or angry or otherwise personal, consider if it is intended to be read that way and ask the person for clarification of intent, in person if possible.
If you disagree strongly, consider giving it a few minutes before responding; think before you react.
Gratitude: Remember always please and thank-you as, even with or without conflicts, there is another co-workers giving us their time to approve a PR.
Whenever there's a disagreement, we should seek a third person's opinion.

Pull-Request Golden Rule

Pull requests should be dynamic and agile, quick and short chat to share knowledge.
Don't take it personally. The review is of the "code", "not of you".
It is not the reviewers' responsibility to test the code.

Code Reviews in the Age of AI

Human interaction: "I fear the day that technology will surpass our human interaction. The world will have a generation of idiots. - Albert Einstein"
Critical Thinking: AI can be a useful tool for catching errors, suggesting improvements, and ensuring consistency, but it shouldn't replace human judgment and critical thinking (please check an article about this: https://dev.to/leolanese/developing-in-the-ai-age-1k35)
AI as an Assistant, not a replacement: Use AI to speed up reviews but ensure human reviewers validate and discuss changes; otherwise, more than having false positive/negatives we miss the essence of the pull-request, which is the sharing and learning opportunity.
Transparency: Let contributors know if AI was used, so they can factor that into the discussion.
Balance: Encourage human judgment for complex refactors, architecture decisions, and deeper code understanding.

💯 Thanks!

Now, don't be a stranger. Let's stay in touch!

🔘 gitroll: LeoLanese

🔘 Linkedin: LeoLanese

🔘 Twitter: @LeoLanese

🔘 Portfolio: www.leolanese.com

🔘 DEV.to: dev.to/leolanese

🔘 Blog: leolanese.com/blog

🔘 Questions / Suggestions / Recommendations: `developer@leolanese.com` email me: developer@leolanese.com

🔘 Linkedin: LeoLanese

🔘 Twitter: @LeoLanese

🔘 Portfolio: www.leolanese.com

🔘 DEV.to: dev.to/leolanese

🔘 Blog: leolanese.

Angular (17+) + NodeJS Users Rest API

Leo Lanese — Fri, 09 Feb 2024 16:04:00 +0000

Angular + NodeJS Users Rest API. Full-Stack Development Workflow

Goal

Show the use of Angular services to consume local and remote end-points, provided localy by NodeJS & ExpressJS and remotly using JsonPlaceHolder Services. We will be using Angular (17+) with stand-alone component and services.

Fetching Users from my NodeJS (and ExpressJS) Rest API

// Front-End
🅰️ Creating an Angular app + Angular Material
 - Initialise GIT repo from GITHUB
 - Create APP:
    - ng new users-rest-api --style=scss
    - code .
    - cd /user-rest-api/npm start
🚉 Adding Angular Material UI
    - ng add @angular/material
🚙 Adding the HttpClient
    - mkdir services
    - cd src/app/services
    - ng g s API-user
    - mkdir models
    - cd src/app/services
    - ng g i users
    - using HTTP Client
🛴 Defining service & interface
    - user Interface (based on public API Service `https://jsonplaceholder.typicode.com/users`)
👥 Fetching & Displaying users

// Back-End
🧨 Endpoint Customisation
    - Moving out from `jsonplaceholder` to local NodeJS Rest API
    - mkdir rest-api-nodejs
    - cd rest-api-nodejs
✨ initialising NodeJS with ExpressJS 
    - npm init -y
    - npm i express
    - npm i morgan
    - npm i cors
    - notepad server.js (add content)
    - node --loader ts-node/esm server.mjs
    - Adjust the `package.json` from "type": "module" to use imports
    - Test API end-point: http://localhost:3000/users
🎇 Adding Image Source for Users
    - Using `RoboHash` for random images (https://robohash.org/${user.id}.png?set=set1&size=45x4)
    - Test App: http://localhost:4200/

Code

Angular-NodeJS-RestAPI

Local mock users locally to be served

// server.mjs
import express from 'express';
import cors from 'cors';

const app = express();
const PORT = 3000;

const users = [
  {
    "id": 1,
    "name": "Leanne Graham",
    "username": "Bret",
    "email": "Sincere@april.biz",
    "address": {
      "street": "Kulas Light",
      "suite": "Apt. 556",
      "city": "Gwenborough",
      "zipcode": "92998-3874",
      "geo": {
        "lat": "-37.3159",
        "lng": "81.1496"
      }
    },
    "phone": "1-770-736-8031 x56442",
    "website": "hildegard.org",
    "company": {
      "name": "Romaguera-Crona",
      "catchPhrase": "Multi-layered client-server neural-net",
      "bs": "harness real-time e-markets"
    }
  },
  {
    "id": 2,
    "name": "Ervin Howell",
    "username": "Antonette",
    "email": "Shanna@melissa.tv",
    "address": {
      "street": "Victor Plains",
      "suite": "Suite 879",
      "city": "Wisokyburgh",
      "zipcode": "90566-7771",
      "geo": {
        "lat": "-43.9509",
        "lng": "-34.4618"
      }
    },
    "phone": "010-692-6593 x09125",
    "website": "anastasia.net",
    "company": {
      "name": "Deckow-Crist",
      "catchPhrase": "Proactive didactic contingency",
      "bs": "synergize scalable supply-chains"
    }
  },
  {
    "id": 3,
    "name": "Clementine Bauch",
    "username": "Samantha",
    "email": "Nathan@yesenia.net",
    "address": {
      "street": "Douglas Extension",
      "suite": "Suite 847",
      "city": "McKenziehaven",
      "zipcode": "59590-4157",
      "geo": {
        "lat": "-68.6102",
        "lng": "-47.0653"
      }
    },
    "phone": "1-463-123-4447",
    "website": "ramiro.info",
    "company": {
      "name": "Romaguera-Jacobson",
      "catchPhrase": "Face to face bifurcated interface",
      "bs": "e-enable strategic applications"
    }
  },
  {
    "id": 4,
    "name": "Patricia Lebsack",
    "username": "Karianne",
    "email": "Julianne.OConner@kory.org",
    "address": {
      "street": "Hoeger Mall",
      "suite": "Apt. 692",
      "city": "South Elvis",
      "zipcode": "53919-4257",
      "geo": {
        "lat": "29.4572",
        "lng": "-164.2990"
      }
    },
    "phone": "493-170-9623 x156",
    "website": "kale.biz",
    "company": {
      "name": "Robel-Corkery",
      "catchPhrase": "Multi-tiered zero tolerance productivity",
      "bs": "transition cutting-edge web services"
    }
  },
  {
    "id": 5,
    "name": "Chelsey Dietrich",
    "username": "Kamren",
    "email": "Lucio_Hettinger@annie.ca",
    "address": {
      "street": "Skiles Walks",
      "suite": "Suite 351",
      "city": "Roscoeview",
      "zipcode": "33263",
      "geo": {
        "lat": "-31.8129",
        "lng": "62.5342"
      }
    },
    "phone": "(254)954-1289",
    "website": "demarco.info",
    "company": {
      "name": "Keebler LLC",
      "catchPhrase": "User-centric fault-tolerant solution",
      "bs": "revolutionize end-to-end systems"
    }
  }
];

app.use(cors()); // Enable CORS for all routes

// Checking if the application is in development mode
// If it is, morgan middleware is added to the express application to log HTTP requests
if(process.env.MODE === 'development'){
  app.use(morgan('dev'))  
}

app.use(express.json());

app.get('/users', (req, res) => {
  res.json(users);
});

// Starting the express server and listening for connections on the specified port.
app.listen(PORT, (err) =>  
    (err) ? console.error(`Failed to start server: ${err}`) :  console.log(`Server running on: ${PORT}`)
);

This project was generated with Angular CLI version 17.0.9.

Development server

Run ng serve for a dev server. Navigate to http://localhost:4200/. The application will automatically reload if you change any of the source files.

Code scaffolding

Build

Run ng build to build the project. The build artifacts will be stored in the dist/ directory.

Running unit tests

Run ng test to execute the unit tests via Karma.

💯 Thanks!

Now, don't be an stranger. Let's stay in touch!

🔘 Linkedin: LeoLanese

🔘 Twitter: @LeoLanese

🔘 Portfolio: www.leolanese.com

🔘 DEV.to: dev.to/leolanese

🔘 Blog: leolanese.com/blog

🔘 Questions / Suggestion / Recommendation: developer@leolanese.com

Run ng e2e to execute the end-to-end tests via a platform of your choice. To use this command, you need to first add a package that implements end-to-end testing capabilities.

Further help

To get more help on the Angular CLI use ng help or go check out the Angular CLI Overview and Command Reference page.

Angular (17+) Reactive Forms + Signals & StandAlone Components

Leo Lanese — Thu, 08 Feb 2024 10:55:06 +0000

Angular (17+) Reactive-Forms with Signals and StandAlone Components

Code

GitHub / Angular Reactive Forms with Signals and StandAlon

Demo

StackBlitz / Angular Reactive Forms with Signals and StandAlone

Goal

Lets Create an standAlone component, with reactive-forms (https://angular.io/guide/reactive-forms) using Signals. In this example we use Angular Signals to represent form control values as signals. firstNameSignal is created using the toSignal function. Represents the value of the 'firstName' form control, so now, instead of manually subscribing to the valueChanges of the form control, we can directly use the signal in our template.

Using signals in a reactive form with Angular has several benefits

Efficient Updates

Signals allow you to represent form control values as signals. This means that only relevant components or parts of your application react to changes in form values. Instead of using traditional subscriptions where all changes trigger an update, signals provide a more efficient way to handle updates, especially in large and complex applications.

Seamless Integration with Reactive Forms

Angular Signals can seamlessly integrate with reactive forms, making it easy to represent the state of form controls as signals. This integration enhances the overall reactivity and performance of your forms.

Clearer Code Structure

Signals provide a clear and declarative way to handle updates in your application. By using signals, you can organise your code in a way that reflects the flow of data and updates, leading to cleaner and more maintainable code.

Simplified State Management

Angular Signals abstract away some of the complexities of state management. By representing form control values as signals, you can simplify the way your application handles and reacts to changes, making the code more readable and maintainable.

Improved Debugging

Signals make it easier to trace the flow of data and identify where updates are originating. This can be beneficial during debugging, as you have a clear structure for handling and responding to changes.

Easily apply RxJS Operators (Debouncing, Throttling, etc)

With signals, you can easily apply operators like debounceTime or throttleTime to control the rate of updates. This is particularly useful in scenarios where you want to delay the reaction to user input or prevent unnecessary updates.

Selective Rendering

Only the parts of your application that rely on a specific signal will update when its value alters. While not a virtual DOM like React, it does offer focused template updates. This means that when a signal changes, only the components or templates that depend on that particular signal will be re-rendered or updated. This is in contrast to a full re-render of the entire DOM, which can be more resource-intensive. Angular Signals achieves selective rendering by leveraging a reactive approach to data. When a signal is updated, Angular Signals intelligently identifies the parts of the application that are directly affected by that signal and updates only those parts, avoiding unnecessary updates to unrelated components.

In brief

Using Angular Signals in reactive forms enhances the reactivity, performance, and maintainability of your Angular applications by providing a streamlined way to handle updates and manage the state of form controls.

DEV Community: Leo Lanese

The Age of AI Isn't About Replacement. It's About Relevance

💯 Thanks!

🔘 linkedin: @LeoLanese

🔘 Twitter: @LeoLanese

🔘 DEV.to: Blog

🔘 Questions / Suggestion / Recommendation: developer@leolanese.com

AI is the Sous‑Chef, Not the Chef

💯 Thanks!

Now, don't be an stranger. Let's stay in touch!

🔘 linkedin: @LeoLanese

🔘 Twitter: @LeoLanese

🔘 DEV.to: Blog

🔘 Questions / Suggestion / Recommendation: developer@leolanese.com

The Miner and the Jeweler: Why AI Code Isn't Production-Ready

The Miner (LLM's) does the brutal, foundational work:

The Perfect Workflow is a Collaboration:

Conclusion:

💯 Thanks!

Now, don't be an stranger. Let's stay in touch!

🔘 linkedin: @LeoLanese

🔘 Twitter: @LeoLanese

🔘 DEV.to: Blog

🔘 Questions / Suggestion / Recommendation: developer@leolanese.com

The Great Compression: Why AI isn't Replacing Developers, It's Refining Them

💯 Thanks!

Now, don't be an stranger. Let's stay in touch!

🔘 linkedin: LeoLanese

🔘 X / Twitter: @LeoLanese

🔘 DEV.to: dev.to/leolanese

🔘 Blog: leolanese.com/blog

🔘 Questions / Suggestion / Recommendation: developer@leolanese.com

The Operator's Manual: Navigating Angular Signals from v17.3 to v21

The Operator's Manual: Navigating Angular Signals from v17.3 to v21

Table of Contents

Chapter 1: The Foundation (Angular 17.3) – Completing the Component API

1.1 Signal-Based Components: The Full Toolkit

1.2 Operating with output() and RxJS Interop

Chapter 2: Stabilization and Architecture (Angular 18–20) – Production Readiness

2.1 From Preview to Prime Time: Graduating to Stable

2.2 The Signal-Powered Service Pattern

2.3 Enabling the Zoneless Future

Chapter 3: The New Frontier (Angular 21 Experimental) – The Signal Ecosystem

3.1 Introducing Signal Forms: A Paradigm Shift

The core principles are:

3.2 Advanced Operations: Async Data and Linked State

Chapter 4: The Operator's Field Guide – Best Practices & Migration

4.1 Core Principles of Signal-Based Code

4.2 Upgrading Your Machinery & migrate: The Migration Path

4.3 Incrementally Migrate to Signal Forms:

4.4 Adopt signal components: Replace async pipes with direct signal calls.

4.5 Refactor services from BehaviorSubject to signals

Conclusion: A New Era of Angular Reactivity

References

Let's connect!

Signals & JS Event Loop: Rethinking Angular Reactive Sync

💯 Thanks!

Hey, don't be an stranger. Let's stay in touch!

🔘 Portfolio: www.leolanese.com

🔘 Linkedin: LeoLanese

🔘 Twitter: @LeoLanese

🔘 DEV.to: Tech Blog

🔘 Questions / Suggestion / Recommendation: developer@leolanese.com

NestJS Performance

Technique

Explanation

1. In-Memory Caching = CacheModule.register({

12. Cache busting

Define to the Module Class which repository to use

Conclusion:

💯 Thanks!

Now, don't be an stranger. Let's stay in touch!

🔘 gitroll: LeoLanese

🔘 Linkedin: LeoLanese

🔘 Twitter: @LeoLanese

🔘 Portfolio: www.leolanese.com

🔘 DEV.to: dev.to/leolanese

🔘 Blog: leolanese.com/blog

🔘 Questions / Suggestions / Recommendations: developer@leolanese.com email me: developer@leolanese.com

Engineering in the AI age

1.2 Operating with `output()` and RxJS Interop

1. In-Memory Caching = `CacheModule.register({`

🔘 Questions / Suggestions / Recommendations: `developer@leolanese.com` email me: developer@leolanese.com

🔘 Questions / Suggestions / Recommendations: `developer@leolanese.com` email me: developer@leolanese.com