When you click on a link on a typical website, the browser loads a brand-new page from the server. This could be sluggish and result in a visible lag, which would force a page refresh. Single-Page Applications (SPAs) were developed to increase performance and user experience. They give online apps the same speed and fluidity as mobile apps.

What is a Single-Page Application?
A Single-Page Application (SPA) is a type of web application that loads a single HTML page and dynamically updates the content as the user interacts with it. Instead of reloading the whole page, only the necessary data is fetched and shown.

Key Features

• Loads Once: The main page loads only once, and further content loads dynamically.
• No Full Page Reloads: Content changes without refreshing the entire page.
• Fast Navigation: Feels smooth and similar to using a native mobile app.
• Heavy Use of JavaScript: SPAs rely on JavaScript frameworks and APIs.

How do SPAs Work?

• SPAs work by using JavaScript to handle routing and update the page's content.
• Initial Load: The browser loads one main HTML, CSS, and JavaScript file.
• User Interaction: When the user clicks a button or link, JavaScript intercepts it.
• Data Fetching: The application requests only the necessary data from the server using APIs (such as AJAX or Fetch).
• Dynamic Update: JavaScript updates only part of the page without a full reload.

Example

• If you use Gmail in your browser.
• When you click on an email, only the email content loads while the sidebar and top menu stay the same.
• This is a perfect example of an SPA. (Language: JavaScript with frameworks like React or Angular)

Technologies Used in SPAs
SPAs depend heavily on JavaScript and frontend frameworks.
Common Frameworks and Libraries:

• React.js: Widely used for building SPAs.
• Angular: A complete framework for large SPAs.
• Vue.js: A simple and flexible option for SPAs.
• Svelte: A newer framework for building SPAs efficiently.

Supporting Tools:

• AJAX / Fetch API: To request data without reloading the page.
• REST APIs / GraphQL: To fetch and send data between frontend and backend.

Advantages of SPAs

• Fast Performance: After the first load, navigation is speedy.
• Better User Experience: Smooth transitions without page reloads.
• Reusable Components: Developers can reuse UI components.
• Mobile App Feel: Feels more interactive, like a mobile application.
• Reduced Server Load: Only the required data is requested.

Disadvantages of SPAs

• Initial Load Time: The first page may take longer to load because JavaScript files are heavy.
• SEO Challenges: Search engines may struggle to index SPAs properly.
• Browser Compatibility: Requires JavaScript; may not work well if disabled.
• Security Risks: Exposed APIs can be targeted if not adequately secured.

Real-World Examples of SPAs

• Gmail: Only updates email content without reloading the entire page.
• Google Maps: Loads the map once and dynamically updates locations.
• Facebook: Clicking posts and comments updates the page instantly.
• Twitter: New tweets load dynamically without a full refresh.

Summary
Single-Page Applications (SPAs) are modern web applications that load a single main HTML page and dynamically update its content as users interact. They provide faster navigation, smoother experiences, and a mobile app-like feel. SPAs are built using JavaScript frameworks like React, Angular, and Vue. While they improve performance and user experience, they also face challenges like SEO issues and heavy initial load times. In short, SPAs are a powerful choice for building interactive and modern web applications.

Understanding CommandResponse<T> in C#
When building applications, it’s common to write methods that need to return data along with the status of execution (success or failure). Instead of just returning raw data or a boolean, a better approach is to use a wrapper response object.
What is CommandResponse<T>?

CommandResponse<T> is a generic wrapper class that can hold:

• Data: the actual result of the operation.
• Errors: a list of errors if something went wrong.
• Success: a quick way to check if the operation succeeded.

It can be challenging to manage packages in a.NET solution with numerous projects.  You've probably seen issues like this if you've worked on big apps with dozens or even hundreds of projects.

• Projects utilizing various iterations of the same NuGet package are known as version mismatches.
• Manual labor: Each must be updated. csproj files one after the other.
• Build failures: CI/CD pipelines malfunctioning due to mismatched package versions.

To make this easier, Microsoft introduced Central Package Management (CPM) in .NET, starting with NuGet 6.0 and SDK-style projects.

