• We check for null even if we expect a value.
• We wrap everything in try/catch just in case.
• We add fallbacks, guards, and defaults — before the need ever arises.

This is called fail-safe programming.

And while it feels responsible, it can actually lead to code that’s noisy, hard to maintain, and less honest about what’s really going on.

⚠️ The Problem with Fail-Safe by Default

Fail-safe logic is expensive when overused:

• ❌ It hides bugs instead of surfacing them
• ❌ It bloats otherwise clear logic
• ❌ It encourages defensive habits over intentional design

Instead of writing code to protect yourself from the unknown, write code that reflects what your system knows to be true — until a real business case says otherwise.

🔧 Example: Updating an Entity with EF Core

Let’s start with this typical fail-safe update method:

public async Task<Result> UpdateProductAsync(int id, ProductUpdateDto dto)
{
    try
    {
        var product = await _dbContext.Products.FindAsync(id);
        if (product == null)
            return Result.Failure("Product not found");

        product.Name = dto.Name;
        product.Price = dto.Price;
        await _dbContext.SaveChangesAsync();

        return Result.Success();
    }
    catch
    {
        return Result.Failure("Something went wrong.");
    }
}

This is safe — but also too cautious.

It assumes:

• The ID might be wrong
• The query might throw
• We must handle everything right here

But if the flow is trusted (say the ID came from a known dropdown or route), this is overkill.

✅ Same Operation, Less Fear

public async Task UpdateProductAsync(int id, ProductUpdateDto dto)
{
    var product = await _dbContext.Products.SingleAsync(p => p.Id == id);
    product.Name = dto.Name;
    product.Price = dto.Price;
    await _dbContext.SaveChangesAsync();
}

Now if something goes wrong — it fails, as it should.

And instead of catching locally, we let global error handling handle the unexpected.

That’s not reckless — that’s clarity.

🧠 Fail-Safe Code Is Not Evil — Just Overused

There are valid reasons to write defensive code.

✅ Use fail-safes when:

• The failure is expected (e.g., external APIs, user input, timeouts)
• The failure is part of business logic (e.g., show “Product not found” if the user needs to see it)
• The recovery improves the experience (e.g., “Try again” buttons)

❌ Avoid fail-safes when:

• You’re defending against internal data that should be valid
• You’re catching errors just to suppress them
• You’re guarding because “that’s what we always do”

🤯 Real-World Fail-Safe Overkill

🔴 React: Over-defensive rendering

function ProductCard({ product }: { product: Product }) {
  if (!product) return null;
  return <div>{product.name}</div>;
}

Why render the component if product is required?

✅ Better (if contract says it’s required)

function ProductCard({ product }: { product: Product }) {
  return <div>{product.name}</div>;
}

🔴 JavaScript: Guarding when you own the value

const name = response?.data?.user?.name ?? "Unknown";

✅ Better: Trust the API contract or validate once

const name = response.data.user.name;

Let it throw — and let your global error handler deal with the unexpected.

✅ Your Rule of Thumb

Don’t write fail-safe code unless the business, domain, or user experience explicitly requires it.

Write code for what should happen — not what might go wrong in theory.

When failure matters, handle it.
When it doesn’t — let the system do its job.

🧵 Final Thought

Fail-safe programming is a useful tool. But used everywhere, it becomes a crutch.

Not all errors need to be caught.
Not all values need to be checked.
Not all flows need fallback logic.

Write code with confidence.
Let failures bubble. Let global handlers do their job.
Fail when it makes sense — not because you’re afraid.

🚀 Happy coding!!!

This article shows you how to take Dapper to the next level by:

• Wrapping Dapper in a clean Unit of Work abstraction
• Automatically handling Created/Modified timestamps and users
• Creating a pluggable, testable, and production-grade data access layer

Source code

The Pain Points of Raw Dapper

Dapper is super fast, but…

• ❌ No built-in transaction scope
• ❌ No auditing support (CreatedBy, ModifiedBy)
• ❌ No unified place to commit/rollback
• ❌ No easy way to plug in user context
• ❌ No bulk insert support

Usage Comparison

Raw Dapper (Insert Example)

using var connection = new SqlConnection("...connectionString...");
await connection.OpenAsync();

var user = new User { Id = Guid.NewGuid(), Name = "Alex" };
await connection.ExecuteAsync(
    "INSERT INTO Users (Id, Name) VALUES (@Id, @Name)",
    user);

UoW Wrapper (Insert Example)

Powered by Dapper.Contrib

using var uow = _unitOfWorkFactory.CreateUOW();

var user = new User { Name = "Alex" };
await uow.InsertAsync(user);
uow.Commit();

UoW Wrapper (Get By Id)

Powered by Dapper.Contrib

using var uow = _unitOfWorkFactory.CreateUOW();
var user = await uow.GetAsync<User>(userId);
uow.Commit();

UoW Wrapper (Update Example)

Powered by Dapper.Contrib

using var uow = _unitOfWorkFactory.CreateUOW();

var user = await uow.GetAsync<User>(userId);
user.Name = "Updated Name";
await uow.UpdateAsync(user);
uow.Commit();

UoW Wrapper (Bulk Copy Example)

using var uow = _unitOfWorkFactory.CreateUOW();

var users = Enumerable.Range(1, 1000).Select(i => new User
{
    Id = Guid.NewGuid(),
    Name = $"User {i}"
});
await uow.BulkCopyAsync(users);
uow.Commit();

• Cleaner and consistent syntax
• Audit fields are handled automatically
• Shared transaction for safety

Introducing the Architecture

We’ll use these key building blocks:

• BaseEntity — for audit fields
• ICurrentUserService — abstraction for current user context
• IUnitOfWork — transactional Dapper wrapper
• UnitOfWork — Dapper + audit logic + transaction + bulk copy
• UnitOfWorkFactory — for creating multiple UoW instances per method

Step 1: The BaseEntity with Audit Fields

using Dapper.Contrib.Extensions;

public class BaseEntity<TID> : AuditableEntity
{
    [Key]
    public TID Id { get; set; } = default!;
}
public class AuditableEntity
{
    public DateTimeOffset Created { get; set; }
    public string CreatedBy { get; set; } = default!;
    public DateTimeOffset? LastModified { get; set; }
    public string? LastModifiedBy { get; set; }
}

Step 2: The Current User Context

public interface ICurrentUserService
{
    public string UserId { get; }
}
public class CurrentUserService : ICurrentUserService
{
    public string UserId => "SYSTEM"; // Replace with real claims logic
}

Step 3: The Unit of Work Interface

public interface IUnitOfWork : IDisposable
{
    IDbConnection Connection { get; }
    Task InsertAsync<T>(T entity) where T : class;
    Task UpdateAsync<T>(T entity) where T : class;
    Task DeleteAsync<T>(T entity) where T : class;
    Task<T?> GetAsync<T>(object id) where T : class;
    Task<IEnumerable<T>> GetAllAsync<T>() where T : class;
    Task<IEnumerable<T>> QueryAsync<T>(string sql, object? param = null);
    Task<T?> QueryFirstOrDefaultAsync<T>(string sql, object? param = null);
    Task<T> QuerySingleAsync<T>(string sql, object? param = null);
    Task<int> ExecuteAsync(string sql, object? param = null);
    Task BulkCopyAsync<T>(IEnumerable<T> items, string? tableName = null);
    void Commit();
    void Rollback();
}

Step 4: The Unit of Work Implementation

public class UnitOfWork : IUnitOfWork
{
    public IDbConnection Connection { get; }
    private IDbTransaction? _transaction;
    private bool _isCompleted;
    private readonly ICurrentUserService _currentUserService;
  
    public UnitOfWork(IDbConnection connection, ICurrentUserService currentUserService, bool transactional = true)
    {
        SqlMapperExtensions.TableNameMapper = (type) => type.Name;
        _currentUserService = currentUserService;
        Connection = connection;
        Connection.Open();
        if (transactional)
        {
            _transaction = Connection.BeginTransaction();
        }
        else
        {
            _isCompleted = true;
        }
    }
    
