DEV Community: Abanoub Kerols

OWASP Web Application Security: A Complete Developer Guide

Abanoub Kerols — Tue, 13 Oct 2026 21:09:03 +0000

Web application security is no longer something that should be handled only by dedicated security engineers. Modern developers are responsible for designing, implementing, and deploying applications that protect user data, business logic, credentials, infrastructure, and APIs.

This is where OWASP becomes extremely important.

The Open Worldwide Application Security Project (OWASP) provides open standards, documentation, methodologies, and tools that help developers understand and prevent common application security vulnerabilities.

This article provides a complete developer-oriented security roadmap covering OWASP fundamentals, HTTP and browser security, authentication, authorization, injection attacks, XSS, CSRF, API security, cryptography, database security, file uploads, SSRF, dependencies, security testing, Node.js/NestJS security, and production architecture.

1. Introduction to OWASP

What Is OWASP?

OWASP stands for the Open Worldwide Application Security Project.

It is a nonprofit organization focused on improving software security.

OWASP provides:

Security standards
Security testing methodologies
Developer guidelines
Security verification requirements
Vulnerability awareness
Security tools
Training materials
Security projects

One of the most famous OWASP resources is the OWASP Top 10, which describes major categories of web application security risks.

The important idea is:

OWASP is not a programming framework. It is a security knowledge and standards ecosystem.

OWASP Foundation

The OWASP Foundation supports open-source security projects and provides resources that developers, security engineers, architects, and organizations can use to improve application security.

Some important OWASP projects include:

OWASP Top 10
OWASP API Security Top 10
OWASP ASVS
OWASP Web Security Testing Guide
OWASP Dependency-Check
OWASP ZAP
OWASP Cheat Sheet Series

2. Vulnerability vs Threat vs Attack vs Risk

These terms are often confused.

Vulnerability

A vulnerability is a weakness in a system.

Example:

app.get('/users/:id', async (req, res) => {
    const user = await User.findById(req.params.id);
    res.json(user);
});

If the application does not verify that the current user is allowed to access that user ID, the application may contain an authorization vulnerability.

Threat

A threat is something that could potentially cause harm.

Examples:

Attacker
Malware
Stolen credentials
Malicious insider

Attack

An attack is the actual exploitation of a vulnerability.

For example:

Attacker
   ↓
Changes /users/100 to /users/101
   ↓
Server returns another user's data

Risk

Risk combines the likelihood and impact of a security problem.

A simplified model is:

Risk ≈ Likelihood × Impact

A vulnerability with low impact may be less urgent than a vulnerability that exposes passwords or financial information.

3. Security Mindset for Developers

Security should not be an afterthought.

Instead of asking:

"Does this feature work?"

Ask:

"How can this feature be abused?"

For every feature, think about:

Input
 ↓
Validation
 ↓
Authentication
 ↓
Authorization
 ↓
Business Logic
 ↓
Database
 ↓
Response
 ↓
Logging

For example, when implementing:

DELETE /api/users/123

Do not only ask:

Does the endpoint delete the user?

Ask:

Is the requester authenticated?
Is the requester authorized?
Can one user delete another user?
Can a normal user delete an admin?
Is the ID predictable?
Is the operation logged?
Is the request rate-limited?
Can the operation be replayed?
Is the response leaking information?

This mindset is one of the most important security skills a developer can develop.

4. HTTP and Browser Security Fundamentals

Understanding web security requires understanding how browsers communicate with servers.

A typical request looks like:

GET /api/profile HTTP/1.1
Host: example.com
Authorization: Bearer TOKEN
Cookie: sessionId=abc123

The server responds:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "name": "John"
}

Security problems can occur at every stage of this communication.

5. Cookies

Cookies allow servers to store small pieces of information in the browser.

Example:

Set-Cookie: sessionId=abc123

The browser automatically sends:

Cookie: sessionId=abc123

Important cookie attributes include:

HttpOnly

Set-Cookie: sessionId=abc123; HttpOnly

JavaScript cannot directly access the cookie.

This helps reduce the impact of some XSS attacks.

Secure

Set-Cookie: sessionId=abc123; Secure

The browser sends the cookie only over HTTPS.

SameSite

Set-Cookie: sessionId=abc123; SameSite=Lax

Controls when cookies are sent in cross-site requests.

Common values:

Strict
Lax
None

6. Sessions

A traditional session system works like:

Browser
   ↓
POST /login
   ↓
Server
   ↓
Create Session
   ↓
sessionId
   ↓
Cookie

The browser later sends:

Cookie: sessionId=abc123

The server looks up the session and identifies the user.

Sessions can be stored in:

Memory
Redis
Database

For distributed applications, Redis is commonly used for session storage.

7. Same-Origin Policy

The browser's Same-Origin Policy prevents websites from freely interacting with resources from other origins.

An origin consists of:

scheme + host + port

For example:

https://example.com:443

is different from:

http://example.com:80

and:

https://api.example.com

8. CORS

CORS stands for Cross-Origin Resource Sharing.

Suppose your frontend runs on:

https://frontend.example.com

and your API runs on:

https://api.example.com

The server can explicitly allow the frontend:

Access-Control-Allow-Origin: https://frontend.example.com

With Express:

app.use(cors({
    origin: 'https://frontend.example.com',
    credentials: true
}));

Avoid blindly doing:

origin: '*'

especially when credentials are involved.

9. CSRF

Cross-Site Request Forgery occurs when an attacker causes a victim's browser to send an authenticated request to another website.

Imagine:

Victim
  ↓
Logged into bank.com

The attacker creates a malicious website.

The victim visits it.

The malicious page attempts to trigger:

POST https://bank.com/transfer

If the browser automatically sends authentication cookies, the request may be authenticated.

CSRF defenses include:

SameSite cookies
CSRF tokens
Origin validation
Referer validation
Avoiding unsafe state changes through GET requests

10. OWASP Top 10

The OWASP Top 10 provides a high-level classification of important web application security risks.

The current 2025 OWASP Top 10 categories include:

Broken Access Control
Security Misconfiguration
Software Supply Chain Failures
Cryptographic Failures
Injection
Insecure Design
Authentication Failures
Software or Data Integrity Failures
Security Logging and Alerting Failures
Mishandling of Exceptional Conditions

The exact categories and terminology can evolve between OWASP editions, so developers should always verify the version they are using.

11. A01 — Broken Access Control

Broken access control occurs when users can perform actions they should not be allowed to perform.

Example:

GET /api/users/123

User A changes:

to:

and receives User B's data.

This is commonly known as:

IDOR — Insecure Direct Object Reference

and is closely related to BOLA — Broken Object Level Authorization.

The solution is not to hide IDs.

The server must enforce authorization.

if (resource.ownerId !== currentUser.id) {
    return res.status(403).json({
        message: 'Forbidden'
    });
}

12. Authentication vs Authorization

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

Example:

Login
 ↓
Authentication
 ↓
User = Abanoub
 ↓
Authorization
 ↓
Can Abanoub access this resource?

Never confuse the two.

13. RBAC

Role-Based Access Control assigns permissions based on roles.

Example:

User
Admin
Moderator
Manager

Example:

if (user.role !== 'admin') {
    return res.status(403).end();
}

A more scalable design uses permissions:

users:read
users:create
users:update
users:delete

Then roles map to permissions.

14. ABAC

Attribute-Based Access Control evaluates attributes.

For example:

User.department === Resource.department

and:

User.clearanceLevel >= Resource.requiredLevel

ABAC can model more complex business rules than simple RBAC.

15. Multi-Tenant Authorization

In SaaS applications, different organizations may use the same application.

For example:

Company A
 ├── Users
 ├── Projects
 └── Documents

Company B
 ├── Users
 ├── Projects
 └── Documents

A critical rule is:

Every resource query must enforce tenant isolation.

For example:

Project.findOne({
    _id: projectId,
    tenantId: currentUser.tenantId
});

Not:

Project.findOne({
    _id: projectId
});

16. Authentication Security

A secure authentication system requires more than a login form.

Important topics include:

Password hashing
Session management
Access tokens
Refresh tokens
Token rotation
Brute-force protection
Credential stuffing protection
Account enumeration protection

17. Password Hashing

Never store:

password123

in the database.

Do not use simple hashing such as:

crypto.createHash('sha256')

for password storage.

Password hashing should use dedicated password hashing algorithms such as:

Argon2
bcrypt

Example conceptually:

Password
   ↓
Argon2
   ↓
Password Hash
   ↓
Database

The hash should be computationally expensive enough to make large-scale guessing attacks more difficult.

18. bcrypt and Argon2

bcrypt is widely used and supported.

Argon2 is a modern password hashing algorithm designed to resist brute-force attacks, particularly attacks accelerated by specialized hardware.

The important principle is:

Password hashing is intentionally expensive.

19. JWT

A JSON Web Token contains claims such as:

{
  "sub": "123",
  "role": "user",
  "exp": 1780000000
}

The server signs the token.

The client sends:

Authorization: Bearer TOKEN

JWTs can be useful for stateless authentication, but they are not automatically secure simply because they are JWTs.

Security depends on:

Signing algorithms
Key management
Token expiration
Token storage
Token revocation strategy
Audience and issuer validation
Refresh token handling

20. Access Tokens and Refresh Tokens

A common architecture is:

Access Token
Short lifetime
       +
Refresh Token
Longer lifetime

For example:

Access Token → 10 minutes
Refresh Token → longer lifetime

When the access token expires:

Client
 ↓
Refresh Token
 ↓
Server
 ↓
New Access Token

Refresh tokens should be protected carefully.

21. Refresh Token Rotation

Instead of keeping one refresh token forever:

Refresh Token A
      ↓
Used
      ↓
Refresh Token B

The old token becomes invalid.

This helps detect token theft and replay.

A secure implementation can maintain refresh-token state in Redis or a database.

22. Account Enumeration

An application should avoid revealing whether an account exists.

Bad:

Email does not exist.

or:

Incorrect password.

depending on the supplied email.

A safer generic response might be:

Invalid email or password.

For password reset:

If an account exists, a reset email will be sent.

23. Brute Force and Credential Stuffing

Brute Force

An attacker repeatedly guesses passwords for one account.

Credential Stuffing

An attacker uses leaked username/password combinations from another service.

Defenses include:

Rate limiting
Login attempt throttling
MFA
Strong password policies
Breached-password detection
Monitoring
Device/risk detection

24. Injection Attacks

Injection occurs when untrusted input is interpreted as part of another language or command.

Examples:

SQL Injection
NoSQL Injection
Command Injection
LDAP Injection
Template Injection
XSS

The general rule is:

Never allow untrusted data to become executable syntax.

25. SQL Injection

Unsafe:

const query = `
    SELECT * FROM users
    WHERE email = '${email}'
`;

If user input becomes SQL syntax, the attacker may manipulate the query.

Use parameterized queries:

const result = await db.query(
    'SELECT * FROM users WHERE email = $1',
    [email]
);

ORMs can help, but they do not automatically eliminate every injection vulnerability.

26. NoSQL Injection

MongoDB applications can also suffer from injection when user-controlled objects are passed directly into database operations.

Never blindly trust:

req.body

as a database query.

Instead, validate and construct the query explicitly:

const user = await User.findOne({
    email: validatedEmail
});

27. Command Injection

Unsafe:

exec(`ping ${host}`);

If attacker-controlled input reaches the shell, the attacker may execute commands.

Prefer APIs that avoid shell interpretation.

For example, use argument arrays where appropriate:

spawn('ping', ['-c', '1', host]);

Even then, validate the input.

28. XSS

Cross-Site Scripting occurs when attacker-controlled content is executed as JavaScript in another user's browser.

There are three major types:

Reflected XSS
Stored XSS
DOM-based XSS

29. Reflected XSS

The malicious input is immediately reflected in the response.

Example concept:

/search?q=<malicious-input>

If the server inserts the value into HTML without proper encoding, the browser may interpret it as markup or script.

30. Stored XSS

The malicious payload is stored on the server.

For example:

User submits comment
       ↓
Database
       ↓
Another user opens page
       ↓
Payload executes

Stored XSS can be especially dangerous because one attacker-controlled value can affect many users.

31. DOM XSS

DOM XSS occurs when client-side JavaScript processes untrusted data unsafely.

Dangerous example:

element.innerHTML = userInput;

Safer:

element.textContent = userInput;

Frameworks such as Angular provide useful protections, but developers can still bypass those protections with unsafe APIs.

32. XSS Prevention

Important defenses include:

Output Encoding

Encode data according to its context:

HTML
Attribute
JavaScript
CSS
URL

Sanitization

When HTML must be accepted, sanitize it with a trusted sanitizer.

CSP

A Content Security Policy can reduce the impact of some XSS vulnerabilities.

HttpOnly Cookies

Sensitive cookies should generally use:

HttpOnly
Secure
SameSite

when appropriate.

33. Content Security Policy

A CSP controls which resources the browser is allowed to load or execute.

Example:

Content-Security-Policy:
default-src 'self';
script-src 'self';
object-src 'none';
base-uri 'self';

A strong CSP can significantly reduce the impact of XSS.

However, CSP should be treated as a defense-in-depth mechanism, not a replacement for secure coding.

34. CSRF Protection

Common defenses include:

SameSite Cookies

SameSite=Lax

or:

SameSite=Strict

depending on application requirements.

CSRF Tokens

The server generates a token.

The client sends it with state-changing requests.

X-CSRF-Token: RANDOM_VALUE

The server verifies it.

Double Submit Cookie

The application stores a CSRF token in a cookie and requires the client to submit the same value in a request parameter/header.

Origin Validation

The server can validate:

Origin: https://example.com

against trusted origins.

35. API Security

Modern applications heavily depend on APIs.

A secure API should implement:

Authentication
Authorization
Validation
Rate Limiting
Logging
Error Handling
Security Headers
Monitoring

36. Input Validation

Never assume API clients are trustworthy.

Validate:

Type
Length
Format
Range
Allowed values
Nested structures

Example:

{
    "age": 25
}

should not automatically become:

{
    "age": {
        "$gt": 0
    }
}

without proper validation.

37. Mass Assignment

Suppose your API expects:

{
  "name": "John"
}

but the client sends:

{
  "name": "John",
  "role": "admin"
}

If the server blindly persists the entire object, the user may escalate privileges.

Instead, explicitly select fields:

const update = {
    name: req.body.name
};

This is called an allowlist approach.

38. Excessive Data Exposure

Suppose the API returns:

{
  "id": 1,
  "name": "John",
  "email": "john@example.com",
  "passwordHash": "...",
  "internalNotes": "...",
  "isAdmin": true
}

The frontend may only need:

{
  "id": 1,
  "name": "John"
}

Return only the data required by the client.

39. Pagination Abuse

An endpoint like:

GET /users?limit=1000000

can consume large amounts of:

CPU
Memory
Database resources
Network bandwidth

Use limits:

Default limit = 20
Maximum limit = 100

40. API Rate Limiting

Rate limiting protects APIs against:

Brute force
Credential stuffing
DoS attempts
Expensive endpoint abuse
Excessive scraping

Example concept:

100 requests / minute / user

Sensitive endpoints should often have stricter limits.

41. Security Headers

Important security headers include:

Content-Security-Policy

Controls allowed resources.

Strict-Transport-Security

Forces browsers to use HTTPS.

Strict-Transport-Security: max-age=31536000; includeSubDomains

X-Content-Type-Options

X-Content-Type-Options: nosniff

Referrer-Policy

Controls how much referrer information is sent.

Referrer-Policy: strict-origin-when-cross-origin

Permissions-Policy

Controls access to browser features.

Frame Protection

Modern applications commonly use CSP:

frame-ancestors 'none'

to prevent unwanted framing.

42. Cryptography

Cryptography has several different purposes.

Do not confuse:

Encryption
Hashing
Encoding
Signing

43. Encryption vs Hashing

Encryption is reversible:

Plaintext
   ↓
Encryption
   ↓
Ciphertext
   ↓
Decryption
   ↓
Plaintext

Hashing is designed to be one-way:

Input
 ↓
Hash Function
 ↓
Digest

Passwords should normally be stored using password hashing rather than reversible encryption.

44. Symmetric Encryption

The same secret key is used to encrypt and decrypt.

Key
 ↓
Encrypt
 ↓
Ciphertext
 ↓
Decrypt
 ↓
Plaintext

AES is a common symmetric encryption algorithm.

45. Asymmetric Cryptography

Uses a key pair:

Public Key
Private Key

Common algorithms include:

Asymmetric cryptography is useful for:

Key exchange
Digital signatures
Authentication

46. Digital Signatures

A digital signature provides integrity and authenticity.

Conceptually:

Message
 ↓
Hash
 ↓
Sign with Private Key
 ↓
Signature

The receiver uses the public key to verify the signature.

JWT signatures are an example of this concept.

47. Key Management

Strong cryptography with poor key management is still insecure.

Never hard-code:

const SECRET = 'my-super-secret';

in source code.

Use:

Environment variables
Secret managers
Key management systems
Proper access control
Key rotation

48. Database Security

Database security includes more than preventing SQL injection.

Important practices include:

Least privilege
Separate database users
Strong authentication
Network restrictions
Encryption
Secure queries
Backups
Monitoring
Secret management

The application should not connect as a database superuser.

49. Least Privilege

If an application only needs:

SELECT
INSERT
UPDATE

do not give it:

DROP DATABASE
CREATE USER
SUPERUSER

Give each component the minimum privileges required.

50. File Upload Security

File uploads are dangerous because attackers may upload:

Executable files
Web shells
Malicious HTML
Malware
Oversized files
Files designed to exploit parsers

Do not trust:

filename
extension
Content-Type

from the client alone.

51. Secure File Upload Pipeline

A safer pipeline looks like:

Upload
  ↓
Authentication
  ↓
Authorization
  ↓
Size Validation
  ↓
Extension Validation
  ↓
MIME Verification
  ↓
Content Validation
  ↓
Malware Scanning
  ↓
Random Filename
  ↓
Private Storage

Store uploads outside executable web directories whenever possible.

52. Path Traversal

Path traversal attempts to access files outside the intended directory.

Example concept:

../../../../etc/passwd

Never directly concatenate user input into filesystem paths.

Use safe path resolution and enforce that the final path remains inside the intended directory.

53. SSRF

Server-Side Request Forgery occurs when an attacker controls a URL that the server requests.

Example:

Attacker
   ↓
Your API
   ↓
Internal service

The server may have access to resources that the attacker cannot access directly.

Potential targets include:

Internal services
localhost
Private networks
Cloud metadata services

54. SSRF Prevention

Do not simply trust user-provided URLs.

Defenses include:

Allowlisting destinations
Blocking private IP ranges
Blocking localhost
Validating protocols
Restricting redirects
DNS/IP validation
Network segmentation
Egress controls

SSRF protection should exist at both application and infrastructure levels.

55. Serialization and Deserialization Security

Serialization converts objects into a transferable representation.

Deserialization reconstructs them.

Unsafe deserialization can become dangerous when attacker-controlled serialized data is interpreted by powerful object mechanisms.

The safest principle is:

Never deserialize untrusted data using unsafe object reconstruction mechanisms.

Prefer simple, well-defined data formats and strict schemas.

56. Security Misconfiguration

Common examples include:

Debug mode enabled
Default credentials
Exposed stack traces
Public .env files
Open database ports
Unnecessary services
Weak CORS configuration
Missing security headers

Production should not expose development information.

Bad:

{
  "error": "MongoServerError...",
  "stack": "..."
}

Better:

{
  "message": "Internal server error"
}

Detailed information should remain in secure server-side logs.

57. Secrets

Never commit:

.env
private keys
API secrets
database passwords
JWT signing keys

to source control.

Use secret management mechanisms appropriate for the deployment environment.

Also remember:

Environment variables are configuration, not automatically a complete secret-management strategy.

58. Docker Security

Containers should follow least privilege.

Avoid running applications as root when unnecessary.

Use:

Minimal base images
Non-root users
Read-only filesystems where practical
Secret management
Image scanning
Pinned versions
Network segmentation

59. Nginx Security

Nginx is commonly used as a reverse proxy.

Typical architecture:

Internet
   ↓
HTTPS
   ↓
Nginx
   ↓
Node.js
   ↓
Database

Nginx can provide:

TLS termination
Rate limiting
Request size limits
Security headers
Reverse proxying
Access logging

60. Dependency Security

Modern applications depend on hundreds or thousands of packages.

One vulnerable dependency can become an application vulnerability.

Useful practices include:

npm audit

and:

Dependabot
Dependency scanners
Lock files
Automated CI security checks

Use lock files such as:

package-lock.json

to make dependency resolution more predictable.

61. Supply-Chain Attacks

An attacker may compromise:

Developer
   ↓
Package
   ↓
Dependency
   ↓
Application

Possible attacks include:

Malicious packages
Compromised maintainers
Dependency confusion
Typosquatting
Compromised build pipelines

Security must therefore include the software supply chain.

62. Logging and Monitoring

Logging is critical for detecting attacks and investigating incidents.

Useful events include:

Login success
Login failure
Password reset
Permission changes
Role changes
Admin actions
Suspicious requests
Rate-limit violations
Security configuration changes

63. What Should Never Be Logged?

Avoid logging:

Passwords
Access tokens
Refresh tokens
Session IDs
Private keys
Credit card information
Sensitive personal data

Logs themselves are sensitive infrastructure.

64. Audit Logs

An audit log answers:

Who?
What?
When?
Where?
What changed?
Was it successful?

Example:

{
  "actorId": "123",
  "action": "ROLE_CHANGED",
  "targetUserId": "456",
  "timestamp": "2026-08-10T10:00:00Z",
  "ip": "..."
}

Audit logs are especially important for administrative operations.

65. Secure Coding Principles

Input Validation

Treat all external data as untrusted.

Sources include:

HTTP requests
Cookies
Headers
Query parameters
Files
Webhooks
Message queues

Output Encoding

Encode output according to its context.

Fail Securely

When something goes wrong:

Default → Deny

not:

Default → Allow

Defense in Depth

Never rely on one security control.

For example:

Input Validation
      +
Authorization
      +
Database Restrictions
      +
Rate Limiting
      +
Monitoring

If one layer fails, another layer can reduce the damage.

66. OWASP API Security Top 10

API-specific security risks include areas such as:

Broken Object Level Authorization
Broken Authentication
Broken Object Property Level Authorization
Unrestricted Resource Consumption
Broken Function Level Authorization
Unrestricted Access to Sensitive Business Flows
Server-Side Request Forgery
Security Misconfiguration
Improper Inventory Management
Unsafe Consumption of APIs

API security requires understanding both technical vulnerabilities and business logic.

67. OWASP ASVS

OWASP ASVS stands for:

Application Security Verification Standard

It provides requirements that can be used to verify the security of an application.

Instead of asking:

"Did we follow OWASP?"

you can ask:

"Which security requirements does our application satisfy?"

ASVS can be used during:

Architecture
Development
Code Review
Testing
Security Audits
Release

68. OWASP Testing Guide

Security testing should follow a methodology.

A simplified workflow is:

Reconnaissance
      ↓
Enumeration
      ↓
Authentication Testing
      ↓
Authorization Testing
      ↓
Input Validation
      ↓
Session Testing
      ↓
Business Logic Testing
      ↓
Configuration Testing
      ↓
Reporting

The goal is not simply to find vulnerabilities.

The goal is to systematically evaluate the application's security.

69. Security Testing Tools

Common tools include:

Burp Suite

Used for:

HTTP interception
Request manipulation
Replaying requests
API testing
Authentication testing

OWASP ZAP

An open-source web application security testing proxy.

Nmap

Used for network discovery and service enumeration.

Postman

Useful for API development and security testing.

npm audit

Useful for identifying known vulnerable npm dependencies.

Tools are only as effective as the methodology behind them.

70. Secure Node.js Application

A production Node.js application should consider:

Express Security
Helmet
CORS
Rate Limiting
Validation
Authentication
Authorization
JWT
Secure Cookies
CSRF
Database Security
Logging
Error Handling
Dependency Security

Example:

app.use(helmet());
app.use(express.json({ limit: '1mb' }));

Use validation libraries and explicitly define accepted input.

71. Secure Express Architecture

A useful architecture is:

Request
  ↓
Nginx
  ↓
Rate Limiting
  ↓
Express
  ↓
Security Middleware
  ↓
Authentication
  ↓
Authorization
  ↓
Validation
  ↓
Controller
  ↓
Service
  ↓
Repository
  ↓
Database

This separates security responsibilities.

72. Secure NestJS Application

NestJS provides several mechanisms useful for security.

Guards

Guards are useful for:

Authentication
Authorization
Role checks

Example:

@UseGuards(AuthGuard)
@Get('/profile')
getProfile() {
    return this.userService.profile();
}

Pipes

Pipes can validate and transform incoming data.

Example:

app.useGlobalPipes(
    new ValidationPipe({
        whitelist: true,
        forbidNonWhitelisted: true,
        transform: true
    })
);

This is extremely useful for preventing unexpected fields from entering your application.

73. NestJS Authorization

You can implement:

Authentication Guard
        ↓
Roles Guard
        ↓
Controller

For example:

@Roles('admin')
@UseGuards(AuthGuard, RolesGuard)
@Delete(':id')
deleteUser() {}

But remember:

Authorization should be based on business rules, not only decorators.

Resource ownership must still be checked.

74. Production Security Architecture

A realistic deployment might look like:

                 Internet
                    │
                    ▼
                HTTPS/TLS
                    │
                    ▼
                 Nginx
                    │
              ┌─────┴─────┐
              │           │
          Rate Limit     Headers
              │
              ▼
         API Gateway
              │
       ┌──────┼──────┐
       │      │      │
     Auth   Users   Orders
       │      │      │
       └──────┼──────┘
              │
            Redis
              │
         Database

Each layer provides different security controls.

75. Zero Trust Basics

Zero Trust follows a principle similar to:

Never trust automatically; verify explicitly.

For service-to-service communication:

Service A
   ↓
Authentication
   ↓
Authorization
   ↓
Service B

Do not assume that because traffic is inside a private network, it is automatically trusted.

76. Final Production Project

The best way to learn application security is to build a complete secure application.

A suitable final project is a:

Secure Authentication and Authorization Platform

Technology stack:

Frontend
Angular

Backend
Node.js + NestJS

Database
PostgreSQL or MongoDB

Cache
Redis

Reverse Proxy
Nginx

Deployment
Docker

Security
HTTPS
JWT
Refresh Tokens
RBAC
CSRF
CSP
Security Headers
Rate Limiting
Audit Logs

77. Authentication Flow

A possible architecture:

POST /auth/login
        ↓
Validate Input
        ↓
Find User
        ↓
Verify Password
        ↓
Create Access Token
        ↓
Create Refresh Token
        ↓
Store Refresh Token State
        ↓
Return Authentication Response

78. Refresh Token Flow

Client
   ↓
Access Token Expired
   ↓
POST /auth/refresh
   ↓
Validate Refresh Token
   ↓
Check Token State
   ↓
Rotate Refresh Token
   ↓
Generate New Access Token
   ↓
Return Tokens

If token reuse is detected, the application can invalidate the relevant token family/session.

79. RBAC Flow

Example:

Admin
 ├── users:read
 ├── users:create
 ├── users:update
 └── users:delete

Manager
 ├── users:read
 └── users:update

User
 └── profile:read

Authorization should be enforced server-side.

80. Redis Security

Redis can be used for:

Sessions
Refresh-token state
Rate limiting
Temporary security data
Token revocation

But Redis itself must be secured.

Do not expose Redis directly to the public Internet.

Use:

Authentication
Network Restrictions
TLS where appropriate
Least Privilege
Secure Configuration

81. Database Security in the Final Project

The application should use:

Application DB User
        ↓
Minimum Required Permissions
        ↓
Database

Sensitive data should be protected.

Queries should be parameterized or safely constructed.

Indexes should be designed carefully.

82. Rate Limiting Architecture

Different endpoints may require different limits.

For example:

Login
5 attempts / minute

Password Reset
3 requests / hour

Normal API
100 requests / minute

Admin API
Stricter limits

The exact values should depend on the application's behavior and threat model.

83. Security Headers

The production application should implement appropriate headers such as:

Content-Security-Policy
Strict-Transport-Security
X-Content-Type-Options
Referrer-Policy
Permissions-Policy

Frame protection should be configured through appropriate CSP directives such as:

frame-ancestors

84. HTTPS

Production applications should use HTTPS.

Architecture:

Client
  ↓
HTTPS
  ↓
Nginx
  ↓
Node.js

HTTPS protects data in transit from network interception and tampering.

85. Security Testing the Final Project

Test the application against:

Authentication
Authorization
IDOR/BOLA
Brute Force
Credential Stuffing
SQL Injection
NoSQL Injection
XSS
CSRF
SSRF
Path Traversal
File Upload
Mass Assignment
Rate Limiting
Security Headers
CORS
Session Management
Error Handling
Dependency Vulnerabilities

You can use:

Burp Suite
OWASP ZAP
Postman
Nmap
npm audit
Dependency scanners

86. Security Checklist

Before production, ask:

Authentication

Are passwords hashed securely?
Are authentication tokens protected?
Are refresh tokens rotated?
Are sessions invalidated correctly?
Is brute-force protection implemented?

Authorization

Is every sensitive resource authorized?
Is ownership verified?
Are roles and permissions enforced server-side?
Is tenant isolation implemented?

Input

Is every external input validated?
Are request sizes limited?
Are database queries safely constructed?
Is mass assignment prevented?

XSS

Is output encoded?
Is unsafe HTML sanitized?
Is CSP configured?
Are sensitive cookies HttpOnly?

CSRF

Are state-changing requests protected?
Are cookies configured with appropriate SameSite settings?
Is Origin validation considered?

API

Is rate limiting implemented?
Is excessive data exposure prevented?
Are pagination limits enforced?
Are sensitive business operations protected?

Infrastructure

Is HTTPS enabled?
Is Nginx configured securely?
Are secrets protected?
Are containers running with minimal privileges?
Are databases private?

Monitoring

Are security events logged?
Are sensitive values excluded from logs?
Are suspicious activities detected?
Are alerts configured?

87. The Developer Security Mental Model

A secure developer should think about an application in layers:

                USER
                 │
                 ▼
              BROWSER
                 │
                 ▼
              HTTPS
                 │
                 ▼
            REVERSE PROXY
                 │
                 ▼
               API
                 │
        ┌────────┴────────┐
        ▼                 ▼
 AUTHENTICATION      AUTHORIZATION
        │                 │
        └────────┬────────┘
                 ▼
          INPUT VALIDATION
                 │
                 ▼
          BUSINESS LOGIC
                 │
        ┌────────┴────────┐
        ▼                 ▼
     DATABASE           CACHE
        │                 │
        └────────┬────────┘
                 ▼
             LOGGING
                 │
                 ▼
            MONITORING

Security is not a single feature.

It is a property of the entire system.

88. Final Takeaway

Learning OWASP should not mean memorizing a list of vulnerabilities.

The real goal is to develop a security mindset.

When building an application, continuously ask:

Who can access this?
What happens if the input is malicious?
What if the user modifies the request?
What if the token is stolen?
What if the database is compromised?
What if this endpoint is called 100,000 times?
What if this service receives an unexpected file?
What if an internal service is attacked through SSRF?
What information can leak through errors?
What happens when something fails?
Can we detect the attack?

The most important principles are:

Validate Input
        +
Encode Output
        +
Authenticate Correctly
        +
Authorize Every Sensitive Operation
        +
Use Least Privilege
        +
Protect Secrets
        +
Use Secure Cryptography
        +
Limit Resources
        +
Log Security Events
        +
Monitor the System
        +
Test Continuously

The strongest security architecture is not one that assumes attackers will never get through.

It is one that assumes something will eventually fail and is designed to limit the damage.

That is the core mindset behind secure software development.

Recommended Learning Path

If you want to turn this material into a practical developer security course, follow this sequence:

1. OWASP Fundamentals
        ↓
2. HTTP & Browser Security
        ↓
3. Authentication
        ↓
4. Authorization
        ↓
5. Injection
        ↓
6. XSS
        ↓
7. CSRF
        ↓
8. API Security
        ↓
9. Cryptography
        ↓
10. Database Security
        ↓
11. File Upload & Path Traversal
        ↓
12. SSRF
        ↓
13. Security Misconfiguration
        ↓
14. Dependency Security
        ↓
15. Logging & Monitoring
        ↓
16. Secure Coding
        ↓
17. OWASP API Security
        ↓
18. OWASP ASVS
        ↓
19. OWASP Testing Guide
        ↓
20. Burp Suite / ZAP
        ↓
21. Secure Node.js
        ↓
22. Secure NestJS
        ↓
23. Docker + Nginx + HTTPS
        ↓
24. Secure Architecture
        ↓
25. Final Production Project

By completing this path, you move from simply knowing what vulnerabilities are to understanding how to design, implement, test, and deploy secure production applications.

JWT Authentication Explained: Theory, Security, and a Complete Node.js & Express Example

Abanoub Kerols — Sun, 11 Oct 2026 21:28:40 +0000

JSON Web Tokens (JWT) are one of the most widely used technologies for implementing authentication in modern web applications.

You will find JWT in:

Angular applications
React applications
Node.js APIs
Mobile applications
Microservices
BFF architectures
API gateways
Distributed systems

But JWT is often misunderstood.

Many developers know how to write:

jwt.sign(...)

and:

jwt.verify(...)

without really understanding what a JWT is, what problem it solves, how it works internally, where it should be stored, and how to secure it properly.

This article goes beyond simply generating a token.

We will understand JWT from the ground up and build a complete authentication flow using Node.js, Express, TypeScript, and MongoDB-style concepts.

1. Authentication vs Authorization

Before discussing JWT, we need to understand two fundamental concepts.

Authentication

Authentication answers:

Who are you?

For example:

User → Email + Password
        ↓
     Server
        ↓
  Is the user valid?
        ↓
       Yes

The server identifies the user.

Authorization

Authorization answers:

What are you allowed to do?

For example:

User
 ├── Read products       ✅
 ├── Create products     ❌
 ├── Delete products     ❌
 └── Manage users        ❌

Authentication comes first.

Authorization comes after authentication.

2. What Is JWT?

JWT stands for:

JSON Web Token

It is a compact token format used to securely transmit claims between parties.

A JWT typically looks like this:

xxxxx.yyyyy.zzzzz

For example:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJzdWIiOiIxMjM0NSIsInJvbGUiOiJ1c2VyIn0
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

A JWT contains three parts:

HEADER.PAYLOAD.SIGNATURE

3. JWT Structure

Let's break it down.

Header

The header describes the token.

Example:

{
  "alg": "HS256",
  "typ": "JWT"
}

alg represents the signing algorithm.

typ represents the token type.

Payload

The payload contains claims.

Example:

{
  "sub": "12345",
  "email": "user@example.com",
  "role": "admin"
}

Claims are pieces of information about the token or its subject.

Common claims include:

sub
iss
aud
exp
iat
nbf
jti

For example:

{
  "sub": "12345",
  "role": "admin",
  "iat": 1720000000,
  "exp": 1720003600
}

Signature

The signature allows the server to verify that the token has not been modified.

Conceptually:

signature =
    HMAC(
        base64(header) + "." + base64(payload),
        secret
    )

So the final token becomes:

HEADER.PAYLOAD.SIGNATURE

4. Important: JWT Is Not Encryption

This is one of the most important JWT concepts.

A normal JWT payload is not encrypted.

It is encoded using Base64URL.

For example:

{
  "email": "user@example.com",
  "role": "admin"
}

can be decoded.

Therefore, you should never put sensitive information inside a JWT.

Don't do this:

{
  "password": "MySuperSecretPassword"
}

Don't store:

credit card numbers
passwords
private secrets
sensitive personal data

inside the payload.

JWT provides integrity and authenticity through signing, not confidentiality.

If you need confidentiality, encryption is a different concept.

5. Why Do We Need JWT?

Imagine an API:

POST /login

The user sends:

{
  "email": "user@example.com",
  "password": "123456"
}

The server validates the credentials.

Now the user wants:

GET /api/profile

How does the server know who the user is?

One traditional solution is a server-side session.

Another solution is a JWT.

The server can issue:

Access Token

The client then sends the token with future requests.

For example:

Authorization: Bearer eyJhbGciOi...

The server verifies the token.

6. JWT Authentication Flow

A typical authentication flow looks like this:

             Client
                |
                | email + password
                v
             POST /login
                |
                v
             Server
                |
          Validate credentials
                |
                v
          Generate JWT
                |
                v
             Client
                |
          Store/use token
                |
                | Authorization: Bearer JWT
                v
          Protected API
                |
          Verify JWT
                |
                v
             Response

The important idea is:

The server doesn't need to receive the user's password on every request.

7. Stateless Authentication

One major advantage of JWT is that authentication can be stateless.

With traditional sessions:

Client
   |
Session ID
   |
Server
   |
Session Store

The server needs to maintain session state.

With JWT:

Client
   |
JWT
   |
Server

The token itself contains the claims required to identify the user.

The server can verify the signature without necessarily looking up a session.

This can be useful in distributed systems.

8. JWT in a Microservices Architecture

Consider:

                Client
                  |
                  v
             API Gateway
                  |
       +----------+----------+
       |          |          |
       v          v          v
    Users      Orders     Payments
   Service     Service     Service

The client can send:

Authorization: Bearer <token>

Each service can validate the token.

This is one reason JWT is popular in distributed architectures.

However, "stateless" does not mean JWT automatically solves every distributed authentication problem.

Revocation, rotation, expiration, key management, and authorization still need to be designed carefully.

9. Creating JWTs with Node.js

Let's build a simple example.

Install:

npm install express jsonwebtoken bcrypt