What is Central Package Management?
Central Package Management lets you keep all NuGet package versions in one central file for your solution. Instead of writing the version number in every project file, you set it once in a file called Directory.Packages.props, and all projects use that version.

This makes upgrades easier, keeps versions consistent, and reduces maintenance work.

How It Works
Create a central file:
At the solution’s root, add a file named Directory.Packages.props.
<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="Newtonsoft.Json" Version="13.0.3" />
    <PackageVersion Include="RabbitMQ.Client" Version="7.1.2" />
    <PackageVersion Include="Swashbuckle.AspNetCore" Version="9.0.3" />
  </ItemGroup>
</Project>

Central Package Management
2. Reference packages in projects (without specifying versions):
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" />
    <PackageReference Include="RabbitMQ.Client" />
  </ItemGroup>

</Project>

Central Package Management
Note: The project file doesn’t include a version number. Instead, the version is defined in Directory.Packages.props.

3. Automatic adoption:
The .NET SDK automatically finds the Directory.Packages.props file in your solution folder and applies it to all projects.

Benefits of Central Package Management

• Consistency – Every project uses the same package version, avoiding conflicts.
• One place to update – Change the version in a single file instead of many.
• Fewer code conflicts – No version mismatches in .csproj files.
• Reliable builds – CI/CD pipelines run more smoothly.
• Simpler project files – .csproj files stay clean and easy to read.

Here’s a simpler example with different packages:
Suppose you have a solution with 15 projects, all using Newtonsoft.Json. Without CPM, updating it means changing 15 .csproj files.

With CPM, you just add this to Directory.Packages.props:
<PackageVersion Include="Newtonsoft.Json" Version="13.0.3" />

Now all projects use the new version automatically.

Conclusion
Central Package Management (CPM) in .NET makes life easier for teams working on solutions with many projects. It keeps package versions consistent, simplifies updates, and saves time. If you haven’t tried it yet, create a Directory.Packages.props file in your solution. You’ll quickly see the advantages. Happy Coding!

When you first encounter the Readonly keyword in C#, it seems straightforward, prevent fields from being reassigned after construction. But once you start applying it to reference types, things get more nuanced. We’ll break down what Readonly really means, especially when dealing with objects, how it behaves differently with value vs. reference types, and what developers should keep in mind to write safer, cleaner code.

What Does Readonly Actually Do?
In C#, the Readonly keyword:

• Can be applied to fields.
• Ensures the field can only be assigned during declaration or inside the constructor of the class/struct.
• Once assigned, the field can’t point to a different object.

public class User
{
    public string Name { get; set; }
}

public class Account
{
    private readonly User _user = new User();
    public void ChangeUser()
    {
        // This is possible
        _user.Name = "New Name";
        // But this will result in compile-time error
        _user = new User();
    }
}

Misunderstanding:
A Readonly field of a reference type doesn’t make the object itself immutable, it only means the reference can’t be reassigned. You can still modify the object’s internal state.
Reference Types vs. Value Types with Readonly

Value Types:
readonly int number = 5;
// Compile-time error
number = 10;

With value types (like int, bool, struct), Readonly means you cannot change the value.
Reference Types:
readonly List<string> items = new List<string>();
// Possible
items.Add("Test");
// Compile-time error
items = new List<string>();

So, the object can still mutate , it’s the reference that’s locked.

Then, How to Make Reference Types Truly Immutable?
To make an object’s state immutable, you must:

• Avoid set accessors in properties.
• Make all fields Readonly.
• Use init accessors for initialization only.
• Don’t expose collection fields directly.

Example
public class User
{
    public string Name { get; init; }
}

Readonly with Properties
While Readonly can be used on fields, it cannot be directly used on properties. But you can mimic the behavior using init accessor:
public string Role { get; init; } = "admin";

These make the property immutable after initialization.

This article guides you through creating a simple Employee Management System with CRUD functionality using.

• Backend: ASP.NET Core Web API
• Frontend: React.js
• Database: SQL Server (via Entity Framework Core)

Step 1. Backend Setup - ASP.NET Core Web API
1.1. Create Project
Run this command on bash.
dotnet new webapi -n EmployeeAPI
cd EmployeeAPI

