DEV Community: Ravi Vishwakarma

Why HTTP Needed the QUERY Method

Ravi Vishwakarma — Sat, 11 Jul 2026 09:17:42 +0000

HTTP Finally Gets a New Request Method: Meet `QUERY`

For years, HTTP developers have worked with a familiar set of request methods—GET, POST, PUT, PATCH, and DELETE. These methods have served the web remarkably well, but one common problem has always been awkward to solve:

How do you send a complex query to the server without pretending it's a state-changing operation?

The answer was usually one of two compromises:

Stuff everything into a long GET URL.
Use POST even though you're only reading data.

Now, HTTP has a better answer.

With RFC 10008, the HTTP ecosystem introduces a new standardized request method: QUERY.

The Problem with GET

GET is the natural choice for retrieving data because it is:

Safe (doesn't modify server state)
Idempotent
Cache-friendly

However, GET requests carry parameters in the URL.

Imagine searching an e-commerce website with dozens of filters:

GET /products?category=laptops&brand=Dell&brand=Lenovo&priceMin=500&priceMax=1500&sort=-rating&page=3

As filters become more complex, URLs become:

Difficult to read
Hard to maintain
Limited by URL length restrictions in some environments

Even worse, expressing deeply nested filters in a query string can become nearly impossible.

Why Developers Used POST

To avoid enormous URLs, many APIs switched to:

POST /products/search
Content-Type: application/json

{
  "category": "laptops",
  "brands": ["Dell", "Lenovo"],
  "price": {
    "min": 500,
    "max": 1500
  },
  "sort": "-rating"
}

This works technically.

But semantically, it's misleading.

POST is intended for operations that may change server state, while a search is simply retrieving information.

This mismatch affects caching, retries, API documentation, and HTTP semantics.

Enter `QUERY`

The new QUERY method is designed specifically for read-only operations that require a request body.

Example:

QUERY /products
Content-Type: application/json

{
  "category": "laptops",
  "brands": ["Dell", "Lenovo"],
  "price": {
    "min": 500,
    "max": 1500
  },
  "sort": "-rating"
}

Now the intent is clear:

The client is retrieving data.
The request can include a rich JSON body.
The server promises not to modify server state.

Key Characteristics

QUERY is:

Safe
Idempotent
Designed to support a request body
Intended for complex retrieval operations

In many situations, it becomes the ideal middle ground between GET and POST.

GET vs POST vs QUERY

Feature	GET	POST	QUERY
Read data	Yes	Yes	Yes
Request body	No (not generally used)	Yes	Yes
Safe	Yes	No	Yes
Idempotent	Yes	No	Yes
Complex filters	Limited	Yes	Yes
Correct HTTP semantics	Yes	No (for reads)	Yes

Real-World Use Cases

QUERY is especially useful for:

Advanced product searches
Analytics dashboards
Business intelligence queries
Graph-style filtering
GIS and map searches
Large reporting APIs
Log search platforms
AI and vector database queries

Anywhere a client needs to send a structured query without changing data, QUERY is a natural fit.

Will It Replace POST?

Not immediately.

The web ecosystem is vast. Browsers, HTTP libraries, proxies, API gateways, CDNs, and frameworks all need to support the new method. Existing APIs that already use POST /search will likely continue to do so until support for QUERY becomes widespread.

Over time, however, new APIs may adopt QUERY to better express read-only operations.

What This Means for API Designers

For years, developers had to choose between:

Correct semantics (GET) with awkward URLs
Convenient request bodies (POST) with incorrect semantics

QUERY removes that trade-off.

When an endpoint retrieves data but requires a structured request body, developers no longer have to misuse POST.

Final Thoughts

New HTTP methods are introduced very rarely.

The introduction of PATCH was a significant milestone, and now QUERY represents another meaningful evolution of the HTTP protocol.

It is a small addition with a significant impact, making HTTP more expressive while preserving the principles that have made it successful for decades.

As support spreads across frameworks, servers, proxies, and client libraries, QUERY has the potential to become the standard choice for complex, read-only operations.

HTTP doesn't evolve often, but when it does, it's worth paying attention.

Building a Live Data Dashboard with Angular and ASP.NET Core: A Complete Step-by-Step Guide (Beginner to Advanced)

Ravi Vishwakarma — Tue, 30 Jun 2026 06:39:12 +0000

Learn how to build a real-time, live-updating data dashboard using Angular on the frontend and ASP.NET Core with SignalR on the backend. This guide walks through every step — from project setup to production deployment — with full code examples, best practices, and SEO-friendly structure for your own blog or documentation.

Introduction
What You Will Build
Prerequisites
Understanding the Architecture
Part 1 (Beginner): Setting Up the ASP.NET Core Backend
Part 2 (Beginner): Adding SignalR for Real-Time Communication
Part 3 (Beginner): Setting Up the Angular Frontend
Part 4 (Intermediate): Connecting Angular to SignalR
Part 5 (Intermediate): Building the Dashboard UI with Live Charts
Part 6 (Intermediate): Styling the Dashboard
Part 7 (Advanced): Handling Reconnection and Error States
Part 8 (Advanced): Adding Authentication with JWT
Part 9 (Advanced): Scaling SignalR with Redis Backplane
Part 10 (Advanced): Performance Optimization
Part 11 (Advanced): Testing the Application
Part 12 (Advanced): Deploying to Production
Common Errors and Troubleshooting
Best Practices Checklist
Frequently Asked Questions (FAQ)
Conclusion

1. Introduction

Real-time dashboards have become a core requirement in modern web applications — whether you're tracking stock prices, monitoring IoT sensor data, displaying server health metrics, or showing live sales numbers. Instead of forcing users to refresh a page to see updated data, a live data dashboard pushes new information to the browser the moment it becomes available.

In this guide, you will learn how to build a complete live data dashboard using two of the most popular technologies in the enterprise web development world: Angular for the frontend and ASP.NET Core for the backend, connected through SignalR, Microsoft's real-time communication library.

This tutorial is structured to take you from absolute beginner concepts all the way to advanced, production-ready practices including authentication, scaling, and deployment. Whether you are a student building your first real-time app or a professional developer architecting a production dashboard, this guide has something for you.

2. What You Will Build

By the end of this tutorial, you will have a fully functional application consisting of:

An ASP.NET Core Web API backend that generates and broadcasts live data (for example, simulated stock prices, server metrics, or sensor readings).
A SignalR Hub that pushes updates to connected clients instantly, without polling.
An Angular application that connects to the SignalR hub and updates its UI in real time.
Live charts built with a charting library (Chart.js or ngx-charts) that animate as new data arrives.
JWT authentication to secure the dashboard so only logged-in users can view live data.
A production deployment setup using Docker and IIS/Azure.

3. Prerequisites

Before starting, make sure you have the following installed and a basic understanding of these technologies.

Software Requirements

Node.js (LTS version) and npm
Angular CLI (npm install -g @angular/cli)
.NET SDK (latest LTS version of .NET)
Visual Studio Code or Visual Studio 2022
Git for version control
(Optional, for advanced sections) Docker Desktop and a Redis instance

Knowledge Requirements

Basic understanding of TypeScript and Angular components/services
Basic understanding of C# and ASP.NET Core controllers
Familiarity with REST APIs (helpful but not mandatory)

If you are completely new to Angular or ASP.NET Core, don't worry — each step includes explanations of why we are doing something, not just how.

4. Understanding the Architecture

Before writing any code, it's important to understand how the pieces fit together.

 ┌─────────────────────┐         WebSocket / SignalR        ┌──────────────────────┐
 │                      │ <---------------------------------> │                      │
 │   Angular Frontend   │                                     │  ASP.NET Core Backend│
 │  (Dashboard UI +     │         REST API (initial data)     │  (Web API + SignalR  │
 │   SignalR Client)    │ <---------------------------------- │   Hub + Data Service)│
 │                      │                                     │                      │
 └─────────────────────┘                                     └──────────────────────┘
                                                                         │
                                                                         ▼
                                                              ┌──────────────────────┐
                                                              │  Data Source (DB,    │
                                                              │  IoT feed, simulated │
                                                              │  data generator, etc)│
                                                              └──────────────────────┘

Key concept: Instead of the Angular app repeatedly calling an API (polling) every few seconds to check for new data, the ASP.NET Core backend uses SignalR to push data directly to connected clients over a persistent WebSocket connection. This is far more efficient and provides true real-time updates.

We will use a REST API call for the initial page load (to get historical/starting data) and SignalR for all subsequent live updates.

5. Part 1 (Beginner): Setting Up the ASP.NET Core Backend

Step 1.1: Create the Web API Project

Open your terminal and run:

dotnet new webapi -n LiveDashboard.Api
cd LiveDashboard.Api

This creates a new ASP.NET Core Web API project. If you're prompted to choose between minimal APIs and controllers, this guide uses controllers for clarity, but the concepts apply equally to minimal API style.

Step 1.2: Project Structure

Organize your project with the following folders for clarity as the app grows:

LiveDashboard.Api/
 ├── Controllers/
 ├── Hubs/
 ├── Models/
 ├── Services/
 ├── Program.cs
 └── appsettings.json

Create these folders inside your project directory.

Step 1.3: Define the Data Model

Create Models/MetricData.cs:

namespace LiveDashboard.Api.Models
{
    public class MetricData
    {
        public string MetricName { get; set; } = string.Empty;
        public double Value { get; set; }
        public DateTime Timestamp { get; set; }
    }
}

This simple model represents a single data point — for example, a CPU usage percentage, a stock price, or a temperature reading.

Step 1.4: Create a Simulated Data Service

In a real application, this data might come from a database, a message queue, or an external API. For this tutorial, we'll simulate live data so you can see the dashboard working immediately.

Create Services/DataGeneratorService.cs:

using LiveDashboard.Api.Models;

namespace LiveDashboard.Api.Services
{
    public class DataGeneratorService
    {
        private readonly Random _random = new();

        public MetricData GenerateMetric(string metricName, double baseValue, double variance)
        {
            var change = (_random.NextDouble() * 2 - 1) * variance;
            return new MetricData
            {
                MetricName = metricName,
                Value = Math.Round(baseValue + change, 2),
                Timestamp = DateTime.UtcNow
            };
        }
    }
}

builder.Services.AddSingleton<DataGeneratorService>();

Step 1.5: Create a Basic REST Endpoint

Create Controllers/MetricsController.cs to allow the Angular app to fetch the initial set of data when it first loads:

using Microsoft.AspNetCore.Mvc;
using LiveDashboard.Api.Services;

namespace LiveDashboard.Api.Controllers
{
    [ApiController]
    [Route("api/[controller]")]
    public class MetricsController : ControllerBase
    {
        private readonly DataGeneratorService _generator;

        public MetricsController(DataGeneratorService generator)
        {
            _generator = generator;
        }

        [HttpGet("snapshot")]
        public IActionResult GetSnapshot()
        {
            var data = new[]
            {
                _generator.GenerateMetric("CPU", 45, 10),
                _generator.GenerateMetric("Memory", 60, 8),
                _generator.GenerateMetric("RequestsPerSecond", 120, 30)
            };

            return Ok(data);
        }
    }
}

Step 1.6: Enable CORS

Since Angular (running on port 4200 in development) and ASP.NET Core (running on a different port) are different origins, you need to enable CORS. Add this to Program.cs:

builder.Services.AddCors(options =>
{
    options.AddPolicy("AllowAngularDev", policy =>
    {
        policy.WithOrigins("http://localhost:4200")
              .AllowAnyHeader()
              .AllowAnyMethod()
              .AllowCredentials();
    });
});

And later, in the middleware pipeline:

app.UseCors("AllowAngularDev");

Tip: AllowCredentials() is required for SignalR connections to work correctly with CORS.

Step 1.7: Run and Verify

Run the backend with:

dotnet run

Visit https://localhost:<port>/api/metrics/snapshot in your browser or via a tool like Postman to confirm you receive a JSON array of metric data.

At this point, you have a working REST API. Next, we'll add real-time capability using SignalR.

6. Part 2 (Beginner): Adding SignalR for Real-Time Communication

Step 2.1: What Is SignalR?

SignalR is a library built into ASP.NET Core that simplifies adding real-time web functionality. It abstracts away the complexity of WebSockets, automatically falling back to other transport methods (like Server-Sent Events or long polling) when WebSockets aren't available, and handles connection management for you.

Step 2.2: Create the Hub

A "Hub" in SignalR is the core component that handles communication between server and clients. Create Hubs/DashboardHub.cs:

using Microsoft.AspNetCore.SignalR;

namespace LiveDashboard.Api.Hubs
{
    public class DashboardHub : Hub
    {
        public override async Task OnConnectedAsync()
        {
            await Clients.Caller.SendAsync("ReceiveMessage", "Connected to live dashboard hub.");
            await base.OnConnectedAsync();
        }
    }
}

This hub doesn't need many methods yet — most of the data pushing will happen from a background service, not from client-invoked methods. The hub mainly serves as the "pipe" through which data flows.

Step 2.3: Register SignalR in Program.cs

Update Program.cs:

using LiveDashboard.Api.Hubs;
using LiveDashboard.Api.Services;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddSignalR();
builder.Services.AddSingleton<DataGeneratorService>();

builder.Services.AddCors(options =>
{
    options.AddPolicy("AllowAngularDev", policy =>
    {
        policy.WithOrigins("http://localhost:4200")
              .AllowAnyHeader()
              .AllowAnyMethod()
              .AllowCredentials();
    });
});

var app = builder.Build();

app.UseCors("AllowAngularDev");
app.UseRouting();

app.MapControllers();
app.MapHub<DashboardHub>("/hubs/dashboard");

app.Run();

The key line here is app.MapHub<DashboardHub>("/hubs/dashboard"), which exposes the hub at a specific URL that the Angular client will connect to.

Step 2.4: Create a Background Service to Push Live Data

This is where the "live" part of the dashboard comes to life. We'll create a hosted background service that runs continuously, generates new data every few seconds, and broadcasts it to all connected clients via the hub.

Create Services/MetricBroadcastService.cs:

using Microsoft.AspNetCore.SignalR;
using LiveDashboard.Api.Hubs;

namespace LiveDashboard.Api.Services
{
    public class MetricBroadcastService : BackgroundService
    {
        private readonly IHubContext<DashboardHub> _hubContext;
        private readonly DataGeneratorService _generator;

        public MetricBroadcastService(IHubContext<DashboardHub> hubContext, DataGeneratorService generator)
        {
            _hubContext = hubContext;
            _generator = generator;
        }

        protected override async Task ExecuteAsync(CancellationToken stoppingToken)
        {
            while (!stoppingToken.IsCancellationRequested)
            {
                var cpu = _generator.GenerateMetric("CPU", 45, 10);
                var memory = _generator.GenerateMetric("Memory", 60, 8);
                var rps = _generator.GenerateMetric("RequestsPerSecond", 120, 30);

                await _hubContext.Clients.All.SendAsync("ReceiveMetric", cpu, stoppingToken);
                await _hubContext.Clients.All.SendAsync("ReceiveMetric", memory, stoppingToken);
                await _hubContext.Clients.All.SendAsync("ReceiveMetric", rps, stoppingToken);

                await Task.Delay(2000, stoppingToken); // push every 2 seconds
            }
        }
    }
}

builder.Services.AddHostedService<MetricBroadcastService>();

How this works: IHubContext<DashboardHub> lets you send messages to clients from anywhere in your application (not just from within the hub itself) — perfect for a background service that has no direct connection to a specific client, but needs to broadcast to all of them. Clients.All.SendAsync("ReceiveMetric", ...) sends a message named "ReceiveMetric" with the metric data as a payload to every connected client.

Step 2.5: Verify with a Test Client (Optional)

Before building the Angular frontend, you can test the SignalR hub using a tool like the SignalR test client in Postman or a simple HTML page with the SignalR JavaScript client. This isn't required, but it can help isolate backend issues from frontend issues if something doesn't work later.

At this point, your backend is complete for the beginner phase: it has a REST endpoint for the initial snapshot and a SignalR hub broadcasting new data every two seconds.

7. Part 3 (Beginner): Setting Up the Angular Frontend

Step 3.1: Create the Angular Project

In a separate folder (sibling to your backend project), run:

ng new live-dashboard-client --routing --style=scss
cd live-dashboard-client

Choose the default options when prompted, or customize as you prefer.

Step 3.2: Install the SignalR Client Library

Angular communicates with the SignalR hub using Microsoft's official JavaScript/TypeScript client:

npm install @microsoft/signalr

Step 3.3: Install a Charting Library

For this tutorial we'll use Chart.js with the ng2-charts Angular wrapper, since it's lightweight and beginner-friendly. (Advanced alternative: ngx-charts, covered briefly later.)

npm install chart.js ng2-charts

Step 3.4: Project Structure

Generate the core building blocks:

ng generate service services/signalr
ng generate service services/metrics
ng generate component components/dashboard
ng generate component components/metric-card

This gives you a clean separation: a service to manage the SignalR connection, a service to manage metric state, and components for the visual layer.

Step 3.5: Define the Metric Model

Create src/app/models/metric-data.model.ts:

export interface MetricData {
  metricName: string;
  value: number;
  timestamp: string;
}

This mirrors the C# MetricData class on the backend, ensuring type safety across the stack.

At this point, your Angular project is scaffolded and ready to be wired up to the live backend. In the next section, we'll connect it to SignalR.

8. Part 4 (Intermediate): Connecting Angular to SignalR

Step 4.1: Build the SignalR Service

This service will manage the connection lifecycle (connect, disconnect, reconnect) and expose an Observable stream of incoming metric data that any component can subscribe to.

Edit src/app/services/signalr.service.ts:

import { Injectable } from '@angular/core';
import * as signalR from '@microsoft/signalr';
import { Subject } from 'rxjs';
import { MetricData } from '../models/metric-data.model';
import { environment } from '../../environments/environment';

@Injectable({
  providedIn: 'root'
})
export class SignalrService {
  private hubConnection!: signalR.HubConnection;
  private metricSubject = new Subject<MetricData>();

  public metric$ = this.metricSubject.asObservable();

  public startConnection(): void {
    this.hubConnection = new signalR.HubConnectionBuilder()
      .withUrl(`${environment.apiBaseUrl}/hubs/dashboard`)
      .withAutomaticReconnect()
      .configureLogging(signalR.LogLevel.Information)
      .build();

    this.hubConnection
      .start()
      .then(() => console.log('SignalR connection started'))
      .catch(err => console.error('Error starting SignalR connection:', err));

    this.registerHandlers();
  }

  private registerHandlers(): void {
    this.hubConnection.on('ReceiveMetric', (data: MetricData) => {
      this.metricSubject.next(data);
    });

    this.hubConnection.on('ReceiveMessage', (message: string) => {
      console.log('Server message:', message);
    });
  }

  public stopConnection(): void {
    this.hubConnection?.stop();
  }
}

Key concepts explained:

HubConnectionBuilder().withUrl(...) configures the connection to point at the hub endpoint we exposed on the backend (/hubs/dashboard).
.withAutomaticReconnect() tells SignalR to automatically attempt reconnection if the connection drops — essential for a reliable live dashboard.
this.hubConnection.on('ReceiveMetric', ...) registers a handler for the exact same message name ("ReceiveMetric") that the backend uses in SendAsync("ReceiveMetric", ...). These names must match exactly.
We use an RxJS Subject to convert SignalR's callback-based API into an Observable stream, which fits naturally into Angular's reactive patterns.

Step 4.2: Create the Environment Configuration

Update src/environments/environment.ts:

export const environment = {
  production: false,
  apiBaseUrl: 'https://localhost:7000' // match your backend's actual port
};

And src/environments/environment.prod.ts for production builds:

export const environment = {
  production: true,
  apiBaseUrl: 'https://your-production-api.com'
};

Step 4.3: Build the Metrics Service

This service will fetch the initial snapshot via REST and maintain the current state of each metric as live updates arrive.

Edit src/app/services/metrics.service.ts:

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { BehaviorSubject } from 'rxjs';
import { MetricData } from '../models/metric-data.model';
import { environment } from '../../environments/environment';
import { SignalrService } from './signalr.service';

@Injectable({
  providedIn: 'root'
})
export class MetricsService {
  private metricsMap = new Map<string, MetricData>();
  private metricsSubject = new BehaviorSubject<MetricData[]>([]);

  public metrics$ = this.metricsSubject.asObservable();

  constructor(private http: HttpClient, private signalr: SignalrService) {
    this.signalr.metric$.subscribe(metric => this.upsertMetric(metric));
  }

  public loadInitialSnapshot(): void {
    this.http
      .get<MetricData[]>(`${environment.apiBaseUrl}/api/metrics/snapshot`)
      .subscribe(initialData => {
        initialData.forEach(m => this.metricsMap.set(m.metricName, m));
        this.emitMetrics();
      });
  }

  private upsertMetric(metric: MetricData): void {
    this.metricsMap.set(metric.metricName, metric);
    this.emitMetrics();
  }

  private emitMetrics(): void {
    this.metricsSubject.next(Array.from(this.metricsMap.values()));
  }
}

Why a Map keyed by metric name? Each new live update replaces the latest value for that specific metric (e.g., CPU), rather than appending to an ever-growing list. This keeps the current-state view of the dashboard accurate and memory-efficient. (We'll handle historical trend data separately for charts in the next section.)

Step 4.4: Enable HttpClient

Make sure HttpClient is available. In a standalone Angular app (app.config.ts):

import { ApplicationConfig } from '@angular/core';
import { provideHttpClient } from '@angular/common/http';
import { provideRouter } from '@angular/router';
import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideHttpClient()
  ]
};