    public async Task InsertAsync<T>(T entity) where T : class
    {
        if (entity is BaseEntity auditable)
        {
            var now = DateTimeOffset.UtcNow;
            auditable.Created = now;
            auditable.CreatedBy = _currentUserService.UserId;
        }
        await Connection.InsertAsync(entity, _transaction);
    }
    
    public async Task UpdateAsync<T>(T entity) where T : class
    {
        if (entity is BaseEntity auditable)
        {
            auditable.LastModified = DateTimeOffset.UtcNow;
            auditable.LastModifiedBy = _currentUserService.UserId;
        }
        await Connection.UpdateAsync(entity, _transaction);
    }
    
    public async Task DeleteAsync<T>(T entity) where T : class =>
        await Connection.DeleteAsync(entity, _transaction);

    public async Task<T?> GetAsync<T>(object id) where T : class =>
        await Connection.GetAsync<T>(id, _transaction);

    public async Task<IEnumerable<T>> GetAllAsync<T>() where T : class =>
        await Connection.GetAllAsync<T>(_transaction);

    public async Task<IEnumerable<T>> QueryAsync<T>(string sql, object? param = null) =>
        await Connection.QueryAsync<T>(sql, param, _transaction);
    
    public async Task<T> QuerySingleAsync<T>(string sql, object? param = null) =>
        await Connection.QuerySingleAsync<T>(sql, param, _transaction);
    
    public async Task<T?> QueryFirstOrDefaultAsync<T>(string sql, object? param = null) =>
        await Connection.QueryFirstOrDefaultAsync<T>(sql, param, _transaction);
    
    public async Task<int> ExecuteAsync(string sql, object? param = null) =>
        await Connection.ExecuteAsync(sql, param, _transaction);
    
    public async Task BulkCopyAsync<T>(IEnumerable<T> items, string? tableName = null)
    {
        if (Connection is not SqlConnection sqlConnection)
            throw new NotSupportedException("Bulk insert is only supported with SqlConnection.");
        var actualTableName = tableName ?? typeof(T).Name;
        var props = typeof(T)
            .GetProperties(BindingFlags.Public | BindingFlags.Instance)
            .Where(p => p.CanWrite)
            .ToArray();
        var dataTable = new DataTable();
        foreach (var prop in props)
        {
            var type = Nullable.GetUnderlyingType(prop.PropertyType) ?? prop.PropertyType;
            if (type == typeof(DateTimeOffset))
                type = typeof(DateTime);
            dataTable.Columns.Add(prop.Name, type);
        }
        var now = DateTimeOffset.UtcNow;
        var userId = _currentUserService.UserId ?? "system";
        foreach (var item in items)
        {
            var idProp = typeof(T).GetProperty("Id");
            if (idProp != null && idProp.PropertyType == typeof(Guid))
            {
                var idValue = (Guid?)idProp.GetValue(item);
                if (idValue == null || idValue == Guid.Empty)
                {
                    idProp.SetValue(item, Guid.NewGuid());
                }
            }
            if (item is BaseEntity auditable)
            {
                auditable.Created = now;
                auditable.CreatedBy = userId;
            }
            var values = props.Select(p =>
            {
                var value = p.GetValue(item);
                if (value is DateTimeOffset dto)
                    return dto.UtcDateTime;
                return value ?? DBNull.Value;
            }).ToArray();
            dataTable.Rows.Add(values);
        }
        using var bulkCopy = new SqlBulkCopy(sqlConnection, SqlBulkCopyOptions.Default, (SqlTransaction?)_transaction)
        {
            DestinationTableName = actualTableName
        };
        foreach (DataColumn column in dataTable.Columns)
        {
            bulkCopy.ColumnMappings.Add(column.ColumnName, column.ColumnName);
        }
        await bulkCopy.WriteToServerAsync(dataTable);
    }
    public void Commit()
    {
        if (_isCompleted) return;
        _transaction?.Commit();
        _isCompleted = true;
    }
    public void Rollback()
    {
        if (_isCompleted) return;
        _transaction?.Rollback();
        _isCompleted = true;
    }
    public void Dispose()
    {
        if (!_isCompleted)
        {
            try { _transaction?.Rollback(); } catch { }
        }
        _transaction?.Dispose();
        Connection.Dispose();
    }
}

Step 5: The Factory

public interface IUnitOfWorkFactory
{
    public IUnitOfWork CreateUOW();
}

public class UnitOfWorkFactory : IUnitOfWorkFactory
{
    private readonly string _connectionString;
    private readonly ICurrentUserService _currentUserService;
    public UnitOfWorkFactory(string connectionString, ICurrentUserService currentUserService)
    {
        _connectionString = connectionString;
        _currentUserService = currentUserService;
    }
    public IUnitOfWork CreateUOW()
    {
        var connection = new SqlConnection(_connectionString);
        return new UnitOfWork(connection, _currentUserService);
    }
}

Dependency Injection Setup (ASP.NET Core)

builder.Services.AddHttpContextAccessor();
builder.Services.AddScoped<ICurrentUserService, CurrentUserService>();
builder.Services.AddScoped<IUnitOfWorkFactory>(provider =>
{
    var config = provider.GetRequiredService<IConfiguration>();
    var user = provider.GetRequiredService<ICurrentUserService>();
    return new UnitOfWorkFactory(config.GetConnectionString("DefaultConnection"), user);
});

Benefits

• Clean separation of concerns
• Transaction-safe Dapper access
• Auditing baked in automatically
• Fast SqlBulkCopy support for batch inserts
• Pluggable and testable

Happy coding! 💙

Level Up Your Dapper Game: Write Better, Safer Data Code with Ease was originally published in .Net Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Does the connection actually get disposed after using using — or does connection pooling change how it works?

Example:

using (var connection = new SqlConnection(connectionString))
{
    connection.Open(); // Pulls from the pool if available
    var data = connection.Query("SELECT * FROM Products");
} // Connection is returned to the pool

This article explains why the using statement is essential even when connection pooling is enabled (this is the default behavior).

How Connection Pooling Works

When you create a connection using new SqlConnection() and call Open(), the connection pool manager follows these steps:

1. If an available connection exists in the pool, it will reuse that connection instead of creating a new one.
2. If no available connection exists in the pool, it will create a new physical connection to the database.
3. When the connection is closed or disposed, it is returned to the pool instead of being physically closed.

This mechanism reduces the overhead of opening and closing physical connections, improving performance.

🔎 Connection pooling is enabled by default in Microsoft.Data.SqlClient.

Why using is Still Necessary

Even though connection pooling handles connection reuse, the using statement (or explicitly calling Dispose()) is still essential for several reasons:

1. Ensures Connection is Returned to the Pool

• Dispose() signals to the connection pool manager that the connection is no longer in use.
• Without Dispose() or Close(), the connection would remain "checked out" from the pool, reducing the number of available connections.

🚀 Failing to return the connection promptly can lead to connection pool exhaustion under high load.

2. Avoids Connection Leaks

• If you forget to close the connection, it will stay open and consume resources.
• Leaking connections reduces the number of available connections in the pool, causing eventual connection timeouts.

Bad example:

var connection = new SqlConnection(connectionString);
connection.Open();
// Forgot to close the connection!

Good example:

using (var connection = new SqlConnection(connectionString))
{
    connection.Open();
    // Code here
} // Connection is returned to the pool automatically

3. Handles Exceptions

• If an exception occurs, the using block ensures that Dispose() is called even if the operation fails.
• This prevents connections from being left in an open state.

Example:

using (var connection = new SqlConnection(connectionString))
{
    connection.Open();
    throw new Exception("Oops!"); // Still gets disposed
}

4. Prevents Connection Starvation

• When too many connections are left open (by not closing them), new requests will have to wait for an available connection.
• This can lead to degraded performance and timeouts.

5. Cleaner and More Maintainable Code

• using makes the connection lifecycle clear and predictable.
• Without using, you'd need a finally block to call Dispose() manually, which increases complexity and risk of human error.

Best Practices for Dapper and Connection Pooling

• Always use a using block when opening a connection.
• Open the connection late and close it early.
• Let the pool handle connection reuse.
• Avoid holding connections open longer than necessary.

Happy Coding!