1.2. Add EF Core Packages
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
dotnet add package Microsoft.EntityFrameworkCore.Tools

1.3. Create Employee Model
// Models/Employee.cs
namespace EmployeeAPI.Models
{
    public class Employee
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public string Department { get; set; }
        public decimal Salary { get; set; }
    }
}

1.4. Create DbContext
// Data/EmployeeContext.cs
using Microsoft.EntityFrameworkCore;
using EmployeeAPI.Models;

namespace EmployeeAPI.Data
{
    public class EmployeeContext : DbContext
    {
        public EmployeeContext(DbContextOptions<EmployeeContext> options)
            : base(options)
        {
        }
        public DbSet<Employee> Employees { get; set; }
    }
}

1.5. Register DbContext in Program.cs
builder.Services.AddDbContext<EmployeeContext>(options =>
    options.UseSqlServer(
        builder.Configuration.GetConnectionString("DefaultConnection")
    )
);

1.6. Add Connection String to appsettings.json
"ConnectionStrings": {
  "DefaultConnection": "Server=YOUR_SERVER;Database=EmployeeDb;Trusted_Connection=True;"
}

using Microsoft.AspNetCore.Mvc;
using EmployeeAPI.Data;
using EmployeeAPI.Models;
using Microsoft.EntityFrameworkCore;

[ApiController]
[Route("api/[controller]")]
public class EmployeesController : ControllerBase
{
    private readonly EmployeeContext _context;

    public EmployeesController(EmployeeContext context) => _context = context;

    [HttpGet]
    public async Task<ActionResult<IEnumerable<Employee>>> GetEmployees() =>
        await _context.Employees.ToListAsync();

    [HttpGet("{id}")]
    public async Task<ActionResult<Employee>> GetEmployee(int id)
    {
        var emp = await _context.Employees.FindAsync(id);
        return emp == null ? NotFound() : emp;
    }

    [HttpPost]
    public async Task<ActionResult<Employee>> CreateEmployee(Employee emp)
    {
        _context.Employees.Add(emp);
        await _context.SaveChangesAsync();
        return CreatedAtAction(nameof(GetEmployee), new { id = emp.Id }, emp);
    }

    [HttpPut("{id}")]
    public async Task<IActionResult> UpdateEmployee(int id, Employee emp)
    {
        if (id != emp.Id)
            return BadRequest();

        _context.Entry(emp).State = EntityState.Modified;
        await _context.SaveChangesAsync();

        return NoContent();
    }

    [HttpDelete("{id}")]
    public async Task<IActionResult> DeleteEmployee(int id)
    {
        var emp = await _context.Employees.FindAsync(id);
        if (emp == null)
            return NotFound();

        _context.Employees.Remove(emp);
        await _context.SaveChangesAsync();

        return NoContent();
    }
}

1.7. Run Migrations
dotnet ef migrations add InitialCreate
dotnet ef database update

Step 2. Frontend Setup - React.js
2.1. Create React App
npx create-react-app employee-ui
cd employee-ui

2.2. Install Axios
npm install axios

2.3. Create API Service
// src/services/employeeService.js

import axios from 'axios';
const API_URL = 'https://localhost:5001/api/employees';
export const getEmployees = () => axios.get(API_URL);
export const getEmployee = (id) =>
  axios.get(`${API_URL}/${id}`);
export const addEmployee = (data) =>
  axios.post(API_URL, data);
export const updateEmployee = (id, data) =>
  axios.put(`${API_URL}/${id}`, data);
export const deleteEmployee = (id) =>
  axios.delete(`${API_URL}/${id}`);

JavaScript
2.4. Main Component Example

// src/App.js
import React, { useEffect, useState } from 'react';
import * as employeeService from './services/employeeService';

