
<Sponsorships>

This week's issue is sponsored by [**QuadSpinner**](https://quadspinner.com/).

</Sponsorships>

Performance optimization is my favorite thing about software engineering.
Over the last 5 years, I've encountered various performance problems
that taught me different ways to overcome them.

About a month ago, I ran into an issue with an API endpoint that wasn't scaling well.

This endpoint is used to calculate a report for an e-commerce web application.
It needed to talk to multiple modules (services) to gather all the necessary data,
combine it and perform the calculations.

I made a [post about it on LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:6966700329111310336/)
that resonated with many people.

<Image src="blogs/mnw_007/linkedin_post.png" width={762} height={742} />

In this newsletter, I want to break down what I did to achieve a **15x performance improvement**.

## Focus On Bottlenecks First

The first thing I do when I'm solving a performance problem
is determine where the slowest piece of the code is.
Fixing this part of the code will usually give the most significant improvement.

Solving one bottleneck can also reveal where the next bottleneck is.\
This is a continual process.

In my situation, there were a few bottlenecks:

- Calling the database from a loop
- Calling an external service multiple times
- Executing a complex calculation multiple times with identical parameters

How can you measure performance?

A simple approach can be using `System.Timers.Timer` where you
manually log execution times between method calls.
Or you can use a performance profiler.

## Reduce The Number of Round Trips

A round trip between your application and a database
(or some other service) can last 5-10ms, or more.
If you have many round trips in your flow, it's going to add up quickly.

Here are a few things you can do reduce the number of round trips:

1. Don't call the database from a loop. This can usually be solved with a simple query like this:

```sql
   SELECT * FROM [TableName] WHERE Id IN (list_of_ids)
```