Does using Actually Dispose the Connection? (Understanding Connection Pooling in Dapper) was originally published in .Net Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Sorting data dynamically at runtime can greatly enhance the flexibility of your applications, especially when dealing with user-driven sorting criteria. LinqFlex is a .NET library that enables dynamic ordering of IQueryable collections based on property names or key selectors. In this article, we’ll explore how to use LinqFlex for dynamic sorting in your .NET applications.

Installation

First, you need to install the LinqFlex package via NuGet. You can do this using the .NET CLI:

dotnet add package LinqFlex

Or via the NuGet Package Manager in Visual Studio.

Setting Up Your Project

Ensure you have a basic project set up. For demonstration purposes, let’s assume you have a simple Person class:

public class Person
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int Age { get; set; }
}

Using LinqFlex for Dynamic Sorting

One of the primary features of LinqFlex is the ability to order collections dynamically by property name. Here’s how you can do it:

using LinqFlex;

var people = new List<Person>
{
    new Person { Id = 1, Name = "Alice", Age = 30 },
    new Person { Id = 2, Name = "Bob", Age = 25 },
    new Person { Id = 3, Name = "Charlie", Age = 35 }
}.AsQueryable();

// Sort by Name in ascending order
var sortedByName = people.OrderBy("Name", true);

// Sort by Age in descending order
var sortedByAge = people.OrderBy("Age", false);

// Display the sorted results
Console.WriteLine("Sorted by Name:");
foreach (var person in sortedByName)
{
    Console.WriteLine($"{person.Name} - {person.Age}");
}

Console.WriteLine("Sorted by Age:");
foreach (var person in sortedByAge)
{
    Console.WriteLine($"{person.Name} - {person.Age}");
}

Explanation

In the above example, the OrderBy extension method from LinqFlex is used to sort the people collection. By specifying the property name as a string and the sort direction (true for ascending, false for descending), you can dynamically order the collection at runtime.

Handling Invalid Properties

If you try to sort by a property that doesn’t exist, LinqFlex will throw an ArgumentException. This ensures that your application can handle errors gracefully:

try
{
    var invalidSort = people.OrderBy("InvalidProperty", true);
}
catch (ArgumentException ex)
{
    Console.WriteLine(ex.Message); // Outputs: "Property 'InvalidProperty' does not exist on type 'Person'."
}

Conclusion

Dynamic sorting is a powerful feature that can enhance the user experience by allowing flexible data manipulation. With LinqFlex, implementing dynamic ordering in your .NET applications becomes straightforward and efficient. Install LinqFlex today and start leveraging its capabilities to provide dynamic sorting in your projects.

For more information and advanced usage, visit the LinqFlex GitHub repository.

Working with Excel data in C# can be challenging. To simplify this task, we developed the ExcelShaper NuGet package, providing a straightforward and effective method for reading and processing Excel files.

What is ExcelShaper?

ExcelShaper is a NuGet package designed to simplify reading Excel files in C#. It supports reading data by sheet index or headers and allows mapping rows to custom C# objects effortlessly.

Installation

To install ExcelShaper, run the following command in your project directory:

dotnet add package ExcelShaper

You can follow GitHub repository examples project

Basic Usage

Here’s how to set up a C# project to use ExcelShaper. This example reads data from the first sheet by index:

using ExcelShaper;
using System.Text.Json;

class Program
{
    static void Main(string[] args)
    {
       var ret1 = Engine.ReadExcelFileByIndex(filePath);
       Console.WriteLine(JsonSerializer.Serialize(ret1.Take(3)));
    }
}

[["Index","First Name","Last Name","Gender","Country","Age","Date","Id"],
["1","Dulce","Abril","Female","United States","32","15/10/2017","1562"],
["2","Mara","Hashimoto","Female","Great Britain","25","16/08/2016","1582"]]

Reading Excel File by Headers

To read data using sheet headers, use the following code:

var ret4 = Engine.ReadExcelFileByHeader(filePath);
Console.WriteLine(JsonSerializer.Serialize(ret4.Take(3)));

[{"index":"1","firstname":"Dulce","lastname":"Abril","gender":"Female","country":"United States","age":"32","date":"15/10/2017","id":"1562"},
{"index":"2","firstname":"Mara","lastname":"Hashimoto","gender":"Female","country":"Great Britain","age":"25","date":"16/08/2016","id":"1582"},
{"index":"3","firstname":"Philip","lastname":"Gent","gender":"Male","country":"France","age":"36","date":"21/05/2015","id":"2587"}]

Map to Class with Index

To map the data to a custom Person class, use a mapping function:

var ret7 = Engine.ReadExcelFileByIndex(filePath, (i, rowData) =>
{
    //to avoid first header raw
    if (i > 0)
    {
        return new Person
        {
            Age = int.Parse(rowData[5]),
            Country = rowData[4],
            Date = DateTime.ParseExact(rowData[6], "dd/MM/yyyy", CultureInfo.InvariantCulture),
            FirstName = rowData[1],
            Gender = rowData[3],
            Id = int.Parse(rowData[7]),
            LastName = rowData[2],
            Index = int.Parse(rowData[0]),
        };
    }
    return null;
});
Console.WriteLine(JsonSerializer.Serialize(ret7.Take(3)));

Here’s the Person class:

public class Person
{
    public int Index { get; set; }
    public string FirstName { get; set; } = "";
    public string LastName { get; set; } = "";
    public string Gender { get; set; } = "";
    public string Country { get; set; } = "";
    public int Age { get; set; }
    public DateTime Date { get; set; }
    public int Id { get; set; }
}

[{"Index":1,"FirstName":"Dulce","LastName":"Abril","Gender":"Female","Country":"United States","Age":32,"Date":"2017-10-15T00:00:00","Id":1562},
{"Index":2,"FirstName":"Mara","LastName":"Hashimoto","Gender":"Female","Country":"Great Britain","Age":25,"Date":"2016-08-16T00:00:00","Id":1582},
{"Index":3,"FirstName":"Philip","LastName":"Gent","Gender":"Male","Country":"France","Age":36,"Date":"2015-05-21T00:00:00","Id":2587}]

Map to Class with headers

To map the data to a custom Person class, use a mapping function:

var ret8 = Engine.ReadExcelFileByHeader(filePath, (rowData) =>
{
    return new Person
    {
        Age = int.Parse(rowData["age"]),
        Country = rowData["country"],
        Date = DateTime.ParseExact(rowData["date"], "dd/MM/yyyy", CultureInfo.InvariantCulture),
        FirstName = rowData["firstname"],
        Gender = rowData["gender"],
        Id = int.Parse(rowData["id"]),
        LastName = rowData["lastname"],
        Index = int.Parse(rowData["index"]),
    };
});
Console.WriteLine(JsonSerializer.Serialize(ret8.Take(3)));

[{"Index":1,"FirstName":"Dulce","LastName":"Abril","Gender":"Female","Country":"United States","Age":32,"Date":"2017-10-15T00:00:00","Id":1562},
{"Index":2,"FirstName":"Mara","LastName":"Hashimoto","Gender":"Female","Country":"Great Britain","Age":25,"Date":"2016-08-16T00:00:00","Id":1582},
{"Index":3,"FirstName":"Philip","LastName":"Gent","Gender":"Male","Country":"France","Age":36,"Date":"2015-05-21T00:00:00","Id":2587}]

Direct Cast

Reading Excel File by Headers with Inbuilt Mapping Function

var ret9 = Engine.ReadExcelFileByHeader<Person>(filePath);
Console.WriteLine(JsonSerializer.Serialize(ret9.Take(3)));

[{"Index":1,"FirstName":"Dulce","LastName":"Abril","Gender":"Female","Country":"United States","Age":32,"Date":"2017-10-15T00:00:00","Id":1562},
{"Index":2,"FirstName":"Mara","LastName":"Hashimoto","Gender":"Female","Country":"Great Britain","Age":25,"Date":"2016-08-16T00:00:00","Id":1582},
{"Index":3,"FirstName":"Philip","LastName":"Gent","Gender":"Male","Country":"France","Age":36,"Date":"2015-05-21T00:00:00","Id":2587}]

Conclusion