function App() {
  const [employees, setEmployees] = useState([]);
  const [form, setForm] = useState({ name: '', department: '', salary: '' });
  const [editId, setEditId] = useState(null);

  const fetchData = async () => {
    const res = await employeeService.getEmployees();
    setEmployees(res.data);
  };

  useEffect(() => {
    fetchData();
  }, []);

  const handleSubmit = async (e) => {
    e.preventDefault();
    if (editId) {
      await employeeService.updateEmployee(editId, form);
    } else {
      await employeeService.addEmployee(form);
    }
    setForm({ name: '', department: '', salary: '' });
    setEditId(null);
    fetchData();
  };

  const handleEdit = (emp) => {
    setForm(emp);
    setEditId(emp.id);
  };

  const handleDelete = async (id) => {
    await employeeService.deleteEmployee(id);
    fetchData();
  };

  return (
    <div>
      <h2>Employee Management</h2>
      <form onSubmit={handleSubmit}>
        <input
          value={form.name}
          onChange={(e) => setForm({ ...form, name: e.target.value })}
          placeholder="Name"
          required
        />
        <input
          value={form.department}
          onChange={(e) => setForm({ ...form, department: e.target.value })}
          placeholder="Department"
          required
        />
        <input
          value={form.salary}
          onChange={(e) => setForm({ ...form, salary: e.target.value })}
          placeholder="Salary"
          required
          type="number"
        />
        <button type="submit">{editId ? 'Update' : 'Add'}</button>
      </form>

      <ul>
        {employees.map((emp) => (
          <li key={emp.id}>
            {emp.name} ({emp.department}) - ${emp.salary}
            <button onClick={() => handleEdit(emp)}>Edit</button>
            <button onClick={() => handleDelete(emp.id)}>Delete</button>
          </li>
        ))}
      </ul>
    </div>
  );
}

export default App;

Step 3. Enable CORS in .NET Core
builder.Services.AddCors(options =>
{
    options.AddPolicy("AllowReactApp", policy =>
        policy.WithOrigins("http://localhost:3000")
              .AllowAnyMethod()
              .AllowAnyHeader());
});

app.UseCors("AllowReactApp");

Step 4. Run the Projects
Run backend
dotnet run

Run frontend
npm start

Output
A simple UI to.

• List employees
• Add a new employee
• Edit existing employee
• Delete employee

Summary
This full-stack CRUD project demonstrated how to.

• Create and expose RESTful APIs in ASP.NET Core
• Connect SQL Server using EF Core
• Consume those APIs in React
• Use Axios for API calls
• Enable CORS between frontend and backend

I discovered that Swagger can be used for much more than just simple API description, particularly in practical tasks. Advanced use cases like grouping endpoints, allowing versioning, using JWT to secure Swagger, and even hiding endpoints when necessary have improved the efficiency and professionalism of my development approach. In addition to code snippets, advice, and things to avoid, I'm revealing the Swagger features that I really use in.NET 6, 7, and 8 projects in this post.

1. Grouping Endpoints (Using Tags)
Sometimes your Swagger UI becomes overwhelming with too many endpoints. Grouping them into logical sections makes it easier to navigate.

Option 1. Group by controller name (default)
This happens automatically, but you can customize it further.

Option 2. Use [ApiExplorerSettings(GroupName = "v1")]
Or use SwaggerDoc and define multiple groups.
// Program.cs
builder.Services.AddSwaggerGen(c =>
{
    c.SwaggerDoc("v1", new OpenApiInfo { Title = "My API V1", Version = "v1" });
    c.SwaggerDoc("v2", new OpenApiInfo { Title = "My API V2", Version = "v2" });
});

// Controller
[ApiExplorerSettings(GroupName = "v2")]
[Route("api/v2/[controller]")]
public class OrdersController : ControllerBase
{
    //...
}

Now, Swagger UI will show v1 and v2 as tabs.

2. API Versioning in Swagger
If your app supports multiple API versions, Swagger should reflect that. Here’s how to set it up.

Step 1. Add required NuGet packages
dotnet add package Microsoft.AspNetCore.Mvc.Versioning
dotnet add package Microsoft.AspNetCore.Mvc.Versioning.ApiExplorer

Step 2. Configure versioning
builder.Services.AddApiVersioning(options =>
{
    options.ReportApiVersions = true;
    options.AssumeDefaultVersionWhenUnspecified = true;
    options.DefaultApiVersion = new ApiVersion(1, 0);
});

builder.Services.AddVersionedApiExplorer(options =>
{
    options.GroupNameFormat = "'v'VVV";
    options.SubstituteApiVersionInUrl = true;
});