If you're using an NgModule-based app instead, import HttpClientModule into your AppModule.

Step 4.5: Initialize the Connection in the Dashboard Component

Edit src/app/components/dashboard/dashboard.component.ts:

import { Component, OnInit, OnDestroy } from '@angular/core';
import { CommonModule } from '@angular/common';
import { MetricsService } from '../../services/metrics.service';
import { SignalrService } from '../../services/signalr.service';
import { MetricData } from '../../models/metric-data.model';

@Component({
  selector: 'app-dashboard',
  standalone: true,
  imports: [CommonModule],
  templateUrl: './dashboard.component.html',
  styleUrls: ['./dashboard.component.scss']
})
export class DashboardComponent implements OnInit, OnDestroy {
  metrics: MetricData[] = [];

  constructor(
    private metricsService: MetricsService,
    private signalrService: SignalrService
  ) {}

  ngOnInit(): void {
    this.signalrService.startConnection();
    this.metricsService.loadInitialSnapshot();

    this.metricsService.metrics$.subscribe(data => {
      this.metrics = data;
    });
  }

  ngOnDestroy(): void {
    this.signalrService.stopConnection();
  }
}

At this stage, your Angular app connects to the backend, fetches an initial snapshot, and listens for live updates. Next, we'll render this data visually.