For TypeScript:

npm install -D @types/express @types/jsonwebtoken @types/bcrypt

10. JWT Secret

Never hardcode your production secret:

const JWT_SECRET = "my-secret";

Instead:

JWT_SECRET=super-long-random-secret

Then:

const JWT_SECRET = process.env.JWT_SECRET!;

A production secret should be long, random, and protected.

For stronger architectures, asymmetric keys such as RSA or EC keys can be used instead of a shared HMAC secret.

11. Generating an Access Token

Example:

import jwt from "jsonwebtoken";

const token = jwt.sign(
  {
    sub: user.id,
    role: user.role
  },
  process.env.JWT_SECRET!,
  {
    expiresIn: "15m"
  }
);

The resulting token contains claims such as:

{
  "sub": "12345",
  "role": "user",
  "iat": 1720000000,
  "exp": 1720000900
}

12. Why Use `sub`?

sub means:

Subject

It commonly identifies the user.

Instead of putting:

{
  "userId": "12345"
}

you can use:

{
  "sub": "12345"
}

Then your application can interpret:

const userId = payload.sub;

13. Login Endpoint

A simplified login endpoint might look like this:

app.post("/auth/login", async (req, res) => {
  const { email, password } = req.body;

  const user = await User.findOne({ email });

  if (!user) {
    return res.status(401).json({
      message: "Invalid credentials"
    });
  }

  const validPassword = await bcrypt.compare(
    password,
    user.password
  );

  if (!validPassword) {
    return res.status(401).json({
      message: "Invalid credentials"
    });
  }

  const accessToken = jwt.sign(
    {
      sub: user.id,
      role: user.role
    },
    process.env.JWT_SECRET!,
    {
      expiresIn: "15m"
    }
  );

  res.json({
    accessToken
  });
});

The process is:

Email
 ↓
Find user
 ↓
Compare password hash
 ↓
Generate access token
 ↓
Return token

14. Passwords Should Never Be Stored as Plain Text

Never do:

user.password = password;

Instead, hash the password.

Example:

const hashedPassword = await bcrypt.hash(password, 12);

Store:

hashedPassword

not:

password

During login:

const valid = await bcrypt.compare(
  password,
  hashedPassword
);

JWT does not replace password hashing.

They solve different problems.

bcrypt
   ↓
Password protection

JWT
   ↓
Authentication token

15. Protecting Routes with Middleware

Now we need to protect:

GET /api/profile

We can create authentication middleware.

import { Request, Response, NextFunction } from "express";
import jwt from "jsonwebtoken";

export interface AuthRequest extends Request {
  user?: {
    id: string;
    role: string;
  };
}

export function authenticate(
  req: AuthRequest,
  res: Response,
  next: NextFunction
) {
  const authHeader = req.headers.authorization;

  if (!authHeader) {
    return res.status(401).json({
      message: "Authentication required"
    });
  }

  const [scheme, token] = authHeader.split(" ");

  if (scheme !== "Bearer" || !token) {
    return res.status(401).json({
      message: "Invalid authorization header"
    });
  }

  try {
    const payload = jwt.verify(
      token,
      process.env.JWT_SECRET!
    ) as jwt.JwtPayload;

    req.user = {
      id: payload.sub as string,
      role: payload.role as string
    };

    next();
  } catch {
    return res.status(401).json({
      message: "Invalid or expired token"
    });
  }
}

16. Using the Middleware

Now:

app.get(
  "/api/profile",
  authenticate,
  (req: AuthRequest, res) => {
    res.json({
      message: "Protected profile",
      user: req.user
    });
  }
);

The request flow becomes:

Request
   |
Authorization Header
   |
Extract JWT
   |
Verify Signature
   |
Check Expiration
   |
Extract User
   |
next()
   |
Controller

17. What Happens When the Token Is Modified?

Suppose the original payload is:

{
  "sub": "123",
  "role": "user"
}

An attacker changes it to:

{
  "sub": "123",
  "role": "admin"
}

The attacker cannot simply change the payload and create a valid signature.

The server calculates/verifies the signature using its trusted key.

The modified token fails verification.

Therefore:

Original Token
      ↓
Valid Signature
      ↓
Accepted

Modified Token
      ↓
Invalid Signature
      ↓
Rejected

That's the core security property of signed JWTs.

18. JWT Verification vs JWT Decoding

This distinction is extremely important.

You might see:

jwt.decode(token);

and think:

"The token is valid."

No.

decode() only decodes the token.

It does not prove that the token was signed by a trusted issuer.

Use:

jwt.verify(token, secret);

for authentication.

Conceptually:

decode()
   ↓
Read data

verify()
   ↓
Validate signature + token constraints

Never authenticate a user using only decode().

19. JWT Expiration

JWTs should normally expire.

Example:

jwt.sign(
  {
    sub: user.id
  },
  JWT_SECRET,
  {
    expiresIn: "15m"
  }
);

Why?

Because if a token is stolen, a long-lived token gives an attacker a long window of opportunity.

Short-lived access tokens reduce this risk.

A common architecture is:

Access Token
15 minutes

Refresh Token
Longer lifetime

20. Access Token vs Refresh Token

This is one of the most important patterns in modern authentication.

Access Token

Used to access APIs.

Example:

Lifetime: 5–15 minutes

Refresh Token

Used to obtain a new access token.

Example:

Lifetime: days/weeks

The architecture becomes:

              Login
                |
        +-------+-------+
        |               |
        v               v
 Access Token      Refresh Token
   short-lived       long-lived
        |
        v
      API

When the access token expires:

Client
  |
  | refresh token
  v
POST /auth/refresh
  |
  v
Server
  |
  v
New Access Token

21. Why Not Make the Access Token Last 30 Days?

You technically can.

But it's generally a bad security tradeoff.

Imagine:

Access Token
Expires in 30 days

If it gets stolen today, the attacker may have a valid credential for a long period.

Instead:

Access Token
Expires in 15 minutes

and:

Refresh Token
Longer lifetime

This limits the lifetime of the credential used for normal API access.

22. Refresh Token Rotation

A stronger architecture can rotate refresh tokens.

Example:

Refresh Token A
       |
       v
Refresh Endpoint
       |
       +----> Access Token B
       |
       +----> Refresh Token B

The old refresh token becomes invalid.

This can help detect replay attacks and reduce the usefulness of stolen refresh tokens.

A server-side store is often used to track refresh-token state.

For example:

Redis

refresh-token-id → user/session metadata

or a database.

23. JWT Storage: Where Should You Store It?

This is one of the most debated JWT topics.

Possible locations include:

localStorage
sessionStorage
cookies
memory

Each has trade-offs.

24. localStorage

Example:

localStorage.setItem(
  "accessToken",
  token
);

Then:

const token = localStorage.getItem(
  "accessToken"
);

The problem is that JavaScript can access localStorage.

If your application has an XSS vulnerability, malicious JavaScript may potentially read the token.

Therefore:

Storing long-lived authentication credentials in localStorage requires careful consideration of XSS risk.

25. HttpOnly Cookies

A common alternative is:

Set-Cookie: refreshToken=...;
HttpOnly;
Secure;
SameSite=Lax

HttpOnly means client-side JavaScript cannot directly read the cookie.

This reduces the impact of token theft through straightforward JavaScript access.

However, cookies introduce another concern:

CSRF

Therefore, cookie-based authentication must also use appropriate CSRF protections and cookie configuration.

26. A Common Modern Architecture

A practical pattern is:

Access Token
   ↓
Short-lived
   ↓
Memory

Refresh Token
   ↓
Long-lived
   ↓
HttpOnly + Secure Cookie

For example:

Browser
  |
  +---- Access Token → memory
  |
  +---- Refresh Token → HttpOnly Cookie

When the page reloads:

Browser
   |
   | Refresh Cookie
   v
/auth/refresh
   |
   v
New Access Token

This is often preferable to keeping a long-lived access token in JavaScript-readable storage.

The exact design depends on the application architecture and threat model.

27. JWT and XSS

JWT does not magically protect your application from XSS.

Suppose an attacker injects:

<script>
  // malicious code
</script>

If your access token is available to JavaScript:

localStorage.getItem("accessToken");

the attacker may potentially access it.

Therefore, authentication security must include:

XSS protection
+
Secure token handling
+
Content Security Policy
+
Input/output handling

JWT is only one part of the security architecture.

28. JWT and CSRF

If you use cookies for authentication, browsers automatically attach cookies to matching requests.

This creates CSRF considerations.

For example:

Victim Browser
      |
      | Cookie automatically attached
      v
Bank API

A malicious website may try to trigger an unwanted request.

Common defenses include:

SameSite cookies
CSRF tokens
Origin/Referer validation
Proper request design

The correct strategy depends on the architecture.

29. Role-Based Authorization

Authentication tells us:

Who is the user?

Authorization tells us:

What can the user do?

Suppose the JWT contains:

{
  "sub": "123",
  "role": "admin"
}

We can create an authorization middleware.

function authorize(...roles: string[]) {
  return (
    req: AuthRequest,
    res: Response,
    next: NextFunction
  ) => {
    if (!req.user) {
      return res.status(401).json({
        message: "Authentication required"
      });
    }

    if (!roles.includes(req.user.role)) {
      return res.status(403).json({
        message: "Forbidden"
      });
    }

    next();
  };
}

Use it:

app.delete(
  "/api/users/:id",
  authenticate,
  authorize("admin"),
  deleteUser
);

Now:

No Token
   ↓
401 Unauthorized

Valid Token + user role
   ↓
403 Forbidden

Valid Token + admin role
   ↓
Allowed

30. 401 vs 403

This distinction matters.

401 Unauthorized

Usually means:

The request does not have valid authentication credentials.

Examples:

Missing token
Expired token
Invalid token

403 Forbidden

Usually means:

The user is authenticated but does not have permission.

Example:

Authenticated user
        +
role = user
        ↓
Admin endpoint
        ↓
403

31. Don't Trust Authorization Claims Blindly

Suppose the JWT says:

{
  "sub": "123",
  "role": "admin"
}

Should your application always trust the role forever?

Not necessarily.

Imagine:

User is admin
     ↓
JWT issued
     ↓
Admin account downgraded
     ↓
JWT still valid

The old token may continue carrying:

role = admin

until it expires.

This is one reason authorization design sometimes requires server-side state.

For highly sensitive operations, the application may re-check the user's current permissions.

32. JWT Claims

Let's examine common claims.

`iss`

Issuer:

{
  "iss": "https://auth.example.com"
}

Identifies who issued the token.

`aud`

Audience:

{
  "aud": "api.example.com"
}

Identifies the intended recipient.

`sub`

Subject:

{
  "sub": "user-123"
}

Identifies the principal.

`exp`

Expiration:

{
  "exp": 1720003600
}

After this time, the token should no longer be accepted.

`iat`

Issued-at time:

{
  "iat": 1720000000
}

`nbf`

Not-before:

{
  "nbf": 1720000100
}

The token should not be accepted before this time.

`jti`

JWT ID:

{
  "jti": "unique-token-id"
}

Useful for token identification and certain revocation/replay-detection designs.

33. Algorithm Choice

JWT supports different signing algorithms.

Examples:

HS256
RS256
ES256

HS256

Uses one shared secret.

Private signing secret
        +
Verification secret

Both sides need access to the same secret.

This can be simple for a single backend.

RS256

Uses asymmetric cryptography.

Private Key
    ↓
Sign

Public Key
    ↓
Verify

This is particularly useful in distributed architectures.

For example:

Authorization Server
        |
   Private Key
        |
       JWT
        |
        v
+-------+-------+-------+
|       |       |       |
v       v       v       v
API 1   API 2   API 3   API 4
        |
    Public Key

Services can verify tokens without possessing the private signing key.

34. Never Accept Arbitrary Algorithms

A dangerous implementation mistake is allowing the token itself to dictate a signing algorithm without enforcing what your application expects.

Your verification configuration should explicitly define trusted algorithms.

Conceptually:

jwt.verify(token, publicKey, {
  algorithms: ["RS256"]
});

The server should have a clear trust policy.

35. Complete Authentication Architecture

A more production-oriented architecture could look like this:

                    Browser
                       |
                       v
                  Login Request
                       |
                       v
                Authentication API
                       |
              Validate credentials
                       |
          +------------+------------+
          |                         |
          v                         v
    Access Token              Refresh Token
    Short Lifetime             Long Lifetime
          |                         |
          v                         v
      API Calls               HttpOnly Cookie
          |                         |
          v                         |
      JWT Verify                   |
          |                         |
          +------------+------------+
                       |
                       v
                    API
                       |
                Authorization
                       |
                       v
                   Resource

36. Refresh Endpoint

A simplified implementation might look like:

app.post("/auth/refresh", async (req, res) => {
  const refreshToken = req.cookies.refreshToken;

  if (!refreshToken) {
    return res.status(401).json({
      message: "Refresh token required"
    });
  }

  try {
    const payload = jwt.verify(
      refreshToken,
      process.env.REFRESH_TOKEN_SECRET!
    ) as jwt.JwtPayload;

    const accessToken = jwt.sign(
      {
        sub: payload.sub,
        role: payload.role
      },
      process.env.JWT_SECRET!,
      {
        expiresIn: "15m"
      }
    );

    res.json({
      accessToken
    });
  } catch {
    res.status(401).json({
      message: "Invalid refresh token"
    });
  }
});

A production implementation should go further.

For example:

Refresh Token
      ↓
Verify signature
      ↓
Check expiration
      ↓
Check session/token record
      ↓
Check revocation
      ↓
Rotate token
      ↓
Issue new access token

37. Logout with JWT

With traditional sessions:

DELETE session

and the server can immediately invalidate it.

JWT introduces an interesting problem.

If the access token is self-contained and valid for 15 minutes, how do you instantly revoke it?

There are several strategies.

Strategy 1: Short expiration

Use:

5–15 minute access token

and accept that it remains valid until expiration.

Strategy 2: Token Revocation

Store token identifiers:

jti → revoked

Then check them during authentication.

This introduces server-side state.

Strategy 3: Refresh Token Revocation

A common design is to invalidate the refresh session during logout.

Then:

Existing access token
     ↓
Expires soon

Refresh token
     ↓
Revoked

The user cannot obtain another access token.

38. JWT Blacklist

Another approach is a blacklist.

For example:

Redis

revoked:jti:12345

During authentication:

JWT
 ↓
Verify signature
 ↓
Read jti
 ↓
Check Redis
 ↓
Revoked?
 ├── Yes → Reject
 └── No  → Continue

This gives stronger revocation control but sacrifices some of JWT's stateless simplicity.

39. JWT Is Not Always the Best Choice

JWT is powerful, but it isn't automatically the correct authentication mechanism for every application.

For a traditional server-rendered application, a session-based approach can be simpler.

For example:

Browser
   |
Session Cookie
   |
Server
   |
Session Store

For distributed APIs:

Client
   |
JWT
   |
API Gateway
   |
Microservices

The correct choice depends on the architecture.

Don't choose JWT simply because:

"Everyone uses JWT."

Choose it because its properties fit the system.

40. Common JWT Mistakes

Here are some mistakes developers frequently make.

Mistake 1 — Putting passwords in JWT

Bad:

{
  "email": "user@example.com",
  "password": "123456"
}

Never do this.

Mistake 2 — Treating Base64 as encryption

Bad assumption:

Encoded = Encrypted

False.

JWT payloads are normally readable.

Mistake 3 — Using `decode()` for authentication

Bad:

const payload = jwt.decode(token);

Use verification instead:

jwt.verify(token, secret);

Mistake 4 — Very long-lived access tokens

Bad:

Access Token = 30 days

Prefer short-lived access tokens when appropriate.

Mistake 5 — Hardcoding secrets

Bad:

const secret = "123456";

Use secure secret management.

Mistake 6 — Storing everything in the token

Don't turn JWT into a database.

Bad:

{
  "sub": "123",
  "name": "...",
  "address": "...",
  "permissions": [ "...", "...", "..."],
  "orders": [ "...", "...", "..." ]
}

JWTs should generally remain small.

Mistake 7 — Putting sensitive data in the payload

Remember:

JWT payload ≠ encrypted storage

Mistake 8 — Forgetting expiration

A token without appropriate expiration can become a long-lived credential.

Mistake 9 — Ignoring CSRF when using cookies

Cookie-based authentication requires appropriate CSRF defenses.

Mistake 10 — Assuming JWT solves logout

JWT does not automatically provide instant revocation.

41. Angular + JWT Example

Since JWT is frequently used with Angular, let's see the client-side concept.

An Angular HTTP interceptor can attach an access token:

export const authInterceptor: HttpInterceptorFn = (
  req,
  next
) => {
  const token = authService.getAccessToken();

  if (!token) {
    return next(req);
  }

  const authReq = req.clone({
    setHeaders: {
      Authorization: `Bearer ${token}`
    }
  });

  return next(authReq);
};

The request becomes:

GET /api/profile HTTP/1.1
Authorization: Bearer eyJhbGciOi...

The backend then verifies the token.

42. Handling Expired Tokens in Angular

Suppose the API returns:

401 Unauthorized

The frontend can attempt a refresh flow.

Conceptually:

Angular
   |
API Request
   |
401
   |
Refresh Token
   |
/auth/refresh
   |
New Access Token
   |
Retry Original Request

RxJS is especially useful for implementing this flow safely.

But you must avoid creating infinite refresh loops.

For example:

API request
   ↓
401
   ↓
refresh
   ↓
401
   ↓
refresh
   ↓
401
   ↓
...

A production interceptor must carefully control refresh attempts.

43. JWT in BFF Architecture

JWT also appears in BFF architectures.

For example:

                 Browser
                    |
                    v
                   BFF
                    |
          +---------+---------+
          |         |         |
          v         v         v
       Users     Orders    Payments

The BFF can manage authentication while keeping backend credentials away from browser code.

A common architecture is:

Browser
   |
Secure Cookie
   |
BFF
   |
Access Token
   |
Backend APIs

This can simplify browser security and token management.

44. JWT in an API Gateway

Another architecture:

Client
  |
  | JWT
  v
API Gateway
  |
  | verify
  v
Microservices

The gateway may verify:

Signature
Issuer
Audience
Expiration

Then forward trusted identity information downstream.

However, individual services may still need to perform their own authorization checks.

Authentication at the gateway does not automatically mean:

Every service should trust every request from the gateway.

Trust boundaries must be designed explicitly.

45. A Better Production JWT Checklist

Before shipping JWT authentication, ask:

☑ Is the token signed with a strong algorithm?

☑ Are signing keys stored securely?

☑ Are tokens short-lived?

☑ Is refresh-token rotation implemented where appropriate?

☑ Are refresh tokens revocable?

☑ Are sensitive values excluded from the payload?

☑ Is JWT verification used instead of decode?

☑ Are issuer and audience validated where appropriate?

☑ Are accepted algorithms restricted?

☑ Is XSS protection implemented?

☑ If cookies are used, is CSRF addressed?

☑ Are cookies Secure?

☑ Are cookies HttpOnly when appropriate?

☑ Is SameSite configured appropriately?

☑ Are passwords hashed using a strong password hashing algorithm?

☑ Is authorization checked separately from authentication?

☑ Is logout behavior clearly defined?

☑ Is token revocation strategy documented?

☑ Are secrets/keys managed outside source control?

46. The Most Important Mental Model

Don't think of JWT as:

"A token that logs the user in."

Think of it as:

JWT
 |
 +-- Identity
 |
 +-- Claims
 |
 +-- Expiration
 |
 +-- Issuer/Audience
 |
 +-- Cryptographic Integrity

Then authentication becomes:

Request
   |
   v
Extract Token
   |
   v
Verify Signature
   |
   v
Validate Claims
   |
   +---- exp
   +---- iss
   +---- aud
   +---- nbf
   |
   v
Identify User
   |
   v
Authorization
   |
   v
Allow / Reject

That mental model is much more useful than memorizing:

jwt.sign()
jwt.verify()

47. Complete Example

A simplified backend structure could look like:

src/
├── auth/
│   ├── auth.controller.ts
│   ├── auth.service.ts
│   ├── auth.middleware.ts
│   └── auth.types.ts
│
├── users/
│   ├── user.model.ts
│   ├── user.controller.ts
│   └── user.service.ts
│
├── middleware/
│   └── error.middleware.ts
│
├── app.ts
└── server.ts

Authentication flow:

POST /auth/register
        |
        v
Hash Password
        |
        v
Create User

Then:

POST /auth/login
        |
        v
Validate Credentials
        |
        v
Create Access Token
        |
        v
Create Refresh Token
        |
        v
Return / Set Cookies

Then:

GET /api/profile
        |
        v
Authenticate Middleware
        |
        v
Verify JWT
        |
        v
Authorization
        |
        v
Controller

And finally:

POST /auth/refresh
        |
        v
Validate Refresh Token
        |
        v
Rotate Refresh Token
        |
        v
Issue New Access Token

48. Final Takeaway

JWT is not simply a replacement for sessions.

It is a token format with cryptographic signing capabilities that can be used as part of an authentication and authorization architecture.

The most important concepts to remember are:

JWT
│
├── Header
│
├── Payload
│
└── Signature

And:

Authentication
      ↓
Who are you?

Authorization
      ↓
What can you do?

For a production system:

Short-lived Access Token
          +
Secure Refresh Token
          +
Strong Key Management
          +
HTTPS
          +
XSS Protection
          +
CSRF Protection when needed
          +
Authorization
          +
Revocation / Rotation Strategy

The most important lesson is this:

JWT itself is not the security architecture. JWT is one component inside the security architecture.

Understanding where tokens are stored, how they expire, how they are refreshed, how they are revoked, how keys are managed, and how authorization is enforced is far more important than simply knowing how to generate a token.

If you understand those concepts, you can confidently design JWT authentication for Angular + Node.js, React + Express, BFFs, API Gateways, and microservices architectures.

Blob in JavaScript: A Practical Deep Dive with Real-World Examples

Abanoub Kerols — Fri, 09 Oct 2026 21:17:59 +0000

If you work with modern web applications, sooner or later you'll need to handle data that isn't simply a JavaScript string or JSON object.

You may need to:

Preview an uploaded image before sending it to the server.
Generate a CSV file directly in the browser.
Download a PDF returned by an API.
Convert generated data into a file.
Upload binary data using fetch().
Display an image or PDF without saving it first.
Process audio or video data.

This is where the Blob API becomes extremely useful.

In this article, we'll go beyond the basic definition of Blob.

We'll understand how Blob works, how it relates to File, ArrayBuffer, and typed arrays, and we'll build a complete practical example involving:

Selecting an image → converting it to a Blob → previewing it → uploading it → receiving a Blob from an API → downloading it.

What Is a Blob?
Why Do We Need Blob?
Creating a Blob
Blob Parts
The MIME Type
Blob Properties
Reading Blob Data
Blob.text()
Blob.arrayBuffer()
Blob.stream()
Blob.slice()
Blob and Object URLs
Previewing an Image
Downloading a Blob
Blob vs File
Creating a File from a Blob
Uploading a Blob
Receiving a Blob from an API
Complete Practical Example
Blob vs ArrayBuffer vs Uint8Array
Blob Streams
Memory Management
Common Mistakes
When Should You Use Blob?
Final Thoughts

What Is a Blob?

Blob stands for:

Binary Large Object

A Blob represents immutable raw binary data.

That data could represent:

an image
a PDF
a video
an audio file
a CSV file
plain text
JSON
arbitrary binary data

For example:

const blob = new Blob(
  ["Hello, world!"],
  {
    type: "text/plain"
  }
);

We have created a Blob containing:

Hello, world!

and told the browser:

This data is text/plain.

We can inspect it:

console.log(blob.size);
console.log(blob.type);

The result will be approximately:

13
text/plain

Why approximately?

Because size represents the number of bytes, not necessarily the number of JavaScript characters.

For ASCII text such as "Hello, world!", the number happens to match.

For Unicode text, it can be different:

const blob = new Blob(
  ["Hello 👋"],
  {
    type: "text/plain"
  }
);

console.log(blob.size);

The browser is measuring the encoded binary representation.

Why Do We Need Blob?

JavaScript applications frequently communicate using JSON:

fetch("/api/users")
  .then(response => response.json())
  .then(data => {
    console.log(data);
  });

But not everything is JSON.

Imagine your backend returns:

report.pdf

or:

profile-image.jpg

or:

invoice.xlsx

The browser needs a representation for that binary content.

That's where Blob becomes useful.

A simplified flow looks like this:

flowchart LR
    A[Server] --> B[Binary Data]
    B --> C[Blob]
    C --> D[Preview]
    C --> E[Download]
    C --> F[Upload]
    C --> G[Convert to File]

Blob is therefore especially useful at the boundary between:

Web APIs and binary data

Creating a Blob

The Blob constructor has the following general structure:

new Blob(blobParts, options)

For example:

const blob = new Blob(
  ["Hello Blob!"],
  {
    type: "text/plain"
  }
);

Let's inspect it:

console.log(blob);

You can also inspect:

console.log(blob.size);
console.log(blob.type);

Blob Parts

The first argument is an array of parts.

Those parts can contain different types of data.

For example:

const blob = new Blob([
  "Hello ",
  "world!"
]);

The resulting Blob contains:

Hello world!

You can also combine multiple strings:

const blob = new Blob([
  "Hello\n",
  "This is a Blob\n",
  "Created in JavaScript."
], {
  type: "text/plain"
});

Blob Can Contain Other Blobs

You can also combine existing Blobs:

const first = new Blob(
  ["Hello "],
  { type: "text/plain" }
);

const second = new Blob(
  ["world!"],
  { type: "text/plain" }
);

const combined = new Blob([
  first,
  second
], {
  type: "text/plain"
});

Now:

console.log(await combined.text());

Result:

Hello world!

The MIME Type

The type property represents the Blob's MIME type.

For example:

const blob = new Blob(
  ["Hello"],
  {
    type: "text/plain"
  }
);

Then:

console.log(blob.type);

returns:

text/plain

For an image:

const imageBlob = new Blob(
  [imageData],
  {
    type: "image/png"
  }
);

For a PDF:

const pdfBlob = new Blob(
  [pdfData],
  {
    type: "application/pdf"
  }
);

For JSON:

const jsonBlob = new Blob(
  [JSON.stringify({
    name: "Abanoub"
  })],
  {
    type: "application/json"
  }
);

Common MIME types include:

Content	MIME Type
Plain text	`text/plain`
HTML	`text/html`
JSON	`application/json`
PDF	`application/pdf`
PNG	`image/png`
JPEG	`image/jpeg`
GIF	`image/gif`
WebP	`image/webp`
CSV	`text/csv`
ZIP	`application/zip`
MP3	`audio/mpeg`
MP4	`video/mp4`

The MIME type doesn't magically transform the data.

It is metadata describing what the data represents.

Blob Properties

A Blob mainly exposes two important properties.

`size`

size returns the size of the Blob in bytes.

const blob = new Blob(
  ["Hello"]
);

console.log(blob.size);

Result:

`type`

type returns the MIME type.

const blob = new Blob(
  ["Hello"],
  {
    type: "text/plain"
  }
);

console.log(blob.type);

Result:

text/plain

Reading Blob Data

Creating a Blob is only part of the story.

Eventually, you usually need to consume the data.

The most important methods are:

blob.text()
blob.arrayBuffer()
blob.stream()

`Blob.text()`

Use text() when the Blob contains textual data.

Example:

const blob = new Blob(
  ["Hello from Blob!"],
  {
    type: "text/plain"
  }
);

const text = await blob.text();

console.log(text);

Output:

Hello from Blob!

Because text() returns a Promise, you can use:

blob.text().then(text => {
  console.log(text);
});

Or preferably:

const text = await blob.text();

Reading JSON from a Blob

Suppose you have:

const data = {
  name: "Abanoub",
  role: "Frontend Developer"
};

const blob = new Blob(
  [JSON.stringify(data)],
  {
    type: "application/json"
  }
);

You can read it:

const text = await blob.text();

const parsed = JSON.parse(text);

console.log(parsed.name);
console.log(parsed.role);

Output:

Abanoub
Frontend Developer

`Blob.arrayBuffer()`

If you need the actual binary representation, use:

blob.arrayBuffer()

Example:

const blob = new Blob(
  ["Hello"],
  {
    type: "text/plain"
  }
);

const buffer = await blob.arrayBuffer();

console.log(buffer);

You get an:

ArrayBuffer

This becomes particularly useful when working with:

binary protocols
cryptography
Web APIs
Web Audio
WebSockets
binary file formats
typed arrays

Blob → ArrayBuffer → Uint8Array

A common pattern is:

const buffer = await blob.arrayBuffer();

const bytes = new Uint8Array(buffer);

console.log(bytes);

For "Hello" you'll see byte values similar to:

[72, 101, 108, 108, 111]

The relationship is:

flowchart LR
    A[Blob] -->|arrayBuffer| B[ArrayBuffer]
    B --> C[Uint8Array]
    C --> D[Individual Bytes]

`Blob.stream()`

A Blob can also expose its data as a ReadableStream.

const blob = new Blob(
  ["Hello from Blob"],
  {
    type: "text/plain"
  }
);

const stream = blob.stream();

console.log(stream);

This becomes useful when dealing with streaming APIs and large amounts of data.

We'll return to this later.

`Blob.slice()`

slice() creates a new Blob containing a portion of the original Blob.

Example:

const blob = new Blob(
  ["Hello World"],
  {
    type: "text/plain"
  }
);

const part = blob.slice(0, 5);

console.log(await part.text());

Result:

Hello

The syntax is:

blob.slice(start, end, contentType)

For example:

const part = blob.slice(
  0,
  5,
  "text/plain"
);

This is useful when you need to work with only a portion of binary data.

Blob and Object URLs

One of the most useful concepts associated with Blob is:

URL.createObjectURL()

Suppose you have:

const blob = new Blob(
  ["Hello"],
  {
    type: "text/plain"
  }
);

You can create a temporary URL:

const url = URL.createObjectURL(blob);

console.log(url);

You'll get something similar to:

blob:https://example.com/550e8400-e29b-41d4-a716-446655440000

This URL doesn't represent a file on your server.

It represents the Blob in the browser.

Think of It Like This