Step 3. Update SwaggerGen
builder.Services.AddSwaggerGen();
builder.Services.ConfigureOptions<ConfigureSwaggerOptions>();

(You’ll need to create a ConfigureSwaggerOptions class — I can generate this for you if needed.)

3. Add JWT Authentication to Swagger UI
If you're using JWT Bearer tokens, you can allow Swagger to send them in request headers.

Configure Swagger with Security Definitions
builder.Services.AddSwaggerGen(c =>
{
    c.AddSecurityDefinition("Bearer", new OpenApiSecurityScheme
    {
        Description = "Enter 'Bearer' followed by your JWT token.",
        Name = "Authorization",
        In = ParameterLocation.Header,
        Type = SecuritySchemeType.ApiKey,
        Scheme = "Bearer"
    });

    c.AddSecurityRequirement(new OpenApiSecurityRequirement
    {
        {
            new OpenApiSecurityScheme
            {
                Reference = new OpenApiReference
                {
                    Type = ReferenceType.SecurityScheme,
                    Id = "Bearer"
                }
            },
            Array.Empty<string>()
        }
    });
});

Now Swagger UI will show an Authorize button at the top where you can paste your token.

4. Hiding Specific Endpoints from Swagger
Sometimes you don’t want every endpoint exposed in Swagger, especially internal or admin-only APIs.

Option. Use [ApiExplorerSettings(IgnoreApi = true)]
[ApiExplorerSettings(IgnoreApi = true)]
[HttpGet("internal-only")]
public IActionResult HiddenEndpoint()
{
    return Ok("This won't appear in Swagger");
}

Works at both the action and controller level.

5. Export Swagger JSON/YAML
You can share your API contract with clients or import it into tools like Postman or Azure API Management.
JSON endpoint:
https://localhost:5001/swagger/v1/swagger.json

YAML: You’ll need a separate generator, or use tools like Swagger Editor or SwaggerHub to convert JSON to YAML.

6. Improve Models with DataAnnotations
Swagger auto-generates schemas from your models. Enhance them with [Required], [StringLength], and summaries.
public class ProductDto
{
    [Required]
    [StringLength(50)]
    public string Name { get; set; }

    /// <summary>Product price in USD</summary>
    public decimal Price { get; set; }
}

Make sure XML comments are enabled to see them in the UI.

7. UI Customizations (Logo, Layout, etc.)
You can style Swagger UI by injecting CSS or JS.
app.UseSwaggerUI(c =>
{
    c.InjectStylesheet("/swagger-ui/custom.css");
    c.DocumentTitle = "My API Docs";
});

Use this to:

• Add your company logo
• Change the default collapsed/expanded state
• Customize font/colors

Best Practices I Follow

Conclusion
When you go beyond the basics, Swagger becomes a powerful tool, not just for docs, but for API governance and developer experience. These advanced use cases have helped me a lot when working with large APIs and teams. If you’re already using Swagger in your .NET app, I highly recommend trying out a few of these. They’re not hard to implement, and the payoff is worth it.

JavaScript is frequently used in contemporary web development to create interactive user interfaces. But now that Blazor has been released, Microsoft has given.NET developers the ability to create sophisticated, client-side web apps with C# rather than JavaScript. Blazor supports both client-side and server-side application models and is a component of the ASP.NET Core ecosystem.

What is Blazor?
Blazor is a web UI framework that allows developers to build interactive web UIs using C#. It runs in two main modes:

• Blazor Server: Runs the application on the server and uses SignalR to manage UI interactions.
• Blazor WebAssembly: Runs entirely on the browser using WebAssembly to execute C# code client-side.

Blazor combines the flexibility of modern web development with the productivity of .NET.

Key Features of Blazor

• Component-based architecture for building reusable UI blocks.
• Full .NET support — use C#, Razor, and existing .NET libraries.
• Two-way data binding for easy synchronization of data and UI.
• Dependency injection built-in.
• Routing, event handling, and JavaScript interop support.

Blazor Development Workflow

1. Prerequisites
.NET SDK (.NET 8 or later)
Visual Studio 2022+ or Visual Studio Code
Blazor WebAssembly or Server project template