9. Part 5 (Intermediate): Building the Dashboard UI with Live Charts

Step 5.1: Basic Metric Cards (Numbers View)

Update dashboard.component.html:

<div class="dashboard">
  <h1>Live Data Dashboard</h1>

  <div class="metric-grid">
    <app-metric-card
      *ngFor="let metric of metrics"
      [name]="metric.metricName"
      [value]="metric.value"
      [timestamp]="metric.timestamp">
    </app-metric-card>
  </div>
</div>

Edit metric-card.component.ts:

import { Component, Input } from '@angular/core';
import { CommonModule } from '@angular/common';

@Component({
  selector: 'app-metric-card',
  standalone: true,
  imports: [CommonModule],
  templateUrl: './metric-card.component.html',
  styleUrls: ['./metric-card.component.scss']
})
export class MetricCardComponent {
  @Input() name = '';
  @Input() value = 0;
  @Input() timestamp = '';
}

metric-card.component.html:

<div class="metric-card">
  <h3>{{ name }}</h3>
  <p class="value">{{ value }}</p>
  <small>Updated: {{ timestamp | date:'mediumTime' }}</small>
</div>

This gives you a simple, working live-updating numeric dashboard. Now let's add line charts to visualize trends over time.

Step 5.2: Setting Up ng2-charts

In your standalone component or module, import the chart provider. With standalone components, register it in app.config.ts:

import { provideCharts, withDefaultRegisterables } from 'ng2-charts';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideHttpClient(),
    provideCharts(withDefaultRegisterables())
  ]
};

Step 5.3: Create a Live Chart Component

Generate a new component:

ng generate component components/live-chart

This component needs to maintain a rolling history of values for a given metric (e.g., the last 30 data points) so the chart shows a trend rather than just the latest number.

Edit live-chart.component.ts:

import { Component, Input, OnChanges, SimpleChanges } from '@angular/core';
import { CommonModule } from '@angular/common';
import { BaseChartDirective } from 'ng2-charts';
import { ChartConfiguration, ChartData } from 'chart.js';

@Component({
  selector: 'app-live-chart',
  standalone: true,
  imports: [CommonModule, BaseChartDirective],
  templateUrl: './live-chart.component.html',
  styleUrls: ['./live-chart.component.scss']
})
export class LiveChartComponent implements OnChanges {
  @Input() label = '';
  @Input() value = 0;
  @Input() timestamp = '';

  private readonly maxPoints = 30;

  public lineChartData: ChartData<'line'> = {
    labels: [],
    datasets: [
      {
        data: [],
        label: this.label,
        borderColor: '#3f8cff',
        backgroundColor: 'rgba(63, 140, 255, 0.15)',
        fill: true,
        tension: 0.35,
        pointRadius: 0
      }
    ]
  };

  public lineChartOptions: ChartConfiguration['options'] = {
    responsive: true,
    animation: { duration: 300 },
    scales: {
      x: { display: false },
      y: { beginAtZero: false }
    },
    plugins: {
      legend: { display: false }
    }
  };

  ngOnChanges(changes: SimpleChanges): void {
    if (changes['value'] && !changes['value'].firstChange) {
      this.addDataPoint();
    } else if (changes['value'] && changes['value'].firstChange) {
      this.addDataPoint();
    }
  }

  private addDataPoint(): void {
    const labels = this.lineChartData.labels as string[];
    const dataset = this.lineChartData.datasets[0].data as number[];

    labels.push(new Date(this.timestamp).toLocaleTimeString());
    dataset.push(this.value);

    if (labels.length > this.maxPoints) {
      labels.shift();
      dataset.shift();
    }

    // Reassign to trigger change detection in ng2-charts
    this.lineChartData = {
      ...this.lineChartData,
      labels: [...labels],
      datasets: [{ ...this.lineChartData.datasets[0], data: [...dataset] }]
    };
  }
}

live-chart.component.html:

<div class="chart-wrapper">
  <h4>{{ label }} Trend</h4>
  <canvas
    baseChart
    [data]="lineChartData"
    [options]="lineChartOptions"
    type="line">
  </canvas>
</div>

Step 5.4: Wire the Chart into the Dashboard

Update dashboard.component.html to include the chart alongside the cards:

<div class="dashboard">
  <h1>Live Data Dashboard</h1>

  <div class="metric-grid">
    <app-metric-card
      *ngFor="let metric of metrics"
      [name]="metric.metricName"
      [value]="metric.value"
      [timestamp]="metric.timestamp">
    </app-metric-card>
  </div>

  <div class="chart-grid">
    <app-live-chart
      *ngFor="let metric of metrics"
      [label]="metric.metricName"
      [value]="metric.value"
      [timestamp]="metric.timestamp">
    </app-live-chart>
  </div>
</div>

Don't forget to add LiveChartComponent to the imports array of DashboardComponent since both are standalone.

At this point, your dashboard displays both live numeric values and animated trend lines that update in real time as the backend pushes new data every two seconds.

Step 5.5: Alternative — Using ngx-charts (Advanced Option)

If you prefer a more "Angular-native" charting library with declarative templates instead of imperative chart configuration objects, consider @swimlane/ngx-charts. It integrates well with Angular's change detection and offers built-in chart types (line, bar, gauge, pie) ideal for dashboards. The setup process is similar: install the package, import the chart module, and bind data arrays to chart components via [results] inputs. Many production dashboards mix both libraries depending on the visualization needed — for example, ngx-charts for gauges and Chart.js for dense time-series lines.

10. Part 6 (Intermediate): Styling the Dashboard

A functional dashboard is only half the job — visual clarity matters, especially for monitoring tools that may be displayed on a large screen for extended periods (e.g., a NOC wall display).

Step 6.1: Grid Layout

In dashboard.component.scss:

.dashboard {
  padding: 2rem;
  background: #0f172a;
  min-height: 100vh;
  color: #e2e8f0;
  font-family: 'Inter', sans-serif;

  h1 {
    font-weight: 600;
    margin-bottom: 1.5rem;
  }
}

.metric-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
  gap: 1rem;
  margin-bottom: 2rem;
}

.chart-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(320px, 1fr));
  gap: 1.5rem;
}

Step 6.2: Card Styling

In metric-card.component.scss:

.metric-card {
  background: #1e293b;
  border-radius: 12px;
  padding: 1.25rem;
  box-shadow: 0 4px 12px rgba(0, 0, 0, 0.25);
  transition: transform 0.2s ease;

  &:hover {
    transform: translateY(-2px);
  }

  h3 {
    font-size: 0.85rem;
    text-transform: uppercase;
    letter-spacing: 0.05em;
    color: #94a3b8;
    margin-bottom: 0.5rem;
  }

  .value {
    font-size: 2rem;
    font-weight: 700;
    color: #3f8cff;
    margin: 0;
  }

  small {
    color: #64748b;
  }
}

Step 6.3: Visual Feedback on Update

A nice UX touch for live dashboards is briefly highlighting a value when it changes, so users can visually notice an update without staring at numbers. You can achieve this with a CSS animation triggered by an Angular class binding tied to a "just updated" flag, toggled with a short setTimeout whenever new data arrives. This kind of micro-interaction significantly improves the perceived "liveness" of the dashboard.

11. Part 7 (Advanced): Handling Reconnection and Error States

Production dashboards must gracefully handle network interruptions. SignalR's .withAutomaticReconnect() handles basic reconnection, but you should also surface connection status to users and handle edge cases.

Step 7.1: Expose Connection State

Update signalr.service.ts to track and expose connection status:

import { BehaviorSubject } from 'rxjs';

public connectionState$ = new BehaviorSubject<'connected' | 'reconnecting' | 'disconnected'>('disconnected');

public startConnection(): void {
  this.hubConnection = new signalR.HubConnectionBuilder()
    .withUrl(`${environment.apiBaseUrl}/hubs/dashboard`)
    .withAutomaticReconnect([0, 2000, 5000, 10000, 30000])
    .build();

  this.hubConnection.onreconnecting(() => this.connectionState$.next('reconnecting'));
  this.hubConnection.onreconnected(() => this.connectionState$.next('connected'));
  this.hubConnection.onclose(() => this.connectionState$.next('disconnected'));

  this.hubConnection
    .start()
    .then(() => this.connectionState$.next('connected'))
    .catch(() => this.connectionState$.next('disconnected'));

  this.registerHandlers();
}

The array [0, 2000, 5000, 10000, 30000] passed to withAutomaticReconnect defines custom retry delays (in milliseconds): retry immediately, then after 2s, 5s, 10s, and 30s, after which SignalR stops retrying automatically (you can add logic to manually retry beyond this).

Step 7.2: Display a Connection Banner

In dashboard.component.html, add a status banner:

<div class="connection-banner" *ngIf="connectionState !== 'connected'" [ngClass]="connectionState">
  <span *ngIf="connectionState === 'reconnecting'">Reconnecting to live data...</span>
  <span *ngIf="connectionState === 'disconnected'">Disconnected. Attempting to reconnect...</span>
</div>

Subscribe to connectionState$ in the component class just like you did for metrics. This small addition dramatically improves trust in the dashboard — users immediately know if the data they're looking at might be stale.

Step 7.3: Handle Manual Reconnection

If automatic reconnection exhausts its retries, implement a manual fallback, for instance using setInterval to attempt hubConnection.start() again every 30 seconds while in the disconnected state, with exponential backoff capped at a reasonable maximum to avoid hammering the server.

Step 7.4: Graceful Degradation

Consider what happens if SignalR/WebSockets are entirely blocked (e.g., by a restrictive corporate proxy). SignalR automatically falls back to Server-Sent Events or long polling, but if you want a guaranteed fallback, you could implement a periodic REST polling mechanism as a last resort, triggered only when the connectionState$ remains disconnected for an extended period.

12. Part 8 (Advanced): Adding Authentication with JWT

Most production dashboards display sensitive business data and need to be secured. Here's how to add JWT-based authentication to both the backend and the SignalR connection.

Step 8.1: Backend — Add JWT Authentication

Install the JWT package:

dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer

Configure it in Program.cs:

using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.IdentityModel.Tokens;
using System.Text;

var jwtKey = builder.Configuration["Jwt:Key"]!;

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true,
            ValidIssuer = builder.Configuration["Jwt:Issuer"],
            ValidAudience = builder.Configuration["Jwt:Audience"],
            IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(jwtKey))
        };

        // Required so SignalR can read the access token from the query string,
        // since WebSocket connections cannot set custom Authorization headers.
        options.Events = new JwtBearerEvents
        {
            OnMessageReceived = context =>
            {
                var accessToken = context.Request.Query["access_token"];
                var path = context.HttpContext.Request.Path;

                if (!string.IsNullOrEmpty(accessToken) && path.StartsWithSegments("/hubs"))
                {
                    context.Token = accessToken;
                }

                return Task.CompletedTask;
            }
        };
    });

builder.Services.AddAuthorization();

Add the middleware:

app.UseAuthentication();
app.UseAuthorization();

Secure the hub and controller:

[Authorize]
public class DashboardHub : Hub { ... }

[Authorize]
[ApiController]
[Route("api/[controller]")]
public class MetricsController : ControllerBase { ... }

Important detail: Browsers cannot attach custom Authorization headers to native WebSocket connections, so SignalR's JavaScript client sends the token as a query string parameter (access_token) instead. The OnMessageReceived event above reads that token specifically for requests to the /hubs path.

