DEV Community: Ravi Vishwakarma

How Do You Delete Billions of WhatsApp Statuses Every Day Without Bringing Your Database to Its Knees?

Ravi Vishwakarma — Sat, 22 Aug 2026 17:55:29 +0000

Imagine you run a messaging app used by billions of people.

Every day, people upload photos, videos, and text as Status updates. But there is one important rule: a Status should disappear after about 24 hours.

Now imagine you have to clean up billions of expired Statuses every day.

Your first thought might be:

“Easy. Just run a query that deletes everything older than 24 hours.”

Something like:

DELETE FROM statuses
WHERE expires_at < NOW();

Simple, right?

Unfortunately, at WhatsApp's scale, this can be a terrible idea.

A giant delete can put enormous pressure on the database, causing slow queries, high disk usage, replication delays, locks, and even outages.

So how do large systems actually approach this problem?

Let's understand it from the ground up.

1. First: What Is a WhatsApp Status?

A Status is basically a temporary piece of content.

For example:

Alice posts a photo at 10:00 AM.
Bob posts a video at 2:00 PM.
Carol posts some text at 8:00 PM.

After roughly 24 hours, these Statuses are no longer supposed to be visible.

From a database perspective, you might store something like:

status_id	user_id	content	created_at	expires_at
101	Alice	photo.jpg	10:00	10:00 next day
102	Bob	video.mp4	14:00	14:00 next day
103	Carol	"Hello!"	20:00	20:00 next day

The database now has a simple job:

Find expired records and remove them.

But there's a catch.

At massive scale, there can be an enormous number of expired records.

2. Why Can't We Just Delete Everything at Once?

Suppose there are 1 billion expired records.

You might write:

DELETE FROM statuses
WHERE expires_at < NOW();

The database now has to find and delete a huge number of rows.

That can cause several problems.

Problem #1: Huge amount of work

Deleting a row isn't always as simple as removing a line from a file.

The database may need to:

Locate the row.
Modify indexes.
Write transaction information.
Update storage structures.
Replicate the changes.
Eventually reclaim the space.

Multiply that by billions.

That's a lot of work.

3. The Database Has Other Jobs Too

This is perhaps the most important idea for beginners.

Your database isn't sitting around waiting for the cleanup job.

While the cleanup system is deleting old Statuses, users are still:

uploading new Statuses,
viewing Statuses,
sending messages,
opening chats,
checking contacts.

The database needs to handle those requests too.

Think of a restaurant.

Imagine a restaurant has one kitchen.

During dinner, hundreds of customers are ordering food.

Now someone says:

“Before serving any more customers, let's completely clean the kitchen.”

The kitchen might become extremely busy cleaning instead of cooking.

A massive database deletion can create a similar problem.

4. The Basic Solution: Delete in Small Batches

Instead of deleting one billion rows in one operation, divide the work into small pieces.

For example:

DELETE FROM statuses
WHERE expires_at < NOW()
LIMIT 10,000;

Then repeat.

Conceptually:

Delete 10,000
       ↓
Delete 10,000
       ↓
Delete 10,000
       ↓
Delete 10,000
       ↓
...

Now the database gets many small jobs instead of one enormous job.

This is called batch deletion.

5. Why Batches Are Better

Suppose you need to remove 100 million records.

Instead of:

100,000,000 rows
       ↓
ONE MASSIVE DELETE
       ↓
Database suffers

you could do:

10,000 rows
10,000 rows
10,000 rows
10,000 rows
...

Each transaction is relatively small.

That means:

transactions finish faster,
locks are held for less time,
memory pressure is lower,
replication can keep up more easily,
other queries get opportunities to run.

The goal isn't merely to delete data.

The goal is to delete data without disturbing the rest of the system.

6. But There's Another Problem

You might now say:

“Fine. We'll delete 10,000 rows at a time.”

But how do we find those 10,000 expired rows?

Suppose the table looks like this:

statuses
--------------------------------
id
user_id
content
created_at
expires_at

If expires_at isn't indexed, the database may have to scan a huge portion of the table to discover which rows are expired.

That's expensive.

So we usually want an index.

For example:

CREATE INDEX idx_status_expiry
ON statuses(expires_at);

Now the database can efficiently find records whose expiration time has passed.

Think of an index like the index at the back of a textbook.

Without the index, you might have to read every page to find a topic.

With the index, you can jump closer to where the information lives.