2. Create a New Project
Using CLI
​dotnet new blazorserver -o BlazorApp

or for WebAssembly
dotnet new blazorwasm -o BlazorApp

3. Project Structure

• Pages/: Razor components (.razor files)
• Shared/: Reusable layout or menu components
• Program.cs: App startup and service configuration
• _Imports.razor: Global namespaces for all components

4. Build and Run
cd BlazorApp dotnet run
Then open http://localhost:5000 in your browser.

Simple Example: Counter Component
<h3>Counter</h3> <p>Current count: @count</p> <button class="btn btn-primary" @onclick="IncrementCount">Click me</button> @code { private int count = 0; private void IncrementCount() { count++; } }

This is a basic component showing a counter that increments when the button is clicked. It's fully written in Razor and C# — no JavaScript involved.

Use Cases for Blazor

• Enterprise internal tools and dashboards
• Form-driven business applications
• Interactive reporting interfaces
• Progressive Web Apps (PWAs)

Best Practices

• Break UIs into reusable components.
• Use state management properly for large apps.
• Secure APIs and validate user inputs.
• Use JavaScript interop only when necessary.
• Monitor performance in WebAssembly mode for large apps.

Conclusion
Blazor is revolutionizing web development by enabling full-stack C# development. With its flexible architecture, developer-friendly tooling, and integration with the .NET ecosystem, Blazor is an ideal choice for modern, scalable web applications. Whether you're building line-of-business apps or looking to transition from JavaScript frameworks, Blazor provides a productive and powerful alternative.

Applications commonly depend on external databases, services, and APIs to operate in today's distributed systems and microservices architecture. High traffic, network problems, or temporary difficulties can cause certain dependencies to fail. It is our responsibility as developers to build apps that can gracefully handle such failures. Resilience patterns can help with that. We will use the most recent Polly v8 coupled with Microsoft to construct middleware for Retry and Circuit Breaker in this blog. extensions. tenacity.

When should I use a circuit breaker? What is its pattern?
Modern applications employ the Circuit Breaker design pattern to avoid invoking a service or function that is prone to malfunction. Consider it analogous to your home's electric circuit breaker, which trips and cuts off the electrical supply in the event of an overload to guard against harm. In software, a circuit breaker momentarily halts calls to a malfunctioning service in order to prevent further overloading it.

When Should You Use It?

• When an external service is known to fail frequently.
• When you want to fail fast instead of waiting for timeouts.
• To prevent cascading failures in microservices.
• To improve overall system responsiveness and stability.

Circuit Breaker Flow

What is Polly?
Polly is a .NET resilience and transient-fault-handling library that allows developers to express policies such as Retry, Circuit Breaker, Timeout, Bulkhead Isolation, and Fallback. Polly has been widely adopted in the .NET community, and with Polly v8, Microsoft has introduced deep integration into the Microsoft.Extensions ecosystem through the new Microsoft.Extensions.Resilience package.

Polly with Microsoft.Extensions.Resilience
In Polly v8, resilience is more declarative and integrated into .NET’s dependency injection and configuration model. This makes it easier to build policies that are environment-aware and configurable. Let’s start building our retry and circuit breaker middleware using the latest packages.

Step 1. Set Up Your Project
Create a new web API project in Visual Studio, or if you are using Visual Studio Code, you can execute the following commands.
mkdir PollyResilienceApp
cd PollyResilienceApp
dotnet new PollyV8RetryDemo

Post that adds below the NuGet package
# In case of Visual Studio Code
dotnet add package Microsoft.Extensions.Resilience

# In case of Visual Studio Package Manager Console
NuGet\Install-Package Microsoft.Extensions.Resilience

Step 2. Configure Resilience Policies in the Program.cs
Open the Program.cs file and add the required namespace and Poly service to place it in the middleware. Below is the snippet of Program.cs file with service.
// namespaces
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Resilience;

var builder = WebApplication.CreateBuilder(args);