Step 8.2: Create a Simple Login Endpoint (for demo purposes)

[ApiController]
[Route("api/[controller]")]
public class AuthController : ControllerBase
{
    private readonly IConfiguration _config;
    public AuthController(IConfiguration config) => _config = config;

    [HttpPost("login")]
    public IActionResult Login([FromBody] LoginRequest request)
    {
        // Replace with real user validation against your identity store
        if (request.Username != "demo" || request.Password != "password")
            return Unauthorized();

        var claims = new[] { new Claim(ClaimTypes.Name, request.Username) };
        var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(_config["Jwt:Key"]!));
        var creds = new SigningCredentials(key, SecurityAlgorithms.HmacSha256);

        var token = new JwtSecurityToken(
            issuer: _config["Jwt:Issuer"],
            audience: _config["Jwt:Audience"],
            claims: claims,
            expires: DateTime.UtcNow.AddHours(2),
            signingCredentials: creds);

        return Ok(new { token = new JwtSecurityTokenHandler().WriteToken(token) });
    }
}

public record LoginRequest(string Username, string Password);

Add the corresponding Jwt:Key, Jwt:Issuer, and Jwt:Audience values to appsettings.json.

Step 8.3: Angular — Send the Token with SignalR

Update signalr.service.ts to pass the access token when building the connection:

this.hubConnection = new signalR.HubConnectionBuilder()
  .withUrl(`${environment.apiBaseUrl}/hubs/dashboard`, {
    accessTokenFactory: () => localStorage.getItem('authToken') || ''
  })
  .withAutomaticReconnect()
  .build();

Step 8.4: Add an Angular HTTP Interceptor for REST Calls

To attach the token to your regular REST API calls (like /api/metrics/snapshot), add an HttpInterceptorFn:

import { HttpInterceptorFn } from '@angular/common/http';

export const authInterceptor: HttpInterceptorFn = (req, next) => {
  const token = localStorage.getItem('authToken');
  const cloned = token
    ? req.clone({ setHeaders: { Authorization: `Bearer ${token}` } })
    : req;
  return next(cloned);
};

provideHttpClient(withInterceptors([authInterceptor]))

Step 8.5: Build a Minimal Login Component

Create a simple login form that calls /api/auth/login, stores the returned token in localStorage (or, for better security, a memory-based store with refresh tokens in an HttpOnly cookie for production-grade apps), and redirects to the dashboard route. Use an Angular route guard (CanActivateFn) to prevent unauthenticated access to the dashboard route.

Security note: Storing JWTs in localStorage is convenient but vulnerable to XSS attacks. For production systems handling sensitive data, consider using HttpOnly, Secure cookies combined with short-lived access tokens and a refresh token rotation strategy.

13. Part 9 (Advanced): Scaling SignalR with Redis Backplane

If you deploy your ASP.NET Core backend across multiple server instances (for load balancing or high availability), SignalR connections will be distributed across those instances. By default, a message broadcast from one server instance won't reach clients connected to a different instance. This is solved using a backplane.

Step 9.1: Install the Redis Backplane Package

dotnet add package Microsoft.AspNetCore.SignalR.StackExchangeRedis

Step 9.2: Configure It in Program.cs

builder.Services.AddSignalR()
    .AddStackExchangeRedis(builder.Configuration["Redis:ConnectionString"]!, options =>
    {
        options.Configuration.ChannelPrefix = StackExchange.Redis.RedisChannel.Literal("LiveDashboard");
    });

With this in place, when MetricBroadcastService calls Clients.All.SendAsync(...) on one server instance, Redis ensures the message is relayed to all other instances, which then forward it to their own connected clients. This makes your dashboard horizontally scalable.

Step 9.3: When Do You Need This?

For a single-instance deployment (most small to mid-size applications), you do not need a backplane. Only add this complexity once you're running multiple instances behind a load balancer — typically in higher-traffic production environments.

14. Part 10 (Advanced): Performance Optimization

Step 10.1: Throttle High-Frequency Updates

If your real data source produces updates faster than the UI needs to render them (e.g., hundreds of updates per second), avoid pushing every single update to clients. Instead, batch or throttle on the backend — for example, aggregate updates and broadcast at a fixed interval (every 500ms–1s) using a buffer, rather than sending on every change.

On the Angular side, you can also throttle using RxJS:

import { throttleTime } from 'rxjs/operators';

this.signalrService.metric$
  .pipe(throttleTime(300))
  .subscribe(metric => this.upsertMetric(metric));

Step 10.2: Use OnPush Change Detection

For dashboard components receiving frequent updates, switch to ChangeDetectionStrategy.OnPush to avoid unnecessary re-renders across the entire component tree:

@Component({
  selector: 'app-metric-card',
  changeDetection: ChangeDetectionStrategy.OnPush,
  ...
})

Combined with immutable data patterns (creating new objects/arrays rather than mutating existing ones, as we did in the chart component), OnPush significantly reduces CPU usage on busy dashboards.

Step 10.3: Limit Chart History

Capping chart data to a fixed window (we used maxPoints = 30 earlier) prevents memory growth and keeps rendering fast, especially important if the dashboard runs unattended for hours or days (e.g., on an office wall display).

Step 10.4: Use trackBy for *ngFor

When rendering lists of metric cards or charts, always use trackBy to prevent Angular from destroying and recreating DOM elements unnecessarily on every update:

<app-metric-card *ngFor="let metric of metrics; trackBy: trackByName" ... ></app-metric-card>

trackByName(index: number, metric: MetricData): string {
  return metric.metricName;
}

Step 10.5: Compress SignalR Messages (Advanced)

For very data-heavy dashboards, consider using MessagePack instead of the default JSON protocol for SignalR, which reduces payload size and improves throughput:

dotnet add package Microsoft.AspNetCore.SignalR.Protocols.MessagePack
npm install @microsoft/signalr-protocol-msgpack

Configure it on both server (AddSignalR().AddMessagePackProtocol()) and client (.withHubProtocol(new MessagePackHubProtocol())).

15. Part 11 (Advanced): Testing the Application

Step 11.1: Backend Unit Tests

Use xUnit to test your services in isolation. For example, test that DataGeneratorService.GenerateMetric returns values within the expected variance range:

[Fact]
public void GenerateMetric_ReturnsValueWithinVarianceRange()
{
    var service = new DataGeneratorService();
    var result = service.GenerateMetric("CPU", 50, 10);

    Assert.InRange(result.Value, 40, 60);
    Assert.Equal("CPU", result.MetricName);
}

Step 11.2: Integration Testing the Hub

ASP.NET Core supports integration testing using WebApplicationFactory combined with a real SignalR client connecting to an in-memory test server, allowing you to verify that messages broadcast from the hub are actually received by a connected client.

Step 11.3: Angular Unit Tests

Use Jasmine/Karma (or Jest, if configured) to test that MetricsService correctly upserts metrics:

it('should update existing metric value on new data', () => {
  service['upsertMetric']({ metricName: 'CPU', value: 55, timestamp: '2026-01-01T00:00:00Z' });
  service['upsertMetric']({ metricName: 'CPU', value: 70, timestamp: '2026-01-01T00:00:05Z' });

  service.metrics$.subscribe(metrics => {
    const cpu = metrics.find(m => m.metricName === 'CPU');
    expect(cpu?.value).toBe(70);
  });
});

Step 11.4: End-to-End Testing

Use Playwright or Cypress to verify the full flow: load the dashboard, confirm the initial snapshot renders, wait for a live update, and assert that displayed values change without a page reload.

16. Part 12 (Advanced): Deploying to Production

Step 16.1: Build the Angular App for Production

ng build --configuration production

This outputs static files to dist/live-dashboard-client, which can be served by any static file host or reverse proxy.

Step 16.2: Publish the ASP.NET Core Backend

dotnet publish -c Release -o ./publish

Step 16.3: Dockerize Both Applications

Backend Dockerfile:

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app/publish

FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app/publish .
EXPOSE 80
ENTRYPOINT ["dotnet", "LiveDashboard.Api.dll"]

Frontend Dockerfile (served via Nginx):

FROM node:20 AS build
WORKDIR /app
COPY . .
RUN npm install && npm run build -- --configuration production

FROM nginx:alpine
COPY --from=build /app/dist/live-dashboard-client /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf
EXPOSE 80

A minimal nginx.conf should include a WebSocket-friendly proxy configuration if Nginx also handles routing to the backend, ensuring Upgrade and Connection headers are forwarded correctly for SignalR's WebSocket transport.

Step 16.4: docker-compose for Local Orchestration

version: '3.8'
services:
  api:
    build: ./LiveDashboard.Api
    ports:
      - "5000:80"
    environment:
      - ASPNETCORE_ENVIRONMENT=Production

  client:
    build: ./live-dashboard-client
    ports:
      - "4200:80"
    depends_on:
      - api

Step 16.5: Deploying to Azure

For Azure App Service deployments, deploy the ASP.NET Core backend to an App Service (with WebSockets enabled in the Configuration settings — this is required for SignalR to function correctly) and the Angular frontend to Azure Static Web Apps or a separate App Service serving static files. If you expect multiple backend instances, enable Azure SignalR Service instead of self-hosting SignalR, which handles scaling and connection management for you and removes the need for a Redis backplane.

Step 16.6: Deploying to IIS

If deploying to IIS, ensure the WebSocket Protocol feature is enabled in Windows Server roles/features, and that the ASP.NET Core Module v2 is installed. Without WebSocket support enabled at the IIS/server level, SignalR will silently fall back to long polling, which still works but is less efficient.

Step 16.7: HTTPS and Security Headers