7. Don't Delete Randomly — Delete in Order

There's another optimization.

Suppose expired records have IDs:

Instead of repeatedly asking:

“Give me any 10,000 expired rows.”

we can process them in a predictable order.

For example:

DELETE FROM statuses
WHERE expires_at < NOW()
ORDER BY expires_at
LIMIT 10,000;

Or, in some database designs, we can use an ID/cursor-based approach.

Conceptually:

Start at record 0
       ↓
Process 10,000
       ↓
Remember where we stopped
       ↓
Process the next 10,000
       ↓
Repeat

This is often called cursor-based processing or keyset pagination.

8. The Secret Weapon: Don't Wake Up Every Millisecond

Here's another beginner mistake.

You might create a worker that constantly asks:

"Anything expired?"
"Anything expired?"
"Anything expired?"
"Anything expired?"
...

That's unnecessary.

Instead, a cleanup system can work on a schedule.

For example:

12:00 → clean expired data
12:01 → clean expired data
12:02 → clean expired data
...

Or it can continuously process a queue at a controlled rate.

The important concept is backpressure.

9. What Is Backpressure?

Backpressure simply means:

Slow down when the database is under heavy load.

Imagine your cleanup worker can delete 100,000 records per second.

But the database is already extremely busy.

Instead of saying:

“I must delete 100,000 per second!”

the cleanup system can say:

“The database is busy. I'll reduce my deletion rate.”

For example:

Database healthy
→ delete faster

Database busy
→ delete slower

Database overloaded
→ pause cleanup temporarily

This is extremely useful in large distributed systems.

Cleanup is important.

But serving users is usually more important.

10. Even Better: Use a Queue

Instead of having one giant cleanup process constantly scanning the database, you can use a queue.

Imagine every Status gets an expiration event.

When Alice creates a Status:

Alice creates Status
        ↓
Status expires in 24 hours
        ↓
Create expiration task
        ↓
Queue

Later:

Queue
 ↓
Worker
 ↓
Delete Status

You can have many workers processing the queue.

For example:

                 ┌── Worker 1
Queue ───────────┼── Worker 2
                 ├── Worker 3
                 └── Worker 4

Now cleanup can scale horizontally.

Need more capacity?

Add more workers.

Need less capacity?

Remove workers.

11. But What If a Worker Crashes?

Distributed systems assume something will eventually fail.

A worker might crash halfway through its work.

That's why cleanup jobs should generally be idempotent.

Don't worry about the fancy word.

It basically means:

Running the same cleanup operation again should not cause a disaster.

For example:

Delete Status 123

If Status 123 is already gone, trying to delete it again shouldn't break the system.

This makes retries much safer.

12. A Very Important Idea: Soft Delete vs Hard Delete

There are actually two different meanings of "delete."

Soft delete

Instead of physically removing the row, mark it as deleted:

deleted = true

The application simply ignores deleted records.

Hard delete

Actually remove the database record.

For example:

DELETE FROM statuses
WHERE id = 123;

Large systems may sometimes use a combination of both approaches.

For example:

Status expires
      ↓
Immediately stop showing it
      ↓
Physical cleanup happens later

This is useful because the user-facing requirement is:

“Don't show expired content.”

It doesn't necessarily mean:

“The physical database bytes must disappear at exactly 24:00:00.”

Those are two different requirements.

13. This Difference Is Huge

Suppose a Status expires at:

10:00:00

The application can immediately treat it as unavailable:

expires_at <= current_time

So the user can't see it anymore.

The physical deletion might happen at:

depending on system load.

That's often perfectly acceptable.

This gives the cleanup system flexibility.

14. What About Photos and Videos?

There's another important detail.

The database might not actually contain the entire photo or video.

A database record might simply contain metadata:

status_id
user_id
storage_location
created_at
expires_at

The actual video could live in an object-storage system.

So deleting a Status may involve multiple steps:

Database record
      +
Media object
      +
Caches
      +
Indexes
      +
Metadata

You need to make sure all of these eventually get cleaned up.

15. Don't Delete Everything at the Exact Expiration Time

Here's a subtle but important design idea.

Imagine 100 million people uploaded Statuses between 10:00 AM and 10:01 AM.

Twenty-four hours later, a huge number of objects become eligible for deletion at roughly the same time.

If your system tries to delete all of them immediately, you get a thundering herd.

Instead, you can spread the cleanup work out.

For example:

10:00 → 100,000 deletions
10:01 → 100,000 deletions
10:02 → 100,000 deletions
...

The work is distributed over time.

This makes the system much smoother.

16. Partitioning Can Help Too

At very large scale, a single enormous table can become difficult to manage.

One technique is partitioning.

Imagine splitting Status data by time:

statuses_2026_08_20
statuses_2026_08_21
statuses_2026_08_22
statuses_2026_08_23

Now old data is grouped together.

Instead of deleting billions of individual rows one by one, a database may be able to remove or detach an entire old partition.

Conceptually:

Old partition
      ↓
No longer needed
      ↓
Drop partition
      ↓
Large amount of data removed efficiently

This can be dramatically cheaper than row-by-row deletion, depending on the database architecture.

However, partitioning isn't a magic solution. It has its own design and operational trade-offs.

17. A Realistic Architecture

A simplified large-scale design might look like this:

              User creates Status
                       │
                       ▼
                 Status Service
                       │
             ┌─────────┴─────────┐
             ▼                   ▼
        Database             Media Storage
             │
             ▼
      Expiration Scheduler
             │
             ▼
       Cleanup Queue
             │
       ┌─────┼─────┐
       ▼     ▼     ▼
    Worker Worker Worker
       │     │     │
       └─────┼─────┘
             ▼
        Batch Delete

The key idea is that expiration and physical deletion are separate concerns.

18. What Happens If the Database Is Overloaded?

A good cleanup system should be able to say:

“Not now.”

For example:

Cleanup worker
      ↓
Check database health
      ↓
Is database overloaded?
   /          \
 Yes           No
  ↓             ↓
Slow down    Continue
or pause     deleting

This is a crucial production principle:

Background work should be a good citizen.

User-facing traffic gets priority.

Cleanup can wait.

19. Monitoring Is Just as Important

You don't want to build the cleanup system and forget about it.

You need metrics.

For example:

Expired items waiting

50 million

Cleanup rate

200,000 items/sec

Database CPU

45%

Queue size

2 million jobs

Cleanup latency

Average: 3 minutes

Now you can see whether the system is keeping up.

20. What If Cleanup Falls Behind?

Suppose:

New expired Statuses:
1 billion/day

Cleanup capacity:
800 million/day

You're losing the race.

The queue will grow forever.

So the system needs to scale.

Possible solutions include:

increase worker count,
increase batch size carefully,
optimize indexes,
partition the data,
move cleanup to replicas or specialized stores where appropriate,
spread work over a longer window,
improve storage architecture.

The important thing is to measure the system instead of guessing.

21. The Beginner's Mental Model

You don't need to understand every database engine to understand the core idea.

Think of expired Statuses as garbage.

Imagine a city produces billions of pieces of garbage every day.

You wouldn't wait until the end of the month and tell one truck:

“Collect everything.”

You'd probably use:

many trucks,
scheduled pickups,
different neighborhoods,
manageable loads,
monitoring,
extra capacity during busy periods.

Database cleanup works in a similar way.

Don't create one giant cleanup operation. Build a controlled garbage-collection system.

22. The Big Lessons

If you remember only a few things, remember these:

1. Don't perform gigantic deletes

Break the work into batches.

10,000
10,000
10,000
...

2. Make finding expired data cheap

Indexes on expiration-related fields can be important.

3. Don't block user traffic

Cleanup should run as background work.

4. Use queues and workers when appropriate

They allow cleanup to scale horizontally.

5. Use backpressure

When the database is busy, slow down.

6. Consider partitioning

Time-based data can sometimes be efficiently managed through partitions.

7. Separate logical expiration from physical deletion

A Status can stop being visible immediately while physical cleanup happens later.

8. Make cleanup retry-safe

Failures are normal in distributed systems.

9. Monitor everything

Know how much data is waiting and how quickly you're processing it.

Final Picture

So, how can a service like WhatsApp deal with billions of temporary Statuses?

The answer isn't one magical SQL query.

It's an architecture.

Instead of:

Billions of expired records
          ↓
     ONE DELETE
          ↓
     💥 Database

you want something closer to:

              Expired Statuses
                     │
                     ▼
              Cleanup Queue
                     │
          ┌──────────┼──────────┐
          ▼          ▼          ▼
       Worker      Worker      Worker
          │          │          │
          └──────────┼──────────┘
                     ▼
               Small Batches
                     │
                     ▼
              Database / Storage