ExcelShaper simplifies Excel data processing in C#. Its ease of use and flexibility make it an excellent choice for developers working with Excel files.

Additional Resources

• GitHub Repository
• NuGet Package

Microfrontend architecture is a design approach for developing web applications as a collection of smaller, independent frontend apps. This strategy enables teams to work in parallel on different features or components of a larger application, improving scalability, flexibility, and the speed of development. Microfrontends extend the concepts of microservices from the backend to the frontend, allowing different parts of a web application to be developed, tested, and deployed independently.

What are Microfrontends?

Microfrontends are essentially small, independent applications that work together to form a larger, cohesive whole. Each microfrontend is responsible for a distinct feature or domain of the application, such as a product search or user profile. These components can be developed using different frameworks or technologies, depending on the team’s expertise or the specific requirements of each component.

Benefits of Microfrontend Architecture

1. Decoupled Development: Teams can work on separate components independently, reducing dependencies and conflicts. This leads to faster development cycles and easier code management.
2. Technology Agnosticism: Microfrontends allow the use of different technologies and frameworks within the same application, enabling the best tool for each specific task.
3. Scalable Teams: The architecture supports scaling development teams by allowing multiple teams to work in parallel without stepping on each other’s toes.
4. Easier Upgrades and Updates: Updating or upgrading a specific part of the application is easier and less risky, as changes are isolated to individual microfrontends.
5. Reusable Components: Components developed for one part of the application can be reused elsewhere, promoting efficiency and consistency across the platform.

Challenges of Microfrontend Architecture

1. Integration Complexity: Ensuring that all microfrontends work together seamlessly can be challenging, especially when different technologies are involved.
2. Performance Overhead: The need to load multiple frameworks and libraries can impact the application’s overall performance and load times.
3. Consistent User Experience: Maintaining a uniform look and feel across the application requires extra coordination and effort.
4. Operational Complexity: Deploying and managing multiple microfrontends can be more complex than a monolithic application, requiring sophisticated CI/CD pipelines and monitoring solutions.

Let’s set up a sample App

1. App Shell: This is the main container of your application. Think of it as the skeleton or the frame that holds everything together. The App Shell is responsible for loading the microfrontends (App-One and App-Two) and ensures that the user navigates smoothly between different parts of the application. It’s like the entryway that directs visitors to various rooms in a house.
2. App-One and App-Two: These are the microfrontends, akin to individual rooms within the house. Each room (microfrontend) serves a distinct purpose or feature of the application. For example, App-One might handle user profiles, while App-Two could be focused on product searches. They are independent of each other, meaning they can be updated, changed, or developed separately without affecting the rest of the house.
3. UI Library: This is a collection of reusable UI components, such as buttons, input fields, and labels, that both App-One and App-Two can use. It’s similar to having a set of furniture and decorations that can be used to furnish both rooms, ensuring they share a consistent look and feel. The UI Library helps maintain design consistency across your application and speeds up development by allowing you to reuse components.
4. Install Nx CLI

npm install -g nx

2. Create a New Nx Workspace

echo y | npx create-nx-workspace@18.0.7 app-workspace --preset=apps; cd app-workspace

The command echo y | npx create-nx-workspace@18.0.7 app-workspace --preset=apps; cd app-workspace automates the creation of an Nx workspace named app-workspace with version 18.0.7, set up for application development (--preset=apps). It automatically agrees to any setup prompts (echo y |), and upon completion, navigates into the newly created workspace directory.

3. Adding Angular support

npx nx add @nrwl/angular

The command npx nx add @nrwl/angular adds Angular support to your Nx workspace, enabling Angular app development within that environment.

4. Adding App Shell (App Shell is the base application)

npx nx generate @nrwl/angular:app apps/app-shell --style=scss --routing=true --e2eTestRunner=cypress --bundler=webpack --ssr=false

The command npx nx generate @nrwl/angular:app apps/app-shell --style=scss --routing=true --e2eTestRunner=cypress --bundler=webpack --ssr=false creates a new Angular application named app-shell in an Nx workspace, with SCSS for styling, routing enabled, Cypress for end-to-end testing, using Webpack as the bundler, and without server-side rendering.

5. Adding two microfrontends

npx nx generate @nrwl/angular:app apps/app-one --style=scss --routing=true --e2eTestRunner=cypress --bundler=webpack --ssr=false;npx nx generate @nrwl/angular:app apps/app-two --style=scss --routing=true --e2eTestRunner=cypress --bundler=webpack --ssr=false

6. Generating Library

npx nx generate @nrwl/angular:lib ui --directory=libs/ui;npx nx generate @nrwl/angular:component ui-button --directory=libs/ui/src/lib/ui-button --export;npx nx generate @nrwl/angular:component ui-label --directory=libs/ui/src/lib/ui-label --export

In this command sequence, we use Nx to create a UI library within an Angular project, and then generate two components within that library: ui-button and ui-label. The commands organize these components into a structured directory (libs/ui) for easy management and ensure they're ready for use across the project by marking them as exported. This approach streamlines the development process by centralizing reusable UI elements, facilitating their reuse across different parts of the application, and maintaining consistency in design and functionality.

All the microfrontends and libraries are ready let's integrate everything.

1. Let’s add aliases

By adding aliases in tsconfig.base.json, we make it easier to work with our project. It's like assigning nicknames to frequently used folders so we don't have to type out long addresses every time we need something from them. This makes our code cleaner and our lives a bit easier, especially as our project grows.

To add aliases you have to edit tsconfig.base.json

{
  "compileOnSave": false,
  "compilerOptions": {
    "rootDir": ".",
    "sourceMap": true,
    "declaration": false,
    "moduleResolution": "node",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "importHelpers": true,
    "target": "es2015",
    "module": "esnext",
    "lib": ["es2020", "dom"],
    "skipLibCheck": true,
    "skipDefaultLibCheck": true,
    "baseUrl": ".",
    "paths": {
      "@app-workspace/app-one/*": ["apps/app-one/src/app/*"],
      "@app-workspace/app-two/*": ["apps/app-two/src/app/*"],
      "@app-workspace/ui": ["libs/ui/src/index.ts"]
    }
  },
  "exclude": ["node_modules", "tmp"]
}

2. Updating routes

To help users navigate to either App-One or App-Two, we need to adjust the app.routes.ts file within the App Shell, located at app-workspace\apps\app-shell\src\app. By setting up these routes, we create clear paths to each microfrontend, ensuring users can easily switch between them as needed.

import { Route } from '@angular/router';

export const appRoutes: Route[] = [
    {
        path: 'app-one',
        loadComponent: () => import('@app-workspace/app-one/app.component').then(m => m.AppComponent)
      },
      {
        path: 'app-two',
        loadComponent: () => import('@app-workspace/app-two/app.component').then(m => m.AppComponent)
      },
];

3. Clean up

For a bit of housekeeping, let’s remove the default nx-welcome.component and give our app components unique, descriptive names. This step, while optional, sharpens the identity of our components, making our project more intuitive. By doing so, your app components will look something like this

<h1>App Shell</h1>
<router-outlet></router-outlet>

4. The last step is using the library.

The final step in setting up our architecture involves integrating the shared UI library into our microfrontends. This means importing the library components we need, such as buttons or labels, directly into our microfrontend apps. By doing this, we ensure that all parts of our application can use these well-designed, consistent components, making our app look and feel unified across different sections. It’s like giving all rooms in a house access to the same set of quality furniture, ensuring a cohesive style throughout.

import { Component } from '@angular/core';
import { RouterModule } from '@angular/router';
import {  UiLabelComponent } from '@app-workspace/ui';
@Component({
  standalone: true,
  imports: [ RouterModule,UiLabelComponent],
  selector: 'app-workspace-root',
  templateUrl: './app.component.html',
  styleUrl: './app.component.scss',
})
export class AppComponent {
  title = 'app-one';
}

Use the library

<h2>App One</h2>
<app-workspace-ui-label></app-workspace-ui-label>
<router-outlet></router-outlet>

Relationship