In production, always serve both frontend and backend over HTTPS — mixed content (HTTPS frontend calling an HTTP backend) will be blocked by browsers, and WebSocket connections (wss://) require a secure context when the page itself is loaded over HTTPS.

17. Common Errors and Troubleshooting

Error: "Failed to complete negotiation with the server"
Usually caused by CORS misconfiguration or the backend not running. Confirm AllowCredentials() is set and that the origin matches exactly (including protocol and port).

Error: SignalR connects but no data arrives
Double-check that the event name in hubConnection.on('ReceiveMetric', ...) exactly matches the string used in SendAsync("ReceiveMetric", ...) on the backend — these are case-sensitive string matches, not type-checked.

Error: Connection works locally but fails after deployment
Almost always a missing WebSocket configuration at the hosting/proxy layer (IIS, Nginx, or a load balancer not configured for WebSocket passthrough).

Charts not updating despite new data arriving
Verify you are creating new array/object references when updating chart data (as shown in Step 5.3) rather than mutating existing objects in place — Angular and Chart.js both rely on reference changes to detect updates efficiently.

401 Unauthorized when connecting to the hub after adding JWT auth
Confirm the accessTokenFactory is correctly returning a valid, non-expired token, and that the OnMessageReceived handler on the backend is scoped to the /hubs path.

18. Best Practices Checklist

Use SignalR for live updates; use REST only for the initial data snapshot.
Always implement .withAutomaticReconnect() and surface connection status in the UI.
Cap historical data arrays to avoid unbounded memory growth in long-running dashboard sessions.
Use OnPush change detection and trackBy for performance on data-heavy dashboards.
Secure both the REST API and the SignalR hub with [Authorize] once authentication is added.
Enable WebSockets explicitly on your hosting environment (IIS, Azure App Service, Nginx).
Use a Redis backplane or Azure SignalR Service only once you scale beyond a single backend instance.
Throttle extremely high-frequency data sources before broadcasting to clients.
Always test reconnection behavior by manually killing and restarting the backend during development.

19. Frequently Asked Questions (FAQ)

Q: Do I need SignalR, or can I just poll the API every few seconds?
Polling works for simple cases but is less efficient and introduces latency. SignalR provides true push-based real-time updates with lower overhead once a connection is established, making it the better choice for dashboards needing sub-second responsiveness.

Q: Can I use this approach with React or Vue instead of Angular?
Yes. The backend (ASP.NET Core + SignalR) is frontend-agnostic. Microsoft provides the same @microsoft/signalr JavaScript client that works with any frontend framework, not just Angular.

Q: What's the difference between SignalR and raw WebSockets?
SignalR is a higher-level abstraction built on top of WebSockets (with automatic fallback to other transports). It handles connection management, reconnection, and message serialization for you, whereas raw WebSockets require you to build all of that yourself.

Q: How do I handle dashboards with many different data types (not just numeric metrics)?
Use a more generic message envelope (e.g., a DashboardEvent with a type field and a polymorphic payload) instead of a single MetricData model, and route messages to different handlers/components based on type on the client side.

Q: Is SignalR suitable for very high-frequency data (thousands of updates per second)?
For extremely high-frequency data, consider batching updates on the server before broadcasting (as discussed in the performance section) rather than sending every single data point individually.

20. Conclusion

You've now built a complete, real-time live data dashboard from the ground up — starting with a simple ASP.NET Core Web API, layering in SignalR for true real-time push updates, building a reactive Angular frontend with live-updating charts, and progressing through advanced topics like authentication, scaling, performance optimization, and production deployment.

This architecture pattern — REST for initial state, SignalR for live updates, RxJS for reactive state management on the client — is a robust foundation you can extend to almost any real-time use case: IoT monitoring, financial dashboards, server health monitors, live order tracking, or collaborative applications.

From here, consider exploring related topics such as integrating a real database with Entity Framework Core instead of simulated data, adding role-based dashboards where different users see different metrics, or building alerting rules that trigger notifications when metric thresholds are crossed.

If you found this guide helpful, consider bookmarking it as a reference architecture for your next real-time Angular + ASP.NET Core project.

The Complete Guide to Types of Testing in Software Engineering

Ravi Vishwakarma — Sun, 07 Jun 2026 13:49:25 +0000

Software testing is primarily divided into two main categories:

Functional Testing, which verifies what the system does against business requirements
Non-Functional Testing, which evaluates how the system performs regarding usability, speed, and security.

These categories are executed across different stages, methods, and levels to ensure the final product is stable and reliable.

1. Functional Testing (The "What")

Functional testing focuses on the business requirements of an application, validating that every feature operates according to specified expectations.

Unit Testing: Checks individual blocks, methods, or functions of code in strict isolation.
Integration Testing: Verifies that different modules or units work together seamlessly when combined.
System Testing: Evaluates the complete, fully integrated software system as a whole to check overall business compliance.
Acceptance Testing (UAT): Conducted by clients or end-users to confirm if the application is ready for real-world deployment.
Regression Testing: Re-tests existing features after updates or code modifications to ensure no new bugs were introduced.
Smoke Testing: Runs rapid, high-level checks on core functionalities to verify if a build is stable enough for deeper testing.

2. Non-Functional Testing (The "How")

Non-functional testing evaluates the quality, technical behaviors, and operational readiness of the software rather than specific features.

Performance Testing: Measures system responsiveness, speed, and resource usage under normal and peak conditions.
Load Testing: Evaluates how the application behaves under a specific, expected volume of simultaneous users.
Stress Testing: Pushes the system past its normal performance capacity to find its breaking point.
Security Testing: Scans the application for internal or external vulnerabilities and cyber threats.
Usability Testing: Assesses user experience, interface layout, and overall user-friendliness.
Compatibility Testing: Verifies the software functions correctly across various operating systems, browsers, and devices.

3. Testing Approaches (The "Knowledge")

Software tests are also classified by how much visibility the tester has into the underlying programming code:

Black-Box Testing: Testing is done completely from the outside, with no knowledge of the internal code or logic structure.
White-Box Testing: Testing is executed with deep knowledge of the code, loops, data flows, and internal architectures.
Grey-Box Testing: A hybrid approach where the tester has limited or partial knowledge of the internal system backend.

4. Methods of Execution

Depending on the engineering team's goals and resources, the testing types above can be carried out through two primary execution methods:

Manual Testing: Human QA specialists manually interact with the user interface and tools to log unexpected defects.
Automated Testing: Writing scripts and utilizing testing frameworks to execute repetitive test suites with speed and precision.

Keep coding.

How to Implement SSE for Notifications in .NET in a Production-Ready Way?

Ravi Vishwakarma — Thu, 16 Apr 2026 02:43:20 +0000

This is not a demo – this is the same pattern used in real chat/notification systems (WhatsApp-like browser notifications, dashboards, etc.).

1. When to Use SSE (Production Decision)

Use SSE when:

One-way server → browser notifications
Chat message alerts (not full chat transport)
Live counters, alerts, status updates
Browser-based apps (no mobile socket requirement)

Do NOT use SSE for:

Binary streaming
High-frequency bidirectional chat typing events
Mobile background connections (WebSocket better)

2. Architecture (Production)

Browser (EventSource)
        ↓
SSE Controller (long-lived HTTP)
        ↓
ConcurrentDictionary<UserId, SseClient>
        ↓
Notification Publisher (Chat / Job / API)

Key rules:

One SSE connection per user
No DB polling
No blocking threads
Heartbeat required
Auto-reconnect handled by browser

3. Core SSE Infrastructure (IMPORTANT)

3.1 SSE Client Model

public class SseClient
{
    public int UserId { get; set; }
    public HttpResponse Response { get; set; }
    public DateTime ConnectedAt { get; set; }
}

3.2 SSE Connection Manager (Thread-Safe)

public static class SseConnectionManager
{
    private static readonly ConcurrentDictionary<int, SseClient> _clients
        = new ConcurrentDictionary<int, SseClient>();

    public static bool AddClient(int userId, HttpResponse response)
    {
        RemoveClient(userId); // ensure single tab policy (optional)
        return _clients.TryAdd(userId, new SseClient
        {
            UserId = userId,
            Response = response,
            ConnectedAt = DateTime.UtcNow
        });
    }

    public static void RemoveClient(int userId)
    {
        _clients.TryRemove(userId, out _);
    }

    public static bool SendToUser(int userId, string eventName, string data)
    {
        if (!_clients.TryGetValue(userId, out var client))
            return false;

        try
        {
            client.Response.Write($"event: {eventName}\n");
            client.Response.Write($"data: {data}\n\n");
            client.Response.Flush();
            return true;
        }
        catch
        {
            RemoveClient(userId);
            return false;
        }
    }

    public static void Broadcast(string eventName, string data)
    {
        foreach (var userId in _clients.Keys)
        {
            SendToUser(userId, eventName, data);
        }
    }
}

Thread-safe
Memory-safe
Handles broken connections

4. SSE Controller (Production-Safe)

public class SseController : Controller
{
    [HttpGet]
    public void Subscribe()
    {
        int userId = GetLoggedInUserId();

        Response.ContentType = "text/event-stream";
        Response.CacheControl = "no-cache";
        Response.BufferOutput = false;

        SseConnectionManager.AddClient(userId, Response);

        try
        {
            while (Response.IsClientConnected)
            {
                // Heartbeat every 15 sec
                Response.Write("event: ping\n");
                Response.Write("data: {}\n\n");
                Response.Flush();

                Thread.Sleep(15000);
            }
        }
        finally
        {
            SseConnectionManager.RemoveClient(userId);
        }
    }

    private int GetLoggedInUserId()
    {
        return int.Parse(User.Identity.Name);
    }
}

Why heartbeat?

Prevents proxy/load-balancer timeout
Detects dead connections

5. Sending Notifications (Chat / API / Jobs)

Example: Chat Message Notification

public class NotificationService
{
    public static void NotifyUser(int userId, object payload)
    {
        string json = Newtonsoft.Json.JsonConvert.SerializeObject(payload);
        SseConnectionManager.SendToUser(userId, "message", json);
    }
}

Usage:

NotificationService.NotifyUser(671496, new
{
    fromUserId = 655093,
    text = "Hello 👋",
    createdAt = DateTime.UtcNow
});

6. Browser Client (Production JS)

<script>
let source = new EventSource("/sse/subscribe");

source.addEventListener("message", function (e) {
    let data = JSON.parse(e.data);
    console.log("Message:", data);
});

source.addEventListener("ping", function () {
    console.log("heartbeat");
});

source.onerror = function () {
    console.log("SSE disconnected. Reconnecting...");
};
</script>

Auto-reconnect handled by browser
No polling
Low memory footprint

7. Multi-Tab Handling (WhatsApp-Like Behavior)

If same user opens multiple tabs, enforce single active tab:

public static bool AddClient(int userId, HttpResponse response)
{
    RemoveClient(userId); // kicks old tab
    return _clients.TryAdd(userId, new SseClient
    {
        UserId = userId,
        Response = response,
        ConnectedAt = DateTime.UtcNow
    });
}

Other tabs will automatically disconnect and can show popup:

“This account is active in another tab”

8. Production Hardening Checklist

IIS / Hosting

Disable response buffering
Increase request timeout
Enable keep-alive

Security

Auth-based user binding
No userId in query string
Rate-limit notification sends

Scalability

In-memory only → single server
Multi-server → use Redis Pub/Sub

9. Multi-Server (Redis) Architecture

Server A  ─┐
Server B  ─┼── Redis Pub/Sub ──► SSE Clients
Server C  ─┘

Each server:

Subscribes to Redis channel
Pushes events to connected users

10. Why Big Companies Use SSE

GitHub notifications
Slack web notifications
Trading dashboards
Monitoring systems

Lower cost than WebSockets

Works perfectly behind proxies

Auto-reconnect built-in

11. SSE vs WebSocket (Quick Decision)

Feature	SSE	WebSocket
Direction	Server → Client	Two-way
Complexity	Low	High
Scaling	Easy	Harder
Browser support	Excellent	Excellent
Chat notifications	Best	Overkill

Final Recommendation (For Your Chat App)

Use:

SSE → notifications, unread count, alerts
API → send message
Optional WebSocket → typing indicators only

EmailSpamChecker class for .NET Framework 4.7

Ravi Vishwakarma — Wed, 18 Jun 2025 16:53:15 +0000

Here’s a complete and reusable EmailSpamChecker class for .NET Framework 4.7, which performs:

Syntax validation
Blacklisted domain check
MX record verification (requires DnsClient NuGet)
Scoring logic for spam suspicion
Customizable domain block list

Step 1: Install DnsClient NuGet Package

From NuGet Package Manager Console:

Install-Package DnsClient

Step 2: EmailSpamChecker Class

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net.Mail;
using System.Text.RegularExpressions;
using DnsClient;

public class EmailSpamChecker
{
    private static readonly string[] _blacklistedDomains = new[]
    {
        "mailinator.com", "10minutemail.com", "guerrillamail.com",
        "tempmail.com", "desy.xyz", "yopmail.com", "trashmail.com"
    };

    private static readonly string[] _suspiciousTlds = new[]
    {
        ".xyz", ".tk", ".gq", ".ml", ".cf"
    };

    public class SpamCheckResult
    {
        public bool IsValid { get; set; }
        public int SpamScore { get; set; }
        public List<string> Issues { get; set; } = new List<string>();
    }

    public static SpamCheckResult CheckEmail(string email)
    {
        var result = new SpamCheckResult();

        // Check basic syntax
        if (!IsValidSyntax(email))
        {
            result.Issues.Add("Invalid email syntax.");
            result.SpamScore += 2;
            result.IsValid = false;
            return result;
        }

        string domain = email.Split('@')[1].ToLower();

        // Check blacklist
        if (_blacklistedDomains.Contains(domain))
        {
            result.Issues.Add("Domain is blacklisted.");
            result.SpamScore += 3;
        }

        // Check suspicious TLD
        if (_suspiciousTlds.Any(tld => domain.EndsWith(tld)))
        {
            result.Issues.Add("Suspicious top-level domain.");
            result.SpamScore += 1;
        }

        // Check if it looks random (e.g., xas21@abc.xyz)
        if (IsRandomLooking(email))
        {
            result.Issues.Add("Username looks auto-generated or random.");
            result.SpamScore += 1;
        }

        // Check MX record
        if (!HasValidMxRecord(domain))
        {
            result.Issues.Add("Domain has no MX record (may not receive emails).");
            result.SpamScore += 2;
        }

        result.IsValid = result.SpamScore < 3;
        return result;
    }

    private static bool IsValidSyntax(string email)
    {
        try
        {
            var addr = new MailAddress(email);
            return addr.Address == email;
        }
        catch
        {
            return false;
        }
    }

    private static bool HasValidMxRecord(string domain)
    {
        try
        {
            var lookup = new LookupClient();
            var result = lookup.Query(domain, QueryType.MX);
            return result.Answers.MxRecords().Any();
        }
        catch
        {
            return false;
        }
    }

    private static bool IsRandomLooking(string email)
    {
        string user = email.Split('@')[0];

        // Count digits and special chars
        int digitCount = user.Count(char.IsDigit);
        int symbolCount = user.Count(c => !char.IsLetterOrDigit(c));

        // Very short or too random
        return user.Length < 5 || digitCount + symbolCount > 4;
    }
}

Usage Example

string inputEmail = "xyz@desy.xyz";
var result = EmailSpamChecker.CheckEmail(inputEmail);

if (!result.IsValid)
{
    Console.WriteLine("Potential spam or invalid email:");
    foreach (var issue in result.Issues)
        Console.WriteLine($"- {issue}");
}
else
{
    Console.WriteLine("Email looks clean.");
}

Output Example

Potential spam or invalid email:

Domain is blacklisted.
Suspicious top-level domain.
Domain has no MX record (may not receive emails).

Thanks
Keep Coding.

Clean Architecture in .net application step by step

Ravi Vishwakarma — Sat, 12 Apr 2025 13:54:40 +0000

Clean Architecture is a software design philosophy introduced by Robert C. Martin (Uncle Bob). Its goal is to create systems that are:

Independent of frameworks
Testable
Independent of UI or database
Flexible and maintainable

Key Principles

Separation of Concerns: Each layer of the application has a specific responsibility and doesn't mix with others.
Dependency Rule: Code dependencies must point inward, from outer layers (UI, DB) to inner layers (Use Cases, Entities). Inner layers know nothing about the outer layers.
Inversion of Control: High-level policies (business rules) shouldn't depend on low-level details (DB, APIs). Instead, interfaces should be used to invert control.
Independence:
- Framework Independent: Can change from ASP.NET to another without affecting core logic.
- Database Independent: Can switch from SQL Server to MongoDB.
- UI Independent: Can change from Web to Mobile easily.

The Layers

Domain Layer (Entities)
- Contains core business rules
- Framework and UI agnostic
- Pure business objects (e.g., User, Order)
Application Layer (Use Cases)
- Contains application-specific logic
- Coordinates the flow of data
- Interfaces with repositories
- E.g., CreateUser, GetOrders
Interface Adapters Layer
- Adapts data between use cases and frameworks
- Includes Controllers, Gateways, ViewModels
- Implements interfaces from Application Layer
Frameworks & Drivers
- External tools and frameworks (e.g., ASP.NET Core, EF Core)
- Dependency injection and infrastructure
- Least stable and most replaceable

Flow of Control

UI (Controller) → Use Case → Domain Logic → Output/Result

Controllers receive the input (e.g., HTTP request)
Pass data to the Use Case
Use Case performs business logic using the Domain
Returns results (e.g., DTOs or ViewModels)

⚖️ Advantages

High Testability – Business logic can be tested without UI or DB.
Easy to Maintain – Changes in UI/DB won’t affect core logic.
Scalability– Modular design helps teams work independently.
Reusability– Domain and Use Cases are reusable in different apps.

⚠️ Common Mistakes

Violating the dependency rule (e.g., use case calling Entity Framework directly)
Mixing business logic with framework code
Skipping interfaces (tight coupling)

🧱 Project Structure

Solution: CleanArchitectureDemo.sln
Projects:
├── CleanArchitectureDemo.Domain // Entities
├── CleanArchitectureDemo.Application // Use Cases
├── CleanArchitectureDemo.Infrastructure // DB / Repositories
├── CleanArchitectureDemo.API // Web API (Controllers)

🔧 Create Projects

dotnet new sln -n CleanArchitectureDemo

dotnet new classlib -n CleanArchitectureDemo.Domain
dotnet new classlib -n CleanArchitectureDemo.Application
dotnet new classlib -n CleanArchitectureDemo.Infrastructure
dotnet new webapi   -n CleanArchitectureDemo.API

Add them to the solution:

dotnet sln add CleanArchitectureDemo.Domain
dotnet sln add CleanArchitectureDemo.Application
dotnet sln add CleanArchitectureDemo.Infrastructure
dotnet sln add CleanArchitectureDemo.API

Add project references:

dotnet add CleanArchitectureDemo.Application reference CleanArchitectureDemo.Domain
dotnet add CleanArchitectureDemo.Infrastructure reference CleanArchitectureDemo.Application
dotnet add CleanArchitectureDemo.API reference CleanArchitectureDemo.Application
dotnet add CleanArchitectureDemo.API reference CleanArchitectureDemo.Infrastructure

📁 Layer Implementations

1. Domain/Entities/User.cs

namespace CleanArchitectureDemo.Domain.Entities
{
    public class User
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public string Email { get; set; }
    }
}