The trick is not to make the database delete billions of things instantly.

The trick is to make the system continuously and safely remove expired data at a controlled rate.

That's one of the fundamental lessons of large-scale backend engineering:

At massive scale, the question isn't just “Can we do this?” It's “Can we do this continuously without hurting everything else?”

Optimistic and Pessimistic Locking in .NET with SQL Server

Ravi Vishwakarma — Sat, 22 Aug 2026 14:31:54 +0000

When multiple users access the same application at the same time, they may also try to read or update the same database record.

For example:

User A opens a product and changes its price.
User B opens the same product at the same time and also changes its price.
Both users click Save.

What happens?

Without a strategy to handle concurrent updates, one user's changes may silently overwrite the other's. This is where concurrency control and database locking strategies become important.

Two common approaches are:

Optimistic locking
Pessimistic locking

In this article, we'll learn both approaches using .NET and SQL Server, with beginner-friendly examples and commented code.

What Problem Are We Trying to Solve?

Imagine we have a simple Products table.

CREATE TABLE Products
(
    Id INT PRIMARY KEY,
    Name NVARCHAR(100),
    Price DECIMAL(10, 2)
);

The table contains this record:

Id	Name	Price
1	Laptop	50000

Now imagine two users open this product at exactly the same time.

User A

Reads:

Laptop - ₹50,000

User A changes the price to:

₹55,000

User B

At the same time, User B also reads:

Laptop - ₹50,000

User B changes the price to:

₹48,000

If User A saves first and User B saves afterward, User B's update may overwrite User A's change.

This is often called a lost update problem.

We need a way to detect or prevent this conflict.

1. What Is Optimistic Locking?

Optimistic locking assumes that conflicts are rare.

The basic idea is:

"Let everyone read and work with the data. When someone tries to save, check whether the data has changed since they originally read it."

If the data has not changed, the update succeeds.

If the data has changed, the application detects a concurrency conflict.

How Does It Work?

A common approach is to add a rowversion column to the SQL Server table.

CREATE TABLE Products
(
    Id INT PRIMARY KEY,
    Name NVARCHAR(100),
    Price DECIMAL(10, 2),

    -- SQL Server automatically changes this value
    -- whenever the row is updated.
    RowVersion ROWVERSION NOT NULL
);

The RowVersion column acts like a version identifier for the row.

For example:

Product before update:

Id: 1
Price: 50000
RowVersion: 0x00000000000007D1

When the product is updated, SQL Server changes the RowVersion.

Product after update:

Id: 1
Price: 55000
RowVersion: 0x00000000000007D2

Now, when a user attempts to update the record, we can check whether the version they originally read is still the current version.

Optimistic Locking with ADO.NET

First, let's create a simple C# model.

public class Product
{
    public int Id { get; set; }

    public string Name { get; set; } = string.Empty;

    public decimal Price { get; set; }

    // This stores the row version returned by SQL Server.
    // It helps us detect whether another user changed the row.
    public byte[] RowVersion { get; set; } = Array.Empty<byte>();
}

Step 1: Read the Product

using Microsoft.Data.SqlClient;

public async Task<Product?> GetProductAsync(int id)
{
    // Replace this with your actual connection string.
    var connectionString =
        "Server=.;Database=ShopDb;Trusted_Connection=True;TrustServerCertificate=True;";

    await using var connection =
        new SqlConnection(connectionString);

    await connection.OpenAsync();

    var sql = @"
        SELECT Id, Name, Price, RowVersion
        FROM Products
        WHERE Id = @Id";

    await using var command =
        new SqlCommand(sql, connection);

    // Use parameters instead of string concatenation.
    command.Parameters.AddWithValue("@Id", id);

    await using var reader =
        await command.ExecuteReaderAsync();

    if (!await reader.ReadAsync())
    {
        return null;
    }

    return new Product
    {
        Id = reader.GetInt32(0),
        Name = reader.GetString(1),
        Price = reader.GetDecimal(2),

        // Save the row version that existed when we read the record.
        RowVersion = (byte[])reader["RowVersion"]
    };
}

When the user loads the product, we also store its current RowVersion.

Later, when the user clicks Save, we use that version in the UPDATE statement.

Step 2: Update the Product Safely