To visualize how all parts of our project are connected, run the command npx nx graph. This generates a comprehensive graph showing the relationships between the apps and libraries in your Nx workspace. After running the command, click on the "show all projects" button to see the full picture. This visual aid is incredibly helpful for understanding the structure of your project and how each piece fits together, almost like laying out a map of a city to see all the neighbourhoods and how they're connected.

Run

To get your project up and running, simply use the command npx nx serve app-shell. This fires up your main container, the App Shell, and serves your application so you can see it in action in a web browser. It’s like turning the key in the ignition to start your car—this command gets everything moving and lets you see how your app looks and behaves in real-time.

Navigate to http://localhost:4200/ , http://localhost:4200/app-one, and http://localhost:4200/app-two to see how navigation works between our microfrontends.

Summary

The example showcases setting up a microfrontend architecture with Nx and Angular, where an application is segmented into an app-shell, two microfrontends (app-one and app-two), and a shared UI library. This structure facilitates independent development and deployment of features, allows for the use of varied technologies across teams, and promotes reusability and consistency through a common library of UI components. The approach optimizes development processes, enhances scalability, and ensures a cohesive user experience across the application.

Source Code

For the complete code and more examples, check out the GitHub repository: Microfrontend

Acknowledgment

A heartfelt thank you to Darshana Hettiarachchi for guiding me into the Nx world, and enriching my development experience.

The final part of our series brings the user interface to life, integrating our secure ASP.NET 8 Web API with a React and Redux frontend. In this article, we’ll cover how to manage authentication states, securely store and handle authentication tokens, and communicate with the backend API from your React application. We’ll also delve into best practices for protecting routes and managing user sessions in a SPA (Single Page Application) context. By the end of this guide, you’ll have a fully functional, secure web application with a modern, reactive frontend that seamlessly interacts with your ASP.NET backend. This part is essential for developers looking to bridge the gap between backend security and frontend user experience.

Part 1: Setting Up API
Part 2: Setting Up Integration Tests for API Project
Part 3: Setting Up React Client

Web Project: React Frontend

The web project is created with Vite. We are using ReduxJS Toolkit for state management, Ant Design (AntD) for frontend design, and Axios for API call management.

Visual Studio 2022 provides a new JavaScript project type, and we are utilizing that for our project.

Let’s go through the most important files to understand how the project is wired up.

Web project files

In our application, the entry point is main.tsx, where we configure fundamental aspects such as Redux state management, client-side routing using React Router, and an Axios API interceptor. This file initializes the React app, wraps it in StrictMode for enhanced development checks, and renders the main ‘App’ component within the specified ‘root’ element in the HTML document.

import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App.tsx";
import { BrowserRouter } from "react-router-dom";
import { Provider } from "react-redux";
import { store } from "./app/store.ts";
import { AxiosApiInterceptor } from "./app/AxiosApiInterceptor.ts";

ReactDOM.createRoot(document.getElementById("root")!).render(
  <React.StrictMode>
    <Provider store={store}>
      <BrowserRouter>
        <AxiosApiInterceptor />
        <App />
      </BrowserRouter>
    </Provider>
  </React.StrictMode>
);

store.ts sets up the Redux store configuration for a React application using the @reduxjs/toolkit library. It defines an authentication reducer (authReducer) and combines it with state persistence using redux-persist. The configureStore function creates the Redux store, enabling DevTools during development. The persistStore function is used to create a persisted version of the store, ensuring that the authentication state persists across page reloads. Additionally, type definitions (AppDispatch, RootState, and AppThunk) are provided for consistent use throughout the application. Overall, this configuration facilitates efficient state management, asynchronous actions, and persistent storage for the authentication slice of the Redux store.

import {
  configureStore,
  ThunkAction,
  Action,
  combineReducers,
} from "@reduxjs/toolkit";
import authReducer from "../features/user/authSlice";
import storage from "redux-persist/lib/storage"; 
import { persistReducer, persistStore } from "redux-persist";
import thunk from "redux-thunk";

const authPersistConfig = {
  key: "auth",
  storage:storage,
};

const rootReducer = combineReducers({
  auth: persistReducer(authPersistConfig, authReducer),
});

export const store = configureStore({
  reducer: rootReducer,
  devTools: process.env.NODE_ENV !== "production",
  middleware: [thunk],
});

export const persister = persistStore(store);

export type AppDispatch = typeof store.dispatch;
export type RootState = ReturnType<typeof store.getState>;
export type AppThunk<ReturnType = void> = ThunkAction<
  ReturnType,
  RootState,
  unknown,
  Action<string>
>;

authAPI.ts defines a set of functions for making API requests related to user authentication in a React application. Utilizing Axios, the login, refreshToken, register, logout, and profileApi functions interact with a backend server at a specified base URL. Each function handles its respective endpoint, such as user login, token refresh, registration, logout, and fetching user profile. In case of any errors during API requests, the code logs the exceptions to the console. This collection of functions demonstrates a straightforward and modular approach to integrating user authentication API calls in a React application.

import axios from "axios";
import { iAppResponse } from "../../app/appResponse";

const BASE_URL = "https://localhost:1002";

export const login = async (email: string, password: string) => {
  const response = await axios.post<
  iAppResponse<{ accessToken: string; refreshToken: string }>
  >(`${BASE_URL}/user/login`, {
    email: email,
    password: password,
  }).catch((ex)=>{
    console.log(ex);
  });
  return response?.data;
};
export const refreshToken = async (data: {
  accessToken: string;
  refreshToken: string;
}) => {
  const response = await axios.post<
  iAppResponse<{ accessToken: string; refreshToken: string }>
  >(`${BASE_URL}/user/refreshToken`, data).catch((ex)=>{
    console.log(ex);
  });;
  return response?.data;
};
export const register = async (email: string, password: string) => {
  const response = await axios.post<iAppResponse<{}>>(
    `${BASE_URL}/user/register`,
    {
      email: email,
      password: password,
    }
  ).catch((ex)=>{
    console.log(ex);
  });
  return response?.data;
};
export const logout = async () => {
  const response = await axios.post<iAppResponse<boolean>>(
    `${BASE_URL}/user/logout`
  ).catch((ex)=>{
    console.log(ex);
  });;
  return response?.data;
};
export const profileApi = async () => {
  const response = await axios.post(`${BASE_URL}/user/profile`).catch((ex)=>{
    console.log(ex);
  });
  return response?.data;
};

authSlice.ts for managing authentication-related state in the application. It includes a set of reducers to update or reset authentication tokens, manage loading states, and handle logout asynchronously. Overall, this slice facilitates the centralized management of authentication-related data, making it easier to handle user authentication and related asynchronous actions within the Redux store.

import { PayloadAction, createAsyncThunk, createSlice } from "@reduxjs/toolkit";
import { RootState } from "../../app/store";
import { jwtDecode } from "jwt-decode";
import { logout } from "./authAPI";

export interface iUser {
  Id: string;
  RoleClaim: Array<string>;
  UserName: string;
}
export interface iAuthState {
  status: "idle" | "loading" | "failed";
  accessToken?: string;
  refreshToken?: string;
  user?: iUser;
}

const initialState: iAuthState = {
  status: "idle",
};
export const logoutAsync = createAsyncThunk("user/logout", async () => {
  const response = await logout();
  // The value we return becomes the `fulfilled` action payload
  return response?.data;
});
export const authSlice = createSlice({
  name: "auth",
  initialState,
  // The `reducers` field lets us define reducers and generate associated actions
  reducers: {
    updateToken: (
      state,
      action: PayloadAction<{ accessToken: string; refreshToken: string }>
    ) => {
      state.accessToken = action.payload.accessToken;
      state.refreshToken = action.payload.refreshToken;
      state.user = jwtDecode<iUser>(action.payload.accessToken);
    },
    resetToken: (state) => {
      state.accessToken = undefined;
      state.refreshToken = undefined;
      state.user = undefined;
    },
    setLoading: (state) => {
      state.status = "loading";
    },
    resetLoading: (state) => {
      state.status = "idle";
    },
  },
  extraReducers: (builder) => {
    builder
      .addCase(logoutAsync.pending, (state) => {
        state.status = "loading";
      })
      .addCase(logoutAsync.fulfilled, (state) => {
        state.status = "idle";
        state.accessToken = undefined;
        state.refreshToken = undefined;
        state.user = undefined;
      })
      .addCase(logoutAsync.rejected, (state) => {
        state.status = "failed";
      });
  },
});