2. Application/Interfaces/IUserRepository.cs

using CleanArchitectureDemo.Domain.Entities;
using System.Collections.Generic;

namespace CleanArchitectureDemo.Application.Interfaces
{
    public interface IUserRepository
    {
        IEnumerable<User> GetAll();
        User GetById(int id);
    }
}

3. Application/UseCases/UserService.cs

using CleanArchitectureDemo.Application.Interfaces;
using CleanArchitectureDemo.Domain.Entities;
using System.Collections.Generic;

namespace CleanArchitectureDemo.Application.UseCases
{
    public class UserService
    {
        private readonly IUserRepository _userRepository;

        public UserService(IUserRepository userRepository)
        {
            _userRepository = userRepository;
        }

        public IEnumerable<User> GetUsers() => _userRepository.GetAll();

        public User GetUser(int id) => _userRepository.GetById(id);
    }
}

4. Infrastructure/Repositories/InMemoryUserRepository.cs

using CleanArchitectureDemo.Application.Interfaces;
using CleanArchitectureDemo.Domain.Entities;
using System.Collections.Generic;
using System.Linq;

namespace CleanArchitectureDemo.Infrastructure.Repositories
{
    public class InMemoryUserRepository : IUserRepository
    {
        private readonly List<User> _users = new()
        {
            new User { Id = 1, Name = "Alice", Email = "alice@example.com" },
            new User { Id = 2, Name = "Bob", Email = "bob@example.com" }
        };

        public IEnumerable<User> GetAll() => _users;

        public User GetById(int id) => _users.FirstOrDefault(u => u.Id == id);
    }
}

5. API/Controllers/UserController.cs

using Microsoft.AspNetCore.Mvc;
using CleanArchitectureDemo.Application.UseCases;
using CleanArchitectureDemo.Domain.Entities;
using System.Collections.Generic;

namespace CleanArchitectureDemo.API.Controllers
{
    [ApiController]
    [Route("[controller]")]
    public class UserController : ControllerBase
    {
        private readonly UserService _userService;

        public UserController(UserService userService)
        {
            _userService = userService;
        }

        [HttpGet]
        public IEnumerable<User> Get() => _userService.GetUsers();

        [HttpGet("{id}")]
        public ActionResult<User> Get(int id)
        {
            var user = _userService.GetUser(id);
            if (user == null)
                return NotFound();
            return user;
        }
    }
}

6. API/Program.cs – Register Dependencies

using CleanArchitectureDemo.Application.Interfaces;
using CleanArchitectureDemo.Application.UseCases;
using CleanArchitectureDemo.Infrastructure.Repositories;

var builder = WebApplication.CreateBuilder(args);

// Dependency Injection
builder.Services.AddScoped<IUserRepository, InMemoryUserRepository>();
builder.Services.AddScoped<UserService>();

builder.Services.AddControllers();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

app.UseSwagger();
app.UseSwaggerUI();

app.MapControllers();
app.Run();

Thanks
Keep Coding.

Reduce the page execution time

Ravi Vishwakarma — Sun, 06 Apr 2025 18:32:50 +0000

Alright, you're aiming for top-notch Core Web Vitals — crisp, smooth, fast-loading webpages that make Lighthouse go “WOW” and Google rank you like royalty 👑. Let’s break down the best practices to write HTML, CSS, JS, fonts, etc. that give you green scores across all Web Vitals:

HTML: Keep it Clean, Semantic & Lightweight

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />
  <title>Your Awesome Page</title>

  <!-- Preconnects for performance -->
  <link rel="preconnect" href="https://fonts.googleapis.com" />
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />

  <!-- Inline Critical CSS -->
  <style>
    /* Only critical styles here (for above-the-fold content) */
    body {
      font-family: 'Inter', sans-serif;
      margin: 0;
      padding: 0;
      background: #fff;
      color: #333;
    }
    h1 {
      font-size: 2rem;
      text-align: center;
      margin-top: 2rem;
    }
  </style>

  <!-- Load fonts properly -->
  <link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap" rel="stylesheet" />

  <!-- Defer non-critical CSS -->
  <link rel="stylesheet" href="styles.css" media="print" onload="this.media='all'" />
  <noscript><link rel="stylesheet" href="styles.css" /></noscript>

  <!-- Important: Avoid large JS in <head> -->
</head>
<body>

  <h1>Hello, Web Vitals!</h1>
  <button id="btn">Click Me</button>

  <!-- Minimal Critical JS (inlined) -->
  <script>
    document.addEventListener('DOMContentLoaded', () => {
      document.getElementById('btn').addEventListener('click', () => {
        alert('Hi there!');
      });
    });
  </script>

  <!-- Async/defer all non-critical JS -->
  <script src="main.js" defer></script>
</body>
</html>

CSS: Optimize, Minify & Use Only What’s Needed

Extract Critical CSS and inline it (manually or with tools like critical)
Load the rest asynchronously (media="print" trick)
Avoid unused styles (Lighthouse can show you these)
Use :where() or :is() instead of long selector chains (faster parsing)

JavaScript: Split, Defer, and Delay

Inline only critical JS
Use defer for everything else
Use code splitting (in frameworks like React, Vue, etc.)
Avoid large JS bundles — aim for <150KB (gzipped) for initial load
Lazy-load expensive features like charts, sliders, chat widgets