public async Task<bool> UpdateProductAsync(Product product)
{
    var connectionString =
        "Server=.;Database=ShopDb;Trusted_Connection=True;TrustServerCertificate=True;";

    await using var connection =
        new SqlConnection(connectionString);

    await connection.OpenAsync();

    var sql = @"
        UPDATE Products
        SET
            Name = @Name,
            Price = @Price
        WHERE
            Id = @Id

            -- Only update if the row version is still the same
            -- as when the user originally read the record.
            AND RowVersion = @RowVersion";

    await using var command =
        new SqlCommand(sql, connection);

    command.Parameters.AddWithValue("@Id", product.Id);
    command.Parameters.AddWithValue("@Name", product.Name);
    command.Parameters.AddWithValue("@Price", product.Price);
    command.Parameters.Add("@RowVersion", System.Data.SqlDbType.Timestamp)
        .Value = product.RowVersion;

    // ExecuteNonQueryAsync returns the number of affected rows.
    var affectedRows = await command.ExecuteNonQueryAsync();

    // If 1 row was updated, the operation succeeded.
    // If 0 rows were updated, someone may have changed
    // the record before us.
    return affectedRows == 1;
}

Now imagine this sequence:

User A reads the product

Price: 50000
RowVersion: Version 1

User B reads the product

Price: 50000
RowVersion: Version 1

User A updates the product

The product becomes:

Price: 55000
RowVersion: Version 2

User B tries to update

But User B still has:

RowVersion: Version 1

The SQL query checks:

WHERE Id = @Id
AND RowVersion = @RowVersion

Since the database now contains Version 2, no row matches the condition.

Therefore:

affectedRows = 0

The application can now tell User B:

"This product was modified by another user. Please reload the latest data and try again."

That is optimistic locking.

Optimistic Locking with Entity Framework Core

Entity Framework Core makes optimistic concurrency easier.

First, create the model:

using System.ComponentModel.DataAnnotations;

public class Product
{
    public int Id { get; set; }

    public string Name { get; set; } = string.Empty;

    public decimal Price { get; set; }

    // [Timestamp] tells EF Core that this property
    // should be used for optimistic concurrency checking.
    [Timestamp]
    public byte[] RowVersion { get; set; } = Array.Empty<byte>();
}

You can also configure it using Fluent API:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Product>()
        .Property(p => p.RowVersion)
        .IsRowVersion();
}

When EF Core detects that another user changed the row before SaveChangesAsync(), it can throw a concurrency exception.

try
{
    // Get the product.
    var product = await _context.Products.FindAsync(1);

    if (product == null)
    {
        return;
    }

    // Change the price.
    product.Price = 55000;

    // EF Core generates an UPDATE statement that checks
    // the original concurrency value.
    await _context.SaveChangesAsync();

    Console.WriteLine("Product updated successfully.");
}
catch (DbUpdateConcurrencyException)
{
    // This happens when another user changed or deleted
    // the record before our update was completed.
    Console.WriteLine(
        "The product was modified by another user. " +
        "Reload the latest data and try again.");
}

This is one reason rowversion is commonly used with EF Core applications.

Advantages of Optimistic Locking

Optimistic locking works well when conflicts are relatively uncommon.

Benefits

Users are not blocked while reading data.
Long-running locks are avoided.
It generally scales well for many read operations.
It is useful for web applications where users may keep a page open for several minutes.

Disadvantages

The application must handle concurrency conflicts.
A user may spend time editing data and then discover that another user changed it.
Users may need to reload and merge changes.

2. What Is Pessimistic Locking?

Pessimistic locking takes the opposite approach.

It assumes:

"A conflict might happen, so lock the data while it is being used."

In simple terms:

User A accesses a row.
The application places a lock on that row.
User B tries to access or modify the same row.
User B may have to wait until User A finishes and releases the lock.

The lock usually exists within a database transaction.

Pessimistic Locking Example with SQL Server

Suppose we want to reserve a product row for update.

We can use locking hints such as:

UPDLOCK

and:

ROWLOCK

For example:

SELECT *
FROM Products WITH (UPDLOCK, ROWLOCK)
WHERE Id = 1;

Let's understand these hints.

`UPDLOCK`

This requests an update lock while reading the row.

The intention is:

"I am reading this row because I plan to update it."

`ROWLOCK`

This asks SQL Server to prefer row-level locking rather than locking a larger resource.

However, it is important to understand that SQL Server manages locking internally, and locking hints are requests rather than a guarantee of a particular physical locking behavior in every situation.

Pessimistic Locking with ADO.NET

Here is a simple example.