2. Use a query that returns multiple result sets from the database.
   One library that supports this is [Dapper](https://github.com/DapperLib/Dapper), with the `QueryMultiple` method.

3. If you need to make multiple calls to another service, try to convert that into one call.
   And in the service, aggregate the required data and return everything at once.

## Parallelize External Calls

I had a situation where I was awaiting multiple asynchronous calls from a few services.
These calls had no dependencies on each other, so I used a simple technique
to gain a significant performance improvement.

Let's say you're awaiting two tasks:

```csharp
var task1Result = await CallService1Async();

var task2Result = await CallService2Async();

// Use the results.
```

A simple way to parallelize these calls is using the `Task.WhenAll` method:

```csharp
var task1 = CallService1Async();

var task2 = CallService2Async();

await Task.WhenAll(task1, task2);

// Use the results.
task1.Result;
task2.Result;
```

Notice that I'm directly accessing the `Result` property on the tasks.
This can be **detrimental** if you're using it to block on an asynchronous call,
and can even lead to deadlocks.

However, in this situation it is perfectly safe to do,
because the two tasks will have completed after the call to `Task.WhenAll` completes.

Of course, whether or not these tasks will be executed in parallel
when calling `Task.WhenAll` depends on a few factors, which I won't cover here.

## Caching As a Last Resort

I try to leave caching for the end, after I have exhausted
all other possibilities to improve performance.
While I love to use caching in general, I'm aware
it can introduce some unwanted behavior when data is stale.

You have to consider how long you can safely cache the data,
and how you are going to clear the cache if the underlying data changes.

In simple applications, I use `IMemoryCache`
that is available in **ASP.NET Core** out of the box.
But you can also use an external cache like [Redis](https://redis.io/).

A good candidate for caching is data that is frequently accessed, but rarely modified.

## Closing Thoughts

I think that for most Web applications,
performance optimization can be boiled down to the following approaches:

- [Focus on bottlenecks first](#focus-on-bottlenecks-first)
- [Reduce the number of round trips](#reduce-the-number-of-round-trips)
- [Parallelize external calls](#parallelize-external-calls)
- [Caching](#caching-as-a-last-resort)

I didn't talk about database optimization and indexes here,
but this should also be on your mind if the database is your bottleneck.

---



<Sponsorships>

This week's issue is sponsored by [**QuadSpinner**](https://quadspinner.com/).

</Sponsorships>

Let's imagine we have an existing `Repository` implementation, and we want to introduce caching to reduce the load on the database.

How can we achieve this without changing the original `Repository` implementation?

**Decorator pattern** is a structural design pattern that allows you
to introduce new behavior to an existing class, without modifying the original class in any way.

I'll show you how you can implement this with the **ASP.NET Core DI** container.

## How To Implement The Decorator Pattern

We'll start with an existing `MemberRepository` implementation that implements the `IMemberRepository` interface.

It has only one method, which loads the `Member` from the database.

Here's what the implementation looks like:

```csharp
public interface IMemberRepository
{
    Member GetById(int id);
}

public class MemberRepository : IMemberRepository
{
    private readonly DatabaseContext _dbContext;

    public MemberRepository(DatabaseContext dbContext)
    {
        _dbContext = dbContext;
    }

    public Member GetById(int id)
    {
        return _dbContext
            .Set<Member>()
            .First(member => member.Id == id);
    }
}
```

We want to introduce caching to the `MemberRepository` implementation without modifying the existing class.

To achieve this, we can use the **Decorator pattern** and create a wrapper around our `MemberRepository` implementation.

We can create a `CachingMemberRepository` that will have a dependency on `IMemberRepository`.

```csharp
public class CachingMemberRepository : IMemberRepository
{
    private readonly IMemberRepository _repository;
    private readonly IMemoryCache _cache;

    public CachingMemberRepository(
        IMemberRepository repository,
        IMemoryCache cache)
    {
        _repository = repository;
        _cache = cache;
    }

    public Member GetById(int id)
    {
        string key = $"members-{id}";

        return _cache.GetOrCreate(
            key,
            entry => {
                entry.SetAbsouluteExpiration(
                    TimeSpan.FromMinutes(5));

                return _repository.GetById(id);
            });
    }
}
```

Now I'm going to show you the power of **ASP.NET Core DI**.

We will configure the `IMemberRepository` to resolve an instance of `CachingMemberRepository`,
while it will receive the `MemberRepository` instance as its dependency.

## Configuring The Decorator In ASP .NET Core DI

For the DI container to be able to resolve `IMemberRepository` as `CachingMemberRepository`,
we need to manually configure the service.

We can use the overload that exposes a service provider,
that we will use to resolve the services required to construct a `MemberRepository`.

Here's what the configuration would look like:

```csharp
services.AddScoped<IMemberRepository>(provider => {
    var context = provider.GetService<DatabaseContext>();
    var cache = provider.GetService<IMemoryCache>();

    return new CachingRepository(
         new MemberRepository(context),
         cache);
});
```

Now you can inject the `IMemberRepository`, and the DI will be able to resolve an instance of `CachingMemberRepository`.

## Configuring The Decorator With Scrutor

If the previous approach seems _cumbersome_ to you and like a lot of manual work - that's because it is.

However, there is a simpler way to achieve the same behavior.

We can use the **[Scrutor](https://github.com/khellang/Scrutor)** library to register the decorator:

```csharp
services.AddScoped<IMemberRepository, MemberRepository>();

services.Decorate<IMemberRepository, CachingMemberRepository>();
```

**[Scrutor](https://github.com/khellang/Scrutor)** exposes the `Decorate` method.
The call to `Decorate` will register the `CachingMemberRepository` while ensuring
that it receives the expected `MemberRepository` instance as its dependency.

I think this approach is much simpler, and it's what I use in my projects.

---



In this newsletter, we'll be covering three ways to create middleware in **ASP.NET Core** applications.

**Middleware** allows us to introduce additional logic before or after executing an HTTP request.

You are already using many of the built-in middleware available in the framework.

I'm going to show you three approaches to how you can define custom middleware:

- [With Request Delegates](#adding-middleware-with-request-delegates)
- [By Convention](#adding-middleware-by-convention)
- [Factory-Based](#adding-factory-based-middleware)

Let's go over each of them and see how we can implement them in code.

## Adding Middleware With Request Delegates

The first approach to defining a middleware is by writing a **Request Delegate**.

You can do that by calling the `Use` method on the `WebApplication` instance
and providing a lambda method with two arguments.
The first argument is the `HttpContext` and the second argument is
the actual next request delegate in the pipeline `RequestDelegate`.

Here's what this would look like:

```csharp
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Use(async (context, next) =>
{
    // Add code before request.

    await next(context);

    // Add code after request.
});
```

By awaiting the `next` delegate, you are continuing the request pipeline execution.
You can _short-circuit_ the pipeline by not invoking the `next` delegate.

This overload of the `Use` method is the one suggested by **Microsoft**.

## Adding Middleware By Convention

The second approach requires us to create a class that will represent our middleware.
We have to follow the convention when creating this class so that we can use it as middleware in our application.

I'm first going to show you what this class looks like, and then explain what is the convention we are following here.

Here's how this class would look like:

```csharp
public class ConventionMiddleware(
    RequestDelegate next,
    ILogger<ConventionMiddleware> logger)
{
    public async Task InvokeAsync(HttpContext context)
    {
        logger.LogInformation("Before request");

        await next(context);

        logger.LogInformation("After request");
    }
}
```

The convention we are following has a few rules:

- We need to inject a `RequestDelegate` in the constructor
- We need to define an `InvokeAsync` method with an `HttpContext` argument
- We need to invoke the `RequestDelegate` and pass it the `HttpContext` instance

There's one more thing that's required, and that is to tell our application to use this middleware.

We can do that by calling the `UseMiddleware` method:

```csharp
app.UseMiddleware<ConventionMiddleware>();
```

And with this, we have a functioning middleware.

## Adding Factory-Based Middleware

The third and last approach requires us to also create a class that will represent our middleware.

However, this time we're going to implement the `IMiddleware` interface.
This interface has only one method - `InvokeAsync`.

Here's what this class would like:

```csharp
public class FactoryMiddleware(ILogger<FactoryMiddleware> logger) : IMiddleware
{
    public async Task InvokeAsync(HttpContext context, RequestDelegate next)
    {
        logger.LogInformation("Before request");

        await next(context);

        logger.LogInformation("After request");
    }
}
```

The `FactoryMiddleware` class will be resolved at runtime from dependency injection.

Because of this, we need to register it as a service:

```csharp
builder.Services.AddTransient<FactoryMiddleware>();
```

And like the previous example, we need to tell our application to use our factory-based middleware:

```csharp
app.UseMiddleware<FactoryMiddleware>();
```

With this, we have a functioning middleware.

## A Word On Strong Typing

I'm a big fan of **strong typing** whenever possible.
Out of the three approaches I just showed you, the one using the
`IMiddleware` interface satisfies this constraint the most.
This is also my **preferred** way to implement **middleware**.

Since we're implementing an interface, it's very easy to create
a generic solution to never forget to register your middleware.

You can use reflection to scan for classes implementing
the `IMiddleware` interface and add them to dependency injection,
and also add them to the application by calling `UseMiddleware`.

---



**Clean Architecture** is a popular approach to structuring your application.

It's a layered architecture that splits the project into four layers:

- [Domain](#domain-layer)
- [Application](#application-layer)
- [Infrastructure](#infrastructure-layer)
- [Presentation](#presentation-layer)

Each of the layers is typically one project in your solution.

Here's a visual representation of the **Clean Architecture**:

<Image src="blogs/mnw_004/clean_architecture.png" width={1920} height={1080} />

How do we create this in our .NET solutions?

## Domain Layer

The **Domain layer** sits at the core of the **Clean Architecture**.
Here we define things like: entities, value objects, aggregates, domain events, exceptions, repository interfaces, etc.

Here is the folder structure I like to use:

```
📁 Domain
|__ 📁 DomainEvents
|__ 📁 Entities
|__ 📁 Exceptions
|__ 📁 Repositories
|__ 📁 Shared
|__ 📁 ValueObjects
```

You can introduce more things here if you think it's required.

One thing to note is that the **Domain layer** is not allowed to reference other projects in your solution.

## Application Layer

The **Application layer** sits right above the **Domain layer**.
It acts as an orchestrator for the **Domain layer**, containing the most important use cases in your application.

You can structure your use cases using services or using commands and queries.

I'm a big fan of the **CQRS** pattern, so I like to use the command and query approach.

Here is the folder structure I like to use:

```
📁 Application
|__ 📁 Abstractions
    |__ 📁 Data
    |__ 📁 Email
    |__ 📁 Messaging
|__ 📁 Behaviors
|__ 📁 Contracts
|__ 📁 Entity1
    |__ 📁 Commands
    |__ 📁 Events
    |__ 📁 Queries
|__ 📁 Entity2
    |__ 📁 Commands
    |__ 📁 Events
    |__ 📁 Queries
```

In the `Abstractions` folder, I define the interfaces required for the **Application layer**.
The implementations for these interfaces are in one of the upper layers.

For every entity in the **Domain layer**, I create one folder with the commands, queries, and events definitions.

## Infrastructure Layer

The **Infrastructure layer** contains implementations for external-facing services.

What would fall into this category?

- Databases - PostgreSQL, MongoDB
- Identity providers - Auth0, Keycloak
- Emails providers
- Storage services - AWS S3, Azure Blob Storage
- Message queues - Rabbit MQ

Here is the folder structure I like to use:

```
📁 Infrastructure
|__ 📁 BackgroundJobs
|__ 📁 Services
    |__ 📁 Email
    |__ 📁 Messaging
|__ 📁 Persistence
    |__ 📁 EntityConfigurations
    |__ 📁 Migrations
    |__ 📁 Repositories
    |__ #️⃣ ApplicationDbContext.cs
|__ 📁 ...
```

I place my `DbContext` implementation here if I'm using **EF Core**.

It's not uncommon to make the Persistence folder its project.
I frequently do this to have all database facing-code inside of one project.

## Presentation Layer

The **Presentation layer** is the entry point to our system.
Typically, you would implement this as a Web API project.

The most important part of the **Presentation layer** is the `Controllers`, which define the API endpoints in our system.

Here is the folder structure I like to use:

```
📁 Presentation
|__ 📁 Controllers
|__ 📁 Middlewares
|__ 📁 ViewModels
|__ 📁 ...
|__ #️⃣ Program.cs
```

Sometimes, I will move the **Presentation layer** away from the actual Web API project.
I do this to isolate the `Controllers` and enforce stricter constraints.
You don't have to do this if it is too complicated for you.

## Is This The Only Way?

You don't have to follow the folder structure I proposed to the T.
**Clean Architecture** is very flexible, and you can experiment with it and structure it the way you like.

Do you like more granularity? Create more specific projects.

Do you dislike a lot of projects? Separate concerns using folders.

I'm here to give you options to explore. But it's up to you to decide what's best.

---



I recently ran into an issue with **Entity Framework Core**.

The query I was running was constantly timing out.

I tried to scale up the application server, and it didn't help.

I tried to scale up the database server, and it didn't help.

So how did I solve the problem?

## What Was The Problem With This Query?

I'm working on an application in the e-commerce domain.
To be specific, it's an order management system for a kitchen cabinet manufacturer.

The table that I frequently query on is the `Orders` table.
The `Order` can have one or more `LineItems`.
A typical `Order` will contain 50 `LineItems`.
Also, `LineItems` have a table that contains the valid dimensions - `LineItemDimensions`.

This is the query I was trying to run:

```csharp
dbContext
    .Orders
    .Include(order => order.LineItems)
    .ThenInclude(lineItem => lineItem.Dimensions)
    .First(order => order.Id == orderId);
```

When EF Core converts this into SQL, this is what it will send to the database:

```sql
SELECT o.*, li.*, d.*
FROM Orders o
LEFT JOIN LineItems li ON li.OrderId = o.Id
LEFT JOIN LineItemDimensions d ON d.LineItemId = li.Id
WHERE o.Id = @orderId
ORDER BY o.Id, li.Id, d.Id;
```

In most cases, this query will execute just fine.

However, in my situation I was running into the problem of _Cartesian Explosion_.
This is mainly because of the join to the `LineItemDimensions` table.
And this is what's causing my query to fail, and time out.

So how did I solve this problem?

## Query Splitting To The Rescue

With the release of **EF Core 5.0** we got a new feature called **Query Splitting**.
This allows us to specify that a given LINQ query should be split into multiple `SQL` queries.

To use **Query Splitting**, all you need to do is call the `AsSplitQuery` method:

```csharp
dbContext
    .Orders
    .Include(order => order.LineItems)
    .ThenInclude(lineItem => lineItem.Dimensions)
    .AsSplitQuery()
    .First(order => order.Id == orderId);
```

In this case, EF Core will generate the following SQL queries:

```sql
SELECT o.*
FROM Orders o
WHERE o.Id = @orderId;

SELECT li.*
FROM LineItems li
JOIN Orders o ON li.OrderId = o.Id
WHERE o.Id = @orderId;

SELECT d.*
FROM LineItemDimensions d
JOIN LineItems li ON d.LineItemId = li.Id
JOIN Orders o ON li.OrderId = o.Id
WHERE o.Id = @orderId;
```

Notice that for each `Include` statement we have a separate `SQL` query.
The benefit here is that we are not duplicating data when fetching from the database,
as we were in the previous case.

## Turning On Query Splitting For All Queries

You can enable **Query Splitting** at the database context level.
When configuring your database context you need to call the `UseQuerySplittingBehavior` method:

```csharp
services.AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlServer(
        "CONNECTION_STRING",
        o => o.UseQuerySplittingBehavior(
            QuerySplittingBehavior.SplitQuery)));
```

This will cause all queries that EF Core generates to be split queries.
To revert back to a single query, you need to call the `AsSingleQuery` method:

```csharp
dbContext
    .Orders
    .Include(o => o.LineItems)
    .ThenInclude(li => li.Dimensions)
    .AsSingleQuery()
    .First(o => o.Id == orderId);
```

## What You Should Know About Query Splitting

Although query splitting is an excellent addition to EF Core, there are a few things you need to be aware of.

There is no consistency guarantee for multiple SQL queries.
You may run into a problem if you have a concurrent update going through
at the same time when you query your data.
To mitigate this, you can wrap the queries inside of a transaction, but this will only introduce performance issues elsewhere.

Each query will require one network round trip. This can degrade performance if your latency to the database is high.

Now that you are armed with this knowledge, go and make your EF queries faster!

---



Today, I'm going to share some fascinating things you can do with records and anonymous types.
I will introduce you to the concept of non-destructive mutation.
And I will talk about when and why we might want to use this C# language feature.

## What Is a Record?

With **C# 9** we can use **records** that are a new reference type.
**C# 10** introduced record structs so that you can define records as value types.
Records are distinct from classes in that record types use value-based equality.

Let's see how we would define a `record`:

```csharp
public record Food(string Name, double Price);
```

This way of declaring a `record` is called a positional record.
The constructor we have defined here is called the **primary constructor**.

The `Name` and `Price` properties are init only properties.
This means they can only be set in the constructor or using a property initializer.

Since our properties are init only, is there any way to change their value?

## Non-Destructive Mutation Using The With Expression

We said we can't modify the properties of our `record`, because the properties are init only.
However, we can use the `with` expression (introduced in **C# 9**) to create a new instance
of our record with modified values.

Let's see how we would use the `with` expression:

```csharp
var banana = new Food("🍌", 1.95);

var bananaOnSale = banana with
{
    Price = 0.99
};
```

It's important to highlight two things here:

- The original banana instance remains unchanged
- The `with` expression creates a new record instance with only the `Price` property modified

I mentioned Anonymous Types in the title, so let me show you something interesting you can do with them.

## Anonymous Types And Non-Destructive Mutation

Did you know that you can use the `with` expression with anonymous types?

Just a reminder that the `with` expression is available from **C# 9** and later.

Let's create an anonymous type:

```csharp
var apple = new
{
    Name = "🍎",
    Price = 1.21
};
```

This is how we can modify it using the with expression:

```csharp
var orange = apple with
{
    Name = "🍊"
};
```

And again the same rules apply:

- The original apple instance remains unchanged
- The with expression creates a new anonymous type instance with only the Name property modified

I found this feature useful in LINQ method chains.

For example, loading an anonymous type from the database where some properties have a default value.
You can then use this feature to calculate the values for these properties in memory.

---



## Wishing You a Warm Welcome

First, I want to welcome you to the first edition of **Milan's .NET Weekly** newsletter.

I hope that this newsletter can become a positive force in the .NET community.
To bring many of us together so that we can all continue learning and improving.

With that out of the way, let's get into .NET!

## The Problem With Wide LINQ

Let's consider the following LINQ expression from a code style perspective.

I call this a wide LINQ expression because it stretches horizontally across the entire screen.

```csharp
dbContext.Animals.Where(animal => animal.HasBigEars)
    .OrderBy(animal => animal.IsDangerous).Select(
        animal => (animal.Id, animal.Name)).ToList();
```

- It is difficult to read.
- It is difficult to reason about.
- It is difficult to extend or maintain.

To improve this, I created a simple rule that you can follow:

> When writing LINQ, try to go tall, not wide.

## How to Write Tall LINQ

So how do we write tall LINQ expressions?

I'm going to rewrite the previous expression, to improve it.

Try to follow the _one dot per line rule_:

```csharp
dbContext
    .Animals
    .Where(animal => animal.HasBigEars)
    .OrderBy(animal => animal.IsDangerous)
    .Select(animal => (animal.Id, animal.Name))
    .ToList();
```

Is the new version easier to read? **Yes**, very much so.

It is easier to understand what each expression does,
and how it feeds into the next one in the chain.

If you are working in a team, try to propose this as a coding standard (if it isn't one already).\
You will see that over time this will make a noticeable difference.

---


Previous issues of Milan's .NET Weekly