export const { updateToken, resetToken, setLoading, resetLoading } =
  authSlice.actions;
export const selectAuth = (state: RootState) => state.auth;
export default authSlice.reducer;

AxiosApiInterceptor.ts component is a crucial part of the React application, utilizing Axios interceptors to manage authentication tokens. When a request is made, it ensures the inclusion of the access token in the Authorization header, improving security. Additionally, it monitors responses, particularly handling cases where a 401 status code indicates an expired token. In such situations, it attempts to refresh the token using a provided function. If the refresh is successful, the Redux store is updated with the new tokens, allowing the original request to be retried. If the refresh fails, or if no refresh token is available, the authentication state is reset. This component helps maintain a seamless and secure user authentication experience throughout the application.

import { useEffect } from "react";
import axios from "axios";
import {
  resetToken,
  selectAuth,
  updateToken,
} from "../features/user/authSlice";
import { useAppDispatch, useAppSelector } from "./hooks";
import { refreshToken } from "../features/user/authAPI";

export const AxiosApiInterceptor = () => {
  const authData = useAppSelector(selectAuth);
  const dispatch = useAppDispatch();
  useEffect(() => {
    const requestInterceptor = axios.interceptors.request.use(
      async (config) => {
        const accessToken = authData.accessToken;
        if (accessToken && !config.headers.Authorization) {
          config.headers.Authorization = `Bearer ${accessToken}`;
        }
        return config;
      }
    );

    // Response interceptor
    const responseInterceptor = axios.interceptors.response.use(
      (response) => response,
      async (error) => {
        if (error.response && error.response.status === 401) {
          // Token expired, attempt to refresh it
          if (authData.refreshToken && authData.accessToken) {
            // Make a refresh token request and update access token
            try {
              const response = await refreshToken({
                accessToken: authData.accessToken,
                refreshToken: authData.refreshToken,
              });
              if (response && response.isSucceed && response.data) {
                dispatch(updateToken(response.data));
                error.config.headers.Authorization = `Bearer ${response.data.accessToken}`;
                return axios.request(error.config);
              } else {
                dispatch(resetToken());
              }
            } catch (refreshError) {
              dispatch(resetToken());
              throw refreshError;
            }
          } else {
            dispatch(resetToken());
          }
        }

        return Promise.reject(error);
      }
    );

    return () => {
      // Cleanup: Remove the interceptors when the component unmounts
      axios.interceptors.request.eject(requestInterceptor);
      axios.interceptors.response.eject(responseInterceptor);
    };
  }, [authData, dispatch]);

  return null; // This component doesn't render anything
};

The remaining components are straightforward, and I trust you’ll find them self-explanatory. If you have any further inquiries or need clarification, please feel free to ask.

Summary

This code module serves as a comprehensive guide to integrating a React frontend with an authentication API. Focused on practical implementation, it employs Axios for API requests and demonstrates key functionalities such as user login, token refresh, registration, logout, and fetching user profile. The code promotes a modular and error-handling approach, logging exceptions to the console during API requests. This collection of functions showcases a robust integration of user authentication features within a React application, enhancing practicality and reliability.

Source Code

For the complete code and more examples, check out the GitHub repository: UnifiedApp

What is Keycloak

Centralized User Management

Keycloak allows you to centralize user management in one place, making it easier to manage users, roles, and permissions across multiple applications and services. It supports user federation, which means you can integrate it with existing user directories, such as LDAP or Active Directory.

Single Sign-On (SSO) and Single Log-Out

One of the most significant features of Keycloak is its support for Single Sign-On (SSO). SSO enables users to log in once and gain access to multiple applications without being prompted to log in again at each of them. Similarly, Single Log-Out allows users to log out from all applications simultaneously.

Social Login

Keycloak supports social login, allowing users to sign in using their social media accounts such as Google, Facebook, Twitter, etc. This feature enhances the user experience by simplifying the registration and login processes.

Multi-factor Authentication (MFA)

For enhanced security, Keycloak supports Multi-factor Authentication (MFA). This adds an extra layer of security by requiring users to provide two or more verification factors to gain access to an application.

OpenID Connect (OIDC) and SAML

Keycloak implements modern protocols like OpenID Connect (OIDC) and SAML 2.0 for authentication and authorization, making it versatile and compatible with a wide range of applications.

Customizable Themes

The look and feel of the login pages served by Keycloak can be customized according to your branding requirements. Keycloak allows for theme customizations where you can change the appearance of the login, registration, and account management pages.

Administration Console

Keycloak comes with an easy-to-use web-based administration console for managing realms, users, roles, and permissions. A realm in Keycloak is a space where you manage your users, credentials, roles, and groups.

Security

Keycloak provides robust security features out of the box, including SSL/TLS, password policies, brute force detection, and more. It also allows for the secure storage of user credentials.

API Access Management

Keycloak allows for securing application APIs by using tokens (JWT tokens or SAML assertions). It makes it easy to define which resources are secured and which roles or clients have access to them.

Scalability and High Availability

Keycloak is designed to be scalable and can be deployed in a high-availability configuration to ensure that authentication services are always available to users and applications.

Setting up with docker

docker-compose.yml file

version: '3.7'

services:
  postgres:
    image: postgres:16.2
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    networks:
      - keycloak_network

  keycloak:
    image: quay.io/keycloak/keycloak:23.0.6
    command: start
    environment:
      KC_HOSTNAME: localhost
      KC_HOSTNAME_PORT: 8080
      KC_HOSTNAME_STRICT_BACKCHANNEL: false
      KC_HTTP_ENABLED: true
      KC_HOSTNAME_STRICT_HTTPS: false
      KC_HEALTH_ENABLED: true
      KEYCLOAK_ADMIN: ${KEYCLOAK_ADMIN}
      KEYCLOAK_ADMIN_PASSWORD: ${KEYCLOAK_ADMIN_PASSWORD}
      KC_DB: postgres
      KC_DB_URL: jdbc:postgresql://postgres/${POSTGRES_DB}
      KC_DB_USERNAME: ${POSTGRES_USER}
      KC_DB_PASSWORD: ${POSTGRES_PASSWORD}
    ports:
      - 8080:8080
    restart: always
    depends_on:
      - postgres
    networks:
      - keycloak_network

volumes:
  postgres_data:
    driver: local

networks:
  keycloak_network:
    driver: bridge

.env file

POSTGRES_DB=keycloak_db
POSTGRES_USER=keycloak_db_user
POSTGRES_PASSWORD=keycloak_db_user_password
KEYCLOAK_ADMIN=admin
KEYCLOAK_ADMIN_PASSWORD=password

Services

PostgreSQL Service (postgres):

• Image: Uses the Docker image postgres:16.2 to run a PostgreSQL server.
• Volumes: Maps a volume named postgres_data tob/var/lib/postgresql/data inside the container for persistent storage of the database data.
• Environment Variables: Configures the database with the name (POSTGRES_DB), user (POSTGRES_USER), and password (POSTGRES_PASSWORD) specified by the environment variables.
• Networks: Connects to a custom network keycloak_network for communication with the Keycloak service.

Keycloak Service (keycloak):

• Image: Utilizes quay.io/keycloak/keycloak:23.0.6 for running a Keycloak server.
• Command: Specifies start as the command to run Keycloak.
• Environment Variables: Sets up various settings including hostname (KC_HOSTNAME), port (KC_HOSTNAME_PORT), HTTP configuration (KC_HTTP_ENABLED, KC_HOSTNAME_STRICT_HTTPS), health check (KC_HEALTH_ENABLED), admin credentials (KEYCLOAK_ADMIN, KEYCLOAK_ADMIN_PASSWORD), and database connection details (KC_DB, KC_DB_URL, KC_DB_USERNAME, KC_DB_PASSWORD).
• Ports: Exposes port 8080 on the host, mapping it to port 8080 on the Keycloak container for web access.
• Restart Policy: Configured to always restart unless manually stopped.
• Dependency: Declares a dependency on the Postgres service, ensuring it starts first.
• Networks: Also connected to the keycloak_network.