using Microsoft.Data.SqlClient;

public async Task UpdateProductWithLockAsync(
    int productId,
    decimal newPrice)
{
    var connectionString =
        "Server=.;Database=ShopDb;Trusted_Connection=True;TrustServerCertificate=True;";

    await using var connection =
        new SqlConnection(connectionString);

    await connection.OpenAsync();

    // Start a database transaction.
    await using var transaction =
        (SqlTransaction)await connection.BeginTransactionAsync();

    try
    {
        var selectSql = @"
            SELECT Id, Name, Price
            FROM Products WITH (UPDLOCK, ROWLOCK)
            WHERE Id = @Id";

        await using var selectCommand =
            new SqlCommand(selectSql, connection, transaction);

        selectCommand.Parameters.AddWithValue("@Id", productId);

        await using var reader =
            await selectCommand.ExecuteReaderAsync();

        if (!await reader.ReadAsync())
        {
            throw new Exception("Product not found.");
        }

        // Read the current values while the transaction
        // is still holding the requested lock.
        var productName = reader.GetString(1);
        var currentPrice = reader.GetDecimal(2);

        Console.WriteLine(
            $"Current price of {productName}: {currentPrice}");

        // Close the reader before executing another command.
        await reader.CloseAsync();

        var updateSql = @"
            UPDATE Products
            SET Price = @Price
            WHERE Id = @Id";

        await using var updateCommand =
            new SqlCommand(updateSql, connection, transaction);

        updateCommand.Parameters.AddWithValue("@Id", productId);
        updateCommand.Parameters.AddWithValue("@Price", newPrice);

        await updateCommand.ExecuteNonQueryAsync();

        // Commit releases the transaction's locks.
        await transaction.CommitAsync();

        Console.WriteLine("Product updated successfully.");
    }
    catch
    {
        // If something goes wrong, undo the transaction.
        await transaction.RollbackAsync();

        throw;
    }
}

The important part is:

SELECT *
FROM Products WITH (UPDLOCK, ROWLOCK)
WHERE Id = @Id;

combined with a transaction:

await using var transaction =
    (SqlTransaction)await connection.BeginTransactionAsync();

The lock remains relevant for the transaction according to SQL Server's locking and transaction behavior, helping protect the read-then-update operation from competing modifications.

A Simple Pessimistic Locking Scenario

Imagine User A starts this transaction:

BEGIN TRANSACTION

Read Product 1 with an update lock

Update Product 1

COMMIT

While User A's transaction is still active, User B tries to perform a conflicting operation on the same data.

Depending on the operation, isolation level, and locks involved, User B may wait until User A commits or rolls back.

After User A executes:

COMMIT

the transaction completes and its locks are released.

Then User B can continue.

The Danger of Long Transactions

Pessimistic locking can cause problems if transactions stay open for too long.

For example, this is usually a bad idea:

1. Start transaction
2. Lock product
3. Wait for user to fill out a form
4. User goes for lunch
5. Commit transaction

That could cause other users to wait unnecessarily.

Instead, transactions should generally be as short as possible.

A better pattern is:

1. User fills out the form
2. Start transaction
3. Read and validate the current data
4. Update the data
5. Commit immediately

Pessimistic Locking and Deadlocks

Pessimistic locking can increase the possibility of blocking and, in some situations, deadlocks.

A deadlock can look like this:

Transaction A

Locks Product 1
Waits for Product 2

Transaction B

Locks Product 2
Waits for Product 1

Now both transactions are waiting for each other.

SQL Server detects the deadlock and chooses one transaction as the deadlock victim, rolling it back.

One useful strategy for reducing deadlocks is to access resources in a consistent order.

For example, if you always update products in ID order:

Product 1
Product 2
Product 3

rather than sometimes doing:

Product 3
Product 1

you can reduce certain deadlock scenarios.

Optimistic vs Pessimistic Locking

Feature	Optimistic Locking	Pessimistic Locking
Assumption	Conflicts are rare	Conflicts are likely or costly
Locks held while user edits	No	Usually no user-edit-duration lock; locks are held during the transaction
Conflict handling	Detect conflict during update	Block or serialize conflicting access
Scalability	Often better for read-heavy apps	Can suffer from blocking
Complexity	Requires conflict resolution	Requires careful transaction management
Best for	Web apps, normal CRUD systems	Short critical sections with high contention

Which One Should You Use?

There is no universal answer.