// add service
builder.Services.AddResiliencePipeline("standard-pipeline", pipelineBuilder =>
{
    // add retry configurations
    pipelineBuilder.AddRetry(new RetryStrategyOptions
    {
        MaxRetryAttempts = 3,  // -> this should be from appSettings.json
        Delay = TimeSpan.FromMilliseconds(500), // -> this should be from appSettings.json
        BackoffType = DelayBackoffType.Exponential
    });

    // set the circuit breaker pattern
    // configuration numbers should be driven from appSettings.json
    pipelineBuilder.AddCircuitBreaker(new CircuitBreakerStrategyOptions
    {
        FailureRatio = 0.5,  // -> this should be from appSettings.json
        SamplingDuration = TimeSpan.FromSeconds(30),
        MinimumThroughput = 10,
        BreakDuration = TimeSpan.FromSeconds(15)
    });
});

var app = builder.Build();

app.MapControllers();

app.Run();

Step 3. Inject and Use the Policy in a Controller
Once you set the service in the program.cs, it is time to inject the same in the Controllers. Below is an example of a sample controller where ResiliencePipelineProvider has been injected to execute
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Resilience;

[ApiController]
[Route("api/[controller]")]
public class MyAPIController : ControllerBase
{
    private readonly ResiliencePipelineProvider<string> _pipelineProvider;

    public MyAPIController(ResiliencePipelineProvider<string> pipelineProvider)
    {
        _pipelineProvider = pipelineProvider;
    }

    [HttpGet("execute")]
    public async Task<IActionResult> Execute_v1()
    {
        var pipeline = _pipelineProvider.GetPipeline("standard-pipeline");

        try
        {
            var result = await pipeline.ExecuteAsync(async token =>
            {
                // Actual operations goes here
                // For test, can place an sleep command
                // await Task.Delay(100);
                throw new HttpRequestException("Failure");
            });

            return Ok(result);
        }
        catch (Exception ex)
        {
            return StatusCode(500, $"Operation failed: {ex.Message}");
        }
    }
}

How Polly Helps Achieve the Circuit Breaker Pattern?
Polly allows you to plug in the circuit breaker logic without cluttering your business code. The resilience pipeline acts as a middleware that surrounds your code, monitoring failures, retries, and triggering breaks when needed.

With Polly, you get:

• Observability: You can plug in logging and metrics easily.
• Composability: You can combine Retry + Circuit Breaker + Timeout.
• Declarative configuration: Adjust thresholds without touching the logic.

The diagram below explains how the request is flowing.

While all the retry actions are executing by Polly, logs can be done through the Logging Service. To enable the same, add the following code snippet in Program.cs. Appenders can be used based on the project needs.
builder.Services.AddLogging();

Conclusion
By integrating Polly v8 with Microsoft.Extensions.Resilience, you can build reliable, maintainable, and production-ready applications in .NET. Using the Retry and Circuit Breaker patterns, you shield your applications from transient errors and cascading failures.

If you’re building services at scale or working in a microservices environment, implementing these patterns is not just a good-to-have but a necessity.

MediatR
The application's package message dispatcher is called MediatR. Commands, queries, and handlers are examples of requests and answers that can be implemented with its help. Additionally, MediatR supports a variety of architectural patterns in contemporary.NET and.NET Core apps and permits the delivery of messages. It’s introduced as a .NET Standard library, starting from .NET Core 2.0, 3.1, and till supports the latest .NET 9.0. Additionally, it is a robust, open-source framework for.NET applications that implements the Mediator paradigm. Below is a list of architectures that support mediatR.

Clean Architecture: Well-suited for decoupling the application layers from presentation and infrastructure layers. Clean Architecture is used to keep business logic isolated.
CQRS (Command Query Responsibility Segregation): CQRS  is fit for handling separate write and read operations (commands and queries) in request/responses APIs.
DDD (Domain-Driven Design): This is suitable for loosely coupling applications that can be created with domain events and services.
Event-Driven Architecture: it supports publishing and handling events using INotification and INotificationHandler<T>
Test-Driven Development (TDD): This architecture Handlers are easy to unit test, it's isolated from controllers and infrastructure.

MediatR Features in .NET 9 Core