Volumes

postgres_data: A named volume for storing PostgreSQL data persistently across container restarts, using the default local storage driver.

Networks

keycloak_network: A custom network using the bridge driver, facilitating communication between the Keycloak and PostgreSQL containers.

Environment Variables

Specifies the values for database configuration (POSTGRES_DB, POSTGRES_USER, POSTGRES_PASSWORD) and Keycloak admin credentials (KEYCLOAK_ADMIN, KEYCLOAK_ADMIN_PASSWORD), which are essential for the services to communicate and operate securely.

Summary

This Docker Compose file sets up Keycloak and PostgreSQL, providing an authentication system with data storage. It specifies service configurations, including environment variables for access and a custom network for inter-service communication. Ideal for development, this setup lays the groundwork for application authentication management.

Source Code

For the complete code and more examples, check out the GitHub repository: ForgeContainer

In the second part of our series, the focus shifts towards validating the security and reliability of our ASP.NET 8 Web API through comprehensive integration testing. Integration testing plays a critical role in ensuring that our authentication mechanisms work as intended, under various scenarios and edge cases. We’ll guide you through setting up your testing environment, writing test cases that cover a wide range of authentication scenarios, and interpreting the results to refine your authentication system. This article is designed to provide you with a deep understanding of how to effectively test web APIs, ensuring that your application remains secure and functions correctly under all circumstances.

Part 1: Setting Up API
Part 2: Setting Up Integration Tests for API Project
Part 3: Setting Up React Client

ApiTest Project: Integration test project for API.

The ApiTest project is configured with xUnit, Microsoft.AspNetCore.Mvc.Testing, and FluentAssertions, are here to ensure our API runs smoothly.

ApiTest Project Classes

CustomWebApplicationFactory, The purpose of setting up a custom environment for integration testing. It’s using an in-memory database to isolate the tests, and it’s removing and replacing services appropriately.

    public class CustomWebApplicationFactory<TProgram>
        : WebApplicationFactory<TProgram> where TProgram : class
    {

        protected override void ConfigureWebHost(IWebHostBuilder builder)
        {
            builder.UseEnvironment("Test");
            builder.ConfigureServices(services =>
            {
                var context = services.FirstOrDefault(descriptor => descriptor.ServiceType == typeof(ApplicationDbContext));
                if (context != null)
                {
                    services.Remove(context);
                    var options = services.Where(r => r.ServiceType == typeof(DbContextOptions)
                      || r.ServiceType.IsGenericType && r.ServiceType.GetGenericTypeDefinition() == typeof(DbContextOptions<>)).ToArray();
                    foreach (var option in options)
                    {
                        services.Remove(option);
                    }
                }

                // Add a new registration for ApplicationDbContext with an in-memory database
                services.AddDbContext<ApplicationDbContext>(options =>
                {
                    // Provide a unique name for your in-memory database
                    options.UseInMemoryDatabase("InMemoryDatabaseNameX");
                });
            });
        }
    }

Settings up the environment as “Test”

builder.UseEnvironment("Test");

It’s going to load appsettings.test.json

{
  "TokenSettings": {
    "Issuer": "TestApi",
    "Audience": "TestApp",
    "SecretKey": "DFDGERsjsfjepoeoe@@#$$@$@123112sdaaadasQEWw",
    "TokenExpireSeconds": 10,
    "RefreshTokenExpireSeconds": 20
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  }
}

This code block is preparing the environment for integration tests by ensuring a clean setup for the ApplicationDbContext service, removing any existing registrations, and then configuring it to use an in-memory database with a unique name.

                var context = services.FirstOrDefault(descriptor => descriptor.ServiceType == typeof(ApplicationDbContext));
                if (context != null)
                {
                    services.Remove(context);
                    var options = services.Where(r => r.ServiceType == typeof(DbContextOptions)
                      || r.ServiceType.IsGenericType && r.ServiceType.GetGenericTypeDefinition() == typeof(DbContextOptions<>)).ToArray();
                    foreach (var option in options)
                    {
                        services.Remove(option);
                    }
                }

                // Add a new registration for ApplicationDbContext with an in-memory database
                services.AddDbContext<ApplicationDbContext>(options =>
                {
                    // Provide a unique name for your in-memory database
                    options.UseInMemoryDatabase("InMemoryDatabaseNameX");
                });

Perfect! With the groundwork laid, let’s dive into the actual testing phase.

UserEndPointTest covers different scenarios related to user authentication and registration, checking the API’s behavior under various conditions.

public class UserEndPointTest(CustomWebApplicationFactory<Program> factory) : IClassFixture<CustomWebApplicationFactory<Program>>
{
    private readonly HttpClient _client = factory.CreateClient();

    [Fact]
    public async void LoginSuccessTest()
    {
        var userLoginRequest = new UserLoginRequest
        {
            Email = "UnifiedAppAdmin",
            Password = "UnifiedAppAdmin1!"
        };

        var jsonContent = JsonSerializer.Serialize(userLoginRequest);
        var content = new StringContent(jsonContent, Encoding.UTF8, "application/json");
        var response = await _client.PostAsync("/User/Login", content);
        if (response.IsSuccessStatusCode)
        {
            response.Should().NotBeNull();
            var userLoginResponse = await response.Content.ReadFromJsonAsync<AppResponse<UserLoginResponse>>();
            userLoginResponse.Should().NotBeNull();
            userLoginResponse?.IsSucceed.Should().BeTrue();
            userLoginResponse?.Data.Should().NotBeNull();
            userLoginResponse?.Data?.AccessToken.Should().NotBeNull();
            userLoginResponse?.Data?.RefreshToken.Should().NotBeNull();
        }
        else
        {
            Assert.Fail("Api call failed.");
        }
    }

    [Fact]
    public async void LoginFailTest()
    {
        var userLoginRequest = new UserLoginRequest
        {
            Email = "UnifiedAppAdmin",
            Password = "wrong_password"
        };

        var jsonContent = JsonSerializer.Serialize(userLoginRequest);
        var content = new StringContent(jsonContent, Encoding.UTF8, "application/json");
        var response = await _client.PostAsync("/User/Login", content);
        if (response.IsSuccessStatusCode)
        {
            response.Should().NotBeNull();
            var userLoginResponse = await response.Content.ReadFromJsonAsync<AppResponse<UserLoginResponse>>();
            userLoginResponse.Should().NotBeNull();
            userLoginResponse?.IsSucceed.Should().BeFalse();
            userLoginResponse?.Data.Should().BeNull();

        }
        else
        {
            Assert.Fail("Api call failed.");
        }
    }

    [Fact]
    public async void RegistrationTest()
    {
        var userLoginRequest = new UserRegisterRequest
        {
            Email = "UnifiedAppAdmin1",
            Password = "Pass@#123"
        };

        var jsonContent = JsonSerializer.Serialize(userLoginRequest);
        var content = new StringContent(jsonContent, Encoding.UTF8, "application/json");
        var response = await _client.PostAsync("/User/Register", content);
        if (response.IsSuccessStatusCode)
        {
            response.Should().NotBeNull();
            var userRegisterResponse = await response.Content.ReadFromJsonAsync<AppResponse<bool>>();
            userRegisterResponse.Should().NotBeNull();
            userRegisterResponse?.IsSucceed.Should().BeTrue();
            userRegisterResponse?.Data.Should().BeTrue();


        }
        else
        {
            Assert.Fail("Api call failed.");
        }
    }

    [Fact]
    public async void RegistrationExistingUserTest()
    {
        var userLoginRequest = new UserRegisterRequest
        {
            Email = "UnifiedAppAdmin",
            Password = "Pass@#123"
        };

        var jsonContent = JsonSerializer.Serialize(userLoginRequest);
        var content = new StringContent(jsonContent, Encoding.UTF8, "application/json");
        var response = await _client.PostAsync("/User/Register", content);
        if (response.IsSuccessStatusCode)
        {
            response.Should().NotBeNull();
            var userRegisterResponse = await response.Content.ReadFromJsonAsync<AppResponse<bool>>();
            userRegisterResponse.Should().NotBeNull();
            userRegisterResponse?.IsSucceed.Should().BeFalse();
            userRegisterResponse?.Data.Should().BeFalse();
            userRegisterResponse?.Messages.Any(m => m.Key == "DuplicateUserName").Should().BeTrue();
        }
        else
        {
            Assert.Fail("Api call failed.");
        }
    }