Use Optimistic Locking When

Choose optimistic locking when:

Many users mostly read data.
Simultaneous updates are relatively rare.
Your application can ask users to reload or resolve conflicts.
You are building a typical web application or business application.

For many CRUD applications, optimistic concurrency using SQL Server rowversion is a practical starting point.

Use Pessimistic Locking When

Consider pessimistic locking when:

Multiple processes frequently modify the same data.
Conflicting updates would be especially problematic.
You need to protect a short, critical read-modify-write operation.
Waiting is preferable to allowing concurrent conflicting work.

Examples might include certain inventory, reservation, or financial workflows—but the exact design should depend on the business rules and transaction requirements.

A Real-World Example: Booking the Last Seat

Suppose there is only one seat left.

Two users try to book it at the same time.

Optimistic Approach

Both users may initially see:

Available seats: 1

The first user successfully updates the record.

The second user's update detects that the data changed.

The second user receives a message:

"Sorry, this seat is no longer available."

Pessimistic Approach

The first transaction locks the relevant data, checks availability, and creates the booking.

A competing transaction attempting a conflicting operation may wait.

Once the first transaction completes, the next transaction checks the latest availability.

If no seat remains, it does not create a booking.

The important point is that the entire operation should be designed as a short atomic transaction.

A Safer Inventory Pattern

For inventory-like scenarios, you can often avoid a separate read followed by an update.

Instead, perform the business rule directly in the UPDATE statement.

UPDATE Products
SET Stock = Stock - 1
WHERE Id = @Id
  AND Stock > 0;

Then check how many rows were affected.

In C#:

public async Task<bool> TryBuyProductAsync(int productId)
{
    var connectionString =
        "Server=.;Database=ShopDb;Trusted_Connection=True;TrustServerCertificate=True;";

    await using var connection =
        new SqlConnection(connectionString);

    await connection.OpenAsync();

    var sql = @"
        UPDATE Products
        SET Stock = Stock - 1
        WHERE Id = @Id
          AND Stock > 0";

    await using var command =
        new SqlCommand(sql, connection);

    command.Parameters.AddWithValue("@Id", productId);

    // If affectedRows is 1, stock was available.
    // If affectedRows is 0, either the product does not exist
    // or there was no stock remaining.
    var affectedRows =
        await command.ExecuteNonQueryAsync();

    return affectedRows == 1;
}

This pattern is often simpler and safer than manually locking a row and then performing application-side logic.

A Simple Way to Remember the Difference

Think of a shared document.

Optimistic Locking

Two people can open and edit the document.

When someone saves, the system checks:

"Has somebody else changed this since you opened it?"

If yes, there is a conflict.

Pessimistic Locking

The first person effectively reserves the document for the critical operation.

Other conflicting operations may need to wait until the first person is finished.

Final Thoughts

Concurrency can initially sound complicated, but the core idea is simple:

What should happen when two users try to change the same data at the same time?

Optimistic locking says:

"Let them work independently. Detect the conflict when saving."

Pessimistic locking says:

"Protect the critical section so conflicting operations are coordinated."

For many .NET applications using SQL Server, a good starting point is optimistic concurrency with a rowversion column. It avoids holding long-running locks and works naturally with Entity Framework Core.

For operations where contention is high or correctness requires carefully coordinated access, a short transaction with appropriate locking or an atomic SQL operation may be more suitable.

The key is not simply choosing "optimistic" or "pessimistic." The best solution depends on your application's business rules, how frequently conflicts occur, and what should happen when two users attempt the same operation at the same time.

Key Takeaways

Concurrency means multiple users or processes accessing data at the same time.
Optimistic locking detects conflicts when data is updated.
SQL Server's rowversion is commonly used for optimistic concurrency.
Pessimistic locking coordinates conflicting access during a transaction.
Keep database transactions as short as possible.
Long-running locks can cause blocking and increase the risk of deadlocks.
For some scenarios, an atomic SQL statement is better than manually implementing a lock.
Always design concurrency around the actual business rule you need to protect.

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.

Source Code

The complete source code for this project is available on GitHub.

GitHub Repository:
Live Data Dashboard – GitHub

The repository contains both the ASP.NET Core backend and Angular frontend, including the SignalR implementation used for real-time metric updates.

You can clone the repository and follow the setup instructions in the README to run the project locally.

git clone https://github.com/ravi-vishwakarma-hash/Live_Data_Dashboard.git

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.