Fonts: Load Fast and Avoid Layout Shifts

Use font-display: swap (default with Google Fonts)
Preconnect to fonts.googleapis.com and fonts.gstatic.com
Prefer system fonts for super-fast load (optional)

@import url('https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap');

OR use:

font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;

Images: Compress, Lazy Load, Responsive

<img src="banner.jpg" loading="lazy" alt="Banner" width="600" height="400" />

Use loading="lazy"
Add width and height attributes to prevent CLS (layout shift)
Prefer WebP or AVIF
Use srcsetfor responsive images if needed

Core Web Vitals Targets (What You’re Chasing)
Metric Goal
LCP (Largest Contentful Paint) < 2.5s
FID (First Input Delay) < 100ms
CLS (Cumulative Layout Shift) < 0.1
TTI (Time to Interactive) As fast as possible

Thank You,
Keep coding

Understanding Strong Password Regex in C#: From Basic to Advanced

Ravi Vishwakarma — Mon, 03 Feb 2025 13:09:57 +0000

Introduction

In today’s digital age, ensuring password security is a critical aspect of software development. One way to enforce security standards is by using regular expressions (Regex) to validate passwords. In this article, we will explore different levels of password complexity, ranging from basic to advanced, using C#.

1. Basic Password Validation

A basic password validation rule simply enforces a minimum length. The following Regex pattern ensures that a password is at least 8 characters long:

string basicRegex = "^.{8,}$";

Explanation:

^ and $ mark the start and end of the string.
.{8,} ensures the password has at least 8 characters of any type.

While this rule prevents extremely short passwords, it does not enforce complexity.

2. Intermediate Password Validation

To increase security, we can require passwords to contain at least one letter and one digit:

string intermediateRegex = "^(?=.*[A-Za-z])(?=.*\d)[A-Za-z\d]{8,}$";

Explanation:

(?=.*[A-Za-z]) ensures at least one letter (uppercase or lowercase).
(?=.*\d) ensures at least one digit.
[A-Za-z\d]{8,} allows only letters and digits, with a minimum of 8 characters.

This regex prevents purely numeric or alphabetical passwords but still lacks special character enforcement.

3. Advanced Password Validation (Strong Passwords)

A strong password should meet the following criteria:

At least 8 characters long.
Contains at least one lowercase letter.
Contains at least one uppercase letter.
Contains at least one digit.
Contains at least one special character from a predefined set (e.g., @$!%*?&).

Regex for Strong Passwords:

string advancedRegex = "^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[@$!%*?&])[A-Za-z\d@$!%*?&]{8,}$";

string extendedAdvancedRegex = "^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[@$!%*?&^#()[\]{}|\\/\-+_.:;=,~`])[^\s<>]{8,}$";

Explanation:

(?=.*[a-z]) ensures at least one lowercase letter.
(?=.*[A-Z]) ensures at least one uppercase letter.
(?=.*\d) ensures at least one digit.
(?=.*[@$!%*?&]) ensures at least one special character.
(?=.*[@$!%*?&^#()[\]{}|\\/\-+_.:;=,~]) ensures at least one special character from an extended set.
[^\s<>]{8,} ensures a minimum length of 8 characters while restricting whitespace and certain unsafe characters.

This pattern significantly enhances password security and meets most modern security standards.

4. Implementing Password Validation in C#

Below is a simple C# program that validates passwords using Regex:

using System;
using System.Text.RegularExpressions;

public class PasswordValidator
{
    public static bool IsValidPassword(string password, string pattern)
    {
        return Regex.IsMatch(password, pattern);
    }

    public static void Main()
    {
        string password = "StrongP@ss1";

        // Use one of the regex patterns defined above
        string pattern = "^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[@$!%*?&^#()[\]{}|\\/\-+_.:;=,~`])[^\s<>]{8,}$";

        if (IsValidPassword(password, pattern))
            Console.WriteLine("Password is valid!");
        else
            Console.WriteLine("Password does not meet the requirements.");
    }
}

Conclusion

Implementing password validation using Regex in C# ensures strong security policies for user authentication. By progressively enforcing length, character variety, and complexity, we can significantly reduce vulnerabilities related to weak passwords.

For enterprise-level applications, additional security measures such as multi-factor authentication (MFA) and rate-limiting login attempts should also be implemented alongside Regex-based password validation.

Connect with Me!
Thanks for reading! If you found this helpful, consider following me for more content like this.

🌟 LinkedIn
💻 GitHub

Your support motivates me to keep sharing valuable insights. Stay tuned for more! 🚀

Thanks for Reading.

AddMVC() vs AddControllersWithViews() vs AddControllers() vs AddRazorPages() | ASP.Net Core

Ravi Vishwakarma — Tue, 28 Jan 2025 02:42:18 +0000

In ASP.NET Core, the methods AddMvc(), AddControllersWithViews(), AddControllers(), and AddRazorPages() are used to configure services for various application architectures. Each of these methods serves a specific purpose depending on the type of application you are building.

AddMvc()

Purpose: Configures the app to use the complete ASP.NET Core MVC framework, including support for controllers, views, Razor Pages, and API features.

Status: This method is obsolete in recent ASP.NET Core versions (3.0 and later). It's replaced by more granular methods like AddControllersWithViews() or AddRazorPages().

Use Case: Used in older versions (before ASP.NET Core 3.0) to set up both MVC and Razor Pages in a single step.

AddControllersWithViews()

Purpose: Configures the app to support controllers and views (for MVC-style web apps). Does not include Razor Pages.

Use Case: Ideal for traditional MVC web applications where controllers and views are the primary focus.
Suitable for server-rendered HTML with routing, model binding, and validation.
Features: Adds support for controllers and views.
Does not support Razor Pages (e.g., .cshtml files under the /Pages folder).

Example:

builder.Services.AddControllersWithViews();

AddControllers()

Purpose: Configures the app to support controllers only, for building API applications without views.

Use Case: Suitable for building Web APIs. Does not include Razor Pages or support for views.
Features: Adds support for controllers, but excludes Razor Pages and views. Focused on API endpoints, ideal for RESTful services.

Example:

builder.Services.AddControllers();

AddRazorPages()

Purpose: Configures the app to support Razor Pages, a page-focused programming model.

Use Case: Ideal for applications primarily using Razor Pages for server-side rendering. Suitable for smaller apps or apps with a page-oriented architecture (e.g., intranet applications).

Features:
Supports Razor Pages (e.g., .cshtml files under the /Pages folder).
Does not support controllers or views unless explicitly added.

Example:

builder.Services.AddRazorPages();

.NET Core Middleware Comparison Table

Method	Controllers	Views	Razor Pages	APIs (JSON/XML responses)
AddMvc()	✅	✅	✅	✅
AddControllersWithViews()	✅	✅	❌	✅
AddControllers()	✅	❌	❌	✅
AddRazorPages()	❌	❌	✅	❌

Choosing the Right Method

For APIs:

Use AddControllers().
Example: Building a RESTful API that does not require views or Razor Pages.

For Traditional MVC Applications:

Use AddControllersWithViews().
Example: Building a web app with controllers and views for server-side rendering.

For Razor Pages Applications:

Use AddRazorPages().
Example: Building a simple page-oriented application with .cshtml files under /Pages.

For Hybrid Scenarios:

Combine AddControllersWithViews() and AddRazorPages() for apps that need both controllers and Razor Pages.

builder.Services.AddControllersWithViews();
builder.Services.AddRazorPages();

Best Practices

Use specific configurations (e.g., AddControllersWithViews(), AddRazorPages()) instead of AddMvc() for better clarity and performance.
Choose the appropriate method based on your application's architecture and the required features.
If your app includes API endpoints and views, combine AddControllersWithViews() with features like JsonOptions to configure API behavior.

Connect with Me!
Thanks for reading! If you found this helpful, consider following me for more content like this.

🌟 LinkedIn
💻 GitHub

Your support motivates me to keep sharing valuable insights. Stay tuned for more! 🚀

Thanks for Reading.

Comprehensive Guide to Documentation Comments in C#

Ravi Vishwakarma — Sun, 19 Jan 2025 11:20:09 +0000

Documentation comments in C# are structured comments that describe code functionality and are processed by tools like Visual Studio and Sandcastle to generate user-friendly documentation. These comments are written in XML format and placed above code elements like classes, methods, properties, and fields.

Syntax for Documentation Comments in C#
In C#, documentation comments start with three slashes (///) and support XML-based tags to provide detailed descriptions.

Example

/// <summary>
/// Represents a basic calculator for arithmetic operations.
/// </summary>
public class Calculator
{
    // Class implementation
}

Common XML Tags in C#
Here are the most commonly used XML tags in C# documentation comments:

General Tags

<summary>: Provides a brief summary of a class, method, or property.
<remarks>: Adds additional or detailed remarks about the element.
<example>: Contains code examples to demonstrate usage.
<value>: Describes the value returned by a property.
<inheritdoc>: Inherits documentation from the base class or interface.

Method-Specific Tags

<param>: Describes a method parameter.
<returns>: Documents the return value of a method.
<exception>: Describes exceptions thrown by the method.

Cross-Referencing Tags

<see>: Links to another code element for inline reference.
<seealso>: Refers to related code elements for more information.
<c>: Embeds inline code.
<code>: Displays a block of code in the documentation.

Examples of Documentation Comments in C#

Documenting a Class

/// <summary>
/// Performs basic arithmetic operations such as addition and subtraction.
/// </summary>
/// <remarks>
/// This class is intended for demonstration purposes only.
/// </remarks>
public class Calculator
{
    // Class implementation
}

Documenting a Method

/// <summary>
/// Adds two integers and returns the result.
/// </summary>
/// <param name="a">The first integer.</param>
/// <param name="b">The second integer.</param>
/// <returns>The sum of the two integers.</returns>
/// <exception cref="ArgumentNullException">Thrown if a or b is null.</exception>
public int Add(int a, int b)
{
    if (a == null || b == null)
    {
        throw new ArgumentNullException("Parameters cannot be null.");
    }
    return a + b;
}

Documenting a Property

/// <summary>
/// Gets or sets the name of the calculator's manufacturer.
/// </summary>
/// <value>
/// A string representing the manufacturer's name.
/// </value>
public string Manufacturer { get; set; }

Documenting an Example

/// <example>
/// <code>
/// Calculator calc = new Calculator();
/// int result = calc.Add(5, 10);
/// Console.WriteLine(result); // Output: 15
/// </code>
/// </example>
public int Add(int a, int b)
{
    return a + b;
}

Best Practices for Documentation Comments in C#

Write Clear Summaries: Use to describe the purpose of a code element in a concise and meaningful way.
Use and Tags Appropriately: Ensure all method parameters and return values are documented.
Provide Examples: Use tags to demonstrate usage, especially for complex methods.
Link to Related Elements: Utilize and to refer readers to related parts of the codebase.
Maintain Consistency: Follow consistent formatting and style for all documentation comments.
Update Regularly: Sync documentation comments with code changes to prevent inaccuracies.

For more go to Microsoft Documentation

Thanks for reading.

Global Class Validator for Enhanced Object Validation in EMS

Ravi Vishwakarma — Sun, 19 Jan 2025 10:01:25 +0000

Introducing Global Class Validator: Streamlined Object Validation for Employee Management Systems

Validation is a critical aspect of any application that handles structured data. To ensure accuracy, consistency, and compliance with business logic, validation must be seamless and reliable.

Our Global Class Validator is a powerful utility tailored for .NET applications, particularly useful in systems like the Employee Management System. It simplifies object validation by leveraging .NET’s built-in ValidationAttributeand ensures that your data meets defined standards effortlessly.

Key Features

Thread-Safe Error Tracking: Errors are captured and stored in a thread-safe manner, ensuring accurate results even in multi-threaded environments.
Dynamic Property Validation: The validator dynamically inspects all public properties of an object and applies the associated ValidationAttributeto validate their values.
Comprehensive Error Handling: The tool provides methods to retrieve errors in multiple formats:

GetErrors: Returns a collection of validation errors for detailed inspection.
GetErrorsString: Provides a string-formatted summary of all validation errors.

4.Ease of Use: Add a simple IsValidmethod to your model, and the validator will handle everything from validation checks to error aggregation.

Sample Usage

using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Microsoft.VisualBasic;

namespace Employee_Management_System
{
    internal class EmployeeModel
    {
        public EmployeeModel() { }

        [Required]
        [Range(0, uint.MaxValue)]
        public int EmployeeID { get; set; }

        [Required]
        [StringLength(100, MinimumLength = 2)]
        public string Name { get; set; }

        [Required]
        public string Designation { get; set; }

        [Required]
        public string Department { get; set; }

        [Required]
        [RegularExpression(@"^([\w\.\-]+)@([\w\-]+)((\.(\w){2,3})+)$", ErrorMessage = "Please enter valid EmailID. ")]
        public string Email { get; set; }

        [Required]
        [RegularExpression(@"^\d{8,}$", ErrorMessage = "Please enter valid PhoneNumber. ")]
        public string Phone { get; set; }

        [Required]
        public DateTime JoiningDate { get; set; }

        public EmployeeModel(int employeeID, string name, string designation, string department, string email, string phone, DateTime joiningDate)
        {
            EmployeeID = employeeID;
            Name = name;
            Designation = designation;
            Department = department;
            Email = email;
            Phone = phone;
            JoiningDate = joiningDate;
        }
    }
}

Here’s how you can integrate and use the Global Class Validator in your .NET projects:

var employee = new EmployeeModel { Name = "", Email = "develop" }; // Example model with errors  

bool IsValid = ClassModelValidator<EmployeeModel>.IsValid(employee);

if (!IsValid)
{
     MessageBox.Show( ClassModelValidator<EmployeeModel>.GetErrorsString(), "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
}

Code Implementation

Below is the full implementation of the GlobalClassValidator class for your reference:

using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.Linq;
using System.Reflection;
using System.Runtime.CompilerServices;
using System.Security.Policy;
using System.Text;
using System.Threading.Tasks;

namespace Employee_Management_System.Helper
{
    public static class ClassModelValidator<T> where T : class
    {
        // Errors list for tracking validation issues
        [ThreadStatic]
        private static List<string> Errors;

        static ClassModelValidator()
        {
            Errors = new List<string>();
        }



        public static bool IsValid(T model)
        {
            if (model == null)
            {
                AddError("Model cannot be null.");
                return false;
            }

            Errors.Clear();

            foreach (var property in typeof(T).GetProperties(BindingFlags.Public | BindingFlags.Instance))
            {
                var value = property.GetValue(model);
                foreach (var attribute in property.GetCustomAttributes<ValidationAttribute>())
                {
                    if (!attribute.IsValid(value))
                    {
                        AddError(attribute.FormatErrorMessage(property.Name));
                    }
                }
            }

            return Errors.Count == 0;
        }

        public static IEnumerable<string> GetErrors()
        {
            return Errors;
        }

        public static string GetErrorsString()
        {
            return string.Join(Environment.NewLine, Errors);
        }

        private static void AddError(string error)
        {
            if (!string.IsNullOrEmpty(error))
            {
                Errors.Add(error);
            }
        }
    }
}

Benefits of Using Global Class Validator

Enhances data integrity with minimal overhead.
Reduces boilerplate code by utilizing reflection and attributes.
Easily extensible for specific validation requirements.

With the Global Class Validator, you can ensure that your Employee Management System is robust, efficient, and error-free.

Feel free to integrate this utility into your projects and let us know how it transforms your validation processes!

Thanks for Reading!

For more details, visit:
🔗 Employee Management System on GitHub

Direct link to the code:
🔗 ClassModelValidator.cs

Feel free to explore the repository and contribute! 🚀

Generate SEO-Friendly Slugs from Titles in ASP.NET Core

Ravi Vishwakarma — Sun, 05 Jan 2025 09:50:55 +0000

To create shorter, user-friendly, or "slugged" URLs with Latin-based names, you can use URL slugging. This process typically involves converting strings (like page titles or names) into lowercase, replacing spaces and special characters with hyphens or other valid URL characters, and ensuring the resulting URL is unique and human-readable.

Example: Generating Latin Name Slugs for URLs in ASP.NET Core

Create a Utility Method for Slug Generation

A utility method can convert any string into a slug-friendly format.

using System.Text;
using System.Text.RegularExpressions;
public static class UrlSlugger
{
    public static string GenerateSlug(string input)
    {
        if (string.IsNullOrEmpty(input))
            return string.Empty;

        // Convert to lowercase
        input = input.ToLowerInvariant();

        // Remove diacritics (accents) from Latin characters
        input = RemoveDiacritics(input);

        // Replace spaces and invalid characters with hyphens
        input = Regex.Replace(input, @"[^a-z0-9\s-]", ""); // Allow only alphanumeric, spaces, and hyphens
        input = Regex.Replace(input, @"\s+", "-").Trim();  // Replace spaces with hyphens
        input = Regex.Replace(input, @"-+", "-");         // Replace multiple hyphens with a single one

        return input;
    }

    private static string RemoveDiacritics(string text)
    {
        var normalizedString = text.Normalize(NormalizationForm.FormD);
        var stringBuilder = new StringBuilder();

        foreach (var c in normalizedString)
        {
            var unicodeCategory = System.Globalization.CharUnicodeInfo.GetUnicodeCategory(c);
            if (unicodeCategory != System.Globalization.UnicodeCategory.NonSpacingMark)
            {
                stringBuilder.Append(c);
            }
        }

        return stringBuilder.ToString().Normalize(NormalizationForm.FormC);
    }
}

Using the Slug Generator in Your Application

You can use this slug generator for URLs when defining routes or generating links dynamically.

Example in Controller:

public IActionResult GenerateSluggedUrl(string title)
{
    string slug = UrlSlugger.GenerateSlug(title);
    return Ok($"Generated slug: {slug}");
}

Example Usage:
For a title like "Éxample Title for URL!", the slug will be:

example-title-for-url

Integrating Slugs in Routing

To use slugs in your routing, you can define a route pattern with a {slug} parameter and parse the slug dynamically.

Example in Program.cs:

app.UseEndpoints(endpoints =>
{
    endpoints.MapControllerRoute(
        name: "sluggedRoute",
        pattern: "page/{slug}",
        defaults: new { controller = "Page", action = "Details" });

    // Default route
    endpoints.MapControllerRoute(
        name: "default",
        pattern: "{controller=Home}/{action=Index}/{id?}");
});

Example in PageController:

public class PageController : Controller
{
    public IActionResult Details(string slug)
    {
        // Retrieve the page data by the slug
        return View(model: $"Page with slug: {slug}");
    }
}

Testing Slugged URLs

Example URLs:
/page/example-title-for-url
/page/sample-page-title
Result:
You can use the slug parameter in the controller to load content based on the slug (e.g., querying the database for matching pages).

Additional Tips

Ensure slugs are unique for your content. Add a database field to store slugs and validate uniqueness.
Store slugs in your database alongside the corresponding entity (e.g., articles, pages, or products).
Use slugs in links to improve SEO and user experience.

Thanks

DEV Community: Ravi Vishwakarma

Why HTTP Needed the QUERY Method

HTTP Finally Gets a New Request Method: Meet QUERY

The Problem with GET

Why Developers Used POST

Enter QUERY

Key Characteristics

GET vs POST vs QUERY

Real-World Use Cases

Will It Replace POST?

What This Means for API Designers

Final Thoughts

Building a Live Data Dashboard with Angular and ASP.NET Core: A Complete Step-by-Step Guide (Beginner to Advanced)

Table of Contents

1. Introduction

2. What You Will Build

3. Prerequisites

Software Requirements

Knowledge Requirements

4. Understanding the Architecture

5. Part 1 (Beginner): Setting Up the ASP.NET Core Backend

Step 1.1: Create the Web API Project

Step 1.2: Project Structure

Step 1.3: Define the Data Model

Step 1.4: Create a Simulated Data Service

Step 1.5: Create a Basic REST Endpoint

Step 1.6: Enable CORS

Step 1.7: Run and Verify

6. Part 2 (Beginner): Adding SignalR for Real-Time Communication

Step 2.1: What Is SignalR?

Step 2.2: Create the Hub

Step 2.3: Register SignalR in Program.cs

Step 2.4: Create a Background Service to Push Live Data

Step 2.5: Verify with a Test Client (Optional)

7. Part 3 (Beginner): Setting Up the Angular Frontend

Step 3.1: Create the Angular Project

Step 3.2: Install the SignalR Client Library

Step 3.3: Install a Charting Library

Step 3.4: Project Structure

Step 3.5: Define the Metric Model

8. Part 4 (Intermediate): Connecting Angular to SignalR

Step 4.1: Build the SignalR Service

Step 4.2: Create the Environment Configuration

Step 4.3: Build the Metrics Service

Step 4.4: Enable HttpClient

Step 4.5: Initialize the Connection in the Dashboard Component

9. Part 5 (Intermediate): Building the Dashboard UI with Live Charts

Step 5.1: Basic Metric Cards (Numbers View)

Step 5.2: Setting Up ng2-charts

Step 5.3: Create a Live Chart Component

Step 5.4: Wire the Chart into the Dashboard

Step 5.5: Alternative — Using ngx-charts (Advanced Option)

10. Part 6 (Intermediate): Styling the Dashboard

Step 6.1: Grid Layout

Step 6.2: Card Styling

Step 6.3: Visual Feedback on Update

11. Part 7 (Advanced): Handling Reconnection and Error States

Step 7.1: Expose Connection State

Step 7.2: Display a Connection Banner

Step 7.3: Handle Manual Reconnection

Step 7.4: Graceful Degradation

12. Part 8 (Advanced): Adding Authentication with JWT

Step 8.1: Backend — Add JWT Authentication

Step 8.2: Create a Simple Login Endpoint (for demo purposes)

Step 8.3: Angular — Send the Token with SignalR

Step 8.4: Add an Angular HTTP Interceptor for REST Calls

Step 8.5: Build a Minimal Login Component

13. Part 9 (Advanced): Scaling SignalR with Redis Backplane

Step 9.1: Install the Redis Backplane Package

Step 9.2: Configure It in Program.cs

Step 9.3: When Do You Need This?

14. Part 10 (Advanced): Performance Optimization

Step 10.1: Throttle High-Frequency Updates

Step 10.2: Use OnPush Change Detection

Step 10.3: Limit Chart History

Step 10.4: Use trackBy for *ngFor

Step 10.5: Compress SignalR Messages (Advanced)

15. Part 11 (Advanced): Testing the Application

Step 11.1: Backend Unit Tests

Step 11.2: Integration Testing the Hub

HTTP Finally Gets a New Request Method: Meet `QUERY`

Enter `QUERY`