    [Fact]
    public async void RegistrationPasswordTest()
    {
        var userLoginRequest = new UserRegisterRequest
        {
            Email = "UnifiedAppAdmin",
            Password = "123"
        };

        var jsonContent = JsonSerializer.Serialize(userLoginRequest);
        var content = new StringContent(jsonContent, Encoding.UTF8, "application/json");
        var response = await _client.PostAsync("/User/Register", content);
        if (response.IsSuccessStatusCode)
        {
            response.Should().NotBeNull();
            var userRegisterResponse = await response.Content.ReadFromJsonAsync<AppResponse<bool>>();
            userRegisterResponse.Should().NotBeNull();
            userRegisterResponse?.IsSucceed.Should().BeFalse();
            userRegisterResponse?.Data.Should().BeFalse();
            userRegisterResponse?.Messages.Any(m => m.Key == "PasswordRequiresLower").Should().BeTrue();
            userRegisterResponse?.Messages.Any(m => m.Key == "PasswordTooShort").Should().BeTrue();
            userRegisterResponse?.Messages.Any(m => m.Key == "PasswordRequiresNonAlphanumeric").Should().BeTrue();
            userRegisterResponse?.Messages.Any(m => m.Key == "PasswordRequiresUpper").Should().BeTrue();
        }
        else
        {
            Assert.Fail("Api call failed.");
        }
    }
}

1. LoginSuccessTest:

• Scenario: Attempts to log in with correct credentials.
• Expected Outcome: Expect a successful response with a valid access token and refresh token.

2. LoginFailTest:

• Scenario: Attempts to log in with incorrect credentials.
• Expected Outcome: Expect an unsuccessful response with no access token and a failed login status.

3. RegistrationTest:

• Scenario: Attempts to register a new user.
• Expected Outcome: Expect a successful response indicating a successful registration.

4. RegistrationExistingUserTest:

• Scenario: Attempts to register an existing user.
• Expected Outcome: Expect an unsuccessful response indicating a failed registration due to an existing user.

5. RegistrationPasswordTest:

• Scenario: Attempts to register a user with a weak password.
• Expected Outcome: Expect an unsuccessful response with specific error messages indicating password strength requirements.

TokenTest class contains a set of tests that cover different scenarios related to token-based authentication and refresh token functionality.

public class TokenTest(CustomWebApplicationFactory<Program> factory) : IClassFixture<CustomWebApplicationFactory<Program>>
{
    private readonly HttpClient _client = factory.CreateClient();

    [Fact]
    public async void ApiSuccessTest()
    {
        var token = await GetToken();
        var apiRes = await GetSecureApiRes(token.AccessToken);
        apiRes.Should().NotBeNull();
        apiRes.StatusCode.Should().Be(HttpStatusCode.OK);

    }

    [Fact]
    public async void ApiFailureTest()
    {
        var apiRes = await GetSecureApiRes("");
        apiRes.Should().NotBeNull();
        apiRes.StatusCode.Should().Be(HttpStatusCode.Unauthorized);
    }

    [Fact]
    public async void TokenExpireTest()
    {
        var token = await GetToken();

        await Task.Delay(12000);
        HttpRequestMessage request = new(HttpMethod.Post, "/User/Profile");
        request.Headers.Add("Authorization", "Bearer " + token.AccessToken);
        var apiRes = await _client.SendAsync(request);
        apiRes.Should().NotBeNull();
        apiRes.StatusCode.Should().Be(HttpStatusCode.Unauthorized);
    }

    [Fact]
    public async void GetRefreshTokenTest()
    {
        var token = await GetToken();
        await Task.Delay(12000);
        var rtRes = await GetRefreshToken(new UserRefreshTokenRequest
        {
            AccessToken = token.AccessToken,
            RefreshToken = token.RefreshToken
        });
        rtRes.Should().NotBeNull();
        rtRes.StatusCode.Should().Be(HttpStatusCode.OK);
        var userRefreshTokenResponse = await rtRes.Content.ReadFromJsonAsync<AppResponse<UserRefreshTokenResponse>>();
        userRefreshTokenResponse.Should().NotBeNull();
        userRefreshTokenResponse?.IsSucceed.Should().BeTrue();
        userRefreshTokenResponse?.Data?.Should().NotBeNull();
        var apiRes = await GetSecureApiRes(userRefreshTokenResponse?.Data?.AccessToken ?? "");
        apiRes.Should().NotBeNull();
        apiRes.StatusCode.Should().Be(HttpStatusCode.OK);

    }

    [Fact]
    public async void RefreshTokenExpireTest()
    {
        var token = await GetToken();
        await Task.Delay(22000);
        var rtRes = await GetRefreshToken(new UserRefreshTokenRequest
        {
            AccessToken = token.AccessToken,
            RefreshToken = token.RefreshToken
        });
        rtRes.Should().NotBeNull();
        rtRes.StatusCode.Should().Be(HttpStatusCode.OK);
        var userRefreshTokenResponse = await rtRes.Content.ReadFromJsonAsync<AppResponse<UserRefreshTokenResponse>>();
        userRefreshTokenResponse.Should().NotBeNull();
        userRefreshTokenResponse?.IsSucceed.Should().BeFalse();
        userRefreshTokenResponse?.Data?.Should().BeNull();
        userRefreshTokenResponse?.Messages.Any(m => m.Key == "token").Should().BeTrue();

    }

    private async Task<UserLoginResponse> GetToken()
    {
        var userLoginRequest = new UserLoginRequest
        {
            Email = "UnifiedAppAdmin",
            Password = "UnifiedAppAdmin1!"
        };

        var jsonContent = JsonSerializer.Serialize(userLoginRequest);
        var content = new StringContent(jsonContent, Encoding.UTF8, "application/json");
        var response = await _client.PostAsync("/User/Login", content);
        var userLoginResponse = await response.Content.ReadFromJsonAsync<AppResponse<UserLoginResponse>>();
        return userLoginResponse?.Data ?? default!;
    }
    private async Task<HttpResponseMessage> GetSecureApiRes(string accessToken)
    {
        HttpRequestMessage request = new(HttpMethod.Post, "/User/Profile");
        request.Headers.Add("Authorization", "Bearer " + accessToken);
        return await _client.SendAsync(request);
    }
    private async Task<HttpResponseMessage> GetRefreshToken(UserRefreshTokenRequest userRefreshTokenRequest)
    {

        var jsonContent = JsonSerializer.Serialize(userRefreshTokenRequest);
        var content = new StringContent(jsonContent, Encoding.UTF8, "application/json");
        return await _client.PostAsync("/User/RefreshToken", content);
    }
}

1. ApiSuccessTest:

• Scenario: Requests a secure API resource with a valid access token.
• Expected Outcome: Expect a successful response with an HTTP status code of OK.

2. ApiFailureTest:

• Scenario: Requests a secure API resource with an empty access token.
• Expected Outcome: Expect an unauthorized response with an HTTP status code indicating failure.

3. TokenExpireTest:

• Scenario: Attempts to use an expired access token to access a secure API resource.
• Expected Outcome: Expect an unauthorized response due to the expired token.

4. GetRefreshTokenTest:

• Scenario: Obtains a new access token using a valid refresh token.
• Expected Outcome: Expect a successful response with a new access token, allowing access to a secure API resource.

5. RefreshTokenExpireTest:

• Scenario: Attempts to refresh the token with an expired refresh token.
• Expected Outcome: Expect a failure response, indicating that the refresh token has expired.

Summary

This article serves as a detailed guide on establishing integration tests for a .NET 8 Web API, with a specific focus on token authentication. It provides practical examples and scenarios to validate the effectiveness and reliability of the authentication system.

Source Code

For the complete code and more examples, check out the GitHub repository: UnifiedApp