• .NET 9.0 minimal API and modular project structure enhancements in a better way
• Dynamic Database support provided for using the Entity Framework (SQL Server, PostgreSQL, MySQL, SQLite)
• Better developer experience in lightweight, testable service layers.
• MediatR is used for implementing CQRS and a separate layer like Application, Domain, and infrastructure.
• Event handling is improved with built-in support for Server-Sent Events (SSE), 

Advantages of MediatR in the latest version of .NET

• Testability improved; unit test handlers are easy and isolated
• Good for large applications that maintain many modules and features
• Logging, Validation, and Caching are supported in Pipeline behaviours
• Efficient for real-time applications and event-driven applications, and streaming API like OpenAI’s

Single Responsibility Principle (SRP)
// One class = One job

Every class should have only one reason to change. This means no mixing database logic with business logic or API response formatting with validation rules.

Real-World .NET Example
// Bad: Doing too much
public class UserManager
{
    public void Register(User user) { /* logic */ }
    public void SaveToDb(User user) { /* DB logic */ }
    public void SendWelcomeEmail(User user) { /* Email logic */ }
}
// Good: SRP Applied
public class UserService
{
    public void Register(UserDto dto) { /* business rules */ }
}
public class UserRepository
{
    public void Save(User user) { /* DB only */ }
}
public class EmailSender
{
    public void SendWelcomeEmail(User user) { /* Email only */ }
}

Open/Closed Principle (OCP)
Open for extension, closed for modification

Your code should allow new behavior without changing existing code. This avoids regressions and makes it easier to add future features.

Real-World Example
public interface IDiscountStrategy
{
    decimal ApplyDiscount(decimal price);
}
public class HolidayDiscount : IDiscountStrategy
{
    public decimal ApplyDiscount(decimal price) => price * 0.9m;
}
public class NoDiscount : IDiscountStrategy
{
    public decimal ApplyDiscount(decimal price) => price;
}

By injecting IDiscountStrategy, you can add new discounts without changing your OrderService.

Liskov Substitution Principle (LSP)
Subtypes must be substitutable for their base types

Any derived class should be replaceable for its parent without breaking functionality.

Anti-Pattern
public class Rectangle
{
    public virtual void SetWidth(int width) { }
}
public class Square : Rectangle
{
    public override void SetWidth(int width)
    {
        throw new NotImplementedException(); // LSP Violation
    }
}

Instead, design with interfaces or composition when inheritance breaks behavior.

Interface Segregation Principle (ISP)
Keep interfaces small and focused

Clients shouldn't be forced to implement methods they don’t use. This avoids bloated and confusing code.

Better Design
public interface ILoginService
{
    void Login(string user, string password);
}
public interface IRegistrationService
{
    void Register(UserDto dto);
}

Instead of forcing everything into a single IUserService, split interfaces by responsibility.

Dependency Inversion Principle (DIP)
Depend on abstractions, not concrete classes

High-level modules (like OrderService) should depend on interfaces, not low-level classes like SqlOrderRepository.

Real-World Example
public interface IEmailService
{
    void SendEmail(string to, string message);
}
public class EmailService : IEmailService
{
    public void SendEmail(string to, string message)
    {
        // SMTP logic
    }
}
public class NotificationManager
{
    private readonly IEmailService _emailService;

    public NotificationManager(IEmailService emailService)
    {
        _emailService = emailService;
    }

    public void Notify(string msg)
    {
        _emailService.SendEmail("[email protected]", msg);
    }
}

In Program.cs
services.AddScoped<IEmailService, EmailService>();

How to Apply SOLID Principles Efficiently While Working?

• Start with interfaces, then build implementations.
• Don’t mix responsibilities: Separate service, repository, controller.
• Write unit tests: If a class is hard to test, it’s probably violating SOLID.
• Utilize design patterns:such as Strategy, Factory, and Mediator, to simplify SOLID principles.
• Think like Lego: Compose functionality from small, testable bricks.

Final Thoughts
Mastering SOLID is like upgrading your dev brain. You’ll not only write clean and testable code but also scale faster, debug smarter, and survive enterprise-level chaos like a pro.
Want feedback on how SOLID your current codebase is? Drop a sample, and let's refactor it together!

Happy coding, and stay SOLID.