flowchart LR
    A[Blob in Memory] --> B[URL.createObjectURL]
    B --> C[blob:// URL]
    C --> D[img]
    C --> E[a]
    C --> F[iframe]
    C --> G[video]

This is extremely useful.

Previewing an Image

Let's say the user selects an image.

HTML:

<input
  type="file"
  id="imageInput"
  accept="image/*"
/>

<img
  id="preview"
  width="300"
/>

JavaScript:

const input = document.getElementById("imageInput");
const preview = document.getElementById("preview");

input.addEventListener("change", () => {
  const file = input.files[0];

  if (!file) {
    return;
  }

  const url = URL.createObjectURL(file);

  preview.src = url;
});

Notice something important:

File is already a kind of Blob.

So we don't need to manually convert the selected file into another Blob just to preview it.

Blob URLs Are Temporary

An object URL consumes browser resources.

When you're finished with it, release it:

URL.revokeObjectURL(url);

For example:

const url = URL.createObjectURL(file);

preview.src = url;

preview.onload = () => {
  URL.revokeObjectURL(url);
};

This becomes important when you're creating many object URLs.

Downloading a Blob

One of the most common Blob use cases is generating a file dynamically.

Let's generate a text file.

const content = `
Name: Abanoub
Role: Frontend Developer
`;

const blob = new Blob(
  [content],
  {
    type: "text/plain"
  }
);

Create an object URL:

const url = URL.createObjectURL(blob);

Create a link:

const link = document.createElement("a");

link.href = url;
link.download = "profile.txt";

link.click();

Finally:

URL.revokeObjectURL(url);

Complete example:

function downloadTextFile() {
  const content = `
Name: Abanoub
Role: Frontend Developer
`;

  const blob = new Blob(
    [content],
    {
      type: "text/plain"
    }
  );

  const url = URL.createObjectURL(blob);

  const link = document.createElement("a");

  link.href = url;
  link.download = "profile.txt";

  link.click();

  URL.revokeObjectURL(url);
}

This creates a real downloadable file without sending anything to a server.

Generating a CSV File

Blob becomes particularly useful for exporting data.

Imagine:

const users = [
  {
    name: "Abanoub",
    email: "abanoub@example.com"
  },
  {
    name: "John",
    email: "john@example.com"
  }
];

We can generate CSV:

const csv = [
  "name,email",
  ...users.map(user =>
    `${user.name},${user.email}`
  )
].join("\n");

Then:

const blob = new Blob(
  [csv],
  {
    type: "text/csv;charset=utf-8"
  }
);

Create the download:

const url = URL.createObjectURL(blob);

const link = document.createElement("a");

link.href = url;
link.download = "users.csv";

link.click();

URL.revokeObjectURL(url);

The browser will download:

users.csv

Blob vs File

This is one of the most important distinctions.

A File is essentially a specialized kind of Blob.

Conceptually:

Blob
  ↑
  |
 File

A Blob primarily represents binary data.

A File represents binary data plus file-oriented metadata, such as:

filename
last modified timestamp

For example:

const file = new File(
  ["Hello"],
  "hello.txt",
  {
    type: "text/plain"
  }
);

We can inspect:

console.log(file.name);
console.log(file.size);
console.log(file.type);
console.log(file.lastModified);

File Is a Blob

You can check:

const file = new File(
  ["Hello"],
  "hello.txt",
  {
    type: "text/plain"
  }
);

console.log(file instanceof Blob);

Result:

true

That's why APIs that accept Blob often also accept File.

For example:

function processBlob(blob) {
  console.log(blob.size);
}

You can pass:

processBlob(file);

because File is a Blob.

Creating a File from a Blob

Suppose we already have:

const blob = new Blob(
  ["Hello from JavaScript"],
  {
    type: "text/plain"
  }
);

We can turn it into a File:

const file = new File(
  [blob],
  "hello.txt",
  {
    type: blob.type
  }
);

Now:

console.log(file.name);

returns:

hello.txt

Uploading a Blob

You can send a Blob directly using fetch().

Example:

const blob = new Blob(
  ["Hello from the browser"],
  {
    type: "text/plain"
  }
);

const response = await fetch(
  "/api/upload",
  {
    method: "POST",
    body: blob
  }
);

The request body contains the Blob data.

You can also explicitly specify headers:

await fetch(
  "/api/upload",
  {
    method: "POST",
    headers: {
      "Content-Type": "text/plain"
    },
    body: blob
  }
);

Uploading a File Using FormData

For normal file uploads, FormData is often more convenient.

HTML:

<input
  type="file"
  id="fileInput"
/>

JavaScript:

const input = document.getElementById("fileInput");

const file = input.files[0];

const formData = new FormData();

formData.append(
  "file",
  file
);

await fetch(
  "/api/upload",
  {
    method: "POST",
    body: formData
  }
);

Notice that we don't manually set:

Content-Type

when using FormData.

The browser needs to generate the multipart boundary automatically.

Receiving a Blob from an API

This is another extremely important use case.

Suppose your backend exposes:

GET /api/report

and returns a PDF.

Instead of:

const data = await response.json();

you can do:

const response = await fetch(
  "/api/report"
);

const blob = await response.blob();

Now you have the PDF as a Blob.

You can download it.

const url = URL.createObjectURL(blob);

const link = document.createElement("a");

link.href = url;
link.download = "report.pdf";

link.click();

URL.revokeObjectURL(url);

Opening a PDF

You don't necessarily need to download it.

You can create an object URL:

const response = await fetch(
  "/api/report"
);

const blob = await response.blob();

const url = URL.createObjectURL(blob);

Then:

window.open(url);

Or put it inside an iframe:

<iframe id="pdfViewer"></iframe>

const iframe = document.getElementById(
  "pdfViewer"
);

iframe.src = url;

Complete Practical Example

Now let's build a small application that demonstrates the Blob workflow.

Our application will allow the user to:

Select an image.
Preview it.
Convert/process the image as Blob data.
Display Blob metadata.
Download the image Blob.

HTML

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">

  <meta
    name="viewport"
    content="width=device-width, initial-scale=1.0"
  >

  <title>Blob Demo</title>
</head>

<body>

  <h1>Blob Image Demo</h1>

  <input
    type="file"
    id="imageInput"
    accept="image/*"
  />

  <br><br>

  <img
    id="preview"
    width="400"
    alt="Preview"
  >

  <p>
    Size:
    <span id="size"></span>
  </p>

  <p>
    Type:
    <span id="type"></span>
  </p>

  <button id="downloadButton">
    Download
  </button>

  <script src="app.js"></script>

</body>
</html>

JavaScript

const imageInput =
  document.getElementById("imageInput");

const preview =
  document.getElementById("preview");

const sizeElement =
  document.getElementById("size");

const typeElement =
  document.getElementById("type");

const downloadButton =
  document.getElementById("downloadButton");

let currentBlob = null;
let currentUrl = null;

When the user selects an image:

imageInput.addEventListener(
  "change",
  () => {

    const file =
      imageInput.files[0];

    if (!file) {
      return;
    }

    currentBlob = file;

    sizeElement.textContent =
      `${file.size} bytes`;

    typeElement.textContent =
      file.type;

    if (currentUrl) {
      URL.revokeObjectURL(currentUrl);
    }

    currentUrl =
      URL.createObjectURL(file);

    preview.src =
      currentUrl;
  }
);

Then implement downloading:

downloadButton.addEventListener(
  "click",
  () => {

    if (!currentBlob) {
      alert("Please select an image first.");
      return;
    }

    const url =
      URL.createObjectURL(currentBlob);

    const link =
      document.createElement("a");

    link.href = url;

    link.download =
      "downloaded-image";

    link.click();

    URL.revokeObjectURL(url);
  }
);

Understanding What Happened

The complete flow is:

flowchart TD
    A[User selects image] --> B[File object]
    B --> C[File is a Blob]
    C --> D[URL.createObjectURL]
    D --> E[Blob URL]
    E --> F[Image Preview]

    C --> G[Download]
    G --> H[Browser saves file]

The important point is that we didn't upload anything to the server.

The browser already has the file data.

We simply created a temporary URL pointing to that data.

A More Interesting Example: Generate an Image Blob

We can also create Blob data ourselves.

For example, using a Canvas:

const canvas =
  document.createElement("canvas");

canvas.width = 500;
canvas.height = 300;

const context =
  canvas.getContext("2d");

context.fillStyle = "black";

context.fillRect(
  0,
  0,
  500,
  300
);

Now draw some text:

context.fillStyle = "white";

context.font =
  "30px Arial";

context.fillText(
  "Hello Blob!",
  150,
  150
);

We can convert the canvas to a Blob:

canvas.toBlob(
  blob => {

    console.log(blob);

  },
  "image/png"
);

Now we have:

Canvas
   ↓
PNG Blob

Canvas → Blob → Download

We can combine everything:

canvas.toBlob(
  blob => {

    if (!blob) {
      return;
    }

    const url =
      URL.createObjectURL(blob);

    const link =
      document.createElement("a");

    link.href = url;

    link.download =
      "generated-image.png";

    link.click();

    URL.revokeObjectURL(url);
  },
  "image/png"
);

This is a very practical browser capability.

You can generate an image entirely on the client and download it without a backend.

Blob and `fetch()`

The Fetch API provides several ways to consume a response.

For example:

const response = await fetch("/api/data");

You might use:

await response.json();

for JSON.

Or:

await response.text();

for text.

Or:

await response.blob();

for binary/file-like data.

Or:

await response.arrayBuffer();

for lower-level binary processing.

A useful mental model is:

flowchart TD
    A[HTTP Response] --> B[JSON]
    A --> C[Text]
    A --> D[Blob]
    A --> E[ArrayBuffer]

Choose the representation based on what you need to do with the response.

Blob vs ArrayBuffer vs Uint8Array

This is an area that often confuses developers.

These concepts are related, but they serve different purposes.

Blob

Think:

"I have some data that I want to treat as a file-like binary object."

Example:

const blob = new Blob(
  [data],
  {
    type: "image/png"
  }
);

Great for:

files
downloads
previews
uploads
media
browser APIs

ArrayBuffer

Think:

"I need access to raw binary memory."

Example:

const buffer =
  await blob.arrayBuffer();

An ArrayBuffer represents a fixed-length block of binary memory.

It doesn't tell you what those bytes mean.

Uint8Array

Think:

"I want to access the individual bytes."

Example:

const bytes =
  new Uint8Array(buffer);

console.log(bytes[0]);
console.log(bytes[1]);

Comparison

API	Main Purpose
Blob	File-like binary data
File	Blob + filename/metadata
ArrayBuffer	Raw binary memory
Uint8Array	View/access individual bytes

A useful conceptual relationship is:

flowchart LR
    A[Blob] -->|arrayBuffer| B[ArrayBuffer]
    B --> C[Uint8Array]

But don't think of these as simply different names for the same thing.

They represent different abstractions.

Blob Streams

For large data, streaming can be important.

A Blob can produce a readable stream:

const blob = new Blob([
  "Large amount of data..."
]);

const stream =
  blob.stream();

You can consume it using a reader:

const reader =
  stream.getReader();

while (true) {

  const {
    done,
    value
  } = await reader.read();

  if (done) {
    break;
  }

  console.log(value);
}

The value contains chunks of data.

This is useful when you don't want to conceptually treat the entire resource as one immediately-consumed value.

Memory Management

Blob-related code often involves browser-managed resources.

One particularly important API is:

URL.createObjectURL()

Whenever you create:

const url =
  URL.createObjectURL(blob);

you should eventually consider:

URL.revokeObjectURL(url);

For example:

const url =
  URL.createObjectURL(blob);

image.src = url;

image.onload = () => {
  URL.revokeObjectURL(url);
};

Why Does `revokeObjectURL()` Matter?

Imagine a UI where users continuously select images:

Image 1 → createObjectURL()
Image 2 → createObjectURL()
Image 3 → createObjectURL()
Image 4 → createObjectURL()
...

If you keep creating object URLs and never release them, the browser may retain resources longer than necessary.

A better pattern is:

if (currentUrl) {
  URL.revokeObjectURL(currentUrl);
}

currentUrl =
  URL.createObjectURL(newBlob);

This is especially important in:

image galleries
file managers
video previews
drag-and-drop interfaces
React applications
Angular applications
long-lived single-page applications

Common Mistake #1: Confusing Blob With File

A Blob is not necessarily a file on disk.

This:

const blob = new Blob([
  "Hello"
]);

doesn't mean you created:

hello.txt

on the user's filesystem.

You've created binary data represented by a JavaScript object.

To create a downloadable file, you need to explicitly provide a filename through the download mechanism or create a File object.

Common Mistake #2: Forgetting the MIME Type

You can technically create:

const blob = new Blob([
  data
]);

But if the consuming API needs to know what kind of data it is, specify the type:

const blob = new Blob(
  [data],
  {
    type: "application/pdf"
  }
);

or:

const blob = new Blob(
  [data],
  {
    type: "image/png"
  }
);

Common Mistake #3: Forgetting to Revoke Object URLs

Avoid repeatedly doing:

const url =
  URL.createObjectURL(blob);

without eventually releasing the URL when appropriate.

Use:

URL.revokeObjectURL(url);

Common Mistake #4: Manually Setting Content-Type with FormData

This is a common mistake:

fetch("/upload", {
  method: "POST",
  headers: {
    "Content-Type": "multipart/form-data"
  },
  body: formData
});

Don't manually set this header in normal browser FormData uploads.

Use:

fetch("/upload", {
  method: "POST",
  body: formData
});

The browser generates the correct multipart boundary.

Common Mistake #5: Assuming Blob Automatically Compresses Data

Blob does not mean:

compressed data

A Blob is simply a representation of binary data.

For example:

new Blob([
  hugeString
]);

doesn't automatically compress hugeString.

Compression is a separate concern.

Common Mistake #6: Converting Everything to Base64

Developers sometimes use:

Binary data → Base64 → JSON

for everything.

This can be convenient in some APIs, but it isn't always the best choice.

Base64 introduces additional representation overhead and often makes binary transfer less direct.

For file operations, Blob/File plus fetch() or FormData is often a much more natural browser-side approach.

Blob in React

The Blob API isn't specific to vanilla JavaScript.

You can use it directly inside React.

Example:

function ImagePreview() {

  const [url, setUrl] =
    React.useState(null);

  const handleChange = event => {

    const file =
      event.target.files[0];

    if (!file) {
      return;
    }

    const objectUrl =
      URL.createObjectURL(file);

    setUrl(objectUrl);
  };

  return (
    <>
      <input
        type="file"
        accept="image/*"
        onChange={handleChange}
      />

      {url && (
        <img
          src={url}
          width="300"
          alt="Preview"
        />
      )}
    </>
  );
}

In a production React application, you should also clean up the object URL appropriately.

Blob in Angular

The same browser APIs are available in Angular.

For example:

this.http.get(
  '/api/report',
  {
    responseType: 'blob'
  }
);

Then:

this.http.get(
  '/api/report',
  {
    responseType: 'blob'
  }
).subscribe(blob => {

  const url =
    URL.createObjectURL(blob);

  window.open(url);

});

This is one of the most common Blob patterns in Angular applications.

A Complete API Download Example

Suppose the backend provides:

GET /api/reports/monthly

and returns:

application/pdf

The frontend can do:

async function downloadReport() {

  const response =
    await fetch(
      "/api/reports/monthly"
    );

  if (!response.ok) {
    throw new Error(
      "Failed to download report"
    );
  }

  const blob =
    await response.blob();

  const url =
    URL.createObjectURL(blob);

  const link =
    document.createElement("a");

  link.href = url;

  link.download =
    "monthly-report.pdf";

  document.body.appendChild(link);

  link.click();

  link.remove();

  URL.revokeObjectURL(url);
}

This pattern is extremely common in real-world applications.

A Complete Upload + Preview Workflow

Let's put the concepts together.

flowchart TD
    A[User selects File] --> B[File object]
    B --> C[File is a Blob]
    C --> D[createObjectURL]
    D --> E[Image Preview]

    C --> F[FormData]
    F --> G[POST /upload]
    G --> H[Backend]

    H --> I[Stored File]

    H --> J[GET /download]
    J --> K[Response Blob]
    K --> L[Object URL]
    L --> M[Download]

This is the architecture behind many file upload/download interfaces.

When Should You Use Blob?

Blob is a good choice when you're dealing with browser-side binary or file-like data.

Use Blob when you need to:

Preview files

URL.createObjectURL(file)

Download generated data

new Blob([...])

Download API responses

response.blob()

Upload binary data

fetch(url, {
  method: "POST",
  body: blob
});

Generate files dynamically

new Blob([
  csv
]);

Work with media

Images, audio, and video frequently interact with Blob/File APIs.

When Should You Use ArrayBuffer Instead?

Use ArrayBuffer when you need lower-level binary access.

For example:

const buffer =
  await response.arrayBuffer();

This becomes more appropriate when you're manipulating the bytes themselves.

Examples include:

cryptography
binary protocols
binary file parsing
WebSockets
Web Audio
low-level encoding/decoding

A useful rule is:

Blob is file-oriented; ArrayBuffer is byte-oriented.

It's not an absolute rule, but it's a very useful mental model.

Blob Is Not Just "A File"

This is probably the most important idea to take away.

A Blob doesn't necessarily represent a physical file.

Instead, think of it as:

An immutable container for binary data that the browser can consume as file-like data.

That distinction explains why you can create a Blob from:

const blob = new Blob([
  "Hello"
]);

without creating anything on the user's disk.

You can then decide what you want to do with it:

Blob
 ├── Preview
 ├── Download
 ├── Upload
 ├── Read as text
 ├── Read as ArrayBuffer
 ├── Stream
 └── Convert to File

A Practical Mental Model

When working with browser file APIs, think about the following layers:

flowchart TD
    A[Data] --> B[Blob]
    B --> C[Object URL]
    C --> D[Browser Resource]

    B --> E[File]
    E --> F[File Upload]

    B --> G[ArrayBuffer]
    G --> H[Byte-Level Processing]

Each abstraction has a different job.

Blob

File-like binary data.

File

Blob + filename and file metadata.

Object URL

A temporary browser URL that points to Blob/File data.

ArrayBuffer

Raw binary memory.

Uint8Array

A byte-oriented view over binary memory.

Final Example: Everything Together

Here is a compact example that demonstrates several concepts at once.

<input
  type="file"
  id="fileInput"
/>

<img
  id="preview"
  width="300"
/>

<button id="download">
  Download
</button>

const fileInput =
  document.getElementById("fileInput");

const preview =
  document.getElementById("preview");

const downloadButton =
  document.getElementById("download");

let selectedFile = null;
let previewUrl = null;

fileInput.addEventListener(
  "change",
  () => {

    const file =
      fileInput.files[0];

    if (!file) {
      return;
    }

    selectedFile = file;

    if (previewUrl) {
      URL.revokeObjectURL(previewUrl);
    }

    previewUrl =
      URL.createObjectURL(file);

    preview.src =
      previewUrl;
  }
);

downloadButton.addEventListener(
  "click",
  () => {

    if (!selectedFile) {
      return;
    }

    const url =
      URL.createObjectURL(
        selectedFile
      );

    const link =
      document.createElement("a");

    link.href = url;

    link.download =
      selectedFile.name;

    link.click();

    URL.revokeObjectURL(url);
  }
);

The important flow is:

File
 ↓
Blob
 ↓
Object URL
 ↓
Preview

and:

File
 ↓
Blob
 ↓
Object URL
 ↓
Download

Final Thoughts

The Blob API looks simple at first:

new Blob(...)

but it is actually one of the fundamental browser APIs for working with binary data.

Once you understand Blob, several other browser concepts become much easier to understand:

File
FileReader
FormData
URL.createObjectURL()
fetch().blob()
ArrayBuffer
Uint8Array
file uploads
file downloads
image previews
generated files
API-generated PDFs
browser-side media processing

The most important mental model is:

Blob = immutable binary data

Then:

File = Blob + file metadata

and:

Object URL = temporary browser URL pointing to Blob/File data

while:

ArrayBuffer = raw binary memory

and:

Uint8Array = byte-level view of that memory

Once these distinctions are clear, working with files and binary data in JavaScript becomes much less mysterious.

Quick Cheat Sheet

// Create Blob
const blob = new Blob(
  ["Hello"],
  {
    type: "text/plain"
  }
);

// Size
console.log(blob.size);

// MIME type
console.log(blob.type);

// Read as text
const text = await blob.text();

// Read as binary memory
const buffer =
  await blob.arrayBuffer();

// Create temporary URL
const url =
  URL.createObjectURL(blob);

// Release temporary URL
URL.revokeObjectURL(url);

// Convert Blob to File
const file = new File(
  [blob],
  "hello.txt",
  {
    type: blob.type
  }
);

// Get Blob from Fetch response
const response =
  await fetch("/file");

const downloadedBlob =
  await response.blob();

If you understand these APIs, you already have the foundation needed for most browser-side file and binary-data workflows.

Web Performance Optimization: How to Find and Fix the Real Bottleneck

Abanoub Kerols — Wed, 07 Oct 2026 21:13:03 +0000

A user clicks a button.

Nothing happens.

They wait.

Maybe the page eventually responds. Maybe an API request is still running. Maybe the browser is processing a huge JavaScript bundle. Maybe the database is scanning millions of rows.

From the user's perspective, there is only one conclusion:

The application is slow.

But from an engineer's perspective, this statement is incomplete.

Where is the slowness actually coming from?

It could be the browser, JavaScript, CSS, images, the API, server-side code, the database, a third-party service, the network, or even the infrastructure running the application.

That is why Web Performance Optimization is not simply about making a frontend load faster.

It is about developing a systematic way to answer one question:

Where is the bottleneck, and what evidence proves it?

This article builds a practical mental model for diagnosing and improving performance across the entire web application stack.

What Is Web Performance?
Measure Before You Optimize
Core Web Vitals
Finding the Root Cause
Understanding the Critical Path
Frontend Performance Optimization
Lazy Loading
When Frontend Optimization Isn't Enough
Database Performance
Caching
Algorithms and Profiling
Network, HTTP and CDN
Production Monitoring
A Real Production Scenario
The Performance Optimization Framework
Final Mental Model

What Is Web Performance?

Web performance describes how quickly and efficiently a web application loads, renders, responds to user interaction, communicates with servers, and completes the work requested by users.

It includes much more than:

"How many seconds does the page take to load?"

It includes:

Initial page loading.
Time until important content becomes visible.
Interaction responsiveness.
API latency.
Database query performance.
Server processing time.
Network latency.
JavaScript execution.
Rendering performance.
Visual stability.

Consider this request:

User
  ↓
Browser
  ↓
HTTP Request
  ↓
Backend
  ↓
Database
  ↓
Response
  ↓
Browser Rendering

The user experiences the entire chain.

If the database takes 1.5 seconds, the user doesn't say:

"The database query has a poor execution plan."

They say:

"This page is slow."

That's why performance is ultimately a user-experience concern supported by engineering measurements.

Perceived vs Actual Performance

There is also an important distinction between actual performance and perceived performance.

A page might technically finish loading quickly but still feel slow if the user sees a blank screen for most of that time.

Conversely, a page can start showing useful content quickly while some non-critical work continues in the background.

For example:

Bad experience:

Blank screen
     ↓
     ↓
     ↓
Everything appears

versus:

Better experience:

Header
  ↓
Main content
  ↓
Interactive UI
  ↓
Non-critical content

Performance optimization is therefore not simply about reducing total execution time.

It's about prioritizing the work that matters most to the user.

Measure Before You Optimize

The easiest performance mistake to make is optimizing based on assumptions.

You notice a slow page and immediately start:

rewriting components,
adding caching,
introducing a CDN,
changing database indexes,
splitting bundles.

But what if none of those things is the actual bottleneck?

A better process is:

flowchart TD
    A[Measure] --> B[Reproduce]
    B --> C[Inspect / Profile]
    C --> D[Identify Bottleneck]
    D --> E[Optimize]
    E --> F[Measure Again]
    F --> G[Monitor]
    G --> C

The rule is simple:

Don't optimize blindly.

Core Web Vitals

One of the first places to look when evaluating web performance is Core Web Vitals.

The three primary metrics are:

Metric	What it measures	Common causes of poor results
LCP	Loading performance	Slow server, large images, blocking CSS/JS
INP	Interaction responsiveness	Expensive JavaScript, long tasks
CLS	Visual stability	Images without dimensions, dynamic content, fonts

LCP — Largest Contentful Paint

LCP measures when the largest important content element becomes visible.

A poor LCP could be caused by:

Slow HTML response
      ↓
Render-blocking CSS
      ↓
Large image
      ↓
Slow font
      ↓
Network latency

Notice something important:

LCP is not necessarily a frontend-only problem.

If the server takes 1.5 seconds to generate the HTML, optimizing an image won't solve the entire problem.

INP — Interaction to Next Paint

INP focuses on how quickly the application responds to user interactions.

Consider:

button.addEventListener("click", () => {
  performExpensiveCalculation();
});

If that calculation blocks the browser's main thread, the user may click the button and experience a noticeable delay.

This is why JavaScript optimization is not only about bundle size.

A small JavaScript bundle can still contain expensive runtime work.

CLS — Cumulative Layout Shift

CLS measures unexpected movement of page content.

For example:

Article title

[Image loading...]

Button

Then the image appears:

Article title

[Large image]

Button moved ↓

The user may try to click the button while it moves.

Providing dimensions helps reserve the required space:

<img
  src="/hero.webp"
  width="1200"
  height="675"
  alt="Hero image"
/>

Lab Data vs Field Data

Performance measurements can come from controlled environments or real users.

Lab data is useful for debugging and reproducible testing.

Tools include:

Chrome DevTools
Lighthouse

Field data represents real users and real conditions.

For example:

Developer machine
→ Fast CPU
→ Fast Wi-Fi
→ Low latency

Real user
→ Mid-range phone
→ 4G
→ High latency

A website that looks excellent on a developer's laptop can still perform poorly for real users.

That's why production performance needs both controlled testing and real-user measurements.

Finding the Root Cause

Metrics tell us what is wrong.

Profiling helps explain why.

Chrome DevTools is particularly useful here.

Network tab

Use it to investigate:

Request duration.
Response size.
Waterfalls.
API latency.
Cache behavior.
Blocking resources.

Performance tab

Use it to investigate:

JavaScript execution.
Long tasks.
Layout.
Painting.
Rendering.
Frame drops.
Main-thread activity.

A useful debugging question is:

What operation is consuming the time?

Not:

"Which framework is slow?"

Understanding the Critical Path

When a browser loads a page, not every resource has equal importance.

A simplified rendering process looks like:

flowchart LR
    A[HTML] --> B[DOM]
    A --> C[CSS]
    C --> D[CSSOM]
    B --> E[Render Tree]
    D --> E
    E --> F[Layout]
    F --> G[Paint]
    G --> H[Composite]

Some resources are critical resources because they can delay rendering.

Examples include:

Critical CSS.
Important JavaScript.
LCP images.
Fonts required for visible content.

The goal isn't to make every resource load immediately.

The goal is to make important resources available at the right time.

Frontend Performance Optimization

Once measurement proves that the browser is the bottleneck, frontend optimization becomes much more useful.

JavaScript Optimization

Large JavaScript bundles increase:

Download time.
Parsing time.
Compilation time.
Execution time.

Useful techniques include:

Code splitting.
Tree shaking.
Dynamic imports.
Lazy loading.
Removing unused dependencies.
Minification.
Compression.
Reducing unnecessary JavaScript execution.

For example:

const AdminDashboard = lazy(
  () => import("./AdminDashboard")
);

The dashboard code doesn't need to be part of the initial bundle if the user doesn't immediately need it.

But bundle size isn't everything.

This can still be problematic:

Small bundle
     ↓
Expensive JavaScript execution
     ↓
Long main-thread task
     ↓
Poor INP

CSS Optimization

CSS can become expensive when it is:

Large.
Unused.
Render-blocking.
Responsible for excessive style recalculation.

Potential improvements include:

Removing unused CSS.
Minifying CSS.
Splitting CSS where appropriate.
Keeping critical styles available early.
Avoiding unnecessary CSS complexity.

Image Optimization

Images can easily dominate page weight.

Useful techniques include:

Compression.
WebP.
AVIF.
Responsive images.
srcset.
sizes.
Correct dimensions.
Lazy loading for non-critical images.

Example:

<img
  src="product-800.webp"
  srcset="
    product-400.webp 400w,
    product-800.webp 800w,
    product-1200.webp 1200w
  "
  sizes="(max-width: 600px) 100vw, 50vw"
  alt="Product"
/>

However, don't lazy-load everything.

An image responsible for LCP may need to load immediately.

The important question is:

Is this resource critical to the initial experience?

Lazy Loading

Lazy loading means delaying work until it is actually needed.

It can be applied to:

Images.
JavaScript.
Components.
Routes.
Data.

For example:

const ReportsPage = lazy(
  () => import("./ReportsPage")
);

This reduces the amount of work required during the initial page load.

But lazy loading has a trade-off.

If the user immediately needs a resource, delaying it can make the experience worse.

Therefore:

Critical resource
       ↓
Load early

Non-critical resource
       ↓
Load later

Lazy loading is not automatically good.

Correct prioritization is good.

When Frontend Optimization Isn't Enough

Suppose DevTools shows that the browser is mostly idle.

The frontend looks reasonable.

But this request takes almost two seconds:

GET /api/products
→ 1.8 seconds

Now the investigation moves deeper.

flowchart TD
    A[Browser] --> B[API]
    B --> C[Application Server]
    C --> D[Database]
    C --> E[Third-Party Services]

We need to measure each layer.

For example:

Total request:        1800 ms
Server processing:     900 ms
Database:              700 ms
External API:          150 ms
Other overhead:         50 ms

Now we have evidence.

The database is a much better optimization target than the CSS.

Database Performance

Common database bottlenecks include:

Slow queries.
Missing indexes.
N+1 queries.
Large datasets.
Unnecessary joins.
Fetching unnecessary columns.
Poor pagination.
Excessive database round trips.

Instead of:

SELECT *
FROM users;

retrieve only what is required:

SELECT id, name, email
FROM users
LIMIT 50;

And avoid returning thousands of records when the UI only displays the first page.

Connection pooling can also reduce the cost of repeatedly creating database connections.

Query Execution Plans

When a SQL query is slow, use an execution plan instead of guessing.

For example:

EXPLAIN ANALYZE
SELECT *
FROM orders
WHERE customer_id = 123;

The plan can reveal expensive operations such as table scans or inefficient joins.

You might discover:

Table Scan
    ↓
Millions of rows examined

when an index could enable:

Index Scan
    ↓
Small number of matching rows

But indexes have costs.

They consume:

Storage.
Memory.
Write performance.

Every insert, update, or delete may require index maintenance.

So:

Add indexes because real query patterns need them—not simply because indexes are available.

NoSQL Performance

The same principle applies to NoSQL databases.

Performance depends heavily on the way the application accesses data.

Consider:

Embedding vs referencing.
Indexes.
Aggregations.
Document size.
Read/write patterns.
Query patterns.

A useful design question is:

How will the application access this data?

Database design should reflect real access patterns.

Third-Party Services

Your application may depend on systems outside your infrastructure:

Payment gateways.
Maps.
Analytics.
Authentication providers.
External APIs.

For example:

flowchart LR
    A[Your API] --> B[Payment Gateway]
    A --> C[Maps API]
    A --> D[Authentication Provider]

Any of these can become a bottleneck.

Possible strategies include:

Timeouts.
Carefully controlled retries.
Caching.
Queues.
Asynchronous processing.
Circuit breakers.
Fallbacks.
Graceful degradation.

For example, sending an email doesn't necessarily need to block the HTTP response.

Request
  ↓
Create account
  ↓
Queue email
  ↓
Return response

The email can be processed asynchronously.

Caching

Caching reduces repeated expensive work.

It can exist at multiple layers:

flowchart TD
    A[Browser Cache] --> B[CDN]
    B --> C[Reverse Proxy]
    C --> D[Application Cache]
    D --> E[Redis]
    E --> F[Database]

A common application-level approach is cache-aside:

flowchart TD
    A[Request] --> B{Cache hit?}
    B -->|Yes| C[Return cached data]
    B -->|No| D[Query Database]
    D --> E[Store in Cache]
    E --> F[Return data]

But caching introduces complexity.

You need to consider:

Cache invalidation.
Stale data.
Expiration.
Cache stampedes.
Memory usage.

Caching is powerful when the same expensive data is repeatedly requested.

It is not automatically useful for every piece of data.

Algorithms and Profiling

Sometimes the bottleneck isn't the infrastructure.

It's the algorithm.

Consider nested loops:

for (const user of users) {
  for (const order of orders) {
    if (order.userId === user.id) {
      // ...
    }
  }
}

This can approach:

O(n × m)

A lookup structure such as Map can often reduce the amount of repeated searching.

Common complexity classes include:

Complexity	Example intuition
O(1)	Direct lookup
O(log n)	Binary search
O(n)	Linear scan
O(n log n)	Efficient sorting
O(n²)	Nested comparisons

This is why an algorithmic improvement can sometimes outperform infrastructure changes by a huge margin.

Profiling

Profiling helps answer:

Where is the program spending its time?

A profiler can reveal:

CPU usage.
Memory consumption.
Expensive functions.
Repeated operations.
Blocking work.

It's useful to distinguish:

Measurement
→ How fast is it?

Logging
→ What happened?

Profiling
→ Where is the time going?

Monitoring
→ Is the system healthy over time?

Network, HTTP and CDN

Even when the application server is fast, users can experience latency because of the network.

A simplified request looks like:

sequenceDiagram
    participant B as Browser
    participant D as DNS
    participant S as Server

    B->>D: DNS Lookup
    D-->>B: IP Address
    B->>S: TCP/TLS + HTTP Request
    S-->>B: Response

Latency can come from:

DNS lookup.
TCP connection.
TLS handshake.
Physical distance.
Server processing.
Response transfer.

HTTP/1.1 vs HTTP/2 vs HTTP/3

Modern HTTP protocols improve how resources are transferred.

HTTP/1.1 uses traditional request/connection behavior.

HTTP/2 introduces multiplexing, allowing multiple streams over a connection.

HTTP/3 uses QUIC and can improve connection establishment and behavior under certain network conditions.

But the most fundamental optimization often remains:

Send less data.

Reducing response size can be more effective than trying to make a slow network magically faster.

Cache Headers

HTTP caching can prevent unnecessary transfers.

Important headers include:

Cache-Control
ETag
Last-Modified
Expires

For example, a versioned static asset can use:

Cache-Control: public, max-age=31536000, immutable

while frequently changing resources may need revalidation.

Caching strategy should reflect how often the resource changes.

CDN

A CDN places cached resources closer to users.

Without a CDN:

User
  ↓
Origin Server

With a CDN:

User
  ↓
Nearest Edge Location
  ↓
Cached Content

This is particularly useful for:

Images.
JavaScript.
CSS.
Fonts.
Videos.
Static assets.

A CDN can reduce network latency, but it cannot fix:

Slow database query

or:

Inefficient server algorithm

The CDN optimizes delivery, not application architecture.

Performance vs Scalability

Microservices and horizontal scaling are often discussed in performance conversations, but they solve different problems.

Performance:

How quickly does the system perform a given operation?

Scalability:

How well does the system handle increasing workload?

Microservices can enable independent scaling:

flowchart LR
    LB[Load Balancer] --> A[Auth Service]
    LB --> B[Orders Service]
    LB --> C[Payments Service]

    A --> DB1[(Auth DB)]
    B --> DB2[(Orders DB)]
    C --> DB3[(Payments DB)]

But microservices also introduce:

Network overhead.
Distributed-system complexity.
Monitoring requirements.
Deployment complexity.
Data consistency challenges.

Therefore:

Microservices are not automatically faster.

A Real Production Scenario

Imagine a production application with:

LCP:        Poor
INP:        Poor
API:        1.8s
Database:   900ms
Images:     Large
JS Bundle:  Large

Where should we start?

Not with a random frontend rewrite.

Start with measurements.

flowchart TD
    A[Slow Application] --> B[Measure]
    B --> C{Browser bottleneck?}

    C -->|Yes| D[JS / CSS / Images / Rendering]
    C -->|No| E{API bottleneck?}

    E -->|Yes| F[Profile Server]
    E -->|No| G[Inspect Network / Infrastructure]

    F --> H{Database slow?}
    H -->|Yes| I[Query Plan / Index / Query Optimization]
    H -->|No| J[Application / External Services]

    D --> K[Measure Again]
    I --> K
    J --> K
    G --> K

Suppose the database query is optimized:

Database: 900ms → 80ms
API:      1.8s  → 400ms

Now the remaining LCP or INP problems can be investigated separately.

This is much more effective than optimizing everything simultaneously.

Performance Budgets

Performance should become an engineering constraint rather than an emergency task.

A team might define budgets such as:

JavaScript bundle   < 250 KB
Critical images     < 150 KB
API p95 latency     < 500 ms
LCP                 < 2.5 s
INP                 < 200 ms
CLS                 < 0.1

The exact numbers depend on the application.

The important part is that performance becomes measurable and enforceable.

Production Monitoring

Performance does not end when the optimization is deployed.

A new feature can add:

+500 KB JavaScript

A database can grow from:

100K rows → 20M rows

Traffic can increase dramatically.

A third-party API can become slower.

Therefore, performance needs continuous monitoring.

Useful metrics include:

Request latency.
p50 / p95 / p99 latency.
Error rate.
Throughput.
CPU.
Memory.
Database latency.
Slow queries.
Core Web Vitals.

A common monitoring architecture is:

flowchart LR
    A[Application] --> B[Metrics]
    B --> C[Prometheus]
    C --> D[Grafana]
    D --> E[Dashboard]

Real User Monitoring

A production application should ideally collect performance data from actual users.

flowchart LR
    A[Real Users] --> B[Browser Metrics]
    B --> C[Backend]
    C --> D[Storage]
    D --> E[Aggregation]
    E --> F[Dashboard]

This lets you detect trends such as:

LCP becoming worse after a deployment.
Mobile users experiencing higher INP.
Certain pages having poor CLS.
Geographic regions experiencing higher latency.

A single Lighthouse test is a snapshot.

Real-user monitoring shows what is happening over time.

Alerts

Dashboards are useful, but engineers cannot stare at them all day.

Alerts should represent meaningful problems.

For example:

API p95 latency > 1 second

or:

Error rate > 5%

or:

Database latency suddenly increases

Good alerting focuses on:

Symptoms + user impact

rather than generating an alert for every small internal fluctuation.

Too much alert noise eventually makes alerts useless.

Convincing Management

Performance work often requires engineering time.

The strongest argument is not:

"I think the website is slow."

Use data.

Instead:

"p95 API latency increased from 300 ms to 1.8 seconds, and this affects 40% of requests."

Then connect the technical problem to:

User experience.
Conversion.
Retention.
SEO.
Customer satisfaction.
Revenue.
Infrastructure cost.

Performance becomes much easier to prioritize when technical metrics are connected to business impact.

The Performance Optimization Framework

When a web application is slow, follow this loop:

1. Measure

Collect real metrics.

2. Reproduce

Find the conditions under which the problem occurs.

3. Diagnose

Use DevTools, profiling, logs, database execution plans, and server metrics.

4. Identify the Bottleneck

Check:

Browser
JavaScript
CSS
Images
API
Server
Database
Third-party Services
Network
CDN
Infrastructure

5. Prioritize

Fix the bottleneck with the highest impact.

6. Optimize

Apply the smallest effective change.

7. Measure Again

Compare the result with the baseline.

8. Monitor

Make sure the improvement remains effective in production.

Final Mental Model

When a web application is slow, don't immediately ask:

"How can I make the frontend faster?"

Ask:

"Where is the bottleneck?"

Then move through the system:

flowchart TD
    A[User] --> B[Browser]
    B --> C[Frontend]
    C --> D[API]
    D --> E[Server]
    E --> F[Database]
    E --> G[Third-Party Services]

    B -. Network .-> H[DNS / TCP / TLS]
    H -.-> D

    B -. CDN .-> I[CDN / Edge]
    I -.-> C

    D -. Infrastructure .-> J[CPU / RAM / Disk / Scaling]

The complete mental model is:

Measure
   ↓
Diagnose
   ↓
Optimize
   ↓
Measure Again
   ↓
Monitor
   ↺

The goal isn't to make every component theoretically perfect.

The goal is to find the actual bottleneck, prove it with measurements, improve it, verify the result, and continuously protect that performance in production.

That's the difference between randomly applying performance tricks and practicing Web Performance Engineering.

Conclusion

A slow web application is rarely solved by a single technique.

Sometimes the solution is a smaller JavaScript bundle.

Sometimes it's an optimized image.

Sometimes it's an index.

Sometimes it's a better algorithm.

Sometimes it's caching.

Sometimes it's a CDN.

And sometimes the correct optimization is simply realizing that the thing you were about to optimize was never the bottleneck.

The most valuable performance skill is therefore not memorizing optimization techniques.

It's learning how to systematically answer:

Where is the time going?

Once you can answer that question with evidence, the optimization strategy becomes much clearer.

Measure → Diagnose → Optimize → Measure → Monitor.

That loop is the foundation of reliable web performance.

Server-Side Rendering (SSR) and Hydration: How Modern Web Applications Become Fast and Interactive

Abanoub Kerols — Sat, 03 Oct 2026 21:11:04 +0000

Modern frontend frameworks have changed dramatically.

Applications that once rendered everything in the browser can now render HTML on the server, send meaningful content to the user immediately, and then transform that static HTML into a fully interactive application.

Two concepts are at the center of this architecture:

Server-Side Rendering (SSR)
Hydration

They are often mentioned together, but they solve different problems.

Understanding how they work internally is important if you work with Angular, React, Next.js, Nuxt, or modern full-stack applications.

In this article, we will build the concepts from first principles, understand the browser lifecycle, compare CSR vs SSR, understand hydration, explore common problems, and finally build a complete SSR + hydration project.

1. The Traditional Client-Side Rendering Model

Before understanding SSR, let's start with the traditional approach.

In a typical Client-Side Rendering (CSR) application:

Browser
   |
   | GET /
   v
Server
   |
   | HTML + JavaScript bundles
   v
Browser
   |
   | Download JS
   v
JavaScript executes
   |
   v
Application renders UI
   |
   v
User sees the page

For example, the server might initially return:

<!DOCTYPE html>
<html>
<head>
  <title>My App</title>
</head>

<body>
  <div id="root"></div>

  <script src="/assets/main.js"></script>
</body>
</html>

The important part is:

<div id="root"></div>

There isn't much actual application content in the initial HTML.

JavaScript must execute before the user gets the real UI.

2. What Happens During CSR?

Let's imagine this Angular/React-style application:

function App() {
  return (
    <main>
      <h1>Hello World</h1>
      <p>Welcome to my application.</p>
    </main>
  );
}

The browser initially receives:

<div id="root"></div>

Then:

Download JavaScript
       ↓
Parse JavaScript
       ↓
Execute JavaScript
       ↓
Create components
       ↓
Fetch data
       ↓
Render DOM
       ↓
User sees content

This can be perfectly fine.

But there is a problem.

The browser has to do a lot of work before the user sees meaningful content.

This becomes especially noticeable on:

slow networks
low-end mobile devices
large JavaScript applications
content-heavy websites
SEO-sensitive applications

3. The Idea Behind Server-Side Rendering

SSR changes the responsibility.

Instead of asking the browser to construct the initial HTML, we ask the server to render the application first.

The architecture becomes:

Browser
   |
   | GET /
   v
Application Server
   |
   | Render application
   v
HTML
   |
   | Send HTML
   v
Browser
   |
   | Display HTML immediately
   v
User sees content

For example, instead of:

<div id="root"></div>

the browser receives:

<div id="root">
  <main>
    <h1>Hello World</h1>
    <p>Welcome to my application.</p>
  </main>
</div>

The browser can display this content immediately.

But there is another problem.

The HTML is visible...

but is it interactive?

Not necessarily.

That brings us to hydration.

4. SSR Is Not the Same as Hydration

This distinction is extremely important.

SSR answers:

Who generates the initial HTML?

Answer:

The server.

Hydration answers:

How does the browser turn server-generated HTML into an interactive application?

Answer:

Client-side JavaScript attaches to the existing HTML.

So:

SSR
 ↓
Generate HTML on server
 ↓
Send HTML to browser
 ↓
Browser displays HTML
 ↓
Hydration
 ↓
JavaScript takes over
 ↓
Application becomes interactive

SSR and hydration are complementary concepts.

5. A Simple Analogy

Think about a restaurant.

CSR

The restaurant gives you:

Ingredients + recipe

You must cook the meal yourself.

SSR

The restaurant gives you:

A finished meal

You can immediately eat it.

But the restaurant still needs to give you:

Fork + knife

so you can interact with it.

That's hydration.

SSR = prepare the meal

Hydration = make the meal usable

6. What Exactly Is Hydration?

Suppose the server sends:

<button id="increment">
  Count: 0
</button>

The browser can display the button.

But the browser doesn't automatically know:

button.onclick = incrementCounter;

The server generated HTML.

The client application must now connect its JavaScript behavior to that existing DOM.

Conceptually:

Server HTML
     |
     v
<button>Count: 0</button>
     |
     | Hydration
     v
Existing DOM + JavaScript behavior
     |
     v
Interactive application

The framework doesn't necessarily throw away the existing DOM and recreate everything.

Instead, it attempts to reuse the server-rendered DOM.

7. SSR + Hydration Lifecycle

A simplified lifecycle looks like this:

             SERVER
               |
               v
        Application Code
               |
               v
        Render Components
               |
               v
           HTML Output
               |
               |
        HTTP Response
               |
               v
             BROWSER
               |
               v
        Parse HTML
               |
               v
       Display Content
               |
               v
       Download JS
               |
               v
          Hydration
               |
               v
       Attach Behavior
               |
               v
      Fully Interactive App

This is the fundamental architecture.

8. Why SSR Improves Perceived Performance

Imagine an application that takes:

HTML request             100ms
JavaScript download      500ms
JavaScript execution     300ms
API requests              300ms
Rendering                 100ms

With pure CSR, the user may wait for several of these stages before meaningful content appears.

With SSR, the server can generate the initial HTML:

Request
  ↓
Server renders HTML
  ↓
HTML arrives
  ↓
User sees content

JavaScript still needs to load.

But the user doesn't necessarily stare at an empty page while waiting.

This can improve metrics such as:

First Contentful Paint (FCP)
Largest Contentful Paint (LCP)
perceived performance

However, SSR is not automatically faster in every situation.

The server now has more work to perform.

9. SSR vs CSR

Let's compare them.

Feature	CSR	SSR
Initial HTML	Mostly empty shell	Meaningful HTML
Rendering	Browser	Server
Initial JS dependency	High	Lower for initial display
SEO	Can be harder	Usually easier
Server workload	Lower	Higher
Initial content	Usually later	Usually earlier
Hydration	Not applicable	Usually required
Scalability concerns	Mostly client-side	Server rendering required

A common misconception is:

SSR means there is no client-side JavaScript.

That's false.

Modern SSR applications are usually:

Server-rendered
+
Client-enhanced

10. The Most Important Concept: The Same UI Must Exist on Both Sides

Consider this component:

function App() {
  return <h1>Hello World</h1>;
}

The server renders:

<h1>Hello World</h1>

The browser then loads the client application.

The client expects:

<h1>Hello World</h1>

Everything matches.

Hydration can proceed normally.

But imagine the server renders:

<h1>Hello World</h1>

while the browser expects:

<h1>Hello Abanoub</h1>

Now we have a mismatch.

This is called a:

Hydration Mismatch

11. Hydration Mismatches

Hydration mismatches occur when the server-generated HTML doesn't match what the client expects.

For example:

function App() {
  return (
    <p>
      {Math.random()}
    </p>
  );
}

The server might generate:

<p>0.3214</p>

The browser might calculate:

<p>0.8421</p>

The DOM no longer matches.

Another common example:

const now = new Date();

return <p>{now.toLocaleTimeString()}</p>;

The server and browser may execute at different times.

Result:

Server:
10:30:01

Client:
10:30:02

Mismatch.

12. Browser-Only APIs Can Also Cause Problems

Consider:

const width = window.innerWidth;

The browser has:

window
document
localStorage
navigator

But the server doesn't have a browser DOM.

So this can fail during SSR:

window.innerWidth

or:

localStorage.getItem("theme");

or:

document.querySelector(...)

SSR code must distinguish between:

Server environment

and:

Browser environment

Modern frameworks provide APIs for handling this safely.

13. Data Fetching Is Another SSR Challenge

Suppose your application displays:

Product: MacBook Pro
Price: $1999

The server needs the data before rendering.

So:

Browser
   |
   | GET /products/1
   v
Server
   |
   | Fetch product
   v
Database / API
   |
   v
Product data
   |
   v
Render HTML
   |
   v
Browser

The generated HTML could contain:

<h1>MacBook Pro</h1>
<p>$1999</p>

This is excellent for the initial render.

But now we have another question:

Does the browser need to fetch the same data again during hydration?

Ideally, we want to avoid unnecessary duplicate requests.

14. Server-to-Client Data Transfer

A sophisticated SSR application often transfers server-fetched state to the client.

Conceptually:

Server

Fetch API
   ↓
Product data
   ↓
Render HTML
   ↓
Transfer state
   ↓
Browser
   ↓
Hydrate
   ↓
Reuse existing data

Without state transfer:

Server → API
Browser → API

The same data might be fetched twice.

With state transfer:

Server → API
        ↓
     Transfer
        ↓
     Browser

The browser can reuse the result.

This concept appears in different forms across frameworks.

15. Angular SSR

Angular provides first-class support for SSR.

A traditional Angular application might be rendered entirely in the browser:

Browser
  ↓
Angular Bootstrap
  ↓
Components
  ↓
DOM

With SSR:

Node.js Server
      ↓
Angular Application
      ↓
Rendered HTML
      ↓
Browser
      ↓
Angular Hydration
      ↓
Interactive Application

Modern Angular applications can use:

ng add @angular/ssr

This configures the project for server-side rendering.

16. A Complete Angular SSR Example

Let's create a small product application.

angular-ssr-demo/
│
├── src/
│   ├── app/
│   │   ├── app.ts
│   │   ├── app.html
│   │   └── product.service.ts
│   │
│   ├── main.ts
│   └── main.server.ts
│
├── server.ts
├── angular.json
└── package.json

The application will display:

Product Catalog

MacBook Pro
$1999

Add to Cart

17. Create the Application

Start with:

ng new angular-ssr-demo

Then:

cd angular-ssr-demo

Add SSR:

ng add @angular/ssr

Angular will configure the required server-side infrastructure.

18. Create a Product Service

import { Injectable } from '@angular/core';

export interface Product {
  id: number;
  name: string;
  price: number;
}

@Injectable({
  providedIn: 'root'
})
export class ProductService {

  getProduct(): Product {
    return {
      id: 1,
      name: 'MacBook Pro',
      price: 1999
    };
  }
}

19. Create the Component

import { Component, inject } from '@angular/core';
import { ProductService } from './product.service';

@Component({
  selector: 'app-root',
  template: `
    <main>
      <h1>Product Catalog</h1>

      <section>
        <h2>{{ product.name }}</h2>

        <p>
          Price: ${{ product.price }}
        </p>

        <button (click)="addToCart()">
          Add to Cart
        </button>

        <p>{{ message }}</p>
      </section>
    </main>
  `
})
export class AppComponent {

  private productService = inject(ProductService);

  product = this.productService.getProduct();

  message = '';

  addToCart() {
    this.message = 'Product added to cart!';
  }
}

Now notice something important.

The server can render:

<h1>Product Catalog</h1>

<h2>MacBook Pro</h2>

<p>Price: $1999</p>

<button>Add to Cart</button>

The user can see the content before the client application becomes interactive.

20. What Happens During Hydration?

The server produces:

<button>Add to Cart</button>

The browser displays it.

Then Angular loads.

Angular sees the existing DOM:

<button>Add to Cart</button>

and hydrates it.

Conceptually:

Existing DOM
     |
     v
Angular
     |
     v
Match component structure
     |
     v
Attach event behavior
     |
     v
Interactive button

Now when the user clicks:

Click
 ↓
Angular event handler
 ↓
addToCart()
 ↓
message changes
 ↓
UI updates

This is the transition from:

Static HTML

to:

Interactive application

21. Hydration Does Not Mean "Render Everything Again"

This is one of the most important mental models.

A naive mental model would be:

Server HTML
   ↓
Delete it
   ↓
Render application again

Modern hydration aims to do:

Server HTML
   ↓
Keep existing DOM
   ↓
Connect framework runtime
   ↓
Reuse DOM
   ↓
Interactive application

The goal is to avoid unnecessary DOM reconstruction.

22. Hydration and Event Handlers

Consider:

<button>
  Add to Cart
</button>

Before hydration:

Visible: YES
Interactive: NO

After hydration:

Visible: YES
Interactive: YES

This creates an important performance concept:

Time to Interactive

There can be a period where the user sees the application but JavaScript hasn't finished loading and hydrating.

For example:

0ms
 |
 | HTML arrives
 v
100ms
 |
 | User sees content
 v
300ms
 |
 | JavaScript downloaded
 v
500ms
 |
 | Hydration
 v
600ms
 |
 | Application interactive

The application can look ready before it is actually ready.

This is sometimes called the:

Hydration Gap

23. The Hydration Gap

Suppose the user sees:

[ Add to Cart ]

and immediately clicks it.

But hydration hasn't completed yet.

The click might not be handled.

This creates a UX problem.

Modern frameworks have developed techniques to reduce this problem.

One important approach is:

Partial Hydration

Instead of hydrating the entire application immediately, hydrate only the parts that need to become interactive.

24. Partial Hydration

Imagine a page:

------------------------------------------------
Header
------------------------------------------------
Hero Section
------------------------------------------------
Article Content
------------------------------------------------
Comments Widget
------------------------------------------------
Shopping Cart
------------------------------------------------
Footer
------------------------------------------------

Only these components may need JavaScript:

Comments Widget
Shopping Cart

Why hydrate the entire page?

Instead:

Static HTML
     |
     +---- Header
     |
     +---- Article
     |
     +---- Footer
     |
     +---- Hydrate Comments
     |
     +---- Hydrate Cart

This can significantly reduce client-side JavaScript work.

25. Angular Hydration Concepts

Angular supports hydration so that the server-rendered DOM can be reused on the client.

A typical setup uses:

provideClientHydration()

For example:

import {
  ApplicationConfig
} from '@angular/core';

import {
  provideClientHydration
} from '@angular/platform-browser';

export const appConfig: ApplicationConfig = {
  providers: [
    provideClientHydration()
  ]
};

The exact generated configuration depends on the Angular version and SSR setup, but the fundamental idea is:

Server rendering
      +
Client hydration
      =
Fast initial HTML + interactivity

26. SSR Architecture in Production

A production SSR architecture might look like:

                 ┌──────────────┐
                 │    Browser   │
                 └──────┬───────┘
                        │
                        │ HTTP
                        ▼
                ┌───────────────┐
                │     Nginx     │
                └───────┬───────┘
                        │
                        ▼
                ┌───────────────┐
                │ Node.js SSR   │
                │    Server     │
                └───────┬───────┘
                        │
            ┌───────────┴───────────┐
            ▼                       ▼
      ┌───────────┐           ┌───────────┐
      │   API     │           │ Database  │
      └───────────┘           └───────────┘

The server:

receives the request
loads required data
renders the application
returns HTML
browser displays it
client JavaScript loads
hydration occurs
application becomes interactive

27. SSR With a Backend API

A common architecture is:

Browser
   |
   | GET /
   v
Angular SSR Server
   |
   | GET /api/products
   v
Node.js API
   |
   v
PostgreSQL

The SSR server receives the product data and generates:

<h1>Products</h1>

<article>
  <h2>MacBook Pro</h2>
  <p>$1999</p>
</article>

The browser gets meaningful HTML.

Then:

Angular JS
    ↓
Hydration
    ↓
Existing DOM reused
    ↓
Interactive application

28. SSR Is Not Free

SSR provides benefits, but it introduces costs.

The server now needs to render every request.

For CSR:

Server:
Return static assets

For SSR:

Server:
Execute application
Fetch data
Render HTML
Return response

Therefore SSR can increase:

CPU usage
memory usage
server response complexity
infrastructure cost

This is why architecture matters.

29. SSR and Caching

Caching becomes extremely important.

Suppose 10,000 users request:

/products/123

Rendering the exact same page 10,000 times may be wasteful.

You can introduce caching:

Browser
   |
   v
CDN / Cache
   |
   +---- Cache HIT → HTML
   |
   +---- Cache MISS
             |
             v
          SSR Server

This allows SSR and caching to work together.

30. SSR + CDN

A powerful architecture can look like:

                 Browser
                    |
                    v
                  CDN
               /       \
              /         \
       Cache HIT       Cache MISS
          |                |
          v                v
        HTML           SSR Server
                           |
                           v
                          API

The first request may require server rendering.

Later requests can potentially receive cached HTML.

This gives you:

SSR benefits
+
CDN performance

31. SSR and SEO

One of the major reasons SSR became popular is SEO.

Search engines need to understand your content.

A CSR application might initially return:

<div id="root"></div>

while SSR can return:

<h1>Best Programming Courses</h1>

<p>
  Learn Angular, React, Node.js and TypeScript.
</p>

The content exists directly in the initial HTML.

This is especially useful for:

blogs
documentation
e-commerce
news websites
landing pages
content platforms

However, SEO is more complicated than simply saying:

SSR = good SEO.

Modern search engines can execute JavaScript.

SSR mainly helps by making meaningful content available earlier and more reliably.

32. SSR vs SSG

SSR is not the only server-rendering strategy.

There is also:

Static Site Generation

SSG generates HTML during the build process.

Build Time
   ↓
Generate HTML
   ↓
Deploy static files
   ↓
CDN
   ↓
User

SSR:

Request Time
   ↓
Render HTML
   ↓
Response

SSG:

Build Time
   ↓
Generate HTML
   ↓
Serve HTML

33. SSR vs SSG vs CSR

Strategy	Rendering Time	Best For
CSR	Browser	Dashboards, internal apps
SSR	Request	Dynamic content
SSG	Build	Blogs, documentation
ISR / Revalidation	Periodically	Large content sites

For example:

Admin Dashboard

CSR

because SEO is usually irrelevant.

Blog

SSG

because articles don't change every second.

E-commerce Product Page

SSR / ISR

because product information can be dynamic.

34. SSR + Hydration + API Data

Let's design a complete flow.

Suppose the user visits:

/products/123

The process becomes:

                Browser
                   |
                   | GET /products/123
                   v
              SSR Server
                   |
                   | Fetch product
                   v
                Backend
                   |
                   v
               Database
                   |
                   v
             Product Data
                   |
                   v
            Render Angular
                   |
                   v
                 HTML
                   |
                   v
                Browser
                   |
                   v
             Display HTML
                   |
                   v
          Download JavaScript
                   |
                   v
              Hydration
                   |
                   v
         Interactive Product

This is the architecture you should have in mind when thinking about SSR.

35. A More Realistic Product Example

Imagine the server receives:

GET /products/123

The API returns:

{
  "id": 123,
  "name": "MacBook Pro",
  "price": 1999,
  "description": "Powerful laptop for developers"
}

SSR generates:

<article>
  <h1>MacBook Pro</h1>

  <p>$1999</p>

  <p>
    Powerful laptop for developers
  </p>

  <button>
    Add to Cart
  </button>
</article>

The user immediately sees:

MacBook Pro
$1999
Powerful laptop for developers

[ Add to Cart ]

Then hydration connects:

button click
     ↓
Angular event listener
     ↓
addToCart()
     ↓
application state
     ↓
UI update

36. Common SSR Mistakes

Mistake #1: Using `window` Everywhere

Bad:

const width = window.innerWidth;

During server rendering:

window = undefined

Use platform-aware APIs or execute browser-only logic after the application is running in the browser.

Mistake #2: Using `localStorage` During SSR

Bad:

const token = localStorage.getItem('token');

The server doesn't have browser localStorage.

You need a server-safe strategy.

Mistake #3: Random Values

Bad:

const id = Math.random();

The server and client can produce different values.

Mistake #4: Current Time

Bad:

new Date()

when its result becomes part of rendered markup.

The server and client can disagree.

Mistake #5: Different Data

Server:

{
  "price": 100
}

Client:

{
  "price": 110
}

The DOM can mismatch.

37. How to Think About SSR Code

When writing code for SSR, ask:

Can this code execute on a server?

If the answer is no, isolate it.

Examples:

window
document
localStorage
sessionStorage
navigator
geolocation
Web APIs

These are browser-specific capabilities.

The application should have a clear boundary between:

Universal Code

and:

Browser-only Code

38. The Universal JavaScript Model

SSR applications often follow this model:

             Application Code
                    |
           ┌────────┴────────┐
           │                 │
           ▼                 ▼
        Server             Browser
           │                 │
           ▼                 ▼
        Render             Hydrate
           │                 │
           └────────┬────────┘
                    ▼
              Same Application

The same application logic can participate in two environments.

That's why SSR applications are sometimes described as:

Isomorphic / Universal Applications

39. Hydration Mismatch Debugging Strategy

When you see a hydration error, don't immediately blame the framework.

Check these first:

1. Random values

Math.random()

2. Dates

new Date()

3. Browser APIs

window
document
localStorage

4. Conditional rendering

if (window.innerWidth > 768)

5. Different API results

Server data ≠ Client data

6. Invalid HTML

For example, invalid nesting can cause browsers to normalize the DOM differently.

40. SSR Security Considerations

SSR also introduces security concerns.

Never blindly inject server data into HTML.

Be careful with:

User-generated content
HTML injection
XSS
serialized application state
cookies
authentication data

For example, if server state is serialized into the page:

<script>
  window.__DATA__ = {...}
</script>

that data must be safely serialized.

Never expose secrets such as:

Database passwords
API private keys
Internal credentials
Server-only environment variables

SSR code runs on the server, so you must carefully separate:

PUBLIC configuration

from:

SERVER-ONLY secrets

41. Performance Optimization Strategy

A good SSR architecture should optimize more than rendering.

Consider:

                SSR Performance
                       |
        ┌──────────────┼──────────────┐
        │              │              │
        ▼              ▼              ▼
     Server          Network        Client
      │                │              │
      ▼                ▼              ▼
   Rendering          CDN         Hydration
      │                │              │
      ▼                ▼              ▼
    Caching         Compression    JS Size

Optimize:

server rendering
API latency
database queries
HTML size
JavaScript bundle size
hydration cost
caching
CDN delivery

SSR isn't a magic performance switch.

It changes where the work happens.

42. The Deeper Architecture

The evolution looks like this:

                 Web Application Evolution

CSR
 │
 │ Browser renders everything
 ▼
SSR
 │
 │ Server renders initial HTML
 ▼
SSR + Hydration
 │
 │ Server HTML + client interactivity
 ▼
Partial / Selective Hydration
 │
 │ Hydrate only what needs JavaScript
 ▼
Streaming / Progressive Rendering
 │
 │ Send HTML progressively
 ▼
Modern Full-Stack Rendering

The goal isn't:

"Move everything to the server."

The goal is:

Put each piece of work where it is most efficient.

43. A Complete Mental Model

When a user opens an SSR application:

1. Browser sends HTTP request
          ↓
2. Server receives request
          ↓
3. Application executes on server
          ↓
4. Server fetches required data
          ↓
5. Components render to HTML
          ↓
6. Server sends HTML
          ↓
7. Browser parses HTML
          ↓
8. User sees content
          ↓
9. Browser downloads JavaScript
          ↓
10. Framework starts
          ↓
11. Hydration begins
          ↓
12. Existing DOM is reused
          ↓
13. Event handlers become active
          ↓
14. Application becomes interactive

If you understand these 14 steps, you understand the core of SSR + hydration.

44. The Key Difference in One Diagram

CSR

Request
   ↓
HTML Shell
   ↓
Download JS
   ↓
Execute JS
   ↓
Render UI
   ↓
Interactive

SSR

Request
   ↓
Server Render
   ↓
HTML
   ↓
Display UI
   ↓
Download JS
   ↓
Hydration
   ↓
Interactive

The critical difference is:

CSR:
Render → Browser

SSR:
Render → Server

And hydration bridges:

Server HTML
     ↓
Client JavaScript
     ↓
Interactive DOM

45. When Should You Use SSR?

SSR is especially useful when you care about:

SEO
+
Initial rendering
+
Content discoverability
+
Social previews
+
Performance on slower devices

Good candidates include:

e-commerce
blogs
documentation
marketing websites
news platforms
public product pages
content platforms

46. When CSR May Be Better

SSR isn't always necessary.

For example:

Admin Dashboard
Internal CRM
Back-office application
Private analytics platform

These applications often don't need SEO.

CSR can be simpler:

Browser
   ↓
JavaScript
   ↓
Application

Sometimes simplicity is more valuable than SSR.

47. SSR Is an Architectural Decision

Don't add SSR simply because:

"SSR is faster."

Ask instead:

Do I need SEO?
Do I need fast initial content?
Is my content dynamic?
Can my server handle rendering?
Do I have caching?
How large is my client bundle?
How expensive is hydration?

The answer determines whether SSR is appropriate.

48. Final Architecture

A modern application can look like:

                         USER
                          |
                          v
                       Browser
                          |
                          v
                         CDN
                          |
                 ┌────────┴────────┐
                 │                 │
              Cache HIT         Cache MISS
                 │                 │
                 v                 v
                HTML          SSR Server
                                   |
                     ┌─────────────┼─────────────┐
                     │             │             │
                     v             v             v
                   API          Database       Cache
                     |
                     v
                 Application
                     |
                     v
                Render HTML
                     |
                     v
                  Browser
                     |
                     v
                JavaScript
                     |
                     v
                 Hydration
                     |
                     v
              Interactive UI

This is the architecture behind many modern web applications.

49. Final Takeaways

If you remember only a few things from this article, remember these:

1. CSR

The browser renders the application.

Browser → JavaScript → UI

2. SSR

The server renders the initial HTML.

Server → HTML → Browser

3. Hydration

The client connects JavaScript behavior to the server-rendered HTML.

HTML + JavaScript → Interactive UI

4. SSR does not eliminate JavaScript

It moves the responsibility for the initial render.

5. Hydration should reuse the server DOM

The goal is to avoid unnecessarily rendering the same UI twice.

6. Server and client must agree

Different output can cause hydration mismatches.

7. Browser APIs require special attention

window
document
localStorage
navigator

may not exist on the server.

8. SSR has a cost

You trade some client-side rendering work for server-side rendering work.

9. Caching matters

SSR + CDN + caching can produce a powerful architecture.

10. Modern rendering is not simply CSR vs SSR

Modern frameworks increasingly combine:

SSR
+
Hydration
+
Partial Hydration
+
Streaming
+
Caching
+
Client-side Interactivity

The real goal is to decide where and when each piece of work should happen.

Conclusion

Server-Side Rendering and Hydration are not just framework features.

They represent a fundamental architectural shift in how web applications are delivered.

Instead of forcing the browser to build everything from scratch:

JavaScript
   ↓
Render
   ↓
UI

we can let the server produce meaningful HTML first:

Server
   ↓
HTML
   ↓
Browser

and then use hydration to transform that HTML into a fully interactive application:

Server-rendered HTML
        +
Client JavaScript
        ↓
     Hydration
        ↓
Interactive Application

Once you understand this model, technologies such as Angular SSR, React Server Components, Next.js, Nuxt, streaming SSR, partial hydration, and modern full-stack rendering architectures become much easier to understand.

The most important idea is not simply:

"SSR makes websites faster."

It is:

SSR decides where the initial UI is rendered, while hydration connects that server-rendered UI to the client-side application.

That distinction is the foundation for understanding modern web rendering.

🚀 What to Learn Next

If you're building serious Angular/React applications, the natural progression after SSR and hydration is:

CSR
 ↓
SSR
 ↓
Hydration
 ↓
Transfer State
 ↓
Streaming SSR
 ↓
Partial / Selective Hydration
 ↓
Islands Architecture
 ↓
React Server Components
 ↓
Server Actions
 ↓
Edge Rendering
 ↓
Modern Full-Stack Architecture

Understanding this progression gives you a much deeper understanding of how modern frontend frameworks actually work under the hood.

Building a Production-Ready Authentication System with Next.js

Abanoub Kerols — Wed, 30 Sep 2026 21:37:08 +0000

Authentication is one of those topics that looks simple at first.

You create a login form:

Email + Password
       ↓
     Login
       ↓
   User authenticated

But a real authentication system is much more than checking whether a password is correct.

A production authentication system needs to answer questions such as:

How do we securely store passwords?
Where should authentication tokens live?
How does the server know that a request belongs to an authenticated user?
How do we keep users logged in?
How do we refresh expired access tokens?
How do we log users out?
How do we protect routes?
How do we distinguish authentication from authorization?
How do we prevent token theft and replay attacks?
How does this work with Next.js Server Components and Client Components?
How should the architecture change when the application grows?

This article builds an authentication system from the ground up using Next.js, while focusing on the architectural ideas behind it rather than simply copying an authentication library.

1. Authentication vs Authorization

Before writing code, we need to understand two different concepts.

Authentication

Authentication answers:

Who are you?

For example:

Email: abanoub@example.com
Password: ********

The server verifies the credentials and identifies the user:

User ID: 123
Email: abanoub@example.com

Authorization

Authorization answers:

What are you allowed to do?

For example:

User
 ├── Read posts
 ├── Create posts
 └── Delete own posts

Admin
 ├── Read posts
 ├── Create posts
 ├── Delete posts
 └── Manage users

So:

Authentication → Identity

Authorization → Permissions

This distinction becomes extremely important when designing the backend.

2. The Authentication Architecture

Let's imagine that we have a Next.js application.

A simplified architecture can look like this:

                    Browser
                       │
                       │ HTTPS
                       ▼
                ┌──────────────┐
                │   Next.js    │
                │ Application  │
                └──────┬───────┘
                       │
             ┌─────────┴─────────┐
             │                   │
             ▼                   ▼
        Authentication       Application
           Logic                Logic
             │                   │
             └─────────┬─────────┘
                       ▼
                   Database

The authentication system will be responsible for:

Register
Login
Logout
Session validation
Token refresh
Password hashing
Password reset
Email verification
Authorization

3. The User Model

At the database level, we need a user.

A simplified model might look like:

User {
  id
  name
  email
  passwordHash
  role
  emailVerified
  createdAt
  updatedAt
}

Notice something important:

We don't store:

password

We store:

passwordHash

This is a fundamental security rule.

4. Never Store Plain-Text Passwords

Suppose the user creates:

Password:

MySecretPassword123

We should never save:

password = "MySecretPassword123"

Instead:

Password
   ↓
Hashing Algorithm
   ↓
Password Hash
   ↓
Database

For example:

MySecretPassword123
        ↓
$argon2id$v=19$...

The important property is that hashing is one-way.

We don't decrypt the password during login.

Instead:

Login Password
      ↓
Hash/Verify
      ↓
Compare with stored hash

A modern password hashing algorithm such as Argon2id is a strong choice for password storage.

5. Registration Flow

Let's design the registration process.

The browser sends:

POST /api/auth/register

with:

{
  "name": "Abanoub",
  "email": "abanoub@example.com",
  "password": "MySecretPassword123"
}

The server performs:

Receive request
      ↓
Validate input
      ↓
Normalize email
      ↓
Check existing user
      ↓
Hash password
      ↓
Create user
      ↓
Create authentication state
      ↓
Return response

6. Input Validation

Never trust input coming from the browser.

For example:

const schema = z.object({
  name: z.string().min(2).max(100),

  email: z
    .string()
    .email(),

  password: z
    .string()
    .min(8)
});

Then:

const result = schema.safeParse(body);

if (!result.success) {
  return Response.json(
    {
      message: "Invalid input"
    },
    {
      status: 400
    }
  );
}

The client-side validation improves UX.

The server-side validation provides security and correctness.

You need both.

7. Normalize Email Addresses

Authentication systems should usually normalize emails before querying the database.

For example:

const email = input.email
  .trim()
  .toLowerCase();

Without normalization:

Abanoub@example.com
abanoub@example.com
ABANOUB@example.com

could accidentally be treated as different values depending on the database and application rules.

Ideally, the database should also enforce a unique constraint.

8. Login Flow

Now let's look at login.

The browser sends:

POST /api/auth/login

{
  "email": "abanoub@example.com",
  "password": "MySecretPassword123"
}

The server performs:

Validate input
      ↓
Find user
      ↓
Verify password
      ↓
Create authentication state
      ↓
Set secure cookie
      ↓
Return response

The browser doesn't need to know the user's password after authentication.

9. How Does the Server Remember the User?

This is the core authentication problem.

HTTP is stateless.

For example:

Request 1
GET /dashboard

Request 2
GET /profile

Request 3
GET /orders

Each request is independent.

The server needs some form of authentication state to understand:

These requests belong to user 123.

There are two major approaches:

Session-based authentication
JWT-based authentication

10. Session-Based Authentication

With sessions, the server stores authentication state.

For example:

Database

Session
-------------------------
sessionId
userId
expiresAt
createdAt

The browser receives:

sessionId

inside a cookie.

Then:

Browser
   │
   │ Cookie: sessionId=abc123
   ▼
Next.js
   │
   │ lookup session
   ▼
Database
   │
   ▼
User 123

This is a very clean model for traditional web applications.

11. JWT-Based Authentication

Another approach is JSON Web Tokens.

A JWT contains claims such as:

{
  "sub": "123",
  "role": "user",
  "exp": 1790000000
}

The token is cryptographically signed.

The server can verify:

Signature
Expiration
Issuer
Audience
Claims

without necessarily querying the database for every request.

12. Access Token vs Refresh Token

A common production architecture separates authentication into two tokens.

Access Token
+
Refresh Token

The access token is short-lived.

For example:

Access Token
Expires in 15 minutes

The refresh token lives longer:

Refresh Token
Expires in days/weeks

The idea is:

                Login
                  │
          ┌───────┴────────┐
          ▼                ▼
    Access Token      Refresh Token
      short-lived       long-lived

13. Why Not Use a Long-Lived Access Token?

Imagine:

Access Token
Expires in 30 days

If an attacker steals it:

Attacker
   ↓
Stolen token
   ↓
30 days of access

A short-lived access token reduces the lifetime of a stolen credential.

The refresh mechanism then allows legitimate users to obtain a new access token.

14. Where Should Tokens Be Stored?

This is one of the most important authentication design decisions.

A common mistake is:

localStorage.setItem(
  "accessToken",
  token
);

This can expose the token to JavaScript running in the page.

If an XSS vulnerability exists, malicious JavaScript could potentially read the token.

A common safer browser architecture is:

HttpOnly Cookie
Secure Cookie
SameSite Cookie

For example:

Set-Cookie:
refreshToken=...
HttpOnly;
Secure;
SameSite=Lax;
Path=/api/auth;

The HttpOnly flag means JavaScript cannot access the cookie through:

document.cookie

15. Cookie Security

A production authentication cookie should generally consider:

HttpOnly
Secure
SameSite
Path
Expiration

For example:

cookies().set(
  "refreshToken",
  refreshToken,
  {
    httpOnly: true,
    secure: process.env.NODE_ENV === "production",
    sameSite: "lax",
    path: "/api/auth",
    maxAge: 60 * 60 * 24 * 30
  }
);

The exact configuration depends on your architecture and deployment environment.

16. SameSite Is Not a Complete CSRF Strategy

A common misconception is:

HttpOnly completely solves authentication security.

It doesn't.

HttpOnly primarily prevents JavaScript from reading the cookie.

It does not automatically solve every CSRF scenario.

That's why authentication systems should consider:

SameSite cookies
+
CSRF protection where necessary
+
Origin checking
+
Secure application design

Especially when the application performs state-changing requests.

17. The Authentication Request Lifecycle

Let's put everything together.

Suppose the user requests:

GET /dashboard

The browser automatically sends:

Cookie: session=abc123

or:

Cookie: refreshToken=...

The server:

Request
   ↓
Read cookie
   ↓
Validate authentication
   ↓
Identify user
   ↓
Check authorization
   ↓
Execute business logic
   ↓
Return response

This is the central lifecycle of authentication.

18. Authentication Helper

Instead of repeating authentication logic everywhere, create a reusable function.

For example:

async function getCurrentUser() {
  const cookieStore = await cookies();

  const token = cookieStore.get(
    "accessToken"
  )?.value;

  if (!token) {
    return null;
  }

  try {
    const payload = await verifyToken(token);

    return await getUserById(payload.sub);
  } catch {
    return null;
  }
}

Now application code can simply do:

const user = await getCurrentUser();

if (!user) {
  // unauthenticated
}

This is much cleaner than implementing token parsing in every route.

19. Authentication in Next.js

Next.js introduces an interesting architectural distinction:

Server Components
Client Components
Route Handlers
Middleware
Server Actions

Authentication logic should be placed carefully according to what it needs to do.

For example, if you need to read an HttpOnly cookie, server-side code is a natural place.

A Server Component can retrieve authentication information and render accordingly.

20. Protecting Server Components

Imagine:

export default async function DashboardPage() {
  const user = await getCurrentUser();

  if (!user) {
    redirect("/login");
  }

  return (
    <main>
      <h1>
        Welcome {user.name}
      </h1>
    </main>
  );
}

The important idea is:

Server
  ↓
Read authentication state
  ↓
Validate user
  ↓
Render protected content

The browser doesn't need to decide whether the user is authenticated.

21. Middleware

Middleware can be useful for early route protection.

For example:

/dashboard
/profile
/settings
/admin

could be protected.

Conceptually:

export async function middleware(request) {
  const token =
    request.cookies.get("accessToken");

  if (!token) {
    return Response.redirect(
      new URL("/login", request.url)
    );
  }

  return NextResponse.next();
}

But middleware should not automatically become the only authorization layer.

Why?

Because authorization must also happen at the point where sensitive data or operations are accessed.

22. Never Trust Middleware Alone

Suppose:

POST /api/users/delete

is protected by middleware.

An attacker may still try to call the underlying endpoint directly.

Therefore:

Middleware
   ↓
Early protection

Route Handler / Server Action
   ↓
Actual authorization

The sensitive operation itself should verify permissions.

For example:

const user = await getCurrentUser();

if (!user) {
  return unauthorized();
}

if (user.role !== "admin") {
  return forbidden();
}

23. Authentication vs Authorization in Code

A clean structure is:

const user = await requireUser();

requireRole(user, "admin");

Conceptually:

requireUser()
      ↓
Is authenticated?

requireRole()
      ↓
Is authorized?

This separation makes the system easier to understand and test.

24. Role-Based Access Control

Suppose our application has:

type Role =
  | "user"
  | "admin"
  | "manager";

Then:

User
 ├── View profile
 └── Create orders

Manager
 ├── View reports
 └── Manage orders

Admin
 ├── Manage users
 ├── Manage roles
 └── Manage system settings

Authorization becomes:

if (user.role !== "admin") {
  return forbidden();
}

But real systems can go beyond roles.

25. Permissions

Instead of:

role = admin

we can model permissions:

users:read
users:create
users:update
users:delete
orders:read
orders:create
orders:update

Then:

hasPermission(
  user,
  "users:delete"
);

This becomes useful when the application becomes more complex.

26. Logout

Logout should invalidate the authentication state.

For a cookie-based architecture:

User clicks Logout
        ↓
POST /api/auth/logout
        ↓
Invalidate session/token
        ↓
Clear cookie
        ↓
Redirect to login

For example:

cookies().delete("refreshToken");

If using server-side sessions, you should also invalidate the session in the database.

27. Refresh Token Rotation

A stronger refresh-token architecture uses rotation.

Suppose:

Refresh Token A

is used.

The server returns:

Refresh Token B

and invalidates A.

So:

Token A
   ↓
Refresh
   ↓
Token B
   ↓
Token A invalid

This can reduce the impact of stolen refresh tokens.

You can also detect token reuse.

28. Refresh Token Storage

For a high-security architecture, don't necessarily store the raw refresh token in the database.

Instead:

Refresh Token
      ↓
Hash
      ↓
Database

The database stores something like:

tokenHash
userId
expiresAt
revokedAt
createdAt

Then the server hashes the presented token and looks up the hash.

This follows the same general principle:

Don't store sensitive credentials in recoverable plain text when you don't need to.

29. Session-Based Architecture Can Be Even Simpler

For many Next.js applications, a server-side session architecture is extremely practical:

Browser
   │
   │ session cookie
   ▼
Next.js
   │
   │ session lookup
   ▼
Database / Redis

The browser stores only an opaque identifier.

For example:

session_id = 7f3a...

The server knows:

7f3a...
   ↓
User 123

This gives the server direct control over session revocation.

30. JWT Does Not Automatically Mean "More Secure"

JWT is a technology, not a security strategy.

A poorly designed JWT system can be vulnerable.

For example:

JWT in localStorage
+
Long expiration
+
No rotation
+
No revocation strategy
+
Weak secret management

is not automatically better than sessions.

The correct question is:

What authentication model fits the architecture and security requirements of the application?

31. Password Reset

Authentication isn't complete without password recovery.

A typical flow is:

User clicks:
Forgot Password
        ↓
Enter email
        ↓
Server creates reset token
        ↓
Email sent
        ↓
User clicks link
        ↓
Validate token
        ↓
Set new password

The reset token should be:

random
short-lived
single-use

And ideally the database stores only a hash of the reset token.

32. Email Verification

Registration can also require email verification.

Flow:

Register
   ↓
Create user
   ↓
emailVerified = false
   ↓
Generate verification token
   ↓
Send email
   ↓
User clicks link
   ↓
Verify token
   ↓
emailVerified = true

Then sensitive operations can require:

if (!user.emailVerified) {
  // require verification
}

33. Brute-Force Protection

Imagine an attacker sends:

10,000 login attempts

against:

POST /api/auth/login

The authentication endpoint should be rate-limited.

For example:

IP
+
Email
+
Time Window

could be used to detect excessive attempts.

A production system might use:

Redis

to implement distributed rate limiting.

Conceptually:

login:ip:1.2.3.4
login:user:abanoub@example.com

34. Account Enumeration

Be careful with error messages.

Avoid:

User does not exist.

and:

Wrong password.

because this can allow attackers to determine whether an email address is registered.

A generic response can be:

Invalid email or password.

Similarly, password-reset requests often use generic responses so attackers cannot easily discover registered accounts.

35. Secrets and Environment Variables

Authentication secrets should never be hardcoded.

Bad:

const secret = "my-secret-123";

Better:

AUTH_SECRET=...
DATABASE_URL=...

Then:

process.env.AUTH_SECRET

Also:

.env.local

should not be committed to Git.

36. HTTPS

Authentication should be performed over HTTPS in production.

Why?

Because credentials, cookies, and authentication tokens must be protected while traveling between:

Browser
    ↕
Internet
    ↕
Server

Without transport encryption, an attacker positioned on the network could potentially intercept sensitive data.

37. Secure Cookies

In production:

Secure = true

means the cookie should only be transmitted over HTTPS.

A typical production cookie might look conceptually like:

HttpOnly
Secure
SameSite=Lax

Again, the correct SameSite policy depends on whether your application uses cross-site authentication flows.

38. Database Constraints Are Part of Security

Application-level checks are not enough.

For example:

if (existingUser) {
  throw new Error("Email already exists");
}

is useful.

But the database should also enforce:

UNIQUE(email)

Why?

Because two requests could arrive at almost the same time:

Request A ─┐
           ├── Check email
Request B ─┘

Both might see:

No user exists

and then both try to insert.

The database constraint provides the final guarantee.

39. Race Conditions

Authentication systems contain many opportunities for race conditions.

Examples:

Two registration requests
Two password reset requests
Two refresh requests
Two logout requests
Two email verification requests

Good architecture considers these cases explicitly.

For refresh-token rotation, for example, concurrent refresh requests require careful handling.

40. CSRF

If authentication relies on cookies, the browser automatically sends them with requests.

That creates a CSRF consideration.

Imagine:

Attacker Website
       ↓
POST /api/change-email
       ↓
Browser automatically sends auth cookie

Depending on the cookie and request configuration, the server may receive an authenticated request.

Possible defenses include:

SameSite cookies
CSRF tokens
Origin validation
Same-origin architecture

The correct strategy depends on the application.

41. XSS

Authentication security also depends on preventing XSS.

For example, never render untrusted HTML without sanitization.

An XSS vulnerability can allow malicious JavaScript to perform actions as the user, even when HttpOnly cookies prevent direct token theft.

Therefore:

Authentication Security
        ≠
Token Security Only

It is an application-wide concern.

42. A Better Next.js Project Structure

A growing application might use a structure such as:

src/
├── app/
│   ├── (auth)/
│   │   ├── login/
│   │   ├── register/
│   │   └── forgot-password/
│   │
│   ├── dashboard/
│   ├── profile/
│   │
│   └── api/
│       └── auth/
│           ├── login/
│           ├── register/
│           ├── logout/
│           ├── refresh/
│           └── reset-password/
│
├── lib/
│   ├── auth/
│   │   ├── session.ts
│   │   ├── password.ts
│   │   ├── tokens.ts
│   │   └── authorization.ts
│   │
│   ├── db/
│   └── validation/
│
├── components/
│
└── middleware.ts

The exact structure isn't important.

The separation of responsibilities is.

43. Authentication Service

Instead of mixing everything into route handlers:

export async function login(
  email: string,
  password: string
) {
  const user = await findUserByEmail(email);

  if (!user) {
    throw new AuthenticationError();
  }

  const valid = await verifyPassword(
    password,
    user.passwordHash
  );

  if (!valid) {
    throw new AuthenticationError();
  }

  return createSession(user);
}

Then the route handler becomes thin:

export async function POST(request: Request) {
  const body = await request.json();

  const result = await login(
    body.email,
    body.password
  );

  return Response.json(result);
}

This makes the authentication logic reusable and testable.

44. The Thin Controller Principle

A good API layer should ideally do:

Request
   ↓
Validation
   ↓
Service
   ↓
Response

Instead of:

Route Handler
 ├── validate
 ├── query DB
 ├── hash password
 ├── generate token
 ├── create session
 ├── send email
 ├── authorization
 ├── business logic
 └── response

The second approach becomes difficult to maintain.

45. A Complete Login Architecture

Let's summarize the complete login process.

                 Browser
                    │
                    │ POST /login
                    ▼
              Next.js Route
                    │
                    ▼
             Validate Input
                    │
                    ▼
             Find User
                    │
                    ▼
            Verify Password
                    │
                    ▼
           Create Session
                    │
                    ▼
          Set HttpOnly Cookie
                    │
                    ▼
               Response

Then:

Browser
   │
   │ Cookie
   ▼
Next.js
   │
   ▼
Validate Session
   │
   ▼
Identify User
   │
   ▼
Authorization
   │
   ▼
Business Logic

46. The Mental Model

The most important mental model is this:

Credentials
    ↓
Identity
    ↓
Authentication State
    ↓
Authenticated Request
    ↓
Authorization
    ↓
Business Operation

For example:

Email + Password
       ↓
User #123
       ↓
Session #ABC
       ↓
GET /dashboard
       ↓
Authenticated User
       ↓
Permission: dashboard:read
       ↓
Dashboard Data

Once you understand this flow, authentication stops being a collection of random APIs and becomes a system.

47. Production Authentication Checklist

Before considering an authentication system production-ready, ask:

Passwords

[ ] Are passwords hashed with a password-specific algorithm?
[ ] Are password hashes never exposed through APIs?
[ ] Is password validation performed server-side?

Cookies

[ ] Are sensitive cookies HttpOnly?
[ ] Is Secure enabled in production?
[ ] Is SameSite configured correctly?
[ ] Is the cookie scope as narrow as practical?

Tokens / Sessions

[ ] Do authentication credentials expire?
[ ] Can sessions be revoked?
[ ] Are refresh tokens rotated where appropriate?
[ ] Are refresh tokens protected?
[ ] Is token reuse detectable where required?

APIs

[ ] Are authentication endpoints rate-limited?
[ ] Are inputs validated?
[ ] Are authorization checks performed server-side?
[ ] Are sensitive errors generic enough to avoid account enumeration?

Infrastructure

[ ] Is HTTPS enabled?
[ ] Are secrets stored in environment/secret management?
[ ] Are database constraints enforced?
[ ] Are logs free from passwords and tokens?

Application Security

[ ] Is CSRF considered?
[ ] Is XSS considered?
[ ] Are permissions checked at the resource boundary?
[ ] Are authentication and authorization separated?

48. The Most Important Architectural Lesson

Authentication is not:

Login Page
+
JWT
+
Middleware

Authentication is a complete security boundary.

A useful architecture looks like:

                 ┌───────────────────────┐
                 │       Browser         │
                 └───────────┬───────────┘
                             │
                             ▼
                    ┌────────────────┐
                    │    Next.js     │
                    │                │
                    │ Route Handlers │
                    │ Server Actions │
                    │ Server Comps   │
                    │ Middleware     │
                    └───────┬────────┘
                            │
              ┌─────────────┼─────────────┐
              ▼             ▼             ▼
         Auth Service   Authorization   Business
              │             │             │
              └─────────────┼─────────────┘
                            ▼
                       Database
                            │
                            ▼
                     Session / User

The goal isn't simply to make the login button work.

The goal is to establish a trustworthy chain:

Who is this user?
        ↓
How do we know?
        ↓
Is their authentication state valid?
        ↓
What are they allowed to do?
        ↓
Can we safely execute the operation?

That's the real meaning of building an authentication system.

Conclusion

Building authentication with Next.js is an excellent exercise because it forces you to combine several areas of software engineering:

HTTP
Cookies
Cryptography
Databases
API Design
Security
Authorization
Server-side Rendering
Client-side Applications
Middleware
Distributed Systems

The most important thing to learn is not a specific library or token format.

It's the architecture.

Once you understand:

Authentication
        ↓
Session / Token
        ↓
Request
        ↓
Identity
        ↓
Authorization
        ↓
Business Logic

you can apply the same concepts whether you're building a Next.js application, an Angular + Node.js system, a mobile backend, or a distributed API.

A good authentication system should make it difficult for an attacker to impersonate a user, limit the impact of stolen credentials, provide clear authorization boundaries, and give the server reliable control over access.

That is what turns a simple login feature into a production authentication system.

Redux Explained: Concepts, Architecture, Examples, and Real-World Patterns

Abanoub Kerols — Wed, 23 Sep 2026 21:16:07 +0000

Redux is more than a state management library. It is a predictable architecture for managing application state through explicit actions, pure state transitions, and a centralized store.

If you have worked with React, Angular, or modern frontend applications, you have probably encountered problems such as:

Multiple components needing the same state
State being passed through many layers of components
Difficult-to-debug state changes
Complex asynchronous operations
Inconsistent application state
Business logic scattered across components

Redux was designed to solve these problems by introducing a predictable and structured approach to state management.

In this article, we will go from the fundamentals to practical Redux development, including:

What Redux is
Why Redux exists
Core Redux concepts
Store
Actions
Reducers
Dispatch
Selectors
Immutability
Redux data flow
Middleware
Async operations
Redux Toolkit
RTK Query
Entity management
Real-world architecture
Common mistakes
A complete example

1. What Is Redux?

Redux is a predictable state management library.

The basic idea is simple:

UI
 ↓
Dispatch Action
 ↓
Reducer
 ↓
New State
 ↓
Store
 ↓
UI Updates

Instead of allowing components to modify application state however they want, Redux creates a controlled flow.

For example:

dispatch({
  type: "counter/increment"
});

The action reaches a reducer:

function counterReducer(state, action) {
  if (action.type === "counter/increment") {
    return {
      ...state,
      value: state.value + 1
    };
  }

  return state;
}

The reducer produces the next state.

2. Why Do We Need Redux?

Consider a large application.

You may have:

App
 ├── Header
 │    └── UserMenu
 │         └── UserProfile
 │
 ├── Dashboard
 │    ├── Statistics
 │    ├── Orders
 │    └── Notifications
 │
 └── Sidebar

Suppose the logged-in user is needed by:

Header
UserMenu
Dashboard
Sidebar
Notifications

Without centralized state management, you may end up passing:

App
 ↓
Header
 ↓
UserMenu
 ↓
UserProfile

This is commonly called prop drilling.

Redux provides a centralized store:

             Redux Store
          /       |       \
         ↓        ↓        ↓
      Header   Dashboard  Sidebar

Components can subscribe to the state they need.

3. Redux Core Principles

Redux is based on several important principles.

3.1 Single Source of Truth

Application state is stored in one centralized store.

{
  user: {
    id: 1,
    name: "Abanoub"
  },
  cart: {
    items: []
  },
  products: [],
  ui: {
    theme: "dark"
  }
}

Instead of having unrelated copies of important state throughout the application, Redux provides a central source.

4. State Is Read-Only

Components should not directly modify Redux state.

Incorrect:

state.counter.value++;

Instead, dispatch an action:

dispatch({
  type: "counter/increment"
});

The reducer determines how the state changes.

5. Changes Are Made Through Pure Functions

Reducers are responsible for calculating the next state.

Conceptually:

Previous State + Action = Next State

Example:

const previousState = {
  value: 10
};

const action = {
  type: "increment"
};

const nextState = {
  value: 11
};

The reducer:

function reducer(state, action) {
  switch (action.type) {
    case "increment":
      return {
        ...state,
        value: state.value + 1
      };

    default:
      return state;
  }
}

6. The Redux Store

The store contains the application state.

With modern Redux, the recommended approach is Redux Toolkit.

import { configureStore } from "@reduxjs/toolkit";

const store = configureStore({
  reducer: {
    counter: counterReducer
  }
});

Conceptually:

Store
│
├── counter
├── user
├── products
├── cart
└── notifications

7. Actions

An action describes what happened.

Example:

{
  type: "counter/increment"
}

Another example:

{
  type: "cart/addItem",
  payload: {
    id: 10,
    name: "Keyboard"
  }
}

The action does not directly modify state.

It describes an event.

8. Action Types

An action type is usually a string.

{
  type: "user/login"
}

Examples:

user/login
user/logout
cart/addItem
cart/removeItem
products/load
products/delete

A useful naming convention is:

feature/event

For example:

cart/addItem

9. Payload

The payload contains additional information.

{
  type: "cart/addItem",
  payload: {
    id: 1,
    name: "Laptop",
    price: 1200
  }
}

Another example:

{
  type: "user/setUser",
  payload: {
    id: 5,
    name: "John"
  }
}

10. Reducers

A reducer receives:

Current State
+
Action

and returns:

Next State

Example:

function counterReducer(state = { value: 0 }, action) {
  switch (action.type) {
    case "increment":
      return {
        ...state,
        value: state.value + 1
      };

    case "decrement":
      return {
        ...state,
        value: state.value - 1
      };

    default:
      return state;
  }
}

A reducer should be:

Predictable
Pure
Deterministic
Free of side effects

11. What Does "Pure Function" Mean?

A pure function:

Produces the same output for the same input.
Does not modify external state.
Does not perform side effects.

Example:

function add(a, b) {
  return a + b;
}

This is pure.

But:

let total = 0;

function add(value) {
  total += value;
}

This is not pure because it modifies external state.

Reducers should follow the pure-function principle.

12. Dispatch

Dispatch sends an action to Redux.

dispatch({
  type: "counter/increment"
});

The flow becomes:

Component
   ↓
dispatch(action)
   ↓
Redux
   ↓
Reducer
   ↓
New State
   ↓
Store
   ↓
Subscribed Components

13. Selectors

Selectors read data from the Redux store.

For example:

const selectCount = state => state.counter.value;

Then:

const count = useSelector(selectCount);

Selectors help keep components independent from the exact shape of the state.

Instead of:

state.counter.value

everywhere, you can use:

selectCount(state)

14. Redux Data Flow

Redux follows a predictable one-way data flow.

┌─────────────┐
│     UI      │
└──────┬──────┘
       │
       │ dispatch()
       ↓
┌─────────────┐
│   Action    │
└──────┬──────┘
       ↓
┌─────────────┐
│   Reducer   │
└──────┬──────┘
       ↓
┌─────────────┐
│    Store    │
└──────┬──────┘
       ↓
┌─────────────┐
│     UI      │
└─────────────┘

This predictable flow is one of Redux's biggest advantages.

15. A Simple Redux Example

Let's create a counter.

With Redux Toolkit:

import { createSlice, configureStore } from "@reduxjs/toolkit";

const counterSlice = createSlice({
  name: "counter",

  initialState: {
    value: 0
  },

  reducers: {
    increment(state) {
      state.value += 1;
    },

    decrement(state) {
      state.value -= 1;
    },

    incrementByAmount(state, action) {
      state.value += action.payload;
    }
  }
});

Export the actions:

export const {
  increment,
  decrement,
  incrementByAmount
} = counterSlice.actions;

Create the store:

const store = configureStore({
  reducer: {
    counter: counterSlice.reducer
  }
});

Now:

store.dispatch(increment());

Or:

store.dispatch(incrementByAmount(10));

16. Why Does Redux Toolkit Allow Mutation?

You might notice:

state.value += 1;

Earlier we said Redux state should not be mutated.

So why does this work?

Redux Toolkit uses Immer internally.

Immer allows you to write:

state.value += 1;

while internally producing an immutable state update.

Conceptually:

Your Code
   ↓
Immer
   ↓
Immutable Update
   ↓
Redux State

This gives developers simpler syntax while preserving Redux's immutability model.

17. createSlice

createSlice() is one of the most important Redux Toolkit APIs.

It combines:

State
Reducers
Action creators
Action types

Instead of manually writing:

const INCREMENT = "counter/increment";

function increment() {
  return {
    type: INCREMENT
  };
}

function reducer(state, action) {
  ...
}

you can write:

const counterSlice = createSlice({
  name: "counter",

  initialState: {
    value: 0
  },

  reducers: {
    increment(state) {
      state.value++;
    }
  }
});

Redux Toolkit generates the action creator automatically.

18. Payload Actions

Suppose we want to add a product.

const cartSlice = createSlice({
  name: "cart",

  initialState: {
    items: []
  },

  reducers: {
    addItem(state, action) {
      state.items.push(action.payload);
    }
  }
});

Dispatch:

dispatch(
  addItem({
    id: 1,
    name: "Laptop",
    price: 1200
  })
);

The action becomes conceptually:

{
  type: "cart/addItem",
  payload: {
    id: 1,
    name: "Laptop",
    price: 1200
  }
}

19. Redux With React

Redux itself is independent of React.

To integrate Redux with React, we commonly use React-Redux.

First create the store:

const store = configureStore({
  reducer: {
    counter: counterReducer
  }
});

Then provide it to React:

import { Provider } from "react-redux";

<Provider store={store}>
  <App />
</Provider>

Now components can access Redux.

20. useSelector

useSelector() reads data.

import { useSelector } from "react-redux";

function Counter() {
  const count = useSelector(
    state => state.counter.value
  );

  return <h1>{count}</h1>;
}

When the selected state changes, the component can re-render.

21. useDispatch

useDispatch() allows a component to dispatch actions.

import { useDispatch } from "react-redux";
import { increment } from "./counterSlice";

function CounterButton() {
  const dispatch = useDispatch();

  return (
    <button onClick={() => dispatch(increment())}>
      Increment
    </button>
  );
}

22. Complete React + Redux Example

function Counter() {
  const count = useSelector(
    state => state.counter.value
  );

  const dispatch = useDispatch();

  return (
    <div>
      <h1>{count}</h1>

      <button
        onClick={() => dispatch(increment())}
      >
        +
      </button>

      <button
        onClick={() => dispatch(decrement())}
      >
        -
      </button>
    </div>
  );
}

The component does not directly change:

state.counter.value

Instead:

Button
 ↓
dispatch(increment())
 ↓
Reducer
 ↓
New State
 ↓
useSelector
 ↓
Component Re-render

23. Local State vs Redux State

Not every piece of state belongs in Redux.

For example:

const [isOpen, setIsOpen] = useState(false);

This is usually local UI state.

Redux is more appropriate for state that needs to be shared or coordinated across different parts of an application.

Local State

Examples:

Modal open/closed
Input value
Dropdown state
Temporary UI state

Global State

Examples:

Authenticated user
Shopping cart
Permissions
Global notifications
Shared application configuration
Cached server data

24. Redux Is Not Always Necessary

A common mistake is:

"Every React application should use Redux."

Not true.

For a small application:

React
+
useState
+
useContext

may be enough.

Redux becomes more valuable as state complexity increases.

A useful question is:

Is the complexity of shared state becoming harder to manage than the complexity of introducing Redux?

25. Middleware

Middleware sits between:

dispatch()
   ↓
Middleware
   ↓
Reducer

It can:

Log actions
Perform asynchronous operations
Dispatch additional actions
Handle side effects
Integrate external services

Conceptually:

dispatch(action)
       ↓
   Middleware
       ↓
     Reducer
       ↓
      Store

26. Why Do We Need Middleware?

Reducers should be pure.

Therefore, things like:

fetch()

should not normally happen inside reducers.

Incorrect:

function reducer(state, action) {
  fetch("/api/products");

  return state;
}

Instead, asynchronous work should happen outside reducers, commonly through middleware.

27. Redux Thunk

Redux Toolkit includes thunk middleware by default.

A thunk allows you to dispatch a function-like async workflow.

Example:

const fetchUsers = () => async dispatch => {
  dispatch(usersLoading());

  try {
    const response = await fetch("/api/users");

    const users = await response.json();

    dispatch(usersLoaded(users));
  } catch (error) {
    dispatch(usersFailed(error.message));
  }
};

Then:

dispatch(fetchUsers());

The flow becomes:

Component
   ↓
dispatch(fetchUsers())
   ↓
Thunk
   ↓
API Request
   ↓
dispatch(usersLoaded())
   ↓
Reducer
   ↓
Store

28. createAsyncThunk

Redux Toolkit provides createAsyncThunk() to simplify common async workflows.

export const fetchUsers = createAsyncThunk(
  "users/fetchUsers",

  async () => {
    const response = await fetch("/api/users");

    return response.json();
  }
);

Then handle the lifecycle:

const usersSlice = createSlice({
  name: "users",

  initialState: {
    data: [],
    loading: false,
    error: null
  },

  extraReducers: builder => {
    builder
      .addCase(fetchUsers.pending, state => {
        state.loading = true;
      })

      .addCase(fetchUsers.fulfilled, (state, action) => {
        state.loading = false;
        state.data = action.payload;
      })

      .addCase(fetchUsers.rejected, (state, action) => {
        state.loading = false;
        state.error = action.error.message;
      });
  }
});

Now Redux automatically provides:

pending
fulfilled
rejected

29. Handling API State

A common pattern is:

{
  data: [],
  loading: false,
  error: null
}

The state transitions are:

Initial
 ↓
loading = true
 ↓
API Request
 ↓
 ┌───────────────┐
 │               │
Success        Failure
 │               │
 ↓               ↓
data          error

This makes asynchronous state explicit.

30. RTK Query

For server data, Redux Toolkit provides RTK Query.

RTK Query is designed specifically for:

Fetching data
Caching
Refetching
Loading states
Error states
Request deduplication
Cache invalidation

Example:

const api = createApi({
  reducerPath: "api",

  baseQuery: fetchBaseQuery({
    baseUrl: "/api"
  }),

  endpoints: builder => ({
    getUsers: builder.query({
      query: () => "/users"
    })
  })
});

Then:

const {
  data,
  isLoading,
  error
} = useGetUsersQuery();

This removes a lot of manual async-state management.

31. Redux Toolkit vs Traditional Redux

Traditional Redux often required:

Action Types
Action Creators
Reducers
Store
Middleware
Selectors

with a lot of boilerplate.

Modern Redux recommends Redux Toolkit.

Instead of:

const INCREMENT = "INCREMENT";

const increment = () => ({
  type: INCREMENT
});

function reducer(state, action) {
  switch (action.type) {
    ...
  }
}

you can use:

const counterSlice = createSlice({
  name: "counter",

  initialState: {
    value: 0
  },

  reducers: {
    increment(state) {
      state.value++;
    }
  }
});

Redux Toolkit is now the recommended way to write Redux applications.

32. Normalizing State

Suppose you have:

{
  users: [
    {
      id: 1,
      name: "John"
    },
    {
      id: 2,
      name: "Sarah"
    }
  ]
}

As applications grow, searching and updating entities can become inefficient.

Normalized state can look like:

{
  users: {
    ids: [1, 2],

    entities: {
      1: {
        id: 1,
        name: "John"
      },

      2: {
        id: 2,
        name: "Sarah"
      }
    }
  }
}

Redux Toolkit provides:

createEntityAdapter()

for this use case.

33. createEntityAdapter

Example:

const usersAdapter = createEntityAdapter();

const initialState =
  usersAdapter.getInitialState();

You can then use generated reducers and selectors to manage entities efficiently.

This is especially useful for:

Users
Products
Orders
Messages
Notifications

34. Selectors in Large Applications

Instead of exposing state structure everywhere:

state.products.entities

create selectors:

const selectProducts =
  state => state.products.entities;

Then components use:

const products = useSelector(selectProducts);

This improves maintainability.

35. Derived State

Sometimes you don't need to store everything.

For example, suppose Redux contains:

{
  products: [
    { price: 100 },
    { price: 200 },
    { price: 300 }
  ]
}

You don't necessarily need:

{
  products: [...],
  totalPrice: 600
}

You can derive it:

const selectTotalPrice = state =>
  state.products.reduce(
    (total, product) => total + product.price,
    0
  );

This avoids duplicated state.

36. Memoized Selectors

For expensive calculations, selectors can be memoized.

Redux Toolkit works well with Reselect-style selectors.

Example:

const selectCompletedTodos = createSelector(
  [selectTodos],

  todos =>
    todos.filter(todo => todo.completed)
);

The selector can avoid recalculating when its inputs haven't changed.

37. Redux Architecture

A scalable Redux application can be organized by features:

src/
│
├── app/
│   └── store.js
│
├── features/
│   ├── auth/
│   │   ├── authSlice.js
│   │   ├── authSelectors.js
│   │   └── authApi.js
│   │
│   ├── products/
│   │   ├── productsSlice.js
│   │   ├── productsSelectors.js
│   │   └── productsApi.js
│   │
│   └── cart/
│       ├── cartSlice.js
│       └── cartSelectors.js
│
└── components/

This is called feature-based organization.

It scales much better than organizing everything by technical type.

38. Real-World Example: E-Commerce

Imagine an e-commerce application.

We might have:

Redux Store
│
├── auth
│
├── cart
│
├── products
│
├── orders
│
└── ui

Example:

{
  auth: {
    user: null,
    token: null
  },

  cart: {
    items: []
  },

  products: {
    ids: [],
    entities: {}
  },

  orders: {
    ids: [],
    entities: {}
  },

  ui: {
    sidebarOpen: false
  }
}

39. Adding a Product to the Cart

User clicks:

Add to Cart

The component dispatches:

dispatch(
  addToCart({
    productId: 10,
    quantity: 1
  })
);

Redux flow:

Product Component
       ↓
addToCart()
       ↓
Action
       ↓
Cart Reducer
       ↓
Cart State Updated
       ↓
Cart Icon
       ↓
UI Updated

The cart icon can now select:

const itemCount = useSelector(
  selectCartItemCount
);

40. Authentication Example

Suppose a user logs in.

The UI dispatches:

dispatch(
  loginSuccess({
    id: 1,
    name: "John"
  })
);

The reducer updates:

{
  user: {
    id: 1,
    name: "John"
  },
  isAuthenticated: true
}

Other components can react to this state.

For example:

const user = useSelector(selectCurrentUser);

41. Redux DevTools

One of Redux's biggest advantages is debugging.

Redux DevTools can show:

Action
   ↓
Previous State
   ↓
Action Payload
   ↓
Next State

For example:

cart/addItem

You can inspect:

{
  productId: 10,
  quantity: 2
}

and then compare the previous and next state.

This makes complex state transitions easier to debug.

42. Time-Travel Debugging

Because Redux state transitions are explicit:

State 0
 ↓
Action A
 ↓
State 1
 ↓
Action B
 ↓
State 2
 ↓
Action C
 ↓
State 3

development tools can replay state transitions.

This is one of the conceptual reasons Redux became popular.

43. Common Redux Mistakes

Mistake 1: Putting Everything in Redux

Don't put every UI detail into Redux.

Avoid:

{
  modalIsOpen: true,
  inputValue: "hello",
  hoverState: true
}

unless there is a genuine reason for global access.

Mistake 2: Mutating State Outside Immer

Do not do:

const user = store.getState().user;

user.name = "New Name";

State should be changed through Redux actions and reducers.

Mistake 3: Putting API Calls in Reducers

Avoid:

function reducer(state, action) {
  fetch("/api/users");

  return state;
}

Reducers should remain pure.

Mistake 4: Duplicating Derived Data

Avoid storing:

{
  items: [...],
  itemCount: 5
}

if itemCount can simply be calculated from items.

Mistake 5: Huge Global Slice

Avoid creating:

appSlice.js

with hundreds of unrelated responsibilities.

Prefer:

authSlice
cartSlice
productsSlice
ordersSlice
notificationsSlice

44. Redux vs Context API

React Context and Redux solve related but different problems.

Context

Good for:

Theme
Locale
Authentication context
Simple global configuration

Redux

Useful when you have:

Complex state
Many state transitions
Multiple consumers
Complex async workflows
Need for powerful debugging
Normalized entities
Large application state

Context is not automatically a replacement for Redux.

45. Redux vs useState

useState is excellent for local state.

const [count, setCount] = useState(0);

Redux becomes useful when state needs to be shared and the update logic becomes complex.

Think:

Simple local state
      ↓
useState

versus:

Complex shared application state
      ↓
Redux

46. Redux vs Zustand

Redux and Zustand are both state management solutions.

Redux provides a more structured architecture:

Actions
 ↓
Reducers
 ↓
Store

Zustand generally provides a simpler API with less ceremony.

Redux is often preferred when:

The application is large
A standardized architecture matters
Teams need predictable conventions
Advanced Redux tooling is valuable
Existing ecosystem integrations are important

Zustand can be attractive when simplicity and minimal boilerplate are priorities.

47. A Practical Redux Mental Model

If you remember only one model, remember this:

STATE
  ↑
REDUCER
  ↑
ACTION
  ↑
DISPATCH
  ↑
UI

Or:

User Interaction
      ↓
    Action
      ↓
    Reducer
      ↓
  New State
      ↓
     UI

48. Complete Mini Project

Let's combine the concepts.

Store

import { configureStore } from "@reduxjs/toolkit";
import cartReducer from "./cartSlice";

export const store = configureStore({
  reducer: {
    cart: cartReducer
  }
});

Slice

import { createSlice } from "@reduxjs/toolkit";

const cartSlice = createSlice({
  name: "cart",

  initialState: {
    items: []
  },

  reducers: {
    addItem(state, action) {
      const existingItem = state.items.find(
        item => item.id === action.payload.id
      );

      if (existingItem) {
        existingItem.quantity += 1;
      } else {
        state.items.push({
          ...action.payload,
          quantity: 1
        });
      }
    },

    removeItem(state, action) {
      state.items = state.items.filter(
        item => item.id !== action.payload
      );
    },

    clearCart(state) {
      state.items = [];
    }
  }
});

export const {
  addItem,
  removeItem,
  clearCart
} = cartSlice.actions;

export default cartSlice.reducer;

Selector

export const selectCartItems =
  state => state.cart.items;

export const selectCartCount =
  state =>
    state.cart.items.reduce(
      (total, item) => total + item.quantity,
      0
    );

Component

function Cart() {
  const items = useSelector(selectCartItems);
  const count = useSelector(selectCartCount);

  const dispatch = useDispatch();

  return (
    <div>
      <h1>Cart ({count})</h1>

      {items.map(item => (
        <div key={item.id}>
          {item.name}

          <button
            onClick={() =>
              dispatch(removeItem(item.id))
            }
          >
            Remove
          </button>
        </div>
      ))}

      <button
        onClick={() => dispatch(clearCart())}
      >
        Clear Cart
      </button>
    </div>
  );
}

This is already a realistic Redux pattern.

49. The Most Important Redux APIs

Modern Redux development commonly revolves around:

configureStore()
createSlice()
createAsyncThunk()
createEntityAdapter()
createSelector()
createApi()
fetchBaseQuery()

React integration commonly uses:

Provider
useSelector()
useDispatch()

You do not need to memorize everything immediately.

Understand the architecture first.

50. Redux in One Diagram

                         ┌──────────────┐
                         │     UI       │
                         └──────┬───────┘
                                │
                         dispatch(action)
                                │
                                ↓
                         ┌──────────────┐
                         │ Middleware   │
                         └──────┬───────┘
                                │
                                ↓
                         ┌──────────────┐
                         │   Reducer    │
                         └──────┬───────┘
                                │
                         New Immutable State
                                │
                                ↓
                         ┌──────────────┐
                         │    Store     │
                         └──────┬───────┘
                                │
                          subscribe/select
                                │
                                ↓
                         ┌──────────────┐
                         │     UI       │
                         └──────────────┘

Conclusion

Redux is fundamentally about predictable state transitions.

The most important concepts are:

Store
Actions
Reducers
Dispatch
Selectors
Middleware
Immutability

Modern Redux development should generally use Redux Toolkit rather than manually writing the older Redux boilerplate.

The key mental model is:

UI
 ↓
dispatch(Action)
 ↓
Middleware
 ↓
Reducer
 ↓
New State
 ↓
Store
 ↓
Selectors
 ↓
UI

Once you understand this flow, advanced Redux concepts such as asynchronous actions, RTK Query, entity adapters, memoized selectors, and large-scale Redux architecture become much easier to understand.

Redux isn't simply a place to put variables.

It is an architecture for making state changes explicit, predictable, traceable, and easier to manage as an application grows.

Why React & Next.js Users Get `ChunkLoadError` After Deployment — And How to Fix It

Abanoub Kerols — Sun, 20 Sep 2026 21:14:25 +0000

Imagine this:

You have a React or Next.js application running in production.

You deploy a new version.

New visitors can use the website normally.

But some users who already had the website open suddenly see:

ChunkLoadError
Failed to load chunk
Failed to fetch dynamically imported module
Loading chunk failed

Then they refresh the page...

And everything works again.

So what's happening?

Is the solution really to force every user to refresh?

No.

The refresh may recover the application, but it doesn't solve the underlying deployment problem.

The real issue is usually a version mismatch between the application running in the user's browser and the assets available on the server after deployment.

In this article, we'll understand why this happens and how production deployments should handle it.

The Problem
What Happens When a User Opens the Application?
What Changes During a Deployment?
Why Does the Old User Break?
Why Does Refreshing Fix It?
Understanding JavaScript Chunks
The Real Solution
Immutable Assets
Versioned Releases
Atomic Deployments
Rolling Deployments
Caching Strategy
What About Automatic Refresh?
A Production Architecture
The Interview Answer
Final Takeaway

The Problem

Let's start with a simple scenario.

A user opens your application:

https://example.com

At that moment, the production application is:

Version 1

The browser downloads the HTML and JavaScript assets required by that version.

For example:

app-ABC123.js
dashboard-XYZ456.js
profile-111.js

The user keeps the tab open.

After a few hours, you deploy a new version.

Now the server is running:

Version 2

The new build generates different assets:

app-DEF789.js
dashboard-QWE321.js
profile-222.js

Now we have:

Browser
   |
   | Version 1
   | Old runtime
   | Old chunks
   |
   v
--------------------
      Server
--------------------
   |
   | Version 2
   | New runtime
   | New chunks

This is where things can go wrong.

What Happens When a User Opens the Application?

A modern frontend application is usually not one giant JavaScript file.

The browser may load:

HTML
 |
 +-- main JavaScript
 |
 +-- framework/runtime
 |
 +-- feature chunks
 |
 +-- dynamically loaded chunks

For example:

flowchart TD
    A[Browser requests HTML] --> B[Application Runtime]
    B --> C[Initial JavaScript]
    B --> D[Dashboard Chunk]
    B --> E[Profile Chunk]
    B --> F[Other Dynamic Chunks]

Some chunks may only be loaded when the user navigates to a particular feature.

For example:

User opens application
        |
        v
Loads main application
        |
        v
User opens Dashboard
        |
        v
Browser requests dashboard chunk

This is one of the reasons modern frontend applications can be fast.

The browser doesn't necessarily download everything immediately.

What Changes During a Deployment?

Now imagine we change the Dashboard.

Version 1 contains:

dashboard-ABC123.js

After rebuilding the application:

Version 2 contains:

dashboard-DEF456.js

The new version is deployed.

If the deployment process removes the old asset:

dashboard-ABC123.js

then an existing browser session may still expect it.

That's the key problem.

Why Does the Old User Break?

Let's follow the request.

The user opened Version 1 earlier.

Their browser is still running the old runtime.

The old runtime says:

"I need dashboard-ABC123.js"

The browser requests:

GET /assets/dashboard-ABC123.js

But the deployment has already deleted it.

The server responds:

404 Not Found

The frontend may then produce:

ChunkLoadError

or:

Failed to fetch dynamically imported module

The sequence looks like this:

sequenceDiagram
    participant Browser
    participant Server

    Browser->>Server: Request old chunk
    Server-->>Browser: 404 Not Found
    Browser->>Browser: ChunkLoadError

The important point is:

The browser isn't necessarily broken. The deployment made the asset that its current runtime needs unavailable.

Why Does Refreshing Fix It?

This is the interesting part.

When the user refreshes the page, the browser requests the current application again.

Now the server returns Version 2.

The browser receives:

Version 2 HTML
       |
       v
Version 2 Runtime
       |
       v
Version 2 Chunks

Everything matches.

So the application works.

That's why a refresh appears to "fix" the problem.

But the refresh is only recovering the user by replacing the old application version with the new one.

It doesn't solve the deployment strategy.

The Real Problem: Version Mismatch

We can summarize the problem as:

Old Runtime
     +
Missing/Incompatible Old Assets
     =
Chunk Loading Failure

Or:

Browser Version
       !=
Available Server Assets

This is the mental model I use when debugging these issues.

Understanding JavaScript Chunks

Modern frontend build systems use techniques such as:

Code splitting
Lazy loading
Dynamic imports
Route-based splitting

Instead of generating:

application.js

the build may produce:

main-ABC123.js
dashboard-DEF456.js
profile-GHI789.js
settings-JKL012.js

The browser loads the chunks it needs.

For example:

const Dashboard = lazy(() => import("./Dashboard"));

The exact implementation differs between React, Next.js, bundlers, and deployment environments, but the important concept is the same:

The runtime needs to know where to find the correct assets for its build.

If those assets disappear during deployment, existing sessions can fail.

The Real Solution

So what should we do?

Not:

Deploy
   ↓
Delete everything old
   ↓
Hope existing users refresh

Instead, we want:

Build
  ↓
Create new release
  ↓
Publish new assets
  ↓
Validate release
  ↓
Switch traffic
  ↓
Keep old assets temporarily
  ↓
Cleanup later

This leads to several important concepts:

Immutable assets
Versioned releases
Atomic deployments
Rolling deployments
Correct caching
Controlled recovery

Let's look at each one.

Immutable Assets

One of the most important ideas is immutable assets.

Suppose Version 1 generates:

app-A1B2C3.js

Version 2 generates:

app-D4E5F6.js

Instead of modifying the old file, we keep both:

/assets/

app-A1B2C3.js
app-D4E5F6.js

Version 1 users can still request:

app-A1B2C3.js

Version 2 users can request:

app-D4E5F6.js

Both can coexist.

flowchart LR
    A[Old Users] --> B[Old Assets]
    C[New Users] --> D[New Assets]

    B --> E[Release 1]
    D --> F[Release 2]

This is much safer than replacing the contents of the same filename.

Why Do Asset Hashes Help?

Production builds commonly generate content-based filenames.

For example:

app-a82f91.js

If the code changes:

app-b91d72.js

The filename changes.

This gives us a very useful property:

If the filename contains the content hash, changing the content produces a different asset.

That means we can safely cache a particular asset for a long time because that exact file is not expected to change.

Versioned Releases

Another useful strategy is to treat every deployment as a separate release.

For example:

/releases/

release-101/
release-102/
release-103/

Each release contains its own application build.

Conceptually:

release-101/
    build/
    assets/
    server/

release-102/
    build/
    assets/
    server/

Then we have a pointer to the active release:

current -> release-102

When we deploy:

current -> release-103

The old release doesn't have to disappear immediately.

This gives existing users time to finish their current session.

Atomic Deployments

A dangerous deployment might look like:

Stop application
      ↓
Delete old build
      ↓
Copy new build
      ↓
Start application

This creates a period where the application may be partially unavailable.

A safer approach is:

Build new release
      ↓
Upload new release
      ↓
Validate it
      ↓
Switch traffic
      ↓
Keep old release
      ↓
Cleanup later

The switch between releases should be as atomic as possible.

For example:

flowchart TD
    A[Load Balancer / Nginx] --> B[Current Release]

    B --> C[Release 101]
    B --> D[Release 102]

    D --> E[New Release]

After validation:

Current → Release 102

Then Release 101 can remain available until it is safe to remove.

Rolling Deployments

If your application runs multiple instances, another option is a rolling deployment.

Suppose we start with:

Server 1 → Version 1
Server 2 → Version 1
Server 3 → Version 1

We deploy Version 2 gradually:

Server 1 → Version 2
Server 2 → Version 1
Server 3 → Version 1

Then:

Server 1 → Version 2
Server 2 → Version 2
Server 3 → Version 1

Finally:

Server 1 → Version 2
Server 2 → Version 2
Server 3 → Version 2

Health checks and a load balancer can help ensure traffic is only sent to healthy instances.

This reduces the chance of taking the entire application offline during deployment.

Caching Strategy

Caching is another important part of this problem.

We normally have two very different categories of resources:

HTML

and:

Hashed static assets

They should not necessarily have the same caching strategy.

For hashed assets:

app-a82f91.js

we can often use long-lived caching:

Cache-Control: public, max-age=31536000, immutable

because if the application changes, the build generates another filename.

For example:

Old:
app-a82f91.js

New:
app-b91d72.js

The old file doesn't need to be overwritten.

What About HTML?

HTML is different.

The HTML document references the assets belonging to a particular application version.

For example:

<script src="/assets/app-a82f91.js"></script>

A new deployment may produce:

<script src="/assets/app-b91d72.js"></script>

Therefore, caching HTML indefinitely can cause users to receive stale references.

A common high-level strategy is:

HTML
→ Revalidate more frequently

Hashed JS/CSS
→ Cache for a long time

The exact configuration depends on your framework, CDN, reverse proxy, and hosting architecture.

What About Next.js?

Next.js uses generated build assets under paths such as:

/_next/static/

A production deployment should treat the build as a coherent release.

The important principle is not:

"Never delete .next."

The important principle is:

Don't make assets required by an active application version disappear before that version is no longer needed.

How you achieve that depends on the deployment architecture.

For example, you might use:

Release 101
    |
    +-- .next
    +-- server
    +-- static assets

Release 102
    |
    +-- .next
    +-- server
    +-- static assets

Then switch the active release after the new version is ready.

What About React?

The same general concept applies to React applications.

For example, a Vite production build may generate:

dist/

assets/
    index-A1B2C3.js
    Dashboard-D4E5F6.js
    index-G7H8I9.css

After another build:

assets/
    index-J1K2L3.js
    Dashboard-M4N5O6.js
    index-P7Q8R9.css

The deployment should not blindly destroy assets that an existing application version may still require.

The exact files and runtime behavior depend on the build tool and architecture, but the deployment principle remains the same.

What About Automatic Refresh?

Now we can answer the original interview question.

Could we detect:

ChunkLoadError

and reload the page?

Yes.

A recovery mechanism could conceptually do:

ChunkLoadError
      ↓
Detect error
      ↓
Reload once
      ↓
Load current release

This can be useful.

But:

Automatic reload is a fallback, not the primary deployment solution.

If your deployment consistently deletes assets required by active sessions, adding window.location.reload() doesn't fix the architecture.

It only hides the symptom.

Why Blindly Reloading Can Be Dangerous

Imagine a user is filling out a form:

Name: John
Email: john@example.com
Phone: 01012345678

Then a chunk-loading error occurs.

If your application automatically executes:

window.location.reload();

the user may lose unsaved state.

There is another possible problem.

If the deployment is still broken:

ChunkLoadError
      ↓
Reload
      ↓
ChunkLoadError
      ↓
Reload
      ↓
ChunkLoadError

You can create a reload loop.

So if automatic recovery is implemented, it should be controlled carefully.

A Production-Oriented Architecture

A simplified architecture could look like this:

flowchart TD
    U[Users] --> CDN[CDN / Nginx]
    CDN --> LB[Load Balancer]

    LB --> R1[Current Release]
    LB --> R2[Previous Release]

    R1 --> A1[New Immutable Assets]
    R2 --> A2[Old Immutable Assets]

    R2 --> C[Cleanup Later]

The key idea is that the old assets don't disappear immediately.

Eventually:

Old users finish their sessions
        ↓
Old release is no longer needed
        ↓
Old assets can be cleaned up

A Complete Deployment Flow

A good mental model is:

Developer pushes code
        ↓
CI/CD builds application
        ↓
Create versioned release
        ↓
Generate hashed assets
        ↓
Publish assets
        ↓
Run tests / health checks
        ↓
Deploy new application version
        ↓
Switch traffic
        ↓
Keep old assets/release temporarily
        ↓
Users naturally move to new version
        ↓
Cleanup old release

This approach is much more robust than:

Delete old files
      ↓
Copy new files
      ↓
Hope everyone refreshes

Is This Only a Next.js Problem?

No.

You can encounter similar deployment problems in applications built with:

React
Next.js
Angular
Vue
Nuxt
Vite-based applications
Other applications using code splitting and dynamically loaded assets

The exact error message may differ.

But the underlying idea is often:

Client is running Version N
        +
Server/CDN is serving Version N+1
        +
Required old assets are unavailable
        =
Application failure

The Interview Answer

If an interviewer asks:

"Why do users who already have the website open get errors after we deploy a new React/Next.js version?"

A strong answer could be:

"It's usually caused by a version mismatch between the application runtime already running in the user's browser and the assets available after the deployment.

An existing user may still be running the old JavaScript runtime, which references a chunk from the previous build. If that chunk was removed during deployment, the browser gets a 404 and the application can throw a ChunkLoadError or fail to load a dynamic module.

I wouldn't solve this simply by forcing users to refresh. I'd use immutable, versioned assets and an atomic or rolling deployment strategy. Old assets should remain available long enough for existing sessions to drain, while new users receive the new release.

I'd also configure caching appropriately: hashed static assets can be cached for a long time, while HTML needs a different caching strategy.

An automatic reload can be used as a fallback recovery mechanism, but it shouldn't be the primary deployment solution."

That answer demonstrates that you understand more than React itself.

You understand the relationship between:

Frontend
   +
Build System
   +
Browser
   +
Caching
   +
CDN
   +
Deployment
   +
Infrastructure

Final Takeaway

The problem isn't simply:

"The user needs to refresh."

The deeper problem is:

A user can continue running an older version of a frontend application after the server has already deployed a newer version.

If the old runtime needs assets that the new deployment has removed, the application can fail.

The solution is to design deployments around version compatibility.

The key concepts are:

Immutable Assets
        +
Versioned Releases
        +
Atomic / Rolling Deployments
        +
Proper Cache Strategy
        +
Temporary Retention of Old Assets
        +
Controlled Recovery

Once you understand this model, ChunkLoadError is no longer just a mysterious React or Next.js error.

It's a client/server deployment consistency problem.

And that's the real answer to the interview question.

One More Thing

The next time someone answers this interview question with:

"Just force the user to refresh."

ask:

"What happens to the JavaScript chunks that the existing browser session is already using?"

That question gets you much closer to the real problem.

NgRx in Angular: A Practical Guide to State Management, Architecture, and Real-World Patterns

Abanoub Kerols — Thu, 17 Sep 2026 21:33:16 +0000

NgRx is more than a store. It is an architecture for managing complex application state in Angular using predictable state transitions, reactive programming, and unidirectional data flow.

Modern Angular applications can start simple, but as the application grows, state management becomes increasingly difficult.

You may eventually have:

Components sharing the same data
Multiple API requests updating the same state
Complex loading and error states
Data that must survive navigation
Business logic spread across components
Race conditions between asynchronous operations
Difficult-to-debug state changes

This is where NgRx becomes useful.

In this article, we will build the concepts from the ground up and gradually move toward real-world patterns.

What Is State Management?
Why Do We Need NgRx?
What Is NgRx?
NgRx Architecture
The Unidirectional Data Flow
Store
Actions
Reducers
Selectors
Effects
Dispatching Actions
Reading State
Complete CRUD Example
Async Operations
Loading and Error States
Entity State
NgRx Entity
Feature-Based State
ComponentStore vs Store
Facades
Immutability
Common NgRx Patterns
Common Mistakes
Performance
Testing
When Should You Use NgRx?
Final Architecture

1. What Is State Management?

Before understanding NgRx, we need to understand state.

State is simply the data that describes the current condition of your application.

For example:

interface User {
  id: number;
  name: string;
  email: string;
}

Your application might have:

interface AppState {
  user: User | null;
  isLoading: boolean;
  error: string | null;
}

At a particular moment:

{
  user: {
    id: 1,
    name: 'John',
    email: 'john@example.com'
  },
  isLoading: false,
  error: null
}

This is application state.

2. Local State vs Global State

Not every piece of state needs NgRx.

Consider a button:

isMenuOpen = false;

This is usually local component state.

You probably don't need a global store for it.

But consider:

Authentication
Products
Shopping Cart
User Profile
Notifications
Permissions
Orders

These may be shared by many parts of the application.

For example:

Navbar
   ↓
User Authentication State
   ↑
Profile Page
   ↑
Checkout
   ↑
Orders

When many components depend on the same state, centralized state management becomes useful.

3. What Is NgRx?

NgRx is a collection of Angular libraries inspired by Redux and built around reactive programming with RxJS.

The core idea is:

Component
   ↓
Action
   ↓
Reducer / Effect
   ↓
Store
   ↓
Selector
   ↓
Component

Instead of allowing components to modify shared state directly, state changes happen through actions.

This creates predictable state transitions.

4. NgRx Architecture

The main pieces are:

                ┌─────────────┐
                │  Component  │
                └──────┬──────┘
                       │
                    dispatch
                       │
                       ▼
                ┌─────────────┐
                │   Action    │
                └──────┬──────┘
                       │
             ┌─────────┴─────────┐
             │                   │
             ▼                   ▼
        ┌──────────┐        ┌──────────┐
        │ Reducer  │        │  Effect  │
        └────┬─────┘        └────┬─────┘
             │                   │
             │                   ▼
             │              HTTP / API
             │                   │
             │                   ▼
             │               Action
             │                   │
             └─────────┬─────────┘
                       ▼
                 ┌──────────┐
                 │  Store   │
                 └────┬─────┘
                      │
                   select
                      │
                      ▼
                ┌─────────────┐
                │  Component  │
                └─────────────┘

There are five concepts you should understand extremely well:

Actions
Reducers
Store
Selectors
Effects

5. The Unidirectional Data Flow

NgRx follows a unidirectional data flow.

That means data moves in a predictable direction.

UI
 ↓
Action
 ↓
State Transition
 ↓
Store
 ↓
Selector
 ↓
UI

For example:

this.store.dispatch(
  increment()
);

The component does not directly change:

count = count + 1;

Instead, it describes what happened:

increment()

The reducer determines how the state should change.

6. The Store

The Store is the centralized state container.

Imagine:

interface AppState {
  counter: number;
  user: User | null;
  products: Product[];
}

Conceptually:

Store
├── counter
├── user
└── products

The Store itself is observable.

You read state reactively:

counter$ = this.store.select(selectCounter);

Then:

<p>{{ counter$ | async }}</p>

7. Actions

An Action describes something that happened.

Example:

import { createAction } from '@ngrx/store';

export const increment = createAction(
  '[Counter] Increment'
);

Another:

export const loadProducts = createAction(
  '[Products Page] Load Products'
);

The string:

[Products Page] Load Products

is the action type.

A good action describes an event.

Prefer:

[Login Page] Login Submitted

over:

[Auth] Set User

Why?

Because the first describes what happened, while the second describes an implementation detail.

8. Actions With Payloads

Actions can carry data.

export const addToCart = createAction(
  '[Cart] Add Product',
  props<{ productId: number }>()
);

Dispatch:

this.store.dispatch(
  addToCart({ productId: 10 })
);

Another example:

export const login = createAction(
  '[Login Page] Login Submitted',
  props<{
    email: string;
    password: string;
  }>()
);

Then:

this.store.dispatch(
  login({
    email: 'john@example.com',
    password: '123456'
  })
);

9. Reducers

Reducers determine how state changes in response to actions.

Example:

import { createReducer, on } from '@ngrx/store';

export const initialState = 0;

export const counterReducer = createReducer(
  initialState,

  on(increment, state => state + 1)
);

The important concept is:

Action
   +
Current State
   ↓
New State

For example:

State = 5

Action = increment

Reducer

5 + 1

New State = 6

10. Reducers Must Be Pure

A reducer should be:

Predictable
Synchronous
Pure
Free from side effects

Don't do this inside a reducer:

on(loadProducts, state => {
  http.get('/products');
  return state;
});

Reducers should not perform HTTP requests.

They should only calculate the next state.

11. Immutable State

NgRx relies heavily on immutability.

Bad:

state.user.name = 'John';

return state;

Good:

return {
  ...state,
  user: {
    ...state.user,
    name: 'John'
  }
};

The idea is to create a new state reference instead of mutating the existing one.

12. Selectors

Selectors are used to read data from the Store.

Suppose:

interface CounterState {
  count: number;
}

Create a feature selector:

export const selectCounterState =
  createFeatureSelector<CounterState>('counter');

Then:

export const selectCount = createSelector(
  selectCounterState,
  state => state.count
);

Component:

count$ = this.store.select(selectCount);

Template:

<h1>
  {{ count$ | async }}
</h1>

13. Why Selectors Are Important

You might ask:

Why not simply get the entire state?

Because selectors provide:

Encapsulation

Components don't need to know how state is structured.

Memoization

Selectors can avoid unnecessary recalculations.

Reusability

Multiple components can use the same selector.

Performance

Components subscribe only to the data they need.

14. Derived State

One of the most powerful selector features is derived state.

Suppose:

interface CartState {
  items: CartItem[];
}

You can calculate:

export const selectCartTotal = createSelector(
  selectCartItems,
  items =>
    items.reduce(
      (total, item) => total + item.price * item.quantity,
      0
    )
);

The total does not need to be stored separately.

Instead:

Cart Items
    ↓
Selector
    ↓
Cart Total

This avoids duplicated state.

15. Effects

Effects handle side effects.

Examples:

HTTP Requests
Local Storage
Analytics
Navigation
WebSocket interactions
External APIs

Suppose:

User clicks Load Products
        ↓
loadProducts action
        ↓
Effect
        ↓
HTTP request
        ↓
API response
        ↓
loadProductsSuccess
        ↓
Reducer
        ↓
Store

This is the main purpose of NgRx Effects.

16. Example Effect

@Injectable()
export class ProductsEffects {

  loadProducts$ = createEffect(() =>
    this.actions$.pipe(

      ofType(loadProducts),

      switchMap(() =>
        this.productsService.getProducts().pipe(

          map(products =>
            loadProductsSuccess({ products })
          ),

          catchError(error =>
            of(loadProductsFailure({ error }))
          )

        )
      )

    )
  );

  constructor(
    private actions$: Actions,
    private productsService: ProductsService
  ) {}
}

The effect listens for:

loadProducts

Then performs:

productsService.getProducts()

And dispatches:

loadProductsSuccess

or:

loadProductsFailure

17. The Complete Request Flow

Let's visualize it:

User
 │
 ▼
Products Component
 │
 │ dispatch()
 ▼
loadProducts
 │
 ▼
Products Effect
 │
 │ HTTP
 ▼
Backend API
 │
 ▼
Response
 │
 ▼
loadProductsSuccess
 │
 ▼
Products Reducer
 │
 ▼
Store
 │
 ▼
selectProducts
 │
 ▼
Products Component

This is one of the most important NgRx flows to understand.

18. Loading and Error State

A realistic application needs more than data.

For example:

interface ProductsState {
  products: Product[];
  loading: boolean;
  error: string | null;
}

Initial state:

const initialState: ProductsState = {
  products: [],
  loading: false,
  error: null
};

When loading starts:

on(loadProducts, state => ({
  ...state,
  loading: true,
  error: null
}))

Success:

on(loadProductsSuccess, (state, { products }) => ({
  ...state,
  products,
  loading: false
}))

Failure:

on(loadProductsFailure, (state, { error }) => ({
  ...state,
  loading: false,
  error
}))

19. Complete Products Example

Actions

export const loadProducts = createAction(
  '[Products Page] Load Products'
);

export const loadProductsSuccess = createAction(
  '[Products API] Load Products Success',
  props<{ products: Product[] }>()
);

export const loadProductsFailure = createAction(
  '[Products API] Load Products Failure',
  props<{ error: string }>()
);

Reducer

export interface ProductsState {
  products: Product[];
  loading: boolean;
  error: string | null;
}

export const initialState: ProductsState = {
  products: [],
  loading: false,
  error: null
};

export const productsReducer = createReducer(
  initialState,

  on(loadProducts, state => ({
    ...state,
    loading: true,
    error: null
  })),

  on(loadProductsSuccess, (state, { products }) => ({
    ...state,
    products,
    loading: false
  })),

  on(loadProductsFailure, (state, { error }) => ({
    ...state,
    loading: false,
    error
  }))
);

Selectors

export const selectProductsState =
  createFeatureSelector<ProductsState>('products');

export const selectProducts = createSelector(
  selectProductsState,
  state => state.products
);

export const selectLoading = createSelector(
  selectProductsState,
  state => state.loading
);

export const selectError = createSelector(
  selectProductsState,
  state => state.error
);

Component

products$ = this.store.select(selectProducts);
loading$ = this.store.select(selectLoading);
error$ = this.store.select(selectError);

loadProducts() {
  this.store.dispatch(loadProducts());
}

Template

<button (click)="loadProducts()">
  Load Products
</button>

@if (loading$ | async) {
  <p>Loading...</p>
}

@if (error$ | async; as error) {
  <p>{{ error }}</p>
}

@for (product of products$ | async; track product.id) {
  <article>
    <h2>{{ product.name }}</h2>
    <p>{{ product.price }}</p>
  </article>
}

20. NgRx Entity

Imagine you have:

Product[]

with thousands of products.

You frequently need:

Find product by ID
Add product
Remove product
Update product
Select all products

Managing arrays manually becomes repetitive.

NgRx Entity provides utilities for normalized collections.

Conceptually:

Entity State

ids:
[1, 2, 3]

entities:
{
  1: Product,
  2: Product,
  3: Product
}

Instead of:

products.find(p => p.id === id);

the entity adapter can provide selectors and operations for you.

21. Entity Adapter

Example:

const adapter = createEntityAdapter<Product>();

Initial state:

const initialState =
  adapter.getInitialState({
    loading: false,
    error: null
  });

Add products:

adapter.addMany(products, state);

Update:

adapter.updateOne(
  {
    id: product.id,
    changes: product
  },
  state
);

Remove:

adapter.removeOne(productId, state);

This becomes extremely useful for large collections.

22. Feature-Based Architecture

A large Angular application should not have one giant Store file.

Instead:

src/app/
│
├── core/
│
├── shared/
│
└── features/
    │
    ├── auth/
    │   ├── store/
    │   │   ├── auth.actions.ts
    │   │   ├── auth.reducer.ts
    │   │   ├── auth.effects.ts
    │   │   └── auth.selectors.ts
    │   │
    │   └── pages/
    │
    ├── products/
    │   ├── store/
    │   │   ├── products.actions.ts
    │   │   ├── products.reducer.ts
    │   │   ├── products.effects.ts
    │   │   └── products.selectors.ts
    │
    └── cart/
        ├── store/
        │   ├── cart.actions.ts
        │   ├── cart.reducer.ts
        │   ├── cart.effects.ts
        │   └── cart.selectors.ts

This keeps features isolated.

23. NgRx Facade Pattern

Some teams don't want components to know about NgRx directly.

Instead, introduce a facade.

@Injectable({
  providedIn: 'root'
})
export class ProductsFacade {

  products$ = this.store.select(selectProducts);

  loading$ = this.store.select(selectLoading);

  constructor(
    private store: Store
  ) {}

  loadProducts() {
    this.store.dispatch(loadProducts());
  }
}

Component:

constructor(
  private productsFacade: ProductsFacade
) {}

products$ = this.productsFacade.products$;

loadProducts() {
  this.productsFacade.loadProducts();
}

Now the component doesn't know about:

Actions
Selectors
Store

It only knows:

ProductsFacade

This can be useful in large applications.

24. RxJS and NgRx

NgRx relies heavily on RxJS.

For example:

this.store.select(selectProducts)

returns an Observable.

Effects also use RxJS operators:

ofType()
switchMap()
mergeMap()
concatMap()
exhaustMap()
map()
catchError()

Understanding RxJS is therefore extremely valuable when working with NgRx.

25. Choosing the Correct Flattening Operator

This is a common interview topic.

switchMap

Cancels the previous request.

Useful for:

Search
Autocomplete

Example:

actions$.pipe(
  ofType(searchProducts),
  switchMap(...)
);

concatMap

Queues requests.

Request 1
   ↓
Request 2
   ↓
Request 3

Useful when order matters.

mergeMap

Runs requests concurrently.

Request 1 ────────┐
Request 2 ────────┤
Request 3 ────────┘

Useful when requests are independent.

exhaustMap

Ignores new requests while one is running.

Useful for:

Login
Submit button
Payment

For example:

actions$.pipe(
  ofType(login),
  exhaustMap(...)
);

If the user clicks Login multiple times quickly, subsequent clicks are ignored until the first request completes.

26. NgRx vs Services

You don't need NgRx for every Angular application.

A simple service may be enough:

@Injectable({
  providedIn: 'root'
})
export class CartService {

  private cartSubject =
    new BehaviorSubject<CartItem[]>([]);

  cart$ = this.cartSubject.asObservable();

  add(item: CartItem) {
    const current = this.cartSubject.value;

    this.cartSubject.next([
      ...current,
      item
    ]);
  }
}

This can work perfectly well for a small application.

NgRx becomes more valuable when state transitions and interactions become complex.

27. NgRx vs ComponentStore

NgRx Store is designed for centralized application state.

ComponentStore is better suited for localized state.

Example:

Global Application State
        ↓
      Store

Feature-local state
        ↓
  ComponentStore

You don't necessarily need to choose one exclusively.

A large application can use both.

28. What Should NOT Go Into NgRx?

A common mistake is putting everything into the Store.

Don't automatically store:

isDropdownOpen
hoveredItem
temporary input values
modal visibility
simple UI flags

unless there is a real reason.

Ask:

Does this state need to be shared, persisted, coordinated, or observed across multiple parts of the application?

If not, local state may be better.

29. Avoid Duplicated State

Suppose you have:

products: Product[];
selectedProduct: Product;

You may be duplicating information.

Instead, consider:

products: Product[];
selectedProductId: number | null;

Then:

export const selectSelectedProduct = createSelector(
  selectProducts,
  selectSelectedProductId,
  (products, id) =>
    products.find(product => product.id === id) ?? null
);

Now there is one source of truth.

30. Keep Business Logic Out of Components

Bad:

loadProducts() {

  this.loading = true;

  this.http.get('/products')
    .subscribe(products => {

      this.products = products;

      this.loading = false;
    });
}

This mixes:

UI
HTTP
State
Loading
Error handling

With NgRx:

loadProducts() {
  this.store.dispatch(loadProducts());
}

The component becomes much simpler.

31. Smart vs Presentational Components

NgRx works well with the separation between container and presentational components.

Container

Responsible for state interaction.

products$ = this.facade.products$;

Presentational

Receives data:

@Input()
products: Product[] = [];

and emits events:

@Output()
productSelected = new EventEmitter<number>();

Architecture:

Container
   │
   ├── Store
   │
   └── Presentational Component
             │
             └── UI

32. Router Store

NgRx can also integrate router state.

This can allow application state to react to route changes.

Conceptually:

URL
 ↓
Router
 ↓
Router Store
 ↓
Selectors
 ↓
Application

This can be useful when route parameters influence application state.

33. DevTools

One of the major advantages of NgRx is debugging.

With Redux DevTools, you can inspect:

Action
 ↓
Previous State
 ↓
Next State

For example:

[Cart] Add Product

Previous:
items: []

Next:
items: [Product 1]

This makes complex state transitions much easier to understand.

34. Time-Travel Debugging

Because state changes are represented as actions, you can conceptually replay state transitions.

Action 1
Action 2
Action 3
Action 4

Instead of debugging:

"Something changed somewhere."

you can investigate:

"Which action caused the state transition?"

This is one of the architectural strengths of Redux-style state management.

35. Testing Reducers

Reducers are easy to test because they are pure functions.

Example:

it('should increment counter', () => {

  const state = counterReducer(
    5,
    increment()
  );

  expect(state).toBe(6);
});

No HTTP request.

No browser.

No asynchronous operation.

Just:

Input
 ↓
Reducer
 ↓
Output

36. Testing Selectors

Selectors can also be tested independently.

For example:

const state = {
  products: [
    { id: 1, price: 100 },
    { id: 2, price: 200 }
  ]
};

Then verify:

expect(selectProducts.projector(
  state.products
)).toEqual(state.products);

Selectors are another reason to keep business calculations outside components.

37. Testing Effects

Effects require testing asynchronous behavior.

Conceptually:

Input Action
     ↓
Effect
     ↓
Mock API
     ↓
Output Action

You can verify:

loadProducts
       ↓
API called
       ↓
loadProductsSuccess

or:

loadProducts
       ↓
API error
       ↓
loadProductsFailure

38. Common NgRx Mistakes

Mistake 1 — Putting everything in Store

Not every variable belongs in global state.

Mistake 2 — Mutating state

Bad:

state.products.push(product);
return state;

Good:

return {
  ...state,
  products: [
    ...state.products,
    product
  ]
};

Mistake 3 — HTTP inside reducers

Never.

Use Effects or another appropriate side-effect mechanism.

Mistake 4 — Huge selectors

Selectors should remain focused and composable.

Mistake 5 — Components containing business logic

If your component becomes:

500+ lines

and heavily interacts with Store, consider extracting logic.

Mistake 6 — Overusing Effects

Effects are for side effects.

Don't create an effect just to transform simple state synchronously when a reducer or selector is enough.

39. NgRx and Angular Signals

Modern Angular applications increasingly use Signals.

You can bridge Store Observables into Signals.

For example:

products = this.store.selectSignal(selectProducts);

Then in the template:

@for (product of products(); track product.id) {
  <p>{{ product.name }}</p>
}

This gives you a more signal-oriented component API while still using NgRx for centralized state management.

40. A Real-World E-Commerce Architecture

Imagine an e-commerce application.

We could structure the state as:

Application Store
│
├── Auth
│   ├── user
│   ├── token
│   └── loading
│
├── Products
│   ├── entities
│   ├── filters
│   ├── loading
│   └── error
│
├── Cart
│   ├── items
│   └── total
│
├── Orders
│   ├── entities
│   ├── loading
│   └── error
│
└── UI
    ├── notifications
    └── theme

The flow could be:

User
 │
 ▼
Angular Component
 │
 ▼
Action
 │
 ├──────────────┐
 ▼              ▼
Reducer        Effect
 │              │
 ▼              ▼
Store          API
 │              │
 │              ▼
 │         Success Action
 │              │
 └──────────────┘
        │
        ▼
     Selector
        │
        ▼
    Component

This architecture scales significantly better than putting all application logic into components.

41. When Should You Use NgRx?

NgRx is a good choice when your application has:

Complex shared state
Multiple features depending on the same data
Many asynchronous workflows
Complex state transitions
Large teams
Strong debugging requirements
Event-driven architecture
Need for predictable state changes
Significant business logic

Examples:

E-commerce
Banking dashboards
Admin platforms
CRM systems
Large SaaS applications
Enterprise applications
Real-time applications

42. When Should You Avoid NgRx?

For a small application:

5 components
2 API calls
simple forms
little shared state

NgRx may introduce unnecessary complexity.

A simple:

Component
   ↓
Service
   ↓
HTTP

architecture might be better.

The goal is not:

"Use NgRx because NgRx is powerful."

The goal is:

"Use the simplest architecture that can reliably manage the application's complexity."

43. The Most Important Mental Model

If you remember only one thing, remember this:

Action = What happened?

Reducer = How does state change?

Effect = What side effect should happen?

Selector = What state does the UI need?

Store = Where is application state centralized?

For example:

User clicks "Add to Cart"

Action:
[Product Page] Add To Cart

        ↓

Reducer:
Add product to cart state

        ↓

Effect:
Maybe synchronize cart with backend

        ↓

Store:
Updated cart

        ↓

Selector:
Calculate cart count

        ↓

UI:
Cart: 3 items

That is NgRx.

44. Final Architecture

A mature Angular + NgRx application can look like:

                    Angular UI
                        │
                        ▼
                  Component / Facade
                        │
                        ▼
                     Action
                        │
             ┌──────────┴──────────┐
             │                     │
             ▼                     ▼
          Reducer                Effect
             │                     │
             │                  HTTP/API
             │                     │
             │                     ▼
             │               Success/Failure
             │                     │
             └──────────┬──────────┘
                        ▼
                      Store
                        │
                        ▼
                    Selectors
                        │
                        ▼
                  Component / UI

This architecture gives you:

Predictable state transitions
Centralized state
Reactive data flow
Testable business logic
Clear separation of concerns
Better debugging
Scalable feature architecture

Conclusion

NgRx is not simply a library for storing variables.

It is a state-management architecture built around a very clear philosophy:

Events
  ↓
Actions
  ↓
State Transitions
  ↓
Store
  ↓
Selectors
  ↓
UI

Effects extend this architecture by handling asynchronous operations and other side effects.

The real power of NgRx appears when an application becomes complex enough that managing state manually starts becoming difficult.

The key is not to memorize APIs.

Understand the architecture first:

Actions
Reducers
Selectors
Effects
Store

Once those concepts are clear, the NgRx APIs become much easier to learn.

And the most important practical rule is:

Don't introduce NgRx because your application is Angular. Introduce it because your application's state management has become complex enough to justify it.

RxJS in Practice: Reactive Programming, Operators, Patterns, and Real-World Examples

Abanoub Kerols — Tue, 15 Sep 2026 21:01:42 +0000

RxJS is not just a library of operators. It is a different way of thinking about asynchronous data.

If you work with Angular, Node.js, React, or any application that deals with asynchronous operations, you will eventually encounter problems involving:

HTTP requests
User input
WebSockets
Events
Timers
State changes
Multiple asynchronous operations
Cancellation
Race conditions
Retries
Error handling

RxJS provides a powerful model for solving these problems through Reactive Programming.

In this article, we will move from the theory to practical examples and finally build a realistic Angular-style application using RxJS.

1. What Is RxJS?

RxJS (Reactive Extensions for JavaScript) is a library for composing asynchronous and event-based programs using Observables.

Instead of thinking:

"I have a function that will eventually return a value."

You start thinking:

"I have a stream of values that may arrive over time."

For example:

const observable$ = new Observable(subscriber => {
  subscriber.next(1);
  subscriber.next(2);
  subscriber.next(3);
});

The observable represents a stream:

1 ───> 2 ───> 3 ───> complete

But an Observable doesn't have to emit only three values.

It could represent:

User clicks
   ↓
click
   ↓
click
   ↓
click
   ↓
...

Or:

HTTP Request
     ↓
Response
     ↓
Complete

Or:

WebSocket
   ↓
Message
   ↓
Message
   ↓
Message
   ↓
Message
   ↓
...

This is the fundamental idea behind RxJS.

2. What Is Reactive Programming?

Reactive programming is a programming paradigm based on:

Reacting to changes and events over time.

Traditional imperative programming often looks like:

const value = getValue();

console.log(value);

You ask for a value and receive it.

Reactive programming looks more like:

value$.subscribe(value => {
  console.log(value);
});

You are saying:

"Whenever a value arrives, execute this logic."

This becomes extremely powerful when dealing with asynchronous systems.

3. The Core RxJS Concepts

RxJS revolves around several important concepts:

Observable
    ↓
Subscribe
    ↓
Receive values
    ↓
Operators
    ↓
Transform / Filter / Combine
    ↓
Observer

The most important concepts are:

Observable
Observer
Subscriber
Subscription
Operators
Subject
Schedulers

Let's understand them.

4. Observable

An Observable represents a stream of values over time.

Example:

import { Observable } from 'rxjs';

const observable$ = new Observable<number>(subscriber => {
  subscriber.next(10);
  subscriber.next(20);
  subscriber.next(30);

  subscriber.complete();
});

Subscribe:

observable$.subscribe(value => {
  console.log(value);
});

Output:

10
20
30

The $ suffix is a common naming convention:

users$
products$
orders$
searchResults$

It usually means:

"This variable represents an Observable."

It is a convention, not a language requirement.

5. Observable Lifecycle

An Observable can emit three kinds of notifications:

next
error
complete

Example:

const observable$ = new Observable<number>(subscriber => {
  subscriber.next(1);
  subscriber.next(2);
  subscriber.next(3);

  subscriber.complete();
});

Conceptually:

next(1)
   ↓
next(2)
   ↓
next(3)
   ↓
complete()

An Observable can also fail:

const observable$ = new Observable<number>(subscriber => {
  subscriber.next(1);

  subscriber.error(
    new Error('Something went wrong')
  );
});

Then:

next(1)
   ↓
error

Once an Observable sends either:

complete()

or:

error(...)

the stream terminates.

6. Observer

An Observer defines what should happen when the Observable emits values, errors, or completes.

observable$.subscribe({
  next: value => {
    console.log('Value:', value);
  },

  error: error => {
    console.error('Error:', error);
  },

  complete: () => {
    console.log('Completed');
  }
});

This is more explicit than:

observable$.subscribe(value => {
  console.log(value);
});

For production code, the object form is often easier to maintain when error or completion handling matters.

7. Subscription

When you subscribe:

const subscription = observable$.subscribe({
  next: value => console.log(value)
});

you receive a Subscription.

You can unsubscribe:

subscription.unsubscribe();

This matters for long-lived streams such as:

WebSockets
DOM events
intervals
Subjects
application-wide streams

Example:

const subscription = interval(1000).subscribe(value => {
  console.log(value);
});

setTimeout(() => {
  subscription.unsubscribe();
}, 5000);

The interval stops after approximately five seconds.

8. Cold Observables

A cold Observable starts its producer separately for each subscriber.

Example:

const observable$ = new Observable<number>(subscriber => {
  console.log('Producer started');

  subscriber.next(Math.random());
});

Subscribe twice:

observable$.subscribe(value => {
  console.log('Subscriber 1:', value);
});

observable$.subscribe(value => {
  console.log('Subscriber 2:', value);
});

The producer runs twice.

Conceptually:

Subscriber 1
     ↓
Producer A

Subscriber 2
     ↓
Producer B

Each subscriber gets its own execution.

9. Hot Observables

A hot Observable represents a shared source.

For example:

WebSocket
   ↓
   ├── Subscriber A
   ├── Subscriber B
   └── Subscriber C

The source exists independently of individual subscribers.

This concept becomes especially important when using:

Subject
share()
shareReplay()

10. Operators

Operators are one of the most important parts of RxJS.

They allow you to transform and control streams.

For example:

source$
  .pipe(
    map(value => value * 2),
    filter(value => value > 10)
  )
  .subscribe(value => {
    console.log(value);
  });

Think of an RxJS pipeline as:

Source
  ↓
map
  ↓
filter
  ↓
subscribe

11. `map`

map transforms every emitted value.

of(1, 2, 3)
  .pipe(
    map(value => value * 10)
  )
  .subscribe(console.log);

Output:

10
20
30

Conceptually:

1 → map → 10
2 → map → 20
3 → map → 30

A very common example is extracting data from an HTTP response:

this.http.get<ApiResponse<User[]>>('/api/users')
  .pipe(
    map(response => response.data)
  );

Now the consumer receives only:

User[]

instead of the complete response object.

12. `filter`

filter allows only values matching a condition.

of(1, 2, 3, 4, 5)
  .pipe(
    filter(value => value % 2 === 0)
  )
  .subscribe(console.log);

Output:

2
4

Think:

1 ❌
2 ✅
3 ❌
4 ✅
5 ❌

13. `tap`

tap allows you to perform side effects without changing the emitted value.

users$
  .pipe(
    tap(users => {
      console.log('Users:', users);
    })
  )
  .subscribe();

tap is useful for:

Logging
Debugging
Analytics
Updating external state
Observing the pipeline

Avoid using tap to secretly transform data.

Bad:

tap(user => {
  user.name = 'Changed';
})

Prefer transformations through operators such as:

map(user => ({
  ...user,
  name: 'Changed'
}))

14. `debounceTime`

One of the most practical RxJS operators.

Imagine a search box.

Without debouncing:

c
ca
cat
cats

You might send four HTTP requests.

With:

debounceTime(300)

the application waits until the user stops typing for 300ms.

searchTerm$
  .pipe(
    debounceTime(300)
  )

Conceptually:

c
ca
cat
cats
         ↓ 300ms
       "cats"

Only "cats" continues through the pipeline.

15. `distinctUntilChanged`

This operator prevents consecutive duplicate values.

of(
  'Angular',
  'Angular',
  'React',
  'React',
  'Vue'
)
.pipe(
  distinctUntilChanged()
)
.subscribe(console.log);

Output:

Angular
React
Vue

Very useful for:

Search inputs
Filters
Route parameters
State changes

16. `switchMap`

switchMap is one of the most important RxJS operators.

Imagine:

User searches:
Angular
Angular RxJS
Angular RxJS operators

Each search creates an HTTP request.

You usually don't want an old request to overwrite the latest result.

switchMap solves this by switching to the newest inner Observable and unsubscribing from the previous one.

searchTerm$
  .pipe(
    switchMap(term => this.searchApi(term))
  )

Conceptually:

Search A
   ↓
Request A

Search B
   ↓
Cancel/Unsubscribe A
   ↓
Request B

Search C
   ↓
Cancel/Unsubscribe B
   ↓
Request C

This makes switchMap ideal for:

Search
Autocomplete
Route parameter changes
Refreshing data
User-driven queries

17. `mergeMap`

mergeMap subscribes to inner Observables concurrently.

ids$
  .pipe(
    mergeMap(id => this.getUser(id))
  );

Conceptually:

ID 1 → Request 1
ID 2 → Request 2
ID 3 → Request 3

All can run concurrently.

Use it when previous operations should not be cancelled.

Typical use cases:

Independent HTTP requests
Processing multiple items
Concurrent operations

18. `concatMap`

concatMap queues inner Observables and runs them sequentially.

actions$
  .pipe(
    concatMap(action => this.save(action))
  );

Conceptually:

Action A
   ↓
Request A
   ↓
Complete

Action B
   ↓
Request B
   ↓
Complete

Action C
   ↓
Request C

Use it when order matters.

For example:

Create record A
      ↓
Update A
      ↓
Delete A

You may not want these operations running concurrently.

19. `exhaustMap`

exhaustMap ignores new emissions while the current inner Observable is running.

Example:

submitClick$
  .pipe(
    exhaustMap(() => this.submitForm())
  );

Imagine the user double-clicks:

Click
 ↓
Request starts

Click
 ↓
IGNORED

Click
 ↓
IGNORED

Request completes

This is extremely useful for preventing duplicate submissions.

20. The Four Important Mapping Operators

A useful mental model:

Operator	Behavior
`switchMap`	Cancel previous
`mergeMap`	Run concurrently
`concatMap`	Queue sequentially
`exhaustMap`	Ignore while busy

Think about them like this:

switchMap
Latest wins

mergeMap
Everything runs

concatMap
One by one

exhaustMap
First wins while busy

Choosing the correct flattening operator is one of the most important RxJS skills.

21. `catchError`

Errors are inevitable.

RxJS provides:

catchError()

Example:

this.http.get<User[]>('/api/users')
  .pipe(
    catchError(error => {
      console.error(error);

      return of([]);
    })
  );

Instead of terminating the application flow unexpectedly, the stream returns an empty array.

However, error handling should reflect the application's requirements.

Sometimes you should recover:

catchError(() => of([]))

Sometimes you should rethrow:

catchError(error => {
  return throwError(() => error);
})

22. `retry`

Transient failures can sometimes be retried.

this.http.get('/api/data')
  .pipe(
    retry(3)
  );

Conceptually:

Request
 ↓
Fail
 ↓
Retry
 ↓
Fail
 ↓
Retry
 ↓
Fail
 ↓
Retry

But blindly retrying everything is a bad idea.

For example, retrying a validation error won't usually solve anything.

Retries are more appropriate for transient failures.

23. `finalize`

finalize runs when the Observable terminates because of completion, error, or unsubscription.

Example:

this.loading = true;

this.http.get('/api/users')
  .pipe(
    finalize(() => {
      this.loading = false;
    })
  )
  .subscribe();

This is useful for cleanup:

Start request
   ↓
loading = true
   ↓
HTTP request
   ↓
complete/error/unsubscribe
   ↓
loading = false

24. Creating Observables

RxJS provides many creation functions.

`of`

of(1, 2, 3)

Emits:

1
2
3

`from`

from([1, 2, 3])

Also emits:

1
2
3

But from can convert many iterable or Promise-like sources.

For example:

from(fetch('/api/users'))

25. `interval`

Creates periodic emissions.

interval(1000)
  .subscribe(value => {
    console.log(value);
  });

Output:

0
1
2
3
4
...

This Observable does not naturally complete.

Therefore, long-lived subscriptions should be managed carefully.

26. `timer`

timer(2000)

Emits after two seconds.

You can also create repeated emissions:

timer(0, 1000)

Conceptually:

0
 ↓ 1 sec
1
 ↓ 1 sec
2
 ↓ 1 sec
3
...

27. Subjects

A Subject is both:

an Observable
an Observer

Example:

const subject$ = new Subject<number>();

subject$.subscribe(value => {
  console.log('A:', value);
});

subject$.subscribe(value => {
  console.log('B:', value);
});

subject$.next(10);
subject$.next(20);

Output:

A: 10
B: 10

A: 20
B: 20

The Subject multicasts values to its subscribers.

28. BehaviorSubject

BehaviorSubject requires an initial value and stores the latest value.

const user$ = new BehaviorSubject<User | null>(null);

When a new subscriber arrives, it immediately receives the current value.

Current value = User A

Subscriber joins
       ↓
Receives User A

This makes BehaviorSubject useful for representing state.

Example:

private currentUserSubject =
  new BehaviorSubject<User | null>(null);

currentUser$ =
  this.currentUserSubject.asObservable();

Then:

this.currentUserSubject.next(user);

29. ReplaySubject

ReplaySubject can replay previous emissions.

const subject$ = new ReplaySubject<number>(2);

subject$.next(1);
subject$.next(2);
subject$.next(3);

subject$.subscribe(value => {
  console.log(value);
});

Output:

2
3

because we configured it to replay the last two values.

30. `combineLatest`

Sometimes you need the latest value from multiple streams.

Example:

combineLatest([
  user$,
  settings$,
  permissions$
])

Conceptually:

User ────────┐
             │
Settings ────┼──> combineLatest
             │
Permissions ─┘

It emits when one source emits, after every source has emitted at least once.

Useful for:

Filters
UI state
User preferences
Multiple dependent inputs

31. `forkJoin`

forkJoin waits for all supplied Observables to complete and then emits their final values.

Perfect for independent HTTP requests:

forkJoin({
  users: this.getUsers(),
  products: this.getProducts(),
  orders: this.getOrders()
})

Conceptually:

Users ────────┐
Products ─────┼──> forkJoin → result
Orders ───────┘

Important distinction:

forkJoin is generally for "wait until all complete."

combineLatest is generally for "react whenever the latest values change."

32. `withLatestFrom`

Sometimes one Observable should trigger the operation while reading the latest value from another.

Example:

submit$
  .pipe(
    withLatestFrom(formValue$)
  )

Think:

submit$ ────────────────┐
                        ↓
                    withLatestFrom
                        ↑
formValue$ ─────────────┘

The submit event is the trigger.

33. RxJS and Angular

RxJS is deeply integrated into Angular.

Common examples include:

HttpClient
ActivatedRoute
Router events
Reactive Forms
Event streams
NgRx
WebSockets

For example:

this.route.params
  .pipe(
    switchMap(params =>
      this.userService.getUser(params['id'])
    )
  );

This is a classic Angular pattern.

34. Real-World Search Example

Let's build a search pipeline.

We have:

searchControl = new FormControl('');

Then:

searchResults$ = this.searchControl.valueChanges.pipe(
  debounceTime(300),

  distinctUntilChanged(),

  filter(term => !!term && term.length >= 2),

  switchMap(term =>
    this.searchService.search(term)
  )
);

Let's understand the pipeline:

User types
   ↓
valueChanges
   ↓
debounceTime
   ↓
distinctUntilChanged
   ↓
filter
   ↓
switchMap
   ↓
HTTP request
   ↓
results

This is a real RxJS use case.

35. Why `switchMap` Matters Here

Imagine:

User types: angular

Request A starts

Then:

User types: angular rxjs

Request B starts

The old search is no longer relevant.

With:

switchMap()

the pipeline switches to the newest request.

Without the correct concurrency strategy, an older response could potentially create stale UI state depending on how the requests are managed.

36. Preventing Duplicate Form Submissions

Consider:

submit$
  .pipe(
    exhaustMap(() => this.api.submitForm())
  )
  .subscribe();

If the user clicks:

Submit
Submit
Submit

while the first request is running:

Submit #1 → Request
Submit #2 → ignored
Submit #3 → ignored

This is one of the clearest real-world uses for exhaustMap.

37. Sequential API Operations

Suppose we need:

Create Order
     ↓
Create Payment
     ↓
Send Confirmation

You may need sequential execution.

For a stream of operations:

operations$
  .pipe(
    concatMap(operation =>
      this.execute(operation)
    )
  );

concatMap preserves order by waiting for the previous inner Observable to complete.

38. Parallel Requests

If operations are independent:

ids$
  .pipe(
    mergeMap(id => this.loadUser(id))
  );

Requests can execute concurrently.

If you need to limit concurrency, mergeMap also accepts a concurrency parameter:

mergeMap(
  id => this.loadUser(id),
  3
)

Now at most three inner subscriptions run concurrently.

39. RxJS Pipeline Thinking

One of the biggest improvements in RxJS comes from learning to think in pipelines.

Instead of:

let result = input;

result = transform(result);

if (condition) {
  result = anotherTransform(result);
}

send(result);

You can model the process as:

input$
  .pipe(
    transform(),
    filter(),
    anotherTransform(),
    tap(),
    ...
  )
  .subscribe();

The stream becomes a data-processing pipeline.

40. Avoid Nested Subscriptions

A common beginner pattern is:

this.userService.getUser().subscribe(user => {

  this.orderService.getOrders(user.id).subscribe(orders => {

    console.log(orders);

  });

});

This can become difficult to maintain.

Instead:

this.userService.getUser()
  .pipe(
    switchMap(user =>
      this.orderService.getOrders(user.id)
    )
  )
  .subscribe(orders => {
    console.log(orders);
  });

This is often called:

Flattening Observables

and it is one of the main reasons higher-order mapping operators exist.

41. Higher-Order Observables

Suppose:

Observable<User>

is normal.

But:

Observable<Observable<User>>

is a higher-order Observable.

For example:

users$
  .pipe(
    map(user => this.getUserDetails(user.id))
  );

Now the result becomes conceptually:

Observable
   ↓
Observable<User>

This is where flattening operators become important:

switchMap
mergeMap
concatMap
exhaustMap

They turn:

Observable<Observable<T>>

into something like:

Observable<T>

while applying different concurrency behavior.

42. `shareReplay`

Suppose multiple components need the same HTTP result.

Without sharing:

users$ = this.http.get<User[]>('/api/users');

Depending on how it is consumed, multiple subscriptions can trigger multiple HTTP executions.

A common caching/sharing pattern is:

users$ = this.http.get<User[]>('/api/users')
  .pipe(
    shareReplay({ bufferSize: 1, refCount: true })
  );

Conceptually:

             ┌── Component A
HTTP Request ─┼── Component B
             └── Component C

The shared result can be replayed to later subscribers while the shared subscription is active.

Be deliberate with caching semantics, especially for data that can become stale.

43. Memory Leaks

Long-lived streams can cause memory leaks when subscriptions remain active unnecessarily.

Potential examples:

interval(...)
fromEvent(...)
WebSocket streams
Subjects

Modern Angular provides tools such as:

takeUntilDestroyed()

For example:

this.events$
  .pipe(
    takeUntilDestroyed(this.destroyRef)
  )
  .subscribe();

This ties the subscription lifetime to the Angular destruction lifecycle.

The important principle is:

Subscription lifetime should match the lifetime of the work you actually need.

44. `take`

You can limit the number of emissions:

interval(1000)
  .pipe(
    take(3)
  )
  .subscribe(console.log);

Output:

0
1
2

Then the Observable completes.

45. `takeUntil`

Another common pattern:

source$
  .pipe(
    takeUntil(destroy$)
  )
  .subscribe();

When:

destroy$.next();

the subscription terminates.

In modern Angular applications, Angular's destruction utilities can often provide a cleaner alternative.

46. Error Handling Strategy

A production RxJS pipeline might look like:

this.api.getUsers()
  .pipe(
    retry(2),

    catchError(error => {
      this.logger.error(error);

      return of([]);
    }),

    finalize(() => {
      this.loading = false;
    })
  )
  .subscribe(users => {
    this.users = users;
  });

Notice the responsibilities:

retry
 ↓
Transient failure handling

catchError
 ↓
Recovery

finalize
 ↓
Cleanup

Each operator has a specific responsibility.

47. RxJS Architecture

A clean Angular application might have:

Component
    ↓
Facade / State Layer
    ↓
Service
    ↓
HttpClient
    ↓
Backend API

RxJS can flow through all these layers.

For example:

Component
    ↓
users$
    ↓
UserService
    ↓
HTTP Observable
    ↓
Backend

The component does not necessarily need to manually manage every asynchronous operation.

48. Async Pipe

Angular's async pipe can subscribe to an Observable in the template.

Example:

users$ = this.userService.getUsers();

Template:

<ul>
  @for (user of users$ | async; track user.id) {
    <li>{{ user.name }}</li>
  }
</ul>

The async pipe handles subscription and cleanup for the template binding.

This can reduce manual subscription management.

49. Observable vs Promise

Promises represent one eventual result:

Promise
   ↓
one result

Observables can represent:

Observable
   ↓
0
1
2
3
...

A Promise:

fetch('/api/users')
  .then(response => response.json());

Observable:

this.http.get<User[]>('/api/users')

Observables also provide rich operators for:

Transformation
Filtering
Cancellation
Combination
Concurrency
Retrying
Error handling
Composition

50. Cancellation

One major difference is cancellation.

Promises do not natively provide the same compositional cancellation model as RxJS subscriptions.

With an Observable:

const subscription = source$.subscribe();

subscription.unsubscribe();

This gives RxJS a powerful way to model work that should stop when it is no longer needed.

This becomes particularly useful with:

Search
Navigation
Live streams
Polling
User interactions

51. RxJS Mental Model

A useful mental model is:

Observable
    ↓
Source of values

Operator
    ↓
Transforms or controls values

Subscription
    ↓
Starts/owns the execution

Observer
    ↓
Consumes values

Think:

SOURCE
  ↓
  ↓
map
  ↓
filter
  ↓
switchMap
  ↓
catchError
  ↓
finalize
  ↓
SUBSCRIBER

Once this mental model becomes natural, RxJS becomes much easier.

52. A Complete Real-World Example

Let's combine everything.

Imagine an Angular product search page.

Requirements:

User enters a search term.
Wait 300ms.
Ignore duplicate terms.
Ignore short terms.
Cancel previous searches.
Retry temporary failures.
Show loading state.
Return an empty result if the request fails.

Implementation:

searchResults$ = this.searchControl.valueChanges.pipe(

  debounceTime(300),

  distinctUntilChanged(),

  map(term => term?.trim() ?? ''),

  filter(term => term.length >= 2),

  tap(() => {
    this.loading = true;
  }),

  switchMap(term =>
    this.productService.search(term).pipe(

      retry(2),

      catchError(error => {
        console.error('Search failed:', error);

        return of([]);
      }),

      finalize(() => {
        this.loading = false;
      })
    )
  )
);

This pipeline represents a complete reactive workflow:

User Input
    ↓
debounce
    ↓
remove duplicates
    ↓
normalize
    ↓
validate
    ↓
loading = true
    ↓
switchMap
    ↓
HTTP
    ↓
retry
    ↓
catchError
    ↓
finalize
    ↓
Results

This is where RxJS becomes much more than just syntax.

53. How to Choose the Correct Operator

When you see an asynchronous problem, ask:

Do I need to transform values?

Use:

map

Do I need to remove values?

Use:

filter

Do I need to wait for user input to settle?

Use:

debounceTime

Do I need to ignore consecutive duplicates?

Use:

distinctUntilChanged

Do I need only the newest request?

Use:

switchMap

Do I need concurrent operations?

Use:

mergeMap

Do I need sequential operations?

Use:

concatMap

Do I need to ignore new triggers while busy?

Use:

exhaustMap

Do I need all requests to finish?

Use:

forkJoin

Do I need the latest values from multiple streams?

Use:

combineLatest

Do I need error recovery?

Use:

catchError

Do I need retries?

Use:

retry

Do I need cleanup?

Use:

finalize

54. The Most Important RxJS Skill

The hardest part of RxJS is not memorizing operators.

It is understanding time and concurrency.

For example:

User Event A
      ↓
Request A

User Event B
      ↓
Request B

What should happen to Request A?

Different answers produce different operators:

Cancel A        → switchMap

Keep A + B      → mergeMap

Wait A → B      → concatMap

Ignore B        → exhaustMap

Once you understand this question, choosing the operator becomes much easier.

55. Common RxJS Mistakes

Mistake 1: Nested subscriptions

Avoid:

a$.subscribe(a => {
  b$.subscribe(b => {
    ...
  });
});

Prefer composition:

a$
  .pipe(
    switchMap(a => b$)
  )
  .subscribe();

Mistake 2: Using `subscribe` everywhere

Don't subscribe just to pass data to another Observable.

Instead of:

this.userService.getUser().subscribe(user => {
  this.user$ = of(user);
});

prefer:

this.user$ = this.userService.getUser();

Mistake 3: Choosing `switchMap` automatically

switchMap is not always the correct operator.

If every operation must complete:

concatMap

may be better.

If operations are independent:

mergeMap

may be better.

If duplicate clicks should be ignored:

exhaustMap

may be better.

Mistake 4: Ignoring subscription lifetime

Long-running subscriptions should have intentional lifecycle management.

Mistake 5: Overusing Subjects

Subjects are useful, but not every Observable needs to become a Subject.

Prefer simple Observable composition when possible.

56. RxJS in One Diagram

The entire philosophy can be summarized as:

                    RxJS
                     │
                     ▼
                Observable
                     │
                     ▼
              Stream of values
                     │
          ┌──────────┴──────────┐
          ▼                     ▼
      Operators             Subscription
          │                     │
          ▼                     ▼
 Transform / Filter       Start / Cleanup
 Combine / Control             │
          │                     │
          └──────────┬──────────┘
                     ▼
                  Observer
                     │
                     ▼
              Application Logic

57. Final Takeaways

RxJS becomes much easier when you stop thinking about it as:

"A huge library with hundreds of operators."

Instead, think of it as:

A way to model values and events over time.

The most important concepts to master are:

Observable
Observer
Subscription
Operators
Subjects
Higher-order Observables
Concurrency
Error handling
Cancellation

And the operators you should know particularly well are:

map
filter
tap
debounceTime
distinctUntilChanged

switchMap
mergeMap
concatMap
exhaustMap

catchError
retry
finalize

combineLatest
forkJoin
withLatestFrom

take
takeUntil
share
shareReplay

If you truly understand:

switchMap
mergeMap
concatMap
exhaustMap

you already understand one of the most important parts of practical RxJS.

The goal is not to memorize every operator.

The goal is to look at a problem and ask:

"How should these values behave over time?"

Once you can answer that question, the RxJS operator usually becomes obvious.

Conclusion

RxJS is powerful because asynchronous behavior is rarely just:

request → response

Real applications contain:

events
requests
cancellation
retries
multiple streams
user interactions
state changes
concurrency
errors

RxJS gives us a unified model for composing all of them.

And that's why RxJS remains such an important skill for modern Angular and reactive JavaScript development.

Don't learn RxJS by memorizing operators. Learn it by understanding streams, time, cancellation, and concurrency.

Using Next.js as a Backend for Frontend (BFF)

Abanoub Kerols — Fri, 11 Sep 2026 21:34:10 +0000

When building a modern web application, the frontend often needs to communicate with multiple backend services:

Browser
   │
   ├── Auth Service
   ├── Product Service
   ├── Order Service
   └── Notification Service

This works, but it makes the frontend tightly coupled to the backend architecture.

A better approach in some systems is to introduce a Backend for Frontend (BFF).

Browser
   │
   ▼
Next.js BFF
   │
   ├── Auth Service
   ├── Product Service
   ├── Order Service
   └── Notification Service

What is a BFF?

A BFF is a backend layer specifically designed for a particular frontend.

Instead of exposing all backend services directly to the browser, the frontend communicates with the BFF, and the BFF communicates with the internal services.

This gives us a place to handle:

Authentication
Authorization
Request validation
API aggregation
Response transformation
Caching
Hiding internal service URLs

Next.js as a BFF

Next.js can implement a BFF using Route Handlers.

For example:

app/
└── api/
    └── products/
        └── route.ts

// app/api/products/route.ts

export async function GET() {
  const response = await fetch(
    `${process.env.PRODUCT_SERVICE_URL}/products`
  );

  if (!response.ok) {
    return Response.json(
      { message: "Failed to fetch products" },
      { status: 500 }
    );
  }

  const products = await response.json();

  return Response.json(products);
}

Now the browser calls:

GET /api/products

Instead of directly calling:

GET http://product-service:3002/products

The architecture becomes:

Browser
   │
   │ GET /api/products
   ▼
Next.js BFF
   │
   │ GET /products
   ▼
Product Service

The internal service URL remains server-side.

API Aggregation

One of the most useful BFF features is aggregation.

Imagine a dashboard needs data from four different services:

User Service
Order Service
Notification Service
Recommendation Service

Instead of making four requests from the browser:

Browser
 ├── GET /users/me
 ├── GET /orders
 ├── GET /notifications
 └── GET /recommendations

The BFF can expose a single endpoint:

GET /api/dashboard

And fetch the data in parallel:

// app/api/dashboard/route.ts

export async function GET() {
  const [
    user,
    orders,
    notifications,
    recommendations,
  ] = await Promise.all([
    fetch(`${process.env.USER_SERVICE_URL}/me`)
      .then(res => res.json()),

    fetch(`${process.env.ORDER_SERVICE_URL}/orders`)
      .then(res => res.json()),

    fetch(`${process.env.NOTIFICATION_SERVICE_URL}/notifications`)
      .then(res => res.json()),

    fetch(`${process.env.RECOMMENDATION_SERVICE_URL}/recommendations`)
      .then(res => res.json()),
  ]);

  return Response.json({
    user,
    orders,
    notifications,
    recommendations,
  });
}

Now the browser only needs:

GET /api/dashboard

The BFF handles the complexity behind the scenes.

Response Transformation

The BFF can also transform backend responses into a format that is better suited for the frontend.

For example, a backend might return:

{
  "id": 15,
  "first_name": "Abanoub",
  "last_name": "Kerols",
  "internal_role_id": 7
}

But the frontend may only need:

{
  "id": 15,
  "name": "Abanoub Kerols"
}

The BFF can perform this transformation:

return Response.json({
  id: user.id,
  name: `${user.first_name} ${user.last_name}`,
});

This prevents the frontend from becoming dependent on internal backend models.

Authentication

A BFF can also be useful for authentication.

For example:

Browser
   │
   │ HttpOnly Cookie
   ▼
Next.js BFF
   │
   │ Authorization: Bearer <token>
   ▼
Backend Service

The BFF can read the server-side authentication state and attach the appropriate credentials when calling internal services.

This can help keep sensitive tokens away from client-side JavaScript.

The Important Architectural Boundary

Using Next.js as a BFF does not mean moving all business logic into Next.js.

A good separation is:

             Next.js
        ┌───────────────┐
        │ UI            │
        │ BFF           │
        │ Authentication│
        │ Aggregation   │
        │ Transformation│
        └───────┬───────┘
                │
                ▼
        Backend Services
        ┌───────────────┐
        │ Business Logic│
        │ Domain Rules  │
        │ Data Access   │
        └───────────────┘

The BFF should mainly adapt backend capabilities to the needs of the frontend, while important domain logic remains in the backend services.

Final Architecture

                    Browser
                       │
                       │ HTTPS
                       ▼
              ┌─────────────────┐
              │     Next.js      │
              │       BFF        │
              │                 │
              │ Auth            │
              │ Validation      │
              │ Aggregation     │
              │ Transformation  │
              │ Caching         │
              └────────┬────────┘
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       Auth API    Product API   Order API
          │            │            │
          ▼            ▼            ▼
       Database     Database     Database

The key idea

Next.js doesn't have to replace your backend. It can become the backend layer specifically designed for your frontend.

That's the core idea behind using Next.js as a Backend for Frontend (BFF).

Dependency Injection in Angular: From Constructor Injection to Modern DI

Abanoub Kerols — Thu, 10 Sep 2026 18:12:21 +0000

Dependency Injection (DI) is one of the most important concepts in Angular.

If you understand Angular DI deeply, you understand much more than how to inject a service into a component. You understand how Angular creates objects, controls their lifetime, chooses implementations, scopes dependencies, handles configuration, supports testing, and builds hierarchical application architecture.

And Angular DI has evolved significantly.

We started with:

constructor(private userService: UserService) {}

Then Angular introduced:

private userService = inject(UserService);

Modern Angular goes even further with:

EnvironmentInjector
InjectionToken
useValue
useClass
useFactory
useExisting
multi
providedIn
providers
viewProviders
Optional
Self
SkipSelf
Host
forwardRef
runInInjectionContext
functional guards and resolvers
provider functions such as provideRouter() and provideHttpClient()
environment-level providers
hierarchical scopes
tree-shakable providers
advanced library DI patterns

This article explains the old Angular DI model, the modern model, and how everything fits together, then builds a complete application that uses these concepts in practice.

1. What Is Dependency Injection?

Before Angular, imagine this service:

export class UserService {
  getUser() {
    return {
      id: 1,
      name: 'Abanoub'
    };
  }
}

Now a component needs it.

A naive approach is:

export class UserComponent {

  private userService = new UserService();

}

This works, but it creates strong coupling.

The component decides:

which implementation to use
how the dependency is created
when it is created
how its dependencies are created

The component is doing too much.

Instead, we want:

export class UserComponent {

  constructor(private userService: UserService) {}

}

The component says:

"I need a UserService."

It does not say:

"I will create a UserService."

That distinction is the foundation of Dependency Injection.

Angular's DI system is responsible for providing dependencies to components, directives, services, functions, and other framework-managed code.

2. Dependency Injection vs Dependency Inversion

These concepts are related but not identical.

Dependency Injection

DI is a mechanism/pattern for supplying dependencies from outside a class.

constructor(private logger: LoggerService) {}

Dependency Inversion

Dependency Inversion is a broader architectural principle.

High-level modules should depend on abstractions rather than concrete implementations.

For example:

export abstract class PaymentGateway {
  abstract pay(amount: number): Promise<void>;
}

Then:

@Injectable()
export class StripePaymentGateway implements PaymentGateway {
  async pay(amount: number) {
    // Stripe implementation
  }
}

Angular DI can connect them:

providers: [
  {
    provide: PaymentGateway,
    useClass: StripePaymentGateway
  }
]

Now the application depends on:

PaymentGateway

rather than:

StripePaymentGateway

This is where Angular DI becomes an architectural tool rather than simply a convenience.

3. What Is a Dependency?

A dependency is anything a class needs to perform its job.

It doesn't have to be a service.

A dependency can be:

class

or:

object

or:

string

or:

number

or:

function

or:

configuration

For example:

class UserService {

  constructor(
    private http: HttpClient,
    private config: AppConfig
  ) {}

}

Both are dependencies.

Angular's DI system can provide services, values, functions, configuration objects, and other JavaScript values.

4. The Three Important DI Concepts

Most Angular DI problems become much easier once you understand these three terms:

Token
   ↓
Provider
   ↓
Injector

For example:

providers: [
  {
    provide: UserService,
    useClass: UserService
  }
]

Here:

Token

UserService

The token identifies what we want.

Provider

{
  provide: UserService,
  useClass: UserService
}

The provider tells Angular how to create or obtain it.

Injector

The injector stores provider information and resolves dependencies when requested.

Conceptually:

Component
    |
    | "Give me UserService"
    ↓
Injector
    |
    | finds provider
    ↓
Provider
    |
    | creates/returns instance
    ↓
UserService

5. The Old Angular DI Model

Before modern Angular patterns became common, you typically saw:

@Injectable({
  providedIn: 'root'
})
export class UserService {}

and:

@Component({
  selector: 'app-user',
  template: `...`
})
export class UserComponent {

  constructor(
    private userService: UserService
  ) {}

}

This is still valid.

It is not an obsolete API.

The major change is that Angular now gives developers another, often cleaner, way to inject dependencies.

6. Constructor Injection

The classic Angular DI syntax is constructor injection:

@Injectable({
  providedIn: 'root'
})
export class UserService {

  getUser() {
    return {
      id: 1,
      name: 'Abanoub'
    };
  }

}

Then:

@Component({
  selector: 'app-user',
  template: `
    <h1>{{ user.name }}</h1>
  `
})
export class UserComponent {

  constructor(
    private userService: UserService
  ) {}

  user = this.userService.getUser();

}

Angular sees:

UserService

and asks the DI system to resolve it.

Why constructor injection was popular

It has several advantages:

explicit dependencies
easy to understand
works naturally with TypeScript
dependencies are available when the class is created
excellent for traditional Angular codebases

But it also has limitations.

For example:

constructor(
  private http: HttpClient,
  private auth: AuthService,
  private router: Router,
  private logger: LoggerService,
  private config: ConfigService
) {}

Large constructors can become noisy.

There are also limitations around TypeScript's decorator metadata and modern standard decorators.

Angular therefore introduced the inject() API as a modern alternative. Angular's migration tooling can convert constructor-based injection to inject().

7. Modern Angular DI: `inject()`

Today you will frequently see:

import { Component, inject } from '@angular/core';

@Component({
  selector: 'app-user',
  template: `...`
})
export class UserComponent {

  private userService = inject(UserService);

}

This is dependency injection too.

Angular resolves:

UserService

from the currently active injector.

The important thing is:

inject(UserService)

does not mean:

new UserService()

Angular still controls the dependency lifecycle and provider resolution.

The inject() function is supported in injection contexts such as constructors, field initializers, provider factories, and other framework-managed DI contexts.

8. Constructor Injection vs `inject()`

Old style

export class DashboardComponent {

  constructor(
    private userService: UserService,
    private router: Router
  ) {}

}

Modern style

export class DashboardComponent {

  private userService = inject(UserService);
  private router = inject(Router);

}

Both are valid.

A practical modern Angular style is:

private userService = inject(UserService);
private router = inject(Router);

because dependencies are declared close to where they are used and TypeScript can infer types naturally.

However, constructor injection remains perfectly legitimate, especially in existing applications and when working with patterns that depend on constructor parameters. Angular's own guidance explicitly supports both approaches.

9. The Injection Context

This is one of the most important modern Angular DI concepts.

You cannot call:

inject(UserService)

anywhere.

This is invalid:

export class UserComponent {

  ngOnInit() {

    const service = inject(UserService); // ❌

  }

}

Why?

Because ngOnInit() executes after the object has already been created.

Angular's DI context is available during class creation/initialization and specific framework-managed contexts, not arbitrary later callbacks.

10. Valid Places for `inject()`

Field initializer

export class UserComponent {

  private userService = inject(UserService);

}

Constructor

export class UserComponent {

  constructor() {

    const service = inject(UserService);

  }

}

Provider factory

{
  provide: UserService,
  useFactory: () => {

    const logger = inject(LoggerService);

    return new UserService(logger);

  }
}

InjectionToken factory

const API_URL = new InjectionToken<string>(
  'API_URL',
  {
    providedIn: 'root',

    factory: () => {

      const config = inject(AppConfig);

      return config.apiUrl;

    }
  }
);

Functional route guard

export const authGuard = () => {

  const auth = inject(AuthService);

  return auth.isAuthenticated();

};

Angular documents functional guards and similar framework APIs as injection contexts.

11. Why `inject()` Fails in Async Code

This is a common mistake:

async loadUser() {

  await delay(1000);

  const userService = inject(UserService); // ❌

}

After the await, you are no longer inside the original synchronous injection context.

Instead:

private userService = inject(UserService);

async loadUser() {

  await delay(1000);

  this.userService.getUser();

}

Capture dependencies while you are inside the injection context.

12. `runInInjectionContext()`

Sometimes you genuinely need to execute a function inside an injection context.

Angular provides:

runInInjectionContext()

Example:

import {
  EnvironmentInjector,
  inject,
  runInInjectionContext
} from '@angular/core';

@Injectable({
  providedIn: 'root'
})
export class DynamicService {

  private injector = inject(EnvironmentInjector);

  execute() {

    runInInjectionContext(
      this.injector,
      () => {

        const logger = inject(LoggerService);

        logger.log('Hello');

      }
    );

  }

}

This creates a temporary injection context for the callback.

Use this when you actually need dynamic DI.

Do not use it as a replacement for normal injection.

13. `Injector`

Angular also exposes the injector itself.

private injector = inject(Injector);

You can then resolve dependencies manually:

const service = this.injector.get(UserService);

This can be useful when the dependency needs to be resolved later.

For example:

private injector = inject(Injector);

loadLater() {

  setTimeout(() => {

    const userService =
      this.injector.get(UserService);

    userService.getUser();

  }, 1000);

}

Angular's debugging guidance recommends capturing dependencies normally where possible and using Injector.get() for deferred retrieval when necessary.

14. `@Injectable()`

The classic way to declare an injectable service is:

@Injectable()
export class UserService {}

However, this alone doesn't necessarily make the service globally available.

You need a provider.

For example:

@Component({
  providers: [
    UserService
  ]
})
export class UserComponent {}

Or:

bootstrapApplication(AppComponent, {
  providers: [
    UserService
  ]
});

15. `providedIn`

The most common modern approach is:

@Injectable({
  providedIn: 'root'
})
export class UserService {}

This tells Angular that the service belongs to the root injector.

It is also tree-shakable.

That means Angular's build system can remove unused injectable definitions from the final bundle when they are not referenced.

For most application-wide services:

@Injectable({
  providedIn: 'root'
})

is the default choice.

16. `providedIn: 'root'`

@Injectable({
  providedIn: 'root'
})
export class AuthService {}

This normally gives the application a single instance associated with the root environment injector.

Every component requesting:

inject(AuthService)

will resolve the same root-scoped instance unless a closer provider overrides it.

17. `providedIn: 'platform'`

Historically Angular also supported:

@Injectable({
  providedIn: 'platform'
})

This places the service in the platform-level injector rather than the application root.

It is useful for special scenarios involving multiple Angular applications sharing a platform.

It is not something you should use by default.

18. The Historical `providedIn: 'any'`

Older Angular versions supported:

providedIn: 'any'

This had special behavior with lazy-loaded injectors.

Modern Angular documentation marks 'any' as deprecated.

So if you see:

providedIn: 'any'

in older code, understand what it does before changing it, but don't treat it as the preferred modern pattern.

19. `providedIn: NgModule`

You may also encounter:

@Injectable({
  providedIn: SomeModule
})

This belongs to the older NgModule-oriented DI model.

The modern Angular architecture favors environment providers and standalone APIs.

Angular's current documentation marks providedIn: NgModule as deprecated for InjectionToken configuration, and modern applications generally prefer environment-based provider configuration.

20. Manual Providers

Instead of:

@Injectable({
  providedIn: 'root'
})
export class UserService {}

you can manually provide:

providers: [
  UserService
]

For example:

@Component({
  selector: 'app-profile',
  providers: [
    UserService
  ],
  template: `...`
})
export class ProfileComponent {}

Now the service belongs to this component's injector.

21. Component-Level Providers

This is extremely important.

Consider:

@Component({
  providers: [
    CounterService
  ]
})
export class CounterComponent {

  private counter = inject(CounterService);

}

Every instance of CounterComponent gets its own CounterService.

For example:

<app-counter></app-counter>
<app-counter></app-counter>

Conceptually:

CounterComponent #1
   |
   └── CounterService #1

CounterComponent #2
   |
   └── CounterService #2

This is completely different from:

@Injectable({
  providedIn: 'root'
})

where both components normally resolve the same root instance.

Angular's component providers configure the component's ElementInjector, and that instance is destroyed with the component.

22. The Provider Shorthand

This:

providers: [
  UserService
]

is effectively a shorthand for:

providers: [
  {
    provide: UserService,
    useClass: UserService
  }
]

This leads us to one of the most important DI concepts:

Provider Recipes

Angular supports several provider strategies.

23. `useClass`

providers: [
  {
    provide: LoggerService,
    useClass: ConsoleLoggerService
  }
]

Whenever something asks for:

LoggerService

Angular creates:

ConsoleLoggerService

This is extremely useful for abstraction.

For example:

abstract class PaymentGateway {

  abstract pay(amount: number): Promise<void>;

}

Production:

providers: [
  {
    provide: PaymentGateway,
    useClass: StripePaymentGateway
  }
]

Testing:

providers: [
  {
    provide: PaymentGateway,
    useClass: FakePaymentGateway
  }
]

The consumer doesn't change.

24. `useValue`

Sometimes you don't need Angular to create an object.

You already have the value.

Use:

useValue

Example:

export const API_URL =
  new InjectionToken<string>('API_URL');

bootstrapApplication(AppComponent, {

  providers: [
    {
      provide: API_URL,
      useValue: 'https://api.example.com'
    }
  ]

});

Then:

export class ApiService {

  private apiUrl = inject(API_URL);

}

useValue can provide strings, numbers, objects, arrays, functions, configuration, and other static values.

25. Why You Need `InjectionToken`

This won't work:

export interface AppConfig {
  apiUrl: string;
}

and:

constructor(private config: AppConfig) {}

Why?

Because interfaces disappear during TypeScript compilation.

At runtime:

AppConfig

doesn't exist.

Angular needs a runtime token.

That's what InjectionToken provides.

26. `InjectionToken`

export interface AppConfig {

  apiUrl: string;
  production: boolean;

}

export const APP_CONFIG =
  new InjectionToken<AppConfig>('APP_CONFIG');

Provide:

providers: [
  {
    provide: APP_CONFIG,

    useValue: {
      apiUrl: 'https://api.example.com',
      production: false
    }
  }
]

Inject:

private config = inject(APP_CONFIG);

Now:

this.config.apiUrl

is strongly typed.

Angular recommends InjectionToken for dependencies that do not have a runtime representation, such as interfaces, functions, arrays, and parameterized types.

27. InjectionToken Identity Matters

This is a subtle but important bug.

Don't do this:

const API_URL =
  new InjectionToken<string>('API_URL');

in one file and:

const API_URL =
  new InjectionToken<string>('API_URL');

in another.

Even though the names are identical, these are two different objects.

Angular compares token identity, not the description string.

Always export one token:

export const API_URL =
  new InjectionToken<string>('API_URL');

and import that same token everywhere.

28. `useFactory`

Factories are useful when the dependency must be dynamically constructed.

Example:

export const API_CLIENT_PROVIDER = {

  provide: ApiClient,

  useFactory: () => {

    const http = inject(HttpClient);
    const config = inject(APP_CONFIG);

    return new ApiClient(
      http,
      config.apiUrl
    );

  }

};

Now Angular executes the factory when it needs the dependency.

Factories are excellent for:

runtime configuration
environment-dependent implementations
complex initialization
combining multiple dependencies
library configuration

Angular supports both useFactory providers and factory-based injection tokens.

29. Factory Dependencies with `deps`

The older explicit style is:

{
  provide: ApiClient,

  useFactory: (
    http: HttpClient,
    config: AppConfig
  ) => {

    return new ApiClient(
      http,
      config.apiUrl
    );

  },

  deps: [
    HttpClient,
    APP_CONFIG
  ]
}

Modern Angular code can often use inject() directly inside the factory:

{
  provide: ApiClient,

  useFactory: () => {

    const http = inject(HttpClient);
    const config = inject(APP_CONFIG);

    return new ApiClient(
      http,
      config.apiUrl
    );

  }
}

30. `useExisting`

This is one of the most misunderstood provider types.

Suppose:

class NewLogger {}

class OldLogger {}

You can alias:

providers: [
  NewLogger,

  {
    provide: OldLogger,
    useExisting: NewLogger
  }
]

Now:

inject(NewLogger)

and:

inject(OldLogger)

return the same instance.

31. `useExisting` vs `useClass`

This distinction matters.

`useClass`

{
  provide: Logger,
  useClass: ConsoleLogger
}

Angular creates an instance of:

ConsoleLogger

`useExisting`

{
  provide: LegacyLogger,
  useExisting: ConsoleLogger
}

Angular returns the already-existing ConsoleLogger instance.

Conceptually:

useClass

Logger ───────> ConsoleLogger #1


useExisting

Logger ───────┐
              ├──> ConsoleLogger #1
LegacyLogger ─┘

Angular's documentation explicitly distinguishes these behaviors.

32. `multi: true`

Sometimes you don't want one implementation.

You want many.

For example:

export const LOG_HANDLERS =
  new InjectionToken<LogHandler[]>(
    'LOG_HANDLERS'
  );

Then:

providers: [

  {
    provide: LOG_HANDLERS,
    useClass: ConsoleLogHandler,
    multi: true
  },

  {
    provide: LOG_HANDLERS,
    useClass: RemoteLogHandler,
    multi: true
  },

  {
    provide: LOG_HANDLERS,
    useClass: AnalyticsLogHandler,
    multi: true
  }

]

Now:

private handlers = inject(LOG_HANDLERS);

returns an array.

LOG_HANDLERS
     |
     ├── ConsoleLogHandler
     ├── RemoteLogHandler
     └── AnalyticsLogHandler

This pattern is heavily used in extensible Angular architecture.

33. `providers` vs `viewProviders`

These look similar:

providers

and:

viewProviders

but they have an important difference.

Consider:

<app-parent>

  <app-child />

</app-parent>

and:

<app-parent>

  <ng-content />

</app-parent>

providers can be visible to projected content.

viewProviders restricts the provider to the component's own view.

Example:

@Component({
  providers: [
    ThemeService
  ]
})

The service can be available to projected content.

But:

@Component({
  viewProviders: [
    ThemeService
  ]
})

keeps it within the component's own view.

Angular recommends providers by default unless you specifically need the isolation behavior of viewProviders.

34. Angular's Injector Hierarchy

This is where Angular DI becomes really powerful.

Modern Angular has two major injector hierarchies:

EnvironmentInjector hierarchy

        Root
         |
    Environment
         |
    Feature / Route

and:

ElementInjector hierarchy

Component
   |
Child Component
   |
Grandchild Component

Angular documents these as the EnvironmentInjector and ElementInjector hierarchies.

35. EnvironmentInjector

The EnvironmentInjector is used for application/environment-level providers.

For example:

bootstrapApplication(AppComponent, {
  providers: [
    UserService
  ]
});

Or:

@Injectable({
  providedIn: 'root'
})
export class AuthService {}

These belong to the environment hierarchy.

This is the modern standalone Angular replacement for many things developers historically configured through NgModule.providers.

36. ElementInjector

Angular also creates an injector associated with elements/components.

For example:

@Component({
  providers: [
    CounterService
  ]
})
export class CounterComponent {}

This configures the component's ElementInjector.

Angular creates these element-level injectors implicitly, and they are empty unless providers are configured on components or directives.

37. How Angular Resolves a Dependency

Suppose:

@Component({
  providers: [
    UserService
  ]
})
export class ChildComponent {

  private user = inject(UserService);

}

Angular roughly searches:

Child ElementInjector
        ↓
Parent ElementInjector
        ↓
Ancestor ElementInjectors
        ↓
EnvironmentInjector hierarchy
        ↓
Root

The important rule is:

Angular uses the closest matching provider.

If a child defines its own provider, it can override the parent.

Angular's documented resolution process first walks the relevant element injector hierarchy and then falls back to the environment hierarchy.

38. Provider Override

Imagine:

@Injectable({
  providedIn: 'root'
})
export class LoggerService {

  name = 'Global Logger';

}

Then:

@Component({
  providers: [
    {
      provide: LoggerService,
      useValue: {
        name: 'Local Logger'
      }
    }
  ]
})
export class FeatureComponent {}

Inside:

FeatureComponent

you get:

Local Logger

while another component outside that subtree still gets:

Global Logger

This is dependency scoping.

39. `Self`

Sometimes you want Angular to search only the current injector.

With inject():

inject(UserService, {
  self: true
});

Conceptually:

Current Injector
      |
      X
Parent
      |
      X
Root

If the dependency isn't available locally, Angular fails.

This is useful when you explicitly require a local provider.

40. `SkipSelf`

skipSelf does the opposite.

inject(UserService, {
  skipSelf: true
});

Angular skips the current injector and starts searching from the parent.

Conceptually:

Current Injector  ← skipped

Parent Injector   ← start here
       ↓
Grandparent
       ↓
Root

This is useful when a child provider overrides a parent provider but you specifically need the parent instance.

41. `Optional`

Sometimes a dependency is optional.

Instead of throwing an error:

inject(AnalyticsService);

use:

inject(AnalyticsService, {
  optional: true
});

Now Angular can return:

null

if the provider doesn't exist.

Example:

private analytics =
  inject(AnalyticsService, {
    optional: true
  });

track() {

  this.analytics?.track('click');

}

42. `Host`

host limits the DI search according to the host boundary.

inject(UserService, {
  host: true
});

This becomes particularly important with:

component boundaries
directives
viewProviders
content projection

It is an advanced DI modifier and should be used when you actually need control over the resolution boundary. Angular's hierarchical DI documentation provides detailed examples of how host, skipSelf, and viewProviders interact.

43. Combining DI Modifiers

You can combine options.

For example:

inject(UserService, {
  skipSelf: true,
  optional: true
});

Meaning roughly:

"Don't use the current injector. Search the parents, but don't throw if nothing is found."

You can also use:

inject(UserService, {
  host: true,
  skipSelf: true,
  optional: true
});

These combinations become useful in advanced component/library architectures.

44. The Old Decorator Modifiers

In constructor injection, you may see:

constructor(
  @Optional()
  private analytics: AnalyticsService
) {}

or:

constructor(
  @Self()
  private service: LocalService
) {}

or:

constructor(
  @SkipSelf()
  private service: ParentService
) {}

or:

constructor(
  @Host()
  private service: HostService
) {}

You may also see:

@Inject(TOKEN)

These are older constructor-oriented APIs.

Modern inject() expresses the same concepts through options:

inject(TOKEN, {
  optional: true
});

45. `@Inject()`

Suppose the dependency isn't represented by a class:

export const API_URL =
  new InjectionToken<string>('API_URL');

Old style:

constructor(
  @Inject(API_URL)
  private apiUrl: string
) {}

Modern:

private apiUrl = inject(API_URL);

The modern syntax is usually much cleaner.

46. `forwardRef()`

Sometimes Angular needs to reference something before the TypeScript runtime declaration is available.

Example:

@Component({
  providers: [
    {
      provide: ParentComponent,
      useExisting: forwardRef(
        () => ChildComponent
      )
    }
  ]
})
export class ChildComponent {}

forwardRef() allows Angular to resolve a reference later.

It is mostly useful for circular references and unusual declaration-order scenarios.

Angular documents forwardRef() specifically for resolving references that cannot yet be directly referenced because of declaration order or circular relationships.

47. NgModule-Based DI

Older Angular applications commonly looked like:

@NgModule({
  declarations: [
    AppComponent
  ],

  imports: [
    BrowserModule
  ],

  providers: [
    UserService
  ],

  bootstrap: [
    AppComponent
  ]
})
export class AppModule {}

The application started with:

platformBrowserDynamic()
  .bootstrapModule(AppModule);

This architecture is still supported.

But modern Angular applications increasingly use:

bootstrapApplication()

with standalone components and environment providers.

48. Modern Standalone DI

Modern Angular:

bootstrapApplication(
  AppComponent,
  {
    providers: [
      UserService
    ]
  }
);

You can also use Angular's provider functions:

bootstrapApplication(
  AppComponent,
  {
    providers: [
      provideRouter(routes),
      provideHttpClient()
    ]
  }
);

This is one of the biggest architectural changes from the older NgModule era.

49. Provider Functions

Modern Angular libraries frequently expose APIs such as:

provideRouter(...)

and:

provideHttpClient(...)

Instead of asking developers to manually understand dozens of providers, the library exposes a single configuration function.

You can build the same pattern yourself.

Example:

export interface AnalyticsConfig {
  trackingId: string;
}

const ANALYTICS_CONFIG =
  new InjectionToken<AnalyticsConfig>(
    'ANALYTICS_CONFIG'
  );

export function provideAnalytics(
  config: AnalyticsConfig
) {

  return [
    {
      provide: ANALYTICS_CONFIG,
      useValue: config
    },

    AnalyticsService
  ];

}

Consumer:

bootstrapApplication(AppComponent, {

  providers: [
    provideAnalytics({
      trackingId: 'GA-123'
    })
  ]

});

This provideX() pattern is especially useful for Angular libraries because it encapsulates implementation details and makes configuration composable.

50. Feature Functions: `withX()`

Modern Angular libraries also use patterns such as:

provideSomething(
  withCaching(),
  withLogging(),
  withRetry()
)

You can implement the same architecture.

Example:

export function withLogging(): AnalyticsFeature {

  return {
    providers: [
      LoggingAnalyticsHandler
    ]
  };

}

Then:

provideAnalytics(
  config,
  withLogging()
);

This gives libraries a clean, composable API.

51. `InjectionToken` with a Factory

An InjectionToken can provide its own factory.

Example:

export const API_URL =
  new InjectionToken<string>(
    'API_URL',
    {
      providedIn: 'root',

      factory: () => {
        return 'https://api.example.com';
      }
    }
  );

Now you don't need:

providers: [
  {
    provide: API_URL,
    useValue: ...
  }
]

The token knows how to create itself.

This is another tree-shakable DI pattern.

52. DI and Testing

One of the biggest reasons DI exists is testability.

Without DI:

class UserService {

  private api =
    new RealApiClient();

}

Testing becomes difficult.

With DI:

class UserService {

  private api =
    inject(ApiClient);

}

Test:

TestBed.configureTestingModule({

  providers: [

    UserService,

    {
      provide: ApiClient,

      useClass: FakeApiClient
    }

  ]

});

Now the real API doesn't need to be called.

This is Dependency Injection's architectural value.

53. DI and Mocking

Suppose:

export abstract class PaymentGateway {

  abstract pay(
    amount: number
  ): Promise<boolean>;

}

Production:

{
  provide: PaymentGateway,
  useClass: StripePaymentGateway
}

Testing:

{
  provide: PaymentGateway,
  useClass: FakePaymentGateway
}

Your business logic doesn't know which implementation it received.

That's dependency inversion + DI.

54. DI and SOLID

Angular DI strongly supports SOLID principles.

Single Responsibility

A component doesn't need to create its dependencies.

Open/Closed

You can replace implementations without modifying consumers.

Liskov Substitution

Abstractions can be backed by interchangeable implementations.

Interface Segregation

Smaller tokens/interfaces can define focused contracts.

Dependency Inversion

High-level services can depend on abstractions.

DI doesn't automatically make an architecture SOLID, but it provides an excellent mechanism for implementing these principles.

55. DI Is Not a Global Singleton System

This is a common misconception.

People often say:

"Angular services are singletons."

That's not always true.

Consider:

@Injectable({
  providedIn: 'root'
})
export class CartService {}

This is normally application-wide.

But:

@Component({
  providers: [
    CartService
  ]
})
export class CheckoutComponent {}

creates a different scoped instance.

You can therefore have:

Root CartService
        |
        ├── Component A → root instance
        |
        └── Checkout → local instance

Angular DI is fundamentally about scope and resolution, not simply singletons.

56. Service Lifetime

Where you provide a dependency influences its lifetime.

Root provider

providedIn: 'root'

Usually lives for the application lifetime.

Component provider

@Component({
  providers: [CartService]
})

Lives with that component's injector.

When the component is destroyed, its scoped service can be destroyed as well.

This makes component-level DI extremely useful for isolated state.

57. A Perfect Use Case: Local Component State

Imagine:

@Injectable()
export class WizardState {

  currentStep = 1;

  next() {
    this.currentStep++;
  }

}

Then:

@Component({
  selector: 'app-checkout-wizard',

  providers: [
    WizardState
  ],

  template: `...`
})
export class CheckoutWizard {

  state = inject(WizardState);

}

Now every checkout wizard gets independent state.

You don't need:

WizardState #1
WizardState #2
WizardState #3

manually.

Angular's injector gives you the correct scoped instance.

58. Route-Level Providers

Modern Angular also allows providers to be associated with routes.

Conceptually:

export const routes: Routes = [

  {
    path: 'admin',

    providers: [
      AdminService
    ],

    loadComponent: () =>
      import('./admin.component')
        .then(m => m.AdminComponent)
  }

];

This is powerful because you can scope dependencies to a feature.

For example:

Application
   |
   ├── Public area
   |
   └── Admin route
          |
          └── AdminService

The admin dependency doesn't have to become globally available.

59. DI in Functional Guards

Older Angular:

@Injectable()
export class AuthGuard
  implements CanActivate {

  constructor(
    private auth: AuthService
  ) {}

  canActivate() {
    return this.auth.isAuthenticated();
  }

}

Modern Angular can use:

export const authGuard: CanActivateFn = () => {

  const auth =
    inject(AuthService);

  return auth.isAuthenticated();

};

This is a great example of how inject() enables functional Angular APIs.

60. DI in Functional Resolvers

The same principle applies to resolvers:

export const userResolver: ResolveFn<User> =
  () => {

    const userService =
      inject(UserService);

    return userService.getCurrentUser();

  };

No class is required.

Angular supplies the injection context.

61. DI and Directives

DI isn't only for components.

@Directive({
  selector: '[appHighlight]'
})
export class HighlightDirective {

  private element =
    inject(ElementRef);

}

Angular can inject framework-provided tokens such as:

ElementRef

and application services.

Angular documents DI as available to directives and components because they participate in the Angular DI system.

62. DI and Pipes

Injectable dependencies can also be used in pipes.

For example:

@Pipe({
  name: 'currencyFormat'
})
export class CurrencyFormatPipe {

  private config =
    inject(AppConfig);

  transform(value: number) {

    return `${this.config.currency}${value}`;

  }

}

63. DI and Interceptors

Modern functional interceptors are another excellent example:

export const authInterceptor:
  HttpInterceptorFn = (req, next) => {

    const auth =
      inject(AuthService);

    const token =
      auth.getToken();

    return next(
      req.clone({
        setHeaders: {
          Authorization: `Bearer ${token}`
        }
      })
    );

  };

The function itself doesn't receive AuthService as a parameter.

Angular creates the injection context in which the interceptor runs.

64. DI and Environment Configuration

A professional Angular application often needs:

API_URL

APP_NAME

FEATURE_FLAGS

DEFAULT_PAGE_SIZE

Instead of hardcoding these everywhere, define tokens.

export interface AppConfig {

  apiUrl: string;

  appName: string;

  features: {
    analytics: boolean;
    darkMode: boolean;
  };

}

Then:

export const APP_CONFIG =
  new InjectionToken<AppConfig>(
    'APP_CONFIG'
  );

Provide it once:

bootstrapApplication(AppComponent, {

  providers: [

    {
      provide: APP_CONFIG,

      useValue: {
        apiUrl: 'https://api.example.com',
        appName: 'Task Manager',

        features: {
          analytics: true,
          darkMode: true
        }
      }

    }

  ]

});

Now every service can consume strongly typed configuration.

65. Complete Project: Task Management Application

Let's build a realistic Angular architecture that demonstrates DI from beginning to end.

Our application will contain:

Task Management App

├── Configuration
├── Authentication
├── Logging
├── API Client
├── Task Repository
├── Task Service
├── Feature-specific providers
├── Payment abstraction
└── Testing implementation

66. Project Structure

src/
└── app/

    ├── core/
    │   ├── config/
    │   │   └── app-config.ts
    │   │
    │   ├── logging/
    │   │   ├── logger.ts
    │   │   └── console-logger.ts
    │   │
    │   ├── auth/
    │   │   └── auth.service.ts
    │   │
    │   └── api/
    │       └── api-client.ts
    │
    ├── tasks/
    │   ├── task.model.ts
    │   ├── task.repository.ts
    │   ├── task.service.ts
    │   └── task-list.component.ts
    │
    ├── app.component.ts
    ├── app.config.ts
    └── main.ts

67. Application Configuration

Create:

// core/config/app-config.ts

import { InjectionToken } from '@angular/core';

export interface AppConfig {

  apiUrl: string;

  appName: string;

  features: {
    analytics: boolean;
  };

}

export const APP_CONFIG =
  new InjectionToken<AppConfig>(
    'APP_CONFIG'
  );

68. Provide Configuration

// app.config.ts

import {
  ApplicationConfig
} from '@angular/core';

import {
  APP_CONFIG
} from './core/config/app-config';

export const appConfig:
  ApplicationConfig = {

  providers: [

    {
      provide: APP_CONFIG,

      useValue: {
        apiUrl: 'https://api.example.com',

        appName: 'Task Manager',

        features: {
          analytics: true
        }
      }
    }

  ]

};

69. Logger Abstraction

Create:

// core/logging/logger.ts

export abstract class Logger {

  abstract info(
    message: string
  ): void;

  abstract error(
    message: string
  ): void;

}

Now the application depends on:

Logger

not:

ConsoleLogger

70. Logger Implementation

// core/logging/console-logger.ts

import { Injectable } from '@angular/core';

import {
  Logger
} from './logger';

@Injectable()
export class ConsoleLogger
  implements Logger {

  info(message: string) {

    console.log(
      `[INFO] ${message}`
    );

  }

  error(message: string) {

    console.error(
      `[ERROR] ${message}`
    );

  }

}

71. Connect the Abstraction

In app.config.ts:

providers: [

  {
    provide: Logger,
    useClass: ConsoleLogger
  }

]

Now:

inject(Logger)

returns:

ConsoleLogger

The consumer doesn't care about the implementation.

72. Authentication Service

@Injectable({
  providedIn: 'root'
})
export class AuthService {

  private token =
    'fake-jwt-token';

  isAuthenticated(): boolean {

    return !!this.token;

  }

  getToken(): string {

    return this.token;

  }

}

Because it is root-provided, the application can share the service.

73. API Client

@Injectable({
  providedIn: 'root'
})
export class ApiClient {

  private http =
    inject(HttpClient);

  private config =
    inject(APP_CONFIG);

  get<T>(path: string) {

    return this.http.get<T>(
      `${this.config.apiUrl}${path}`
    );

  }

}

Now this service demonstrates DI with:

ApiClient
   |
   ├── HttpClient
   |
   └── APP_CONFIG

Angular constructs the dependency graph.

74. Task Repository

Define:

export abstract class TaskRepository {

  abstract getTasks():
    Observable<Task[]>;

}

Production implementation:

@Injectable()
export class HttpTaskRepository
  implements TaskRepository {

  private api =
    inject(ApiClient);

  getTasks() {

    return this.api.get<Task[]>(
      '/tasks'
    );

  }

}

75. Connect Repository to DI

providers: [

  {
    provide: TaskRepository,

    useClass: HttpTaskRepository
  }

]

Now:

inject(TaskRepository)

returns:

HttpTaskRepository

This is dependency inversion in practice.

76. Task Service

@Injectable({
  providedIn: 'root'
})
export class TaskService {

  private repository =
    inject(TaskRepository);

  getTasks() {

    return this.repository.getTasks();

  }

}

Notice the architecture:

TaskService
     |
     ↓
TaskRepository
     |
     ↓
HttpTaskRepository
     |
     ↓
ApiClient
     |
     ↓
HttpClient

The TaskService does not know how HTTP works.

That's good architecture.

77. Component

@Component({
  selector: 'app-task-list',

  template: `

    <h1>Tasks</h1>

    @for (task of tasks(); track task.id) {

      <article>

        <h2>{{ task.title }}</h2>

        <p>{{ task.description }}</p>

      </article>

    }

  `
})
export class TaskListComponent {

  private taskService =
    inject(TaskService);

  tasks = signal<Task[]>([]);

  constructor() {

    this.taskService
      .getTasks()
      .subscribe(tasks => {

        this.tasks.set(tasks);

      });

  }

}

Now the component doesn't know anything about:

HTTP
URLs
authentication
repositories
configuration

It only knows:

TaskService

That's exactly what DI should help you achieve.

78. Full Dependency Graph

The final graph looks like:

                    AppConfig
                       │
                       ↓
HttpClient ───────→ ApiClient
                       │
                       ↓
              HttpTaskRepository
                       │
                       ↓
                TaskRepository
                       │
                       ↓
                  TaskService
                       │
                       ↓
                TaskListComponent

Angular's DI system resolves this graph.

You don't manually write:

new ApiClient(...)
new HttpTaskRepository(...)
new TaskService(...)

Angular handles construction and provider resolution.

79. Replacing the Repository

Imagine tomorrow you replace REST with GraphQL.

Create:

@Injectable()
export class GraphQLTaskRepository
  implements TaskRepository {

  getTasks() {

    // GraphQL implementation

  }

}

Change the provider:

{
  provide: TaskRepository,

  useClass:
    GraphQLTaskRepository
}

The following code doesn't change:

TaskService

or:

TaskListComponent

That's the real power of abstraction + DI.

80. Adding a Fake Repository for Testing

@Injectable()
export class FakeTaskRepository
  implements TaskRepository {

  getTasks() {

    return of([
      {
        id: 1,
        title: 'Learn Angular DI',
        description:
          'Understand providers and injectors'
      }
    ]);

  }

}

Test configuration:

providers: [

  {
    provide: TaskRepository,

    useClass:
      FakeTaskRepository
  }

]

Now the entire application can run without a backend.

81. Factory-Based API Client

Suppose development and production require different API clients.

You can create:

export const API_CLIENT_PROVIDER = {

  provide: ApiClient,

  useFactory: () => {

    const http =
      inject(HttpClient);

    const config =
      inject(APP_CONFIG);

    const logger =
      inject(Logger);

    return new ApiClient(
      http,
      config,
      logger
    );

  }

};

This is useful when object construction requires multiple dependencies or runtime decisions.

82. Multiple Log Handlers

Let's make logging extensible.

export const LOG_HANDLERS =
  new InjectionToken<LogHandler[]>(
    'LOG_HANDLERS'
  );

Provide:

providers: [

  {
    provide: LOG_HANDLERS,
    useClass: ConsoleLogHandler,
    multi: true
  },

  {
    provide: LOG_HANDLERS,
    useClass: RemoteLogHandler,
    multi: true
  }

]

Then:

@Injectable({
  providedIn: 'root'
})
export class LoggerService {

  private handlers =
    inject(LOG_HANDLERS);

  info(message: string) {

    for (const handler
      of this.handlers) {

      handler.info(message);

    }

  }

}

Now adding another logging destination requires adding another provider rather than changing LoggerService.

83. Building a `provideTasks()` API

We can package the entire feature.

export function provideTasks(): Provider[] {

  return [

    {
      provide: TaskRepository,

      useClass:
        HttpTaskRepository
    },

    TaskService

  ];

}

Then:

bootstrapApplication(
  AppComponent,
  {
    providers: [
      provideTasks()
    ]
  }
);

For a real library, you would typically return an appropriate provider configuration and may compose optional features.

This is the same architectural idea behind Angular's provider-function APIs.

84. Advanced `provideX()` Architecture

A more sophisticated API can look like:

provideTasks(
  withCaching(),
  withLogging(),
  withRetry()
)

Internally:

export function provideTasks(
  ...features: TaskFeature[]
): Provider[] {

  return [

    TaskService,

    ...features.flatMap(
      feature => feature.providers
    )

  ];

}

This pattern is excellent for reusable Angular libraries.

85. `viewProviders` in Real Applications

Consider a reusable component:

@Component({
  selector: 'app-data-table',

  viewProviders: [
    TableState
  ],

  template: `
    <table>
      ...
    </table>

    <ng-content />
  `
})
export class DataTableComponent {}

If TableState is an internal implementation detail, viewProviders can prevent projected content from accidentally depending on it.

This is a real architectural reason to use viewProviders.

86. Lightweight Injection Tokens

Angular libraries sometimes want a parent component to communicate with a child without forcing a hard runtime dependency on the concrete component class.

For example:

export abstract class HeaderToken {

  abstract close(): void;

}

Then:

@Component({
  selector: 'app-header',

  providers: [
    {
      provide: HeaderToken,
      useExisting: HeaderComponent
    }
  ]
})
export class HeaderComponent
  extends HeaderToken {

  close() {
    // ...
  }

}

Consumers depend on:

HeaderToken

instead of:

HeaderComponent

Angular documents this as a lightweight injection-token pattern useful for library design and tree-shaking.

87. DI and Circular Dependencies

Sometimes you accidentally create:

A → B
↑   ↓
└───┘

For example:

ServiceA → ServiceB
ServiceB → ServiceA

This can produce DI errors.

The correct solution is usually architectural:

remove the circular dependency
introduce an abstraction
move shared behavior to another service
restructure the dependency graph

Don't immediately reach for forwardRef().

forwardRef() solves declaration/reference problems; it is not a general solution for bad architecture.

88. Common DI Error: NullInjectorError

You may see:

NullInjectorError:
No provider for UserService!

Usually this means:

inject(UserService)

was called but Angular couldn't find a provider in the available injector hierarchy.

Possible solutions:

@Injectable({
  providedIn: 'root'
})

or:

providers: [
  UserService
]

or:

bootstrapApplication(AppComponent, {
  providers: [
    UserService
  ]
});

But don't blindly add:

providedIn: 'root'

just to make the error disappear.

First determine the intended scope.

89. Common DI Error: Wrong Scope

Suppose:

@Component({
  providers: [
    CartService
  ]
})
export class CheckoutComponent {}

Then another unrelated parent tries:

inject(CartService)

and fails.

Why?

Because the service exists inside the checkout component's injector, not globally.

The solution isn't necessarily moving it to root.

The real question is:

Where should this dependency live?

That's the architectural question DI forces you to answer.

90. Common Error: `inject()` Outside Context

This:

ngOnInit() {

  const service =
    inject(UserService);

}

causes:

NG0203

because ngOnInit() is not an injection context.

Fix:

private service =
  inject(UserService);

Then:

ngOnInit() {

  this.service.load();

}

Angular explicitly documents NG0203 as the error produced when inject() is used outside a valid injection context.

91. Common Error: Two InjectionTokens

Wrong:

const CONFIG =
  new InjectionToken<AppConfig>(
    'CONFIG'
  );

Provider file:

const CONFIG =
  new InjectionToken<AppConfig>(
    'CONFIG'
  );

These are different tokens.

Correct:

// config.token.ts

export const CONFIG =
  new InjectionToken<AppConfig>(
    'CONFIG'
  );

Then:

import { CONFIG }
  from './config.token';

everywhere.

92. Common Error: Confusing `useClass` and `useExisting`

If you want:

same instance

use:

useExisting

If you want Angular to create an implementation from a class:

useClass

Remember:

useClass    → implementation
useExisting → alias

93. Common Error: Making Everything `providedIn: 'root'`

This is probably the most common architectural mistake.

Developers write:

@Injectable({
  providedIn: 'root'
})

for every service.

But some services should be scoped:

@Component({
  providers: [
    FormStateService
  ]
})

Others may belong to:

feature
route
environment
application
component

A good Angular architecture chooses scope intentionally.

94. How to Decide Provider Scope

Ask:

Should every part of the application share one instance?

Use:

providedIn: 'root'

Should every instance of a component have independent state?

Use:

@Component({
  providers: [...]
})

Should a feature have its own dependency?

Consider route/environment providers.

Should the dependency be configurable?

Use:

InjectionToken

Should different implementations be interchangeable?

Use:

abstract class / InjectionToken
+
useClass

Should multiple implementations contribute?

Use:

multi: true

Should an existing provider be exposed under another token?

Use:

useExisting

Does creation require runtime logic?

Use:

useFactory

95. DI in Modern Angular vs Old Angular

Concept	Traditional Angular	Modern Angular
Injection	Constructor	`inject()` + constructor
Application architecture	NgModules	Standalone
Global providers	`AppModule.providers`	`ApplicationConfig` / `providedIn`
Feature providers	NgModules	Environment/route providers
Guards	Class-based	Functional guards
Resolvers	Class-based	Functional resolvers
Configuration	`InjectionToken`	`InjectionToken`
Provider factories	`useFactory`	`useFactory` + `inject()`
Library APIs	NgModule configuration	`provideX()` / `withX()`
Scope	Module/component	Environment/element/route/component

The important point is that Angular did not throw away DI.

Instead, Angular evolved the way DI is configured and consumed.

96. What You Should Learn for an Angular Interview

If an interviewer asks:

"Explain Dependency Injection in Angular."

Don't answer only:

"Angular injects services into components."

A strong answer is:

Angular's Dependency Injection system manages the creation and delivery of dependencies using tokens, providers, and injectors. A provider defines how a token should be resolved, while an injector performs the resolution and controls scope and lifetime. Modern Angular supports both constructor injection and the inject() function. Providers can be configured through providedIn, application/environment providers, routes, components, and directives. Angular also supports provider strategies such as useClass, useValue, useFactory, useExisting, and multi, while hierarchical injectors allow dependencies to be scoped and overridden at different levels.

Then explain:

Token
Provider
Injector
Scope
Resolution

That demonstrates real understanding.

97. The Mental Model You Should Remember

Whenever Angular sees:

inject(SomeDependency)

think:

What token is being requested?
          ↓
Which injector is currently active?
          ↓
Where is the nearest provider?
          ↓
What provider recipe is configured?
          ↓
Does Angular create or reuse an instance?
          ↓
What is the dependency's scope/lifetime?

For example:

inject(TaskRepository)

becomes:

TaskRepository
      ↓
Current Injector
      ↓
Find Provider
      ↓
useClass: HttpTaskRepository
      ↓
Create/Reuse HttpTaskRepository
      ↓
Resolve its dependencies
      ↓
Return instance

That is Angular DI.

98. The Complete Picture

Angular DI can be understood as five layers:

                    ┌──────────────────────┐
                    │       Consumer       │
                    │  Component/Service   │
                    └──────────┬───────────┘
                               │
                               │ inject(Token)
                               ↓
                    ┌──────────────────────┐
                    │       Injector       │
                    │   Resolve dependency │
                    └──────────┬───────────┘
                               │
                               ↓
                    ┌──────────────────────┐
                    │       Provider       │
                    │ useClass/useValue/   │
                    │ useFactory/useExisting│
                    └──────────┬───────────┘
                               │
                               ↓
                    ┌──────────────────────┐
                    │      Dependency      │
                    │ Service/Object/etc.  │
                    └──────────────────────┘

And the injector itself exists within a hierarchy:

                 EnvironmentInjector
                         │
             ┌───────────┴───────────┐
             │                       │
        Application              Feature/Route
             │                       │
             └───────────┬───────────┘
                         │
                  ElementInjector
                         │
                    Component
                         │
                   Child Component
                         │
                  Grandchild Component

99. Best Practices

1. Prefer `providedIn: 'root'` for true application-wide services

@Injectable({
  providedIn: 'root'
})

2. Use component providers for isolated state

@Component({
  providers: [
    FormState
  ]
})

3. Prefer `inject()` for modern Angular code

private service = inject(MyService);

4. Keep constructor injection when it makes sense

You don't need to rewrite every existing Angular application.

5. Use `InjectionToken` for interfaces and configuration

new InjectionToken<AppConfig>()

6. Use abstractions when implementations may change

abstract class PaymentGateway {}

7. Use `useExisting` when you need an alias to the same instance

8. Use `multi` for extensible collections

9. Don't make every service global

Scope dependencies intentionally.

10. Don't use `runInInjectionContext()` unnecessarily

Normal DI should remain the default.

11. Don't create duplicate `InjectionToken` instances

Export one token and reuse it.

12. Use Angular DevTools when debugging injector problems

Angular DevTools can visualize injector hierarchies, provider lists, and resolution paths, which is extremely useful when debugging complex DI behavior.

100. Final Cheat Sheet

// Root service
@Injectable({
  providedIn: 'root'
})
export class UserService {}

// Modern injection
private userService = inject(UserService);

// Classic injection
constructor(
  private userService: UserService
) {}

// Value
{
  provide: API_URL,
  useValue: 'https://api.example.com'
}

// Class
{
  provide: Logger,
  useClass: ConsoleLogger
}

// Alias
{
  provide: LegacyLogger,
  useExisting: Logger
}

// Factory
{
  provide: ApiClient,
  useFactory: () => {

    const http = inject(HttpClient);

    return new ApiClient(http);

  }
}

// Multiple providers
{
  provide: HANDLERS,
  useClass: ConsoleHandler,
  multi: true
}

// Optional
inject(Service, {
  optional: true
});

// Parent
inject(Service, {
  skipSelf: true
});

// Current injector only
inject(Service, {
  self: true
});

// Host boundary
inject(Service, {
  host: true
});

// InjectionToken
const CONFIG =
  new InjectionToken<AppConfig>(
    'CONFIG'
  );

// Component scope
@Component({
  providers: [
    LocalState
  ]
})

// Component view-only scope
@Component({
  viewProviders: [
    InternalService
  ]
})

// Modern application providers
bootstrapApplication(
  AppComponent,
  {
    providers: [
      provideRouter(routes),
      provideHttpClient()
    ]
  }
);

// Custom provider API
provideAnalytics({
  trackingId: '123'
});

Conclusion

Angular Dependency Injection is much more than:

constructor(private service: Service) {}

That syntax is only the visible surface.

Underneath it is a complete dependency-resolution system built around:

Tokens
   ↓
Providers
   ↓
Injectors
   ↓
Hierarchies
   ↓
Scopes
   ↓
Lifetimes
   ↓
Implementations

The evolution from:

constructor(...)

to:

inject(...)

didn't replace Angular DI.

It made DI usable in a much broader range of modern Angular APIs, including functional guards, resolvers, provider factories, standalone applications, environment providers, and library configuration.

The most important concepts to master are:

Dependency Injection
       ↓
Token
       ↓
Provider
       ↓
Injector
       ↓
EnvironmentInjector
       ↓
ElementInjector
       ↓
Hierarchical Resolution
       ↓
Provider Scope
       ↓
useClass
useValue
useFactory
useExisting
multi
       ↓
InjectionToken
       ↓
inject()
       ↓
Injection Context
       ↓
Self / SkipSelf / Host / Optional
       ↓
Standalone + provideX()
       ↓
Testing + Architecture

Once you understand these concepts, Angular DI stops being a collection of decorators and APIs.

You start seeing it as what it really is:

A runtime dependency-resolution and scoping system that allows Angular applications to separate what a component needs from how that dependency is created.

And that separation is one of the foundations of maintainable, testable, scalable Angular architecture.

References

Angular Dependency Injection Guide — Angular DI Documentation
Angular Hierarchical Injectors — Hierarchical Dependency Injection
Angular Provider Configuration — Defining Dependency Providers
Angular Injection Context — Injection Context
Angular inject() API — inject() API
Angular DevTools Injector Tree — Angular DevTools Injectors