Forem: Paula Fahmy

EF Core Change Tracking: The Bug Factory You Accidentally Built

Paula Fahmy — Mon, 19 Jan 2026 13:25:38 +0000

Most production EF Core problems do not start with broken code.
They start with code that works.

Queries return data. Updates succeed. Performance looks acceptable. Then traffic grows, memory spikes, SQL logs explode, or worse, random primary key violations start appearing in places no one touched. Someone flips AsNoTracking() on or off, the system stabilizes, and the team moves on.

Until it happens again (somewhere else).

This article is about how we got there, why those bugs happen, and how to design your data access so you stop toggling tracking like a panic button.

How the Story Usually Starts

EF Core enables change tracking by default.

That sounds reasonable. You query entities, you modify them, you call SaveChanges(). EF figures out what changed and generates SQL. Simple.

That default quietly works its way into production.

Every query tracks entities. Long-lived DbContexts accumulate them. Memory usage grows. GC pressure increases. Latency creeps up. Someone profiles the app and notices thousands of tracked entities sitting in memory doing nothing.

The fix seems obvious.

services.AddDbContext<AppDbContext>(options =>
{
    options.UseSqlServer(conn);
    // Applies everywhere
    options.UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking);
});

Performance improves immediately. Memory drops. Everyone relaxes.

Then the first relationship update fails with a duplicate key exception.

The Bug You Have Seen and Ignored

Before the change, this worked:

var order = await context.Orders
    .Include(o => o.Customer)
    .FirstAsync(o => o.Id == orderId);

order.Customer = existingCustomer;

await context.SaveChangesAsync();

After disabling tracking globally, the same code throws:

Cannot insert duplicate key row in object 'Customers'
The duplicate key value is (...)

Nothing in the code changed. The database did not change. Only tracking did.

This is not an EF Core bug. This is EF Core doing exactly what you asked, just not what you expected.

What Change Tracking Actually Is

Change tracking is EF Core keeping an internal graph of entities it is responsible for.

Tracked entities have:

A known identity (primary key)
A known state (Unchanged, Modified, Added, Deleted)
Snapshot or proxy-based detection of changes

When you call SaveChanges(), EF:

Compares tracked entities against their original state
Generates SQL only for what changed
Maintains relationship consistency automatically

When an entity is not tracked, EF does none of this.

No state. No identity map. No relationship awareness.

Why AsNoTracking() Exists

AsNoTracking() tells EF:

"This data is read-only. Do not waste memory or CPU tracking it."

That is correct and valuable for:

Large result sets
Read-heavy endpoints
Reporting
Projections that will never be saved

Example:

var orders = await context.Orders
    .AsNoTracking()
    .Where(o => o.Status == Status.Open)
    .ToListAsync();

This is faster, leaner, and safer than tracking by default. Nothing is kept in memory for later usage (like when using tracking).

The mistake is using it everywhere without understanding the consequences.

Commands and Queries Are Not the Same Thing

Queries want:

Speed
Low memory usage
No side effects

Commands want:

State awareness
Relationship handling
Correct updates

Using the same tracking strategy for both is where most systems break.

Why SaveChanges() Does Nothing on Detached Entities

Consider this:

var user = await context.Users
    .AsNoTracking()
    .FirstAsync(u => u.Id == id);

user.Name = "New Name";

await context.SaveChangesAsync();

No error. No update. Nothing happens.

Why?

Because EF is not tracking user. From EF’s perspective, nothing changed because nothing was being watched.

This is a silent failure. The worst kind.

The Relationship Trap That Causes Duplicate Keys

This one is more dangerous.

var order = await context.Orders
    .AsNoTracking()
    .FirstAsync(o => o.Id == orderId);

order.Customer = existingCustomer;

context.Orders.Update(order);
await context.SaveChangesAsync();

EF sees:

An untracked Order
A referenced Customer object
No tracking information for either

So it assumes both are new.

EF generates:

INSERT for Order
INSERT for Customer

If the customer already exists, the database rejects it.

This is why disabling tracking globally often "fixes performance" and then breaks relationships.

Attach vs Update vs Already Tracked

These three are not interchangeable.

Tracked Entity (Best Case)

var product = await context.Products.FirstAsync(p => p.Id == id);
product.Price += 10;

await context.SaveChangesAsync();

// Generated SQL:
// UPDATE [Products] SET [Price] = @p0 WHERE [Id] = @p1;

EF tracks changes
Only modified columns are updated
Minimal SQL

Attach

var product = await context.Products.AsNoTracking().FirstAsync(p => p.Id == id);
context.Attach(product);

product.Price += 10;

await context.SaveChangesAsync();

// Generated SQL: // UPDATE [Products] SET [Price] = @p0 WHERE [Id] = @p1;

EF assumes entity exists
Only modified properties are updated
Safe when you know the entity is not new

Update

var product = await context.Products.AsNoTracking().FirstAsync(p => p.Id == id);
product.Price += 10;
context.Update(product); // This forces all columns to be updated
await context.SaveChangesAsync();

EF marks all properties as modified
Generates full-row UPDATE
Large SQL statements
Overwrites columns you did not touch

UPDATE [Products]
SET [Price] = @p0,
    [Name] = @p1,
    [Description] = @p2,
    [Stock] = @p3,
    [CategoryId] = @p4
WHERE [Id] = @p5;

Calling Update() on an already tracked entity is unnecessary and wasteful. EF already knows what changed.

Practical Demo Scenarios

1. Tracked Update Works

var user = await context.Users.FirstAsync(u => u.Id == id);
user.Email = "new@email.com";
await context.SaveChangesAsync();

Correct update. Minimal SQL.

2. AsNoTracking Causes Silent No-Op

var user = await context.Users
    .AsNoTracking()
    .FirstAsync(u => u.Id == id);

user.Email = "new@email.com";
await context.SaveChangesAsync();

No update. No error. No warning.

3. AsNoTracking + Add Causes Duplicate Key Failure

var role = await context.Roles
    .AsNoTracking()
    .FirstAsync(r => r.Id == roleId);

context.Roles.Add(role);
await context.SaveChangesAsync();

EF tries to insert an existing role.

4. Attach Updates Only Modified Columns

context.Attach(user);
user.IsActive = false;
await context.SaveChangesAsync();

Clean and safe when used intentionally.

5. Update Forces Full-Row Update

context.Update(user);
await context.SaveChangesAsync();

All columns marked modified. Bigger SQL. Higher risk.

The Real Fix: Stop Toggling Tracking

The root problem was not EF Core.
It was mixing read and write intent in the same data access path.

The fix was structural.

Splitting Repositories by Intent

Instead of enabling and disabling tracking everywhere, we split repositories.

Read-Only Repository

public class OrderReadRepository
{
    public Task<OrderDto> GetById(Guid id) =>
        context.Orders
            .AsNoTracking()
            .Where(o => o.Id == id)
            .Select(o => new OrderDto(...))
            .FirstAsync();
}

Always no tracking
Safe by design
Easy to cache
Easy to move to a read replica later

Read-Write Repository

public class OrderWriteRepository
{
    public Task<Order> GetTracked(Guid id) =>
        context.Orders.FirstAsync(o => o.Id == id);

    public Task Save() => context.SaveChangesAsync();
}

Tracking is expected
Relationships work
Updates are correct

No flags. No guessing.

One more good idea is to have this kind of configuration set once and for all:

public abstract class ReadOnlyRepository where TEntity : class
{

protected readonly DbContext _context;protected readonly DbSet _dbSet;

protected ReadOnlyRepository(DbContext context)
{
    _context = context;
    _dbSet = context.Set<TEntity>();
    _context.ChangeTracker.QueryTrackingBehavior = QueryTrackingBehavior.NoTracking;
}

public virtual IQueryable<TEntity> GetAll() => _dbSet;
public virtual Task<TEntity> GetByIdAsync(object id) => _dbSet.FindAsync(id).AsTask();

}

public abstract class ReadWriteRepository where TEntity : class
{

protected readonly DbContext _context;protected readonly DbSet _dbSet;

protected ReadWriteRepository(DbContext context)
{
    _context = context;
    _dbSet = context.Set<TEntity>();
    _context.ChangeTracker.QueryTrackingBehavior = QueryTrackingBehavior.TrackAll;
}

public virtual IQueryable<TEntity> GetAll() => _dbSet;
public virtual Task<TEntity> GetByIdAsync(object id) => _dbSet.FindAsync(id).AsTask();

public virtual void Add(TEntity entity) => _dbSet.Add(entity);
public virtual void Update(TEntity entity) => _dbSet.Update(entity);
public virtual void Remove(TEntity entity) => _dbSet.Remove(entity);
public virtual Task<int> SaveChangesAsync() => _context.SaveChangesAsync();

}

Why This Is Not Just Clean Code Overhead

This approach:

Eliminates accidental tracking
Prevents silent no-ops
Prevents duplicate key bugs
Makes performance predictable
Makes intent explicit

At the application layer, it aligns naturally.

A GET endpoint injects a read-only repository.
A command handler injects a write repository.

This pattern scales upward.
It enables read replicas, caching layers, and even separate databases later.

Not because you planned CQRS.
Because you respected intent.

Lessons Learned

Tracking is powerful but expensive
NoTracking is safe only for reads
SaveChanges does nothing for detached entities
Update is a blunt instrument
Attach is precise when used correctly
Repository design must reflect query vs command intent

You do not need full CQRS to think this way.
You just need to stop pretending reads and writes are the same thing.

EF Core was never the problem.
The defaults were.

Once you understand that, the bugs you ignored for years suddenly make sense.

Understanding the Magic of Logarithms in Binary Search

Paula Fahmy — Sat, 09 Mar 2024 15:17:46 +0000

Hey community! 👋 Today, let's demystify the magic behind the efficiency of algorithms like binary search. Ever wondered why we say binary search has a time complexity of O(log N)?

Let's break it down in simple terms.

Imagine you have a row of boxes, and you want to find a particular item in one of them. Now, let's use binary search to make this process super efficient.

Step 1: Start with 16 boxes.

📦📦📦📦📦📦📦📦📦📦📦📦📦📦📦📦

Step 2: Each time, divide the number of remaining boxes by 2.

📦📦📦📦📦📦📦📦   📦📦📦📦📦📦📦📦

Step 3: Repeat until you have only one box left.

        📦📦📦📦📦📦📦📦   📦📦📦📦📦📦📦📦
Step 1:           📦📦📦📦   📦📦📦📦
Step 2:                📦📦   📦📦
Step 3:                   📦   📦
Step 4:                      📦

Here's the cool part: The number of steps it takes to go from 16 boxes to 1 box is surprisingly related to the concept of logarithms!

Mathematically, we can represent this as:

In the case of our 16 boxes example, it becomes:

Now, let's use logarithms to solve for the number of steps. Taking the base-2 logarithm of both sides gives us:

So, in this example:

Steps in this case equals to 4..

Voila! The number of steps it takes to find an item in our binary search is logarithmic with respect to the number of elements (N) we started with. Hence, the time complexity of binary search is O(log N).

Understanding this concept can help us appreciate the efficiency of algorithms that reduce the search space by half in each step.

Happy searching! 🔍💡 #AlgorithmMagic #BinarySearch #LogarithmsExplained

Interview Questions: Singleton Pattern vs the Static Keyword

Paula Fahmy — Fri, 04 Mar 2022 14:46:11 +0000

Introduction

If you've been in the tech industry for a while, you've certainly heard about the buzz words: "Design Patterns", maybe you've also heard about a famous pattern, the Singleton. Additionally, if you've been coding for a brief period, I'm hundred percent sure you've used the keyword static in one or more of your favorite programming languages.

For all of you experienced techies, you might already recognize that "Singletons" are used to create one and only one instance object of a class.

Hello World! once again, today with another interesting programming topic, let's discuss the differences between using the keyword static and implementing the Singleton Design Pattern.

Tech explanation aside, I want to quickly point out that I was hit by question lately while interviewing for a .NET Developer role in a software house, luckily I was prepared because it has popped into my mind a while ago before the interview itself.
Anyways, this is an interview question, so ladies and gentlemen, start taking notes.

I'm going to host my discussion in C# since it is a really powerful programming language, and it is in fact similar to other famous languages like Java and C++, just keep in mind that what's written in this blog should apply to any OOP language, so pick your favorite, and hop on.

The `static` Keyword

We normally use the static keyword (in C#) in order to declare:

Static Classes
Static Class Members, such as:
- Constructors
- Fields
- Properties
- Methods

This specific type of declaration is useful when only one copy of the object (class or class members) is needed that single instance is shared globally among all other objects, in other words the static variable belongs to the type itself rather than to a specific object created from that type.

Let me throw a real-life example to make things a little bit clearer.
I love Mustangs, the Ford cars of course (who doesn't!)...

Let's say we are developing a game, and we want to model this type of car on its own class, what are the properties that we should include?

I'm thinking:

Color
Body type (hatchback or regular)
Top Speed (could differ depending on the model)
First year of production (1965)
Year Model
Logo

Now, we know that "First year of production" for this type of car will always be 1965, also the "Logo", it's the same for all cars. Now let's say Ford decides to modify the logo for some reason, it should be changed for all cars, right?
These two variables are perfect candidates for static variables.
Other variables should depend on the car itself (the object) and could differ for every single one.

class Mustang 
{
    public string Color { get; set; }
    public bool IsHatchback { get; set; }
    public int TopSpeed { get; set; }
    public int YearModel { get; set; }
    public static int FirstYearInProduction { get; set; } = 1965;
    public static string LogoURL { get; set; } = "https://ford.com/logo.png";
}

See how the compiler complains when trying to access the static variable from an instance object?

Which makes sense actually, why would I ask about the first production year using my car, or my friend's car, it's all the same at the end, right?

So in a way, FirstYearInProduction and LogoURL are being singleton-like in their nature, same value for all instances, right?

Like fields and properties, static methods also belong to the type itself.
.. and for the sake completeness of this article, let me list down the features of static classes in C#:

They can only contain static data members.
It is not allowed to create objects of the static class.
Static classes are sealed (could not be inherited from).

Okay, now that we've scratched the surface of the static keyword in most programming languages, now let's discuss what a Singleton Pattern means in order to formulate a rational comparison.

But wait, what are design patterns in the first place⁉️

Design Patterns

According to refactoring.guru:

Design patterns are typical solutions to common problems
in software design. Each pattern is like a blueprint
that you can customize to solve a particular
design problem in your code.

Design Patterns comes in different sizes and shapes, and they can be categorized into 3 main types:

Creational: These patterns are designed for class instantiation. They can be either class-creation patterns or object-creational patterns.
Structural: These patterns are designed with regard to a class's structure and composition. The main goal of most of these patterns is to increase the functionality of the class(es) involved, without changing much of its composition.
Behavioral: These patterns are designed depending on how one class communicates with others.

Singleton Design Pattern

Now, let's get back to our main subject, the Singleton Pattern.

Singletons are not part of a specific language (not a keyword for example) or do they belong to frameworks. Singletons are just special classes built in a special way to fit in a special use case..
Lot of "specials", huh? That's the case with most modern design patterns.

The pattern's main objective is to create only one instance of a class and to provide only one global access point to that object.

As you might've guessed, this description fits nicely into the Creational patterns category, because at the end, we are "creating" an object, with only a "single" instance.

So filling in the gaps of Refactoring Guru's definition stated above, the current design problem at hand is that we need to create only one instance of the object, that's why we've chosen the Singleton Design Pattern.

Singleton Implementation in C#

Now I'm going to write down a couple of versions of Singletons in C#, let's start first by the simplest one, a Naïve one if you will, and I'm going to explain why it wouldn't hold up in tough environments in a moment.

Naïve Singleton

public sealed class NaiveSingleton
{
    private static NaiveSingleton _instance;

    private NaiveSingleton() { }

    public static NaiveSingleton GetInstance()
    {
        if (_instance == null)
        {
            _instance = new NaiveSingleton();
        }
        return _instance;
    }

    public void someBusinessLogic()
    {
        // ...
    }
}

First up, notice the sealed keyword, Singletons should always be a "sealed" in order to prevent class inheritance, which could end up with multiple instances and this contrasts the whole point of Singletons.

Also, the constructor must be private to prevent creating new instances.

Now the GetInstance() method, this is the main entry point for the class, it serves as an alternative to the constructor (which we hid using the *private** keyword)* and lets clients access the same instance of this class over and over.
On the first run, it creates a singleton object and assigns it into the static field _instance.
On subsequent runs, it returns the existing object stored in the static field.

To test our code, we could run this snippet on the main() function of our console application:

static void Main(string[] args)
{
    NaiveSingleton s1 = NaiveSingleton.GetInstance();
    NaiveSingleton s2 = NaiveSingleton.GetInstance();

    if (s1 == s2)
    {
        Console.WriteLine("Singleton works, both variables contain the same instance.");
    }
    else
    {
        Console.WriteLine("Singleton failed, variables contain different instances.");
    }
}

And the output should be as expected:

Singleton works, both variables contain the same instance.

Great, both s1 and s2 are essentially the same, right? Ummm, not always.

Of course, there's a culprit, it shouldn't be that straightforward huh? 😁

Why isn't our solution sophisticated enough?

To better explain my point, let me adjust our main() function a little bit and introduce some asynchrony into the problem.

⚠️ Disclaimer: The following part is a little bit advanced (just a little bit, I promise) and needs some basic understanding of the asynchronous operation in C#, if you don't feel comfortable with async, await and C# Tasks, feel free to check my DEV.TO series about the topic where I attempt to make a simple cup of tea, asynchronously.

Back to our main() function:

static void Main(string[] args)
{
    // Delay getting an instance of our singleton by doing so inside a task.
    Task<NaiveSingleton> ts1 = Task.Run(() => NaiveSingleton.GetInstance());
    Task<NaiveSingleton> ts2 = Task.Run(() => NaiveSingleton.GetInstance());

    // Run both tasks in parallel
    await Task.WhenAll(ts1, ts2);

    // Get the result of each task
    NaiveSingleton s1 = await ts1;
    NaiveSingleton s2 = await ts2;

    if (s1 == s2)
    {
        Console.WriteLine("Singleton works, both variables contain the same instance.");
    }
    else
    {
        Console.WriteLine("Singleton failed, variables contain different instances.");
    }
}

The main point of the previous modification is to access the GetInstance() method of the Singleton from two different "contexts" at the same time, for example, two different threads.

📝 Side Note: The previous modification might have not essentially created a whole new thread, but it certainly accessed the GetInstance() method from two different contexts, for an explanation, read through this StackOverflow answer, you can check this shorter one too on the same question.

Now, let's check the output of the previous modification:

Singleton failed, variables contain different instances.

So, what happened?
Check the comments within the snippet for clarifications

public static NaiveSingleton GetInstance()
{
    // Both contexts entered the GetInstance() method at the same time,
    // both of them queried whether _instance is null at the same time,
    // and since _instance was in fact initially null,
    // both succeeded to enter the if clause at the same time 
    if (_instance == null)
    {
         // .. which resulted in the creation of a new Instance 
         // twice for each context
        _instance = new NaiveSingleton();
    }
    return _instance;
}

Let's fix this small bug, and make our Singleton a little bit more Sophisticated.

Sophisticated Singleton

public sealed class SophisticatedSingleton
{ 
    private static SophisticatedSingleton _instance; 
    private static readonly object _lock = new object(); 

    private SophisticatedSingleton() { } 

    public static SophisticatedSingleton GetInstance()
    {
        lock (_lock)
        {
            if (_instance == null)
            {
                _instance = new SophisticatedSingleton();
            }
        }
        return _instance;
    }
}

Straight up, we could notice a couple of lines making this version a little different than its Naïve sibling.

Simply speaking, I've added a lock object and utilized it using C#'s lock() keyword, this will be used to synchronize threads during first access to the Singleton.

During the initial launch of the program, there are no instances yet, multiple contexts (caused by the Task.WhenAll() call) will simultaneously reach the lock at the same time.
The first of them will acquire it and will proceed further creating an instance, while the others will wait for the lock to be released.

Once the first context leaves the lock block, another context that might have been waiting for the lock release will then enter this section.
This time the Singleton field is already initialized and there would be no further need to initialize it once more with a new instance.

Now let's test our fix, I'll replace references to the NaiveSingleton in our Main() method and migrate to the newer SophisticatedSingleton:

static void Main(string[] args)
{
    // Delay getting an instance of our singleton by doing so inside a task.
    Task<SophisticatedSingleton> ts1 = Task.Run(() => SophisticatedSingleton.GetInstance());
    Task<SophisticatedSingleton> ts2 = Task.Run(() => SophisticatedSingleton.GetInstance());

    // Run both tasks in parallel
    await Task.WhenAll(ts1, ts2);

    // Get the result of each task
    SophisticatedSingleton s1 = await ts1;
    SophisticatedSingleton s2 = await ts2;

    if (s1 == s2)
    {
        Console.WriteLine("Singleton works, both variables contain the same instance.");
    }
    else
    {
        Console.WriteLine("Singleton failed, variables contain different instances.");
    }
}

And here goes our expected output:

Singleton works, both variables contain the same instance.

Hurray 🥳!

Eager vs Lazy Initialization

There is yet one another customization to how you'd implement a singleton.

We've been initializing Singletons throughout the previous couple of examples "lazily", which means that an instance would not be initialized unless the getInstance() function has been called and the _instance == null check returned true, only then would an instance be initialized, in other words, _instance would never be initialized unless at least one context needs it.

But what if we want the Singleton's instance to be available right away?

public sealed class EagerSingleton
{
    private EagerSingleton() { }

    private static EagerSingleton _instance = new EagerSingleton();

    public static EagerSingleton GetInstance()
    {
        return _instance;
    }
}

A minor tweak to the original Naïve Singleton could be done, where we initialize the static _instance field inline, making it ready for usage right before needing it.

This has the benefit of making the instance instantly available, but, a major drawback should be accounted for.

Eagerly initializing the field means that it would be initialized even if no one ever needs it, taking into consideration whether the instance itself might require heavy processing or a substantially large amount of memory bytes, this would certainly form an overhead for your application, so be sure to use this technique wisely.

Use Cases of Singletons

Now I can think of a couple of real-life use cases, for example, we could design our own custom Logger class by it being defined as a singleton. No need to create a new instance every time we need to log something into the console or the database.

Speaking of databases, we could also build our database context using the Singleton Pattern, because again, no need for multiple instances, only one is enough.
One would argue that it would be better to register it as a service (depending on the dependency injection framework of your choice) and inject it to whatever the class that needs it, which is totally valid of course, but for simple projects, I think it would be perfectly fine to design the context as a Singleton.

In addition to database connections and logging services, Singleton classes could also be used for driver objects, caching, or thread pools.

Takeaway 📒

So to answer the main question:

What are the similarities and differences between the two approaches?

As you might've already noticed, a Singleton is nothing but some wrapping methods around a core static field packaged into a sealed class that has no public constructors.

A static field indeed helps in making an object globally accessed, but by itself, it neither does help in making it threadsafe nor lazily constructed, it does not introduce encapsulation into the game, meaning you'll access the field directly without a custom "getter" (like getInstance() method in our case) and it might be dangerous to expose the field like so in some cases.

Here are some key differences that could also be included in our research:

A Singleton can implement interfaces and inherit from other classes. While a static class cannot inherit their instance members. So Singleton is more flexible than static classes and can maintain state.
A Singleton can be initialized lazily, while a static class is generally initialized when it is first loaded.
Singleton Objects are stored on the heap while static classes are stored in stack.
Singleton Objects can dispose but static classes can't.
Singleton Objects can clone but static classes can't.

To sum up 📒, I could use this answer from Stackoverflow:

Static classes are not for anything that needs state. It is useful for putting a bunch of functions together i.e Math (or Utils in projects). So the class name just gives us a clue where we can find the functions and nothing more.

So whenever you need to choose between the two approaches, ask yourself the following question:

If there is a bunch of functions that should be packaged together: go for static.
Anything else which needs single access to some resources and state maintaining, singleton should be the way to go.

Side Note 🗒️:
Singletons are sometimes considered as anti-patterns, here's why:

As we've discussed, Singletons are basically a way to use global variables, global variables are bad because any code anywhere in the system can change their values. So when debugging, it can be challenging to figure out which code path leads to the Singleton's current state.
The previous problem can be handled by proper encapsulation mechanisms though, just be a little bit mindful about how you implement them.

I'd recommend reading this StackOverflow thread about the topic.

Outro

A Singleton class is a pattern, one of many in fact. It would be a great idea to read more about other design patterns too, Refactoring Guru hosts explanations to most of them in a nicely illustrated way, be sure to check them out.

It was my pleasure to conduct this research, and I hope you'd find it interesting and informative. In case you have something on your mind, let's discuss it in the comments section.

Keep Coding 💻!
See you soon. 👋

One-Tap Deployments with Nginx and Docker: Serving your Web Cluster w/ Compose 🐳

Paula Fahmy — Fri, 20 Aug 2021 19:46:30 +0000

Welcome back to the series. In the last article we discussed multiple approaches to configure Nginx for web applications and clusters, now that we've got ourselves good knowledge about it, let's see how we can take it one step further by containerizing a configured Nginx instance pointing at our cluster of backend containers, and deploying the full setup with one tap.

Let's start with the Docker Compose file, I'll be using the published strm/helloworld-http image as the web application for our project:

version: '3'
services:

  app1:
    image: strm/helloworld-http
    container_name: hello_1

  app2:
    image: strm/helloworld-http
    container_name: hello_2

  app3:
    image: strm/helloworld-http
    container_name: hello_3

  nginxserver:
    build: ./Server
    ports:
      - "8080:8080"
    container_name: server

On the file above, I created 3 containers from the Image strm/helloworld-http, I also gave each one a friendly name so that we can access it easily from Nginx using Docker's own DNS lookup.
I also added the server container, pointing to its own Dockerfile location and having a name too.

Now, onto Nginx's Dockerfile:

FROM nginx
COPY nginx.conf /etc/nginx/nginx.conf

The whole point of the file is to copy the configuration automatically into the container upon building it, /etc/nginx is the path where Nginx reads its configurations which would be copied from the local machine.

Finally, let's see how to .conf file would look like:

http {

    upstream apps{
        server hello_1:80;
        server hello_2:80;
        server hello_3:80;
    }

    server {
        listen 8080;
        location / {
            proxy_pass http://apps/;
        }
    }

}
events { }

Important Docker 🐳 Notes:
We used the container names we set earlier in the compose file to access the upstream servers, this is valid because Docker creates a DNS record automatically to point to the container's IP address using its name, that way, you don't have to keep track of the container's IP address.

Container Name	IP Address
hello_1	172.24.0.3
hello_2	172.24.0.4
hello_3	172.24.0.6

Another note to take is that we did not do any port mapping for our three apps, I skipped it for a purpose, here is why:

📝 Reason #1
Each container is already exposed internally on port 80, exposing the container means that we could access it from within the container's network, which is also the one automatically created when we build the docker-compose file.

📝 Reason #2
Mapping a container's port means that we could access it from the host machine, aka localhost, so technically, if we created our container this way: docker run -p 1111:80 strm/helloworld-http we could access it through localhost:1111.

This is all okay if you are accessing the container from the host machine, namely, your machine, the one that has Docker installed, but accessing the container from another container is a whole another story.

If you entered the bash terminal of the Linux container running Nginx and tried to ping localhost:1111 you'll get a nasty time-out error, because from within the container, localhost or 127.0.0.1 means the container itself, not the host machine, so you'd want to figure out the host's IP Address that's accessible from inside Nginx's container in order to access the app on port 1111.
We can skip all the hassle and just use the exposed port with Docker's DNS resolved hostname of the container.

If you've reached up to this point, I've got some good news for you, we are finally about to be run our cluster, let's group our files in a single directory:

|-- HelloNginx
|  |-- docker-compose.yml
|  |-- Server
|  |  |-- nginx.conf
|  |  |-- Dockerfile

... fire up your terminal, head to the root folder of the project /HelloNginx where the compose file exists, and run this command:

foo@bar:~$ docker-compose up
•••

... now head to Nginx Gateway URL: localhost:8080 (remember, we've set the port 8080 within the nginx.conf file) and you'll be welcomed with the first server in the cluster, keep refreshing and as you'll see, after each refresh, the page loads the name of the container from within the cluster application responded.

You could take the full setup anywhere, maybe on the production machine too, just make sure to either copy your source code and build your images remotely on the machine, or you could just push your Docker images to a remote repository that can be accessible from the machine's Docker.

Thanks a lot for taking the time to read through this series, I enjoyed writing and researching about this topic so much and I hope you enjoyed it too. See you soon 👋.

One-Tap Deployments with Nginx and Docker: Configuring for Load Balancing ⚖

Paula Fahmy — Fri, 20 Aug 2021 19:46:29 +0000

Welcome back, in the previous article, we briefly introduced reverse proxies, and how we could use some of them, namely Nginx, to load balance our app, for an easier scale-out and serving. We also concluded the final architecture we'll be after as our final result:

Today, we'll jump right into the basics of Nginx, so first up, make sure you have it installed on your machine.

Once you have it installed, we can navigate to the configuration folder where all the magic really happens. Start off by navigating to this path /etc/nginx/ (if you're on Linux), you should be able to see an nginx.conf file, launch it using your favorite text editor, and let's have a look in there.
The file is not empty, and it has some default configurations already set, lets delete everything and start from scratch.

We will learn today 3 basic setups:

Serving local files
Serving a hosted URL
Accessing multiple instances through Load Balancing

Serving Local Files

The basic skeleton of a nginx.conf file should (in most scenarios) contain these two directives.

http {

}

events {

}

We'll leave events empty for now and focus on the other directive, http which is where we'll be configuring Nginx as an HTTP server.

Before we continue, note that we'll be stopping and starting Nginx multiple times whenever we apply changes to the conf file, so if Nginx is not already running, run it using nginx command.
If it is already running and we need to restart it, we'll have to stop it using nginx -s stop command, and then start it once again using nginx.
If you're on Linux make sure that you are running these commands in an elevated grant using sudo.

Let's add an HTTP server, which listens on port 8080:

http {
    server {
        listen 8080;        
    }
}

events { }

Save the file, restart Nginx and navigate to localhost:8080, you should be able to see the following welcome screen:

Nginx has pulled this static HTML file from a default path because we've not yet set any. We'll be setting one now, I created a simple HTML file called index.html in a folder called Nginx_Article on the Desktop:

<html>
  <body>
    CUSTOM NGINX PAGE, YAY!
  </body>
</html>

Its full path should be /home/{myusername}/Desktop/Nginx_Article/, remember I'm using Linux, so this path might be a little bit different in your case, also don't forget to replace {myusername} with your account's username (without the curly braces of course).
Now let's configure Nginx to point to this web page when we hit port number 8080:

http {
    server {
        listen 8080;
        root /home/{myusername}/Desktop/Nginx_Article/;
    }
}

events { }

Restart Nginx and reload localhost:8080, and you should be able to see our index.html nicely served.

Now, let's go a level higher, what if we've got multiple directories that need to be served, not just a single root?
Easy,

http {

    server {
        listen 8080;

        location /images {
            root /home/{myusername}/Desktop/Nginx_Article_Another_Directory/;
        }

               location /videos {
            root /path/to/another/root/;
        }
    }

}
events { }

Here we used the root directive inside a location directive, this setup will ask Nginx to serve this directory: /home/{myusername}/Desktop/Nginx_Article_Another_Directory/images in case localhost:8080/images was requested.

Don't forget to create the directory on your machine, and maybe add some images to test requesting them.

Important Note: The directory /images should have an index.html file to be served by default OR you'll have to ask for a specific file, for example: localhost:8080/images/cat.jpg, and if no files are saved in /images, the previous request will return forbidden status.

Another way of path mapping is using the alias directive as below:

http {

    server {
        listen 8080;

        location /documents {
            alias /home/{myusername}/Desktop/Nginx_Article_Another_Directory/top_secret;
        }
    }

}
events { }

The alias directive will ask Nginx to serve this directory: home/{myusername}/Desktop/Nginx_Article_Another_Directory/top_secret in case localhost:8080/documents was requested.

🧾 Let's Summarize

In case of alias directory, we have to provide the full path to which Nginx was supposed to navigate, on the other hand, the root directory just had the root path of the directory, and the location value is to be appended to that path.
There is no actual directory named /documents inside Nginx_Article_Another_Directory, we are just creating an "alias" for the directory /top_secret.

Serving a hosted URL

Let's say we're building a reverse proxy to www.example.com, we want users to view the site from our own domain, this could be done easily through the following configuration:

http {

    server {
        listen 8080;
        location / {
            proxy_pass http://www.example.com/;
        }
    }

}

events { }

Try navigating to localhost:8080 after restarting Nginx, you should be able to see the exact same page as that of example.com.

This could be used the same way when serving a locally hosted application (in our case, the backend application) that's accessible through port 5000,

http {

    server {
        listen 8080;
        location / {
            proxy_pass http://127.0.0.1:5000/;
        }
    }

}

events { }

Accessing multiple instances through load balancing

For this use case, we are going to deploy a simple Hello World app, with minimal setup, all you'll need is a working Docker setup on your machine.
Head down to your favorite terminal app, and spin up 3 instances of the same app, each on its own container, we'll be using the "helloworld" Docker Image, which is exposed internally on port 80, when requested, it will print the Id of the container for the response:

foo@bar:~$ docker run -p 1111:80 -d strm/helloworld-http
478405720f2106d718edb1602812528ae53011cb196dc3731447c64d0bd8f2ff

foo@bar:~$ docker run -p 1112:80 -d strm/helloworld-http
a374ce45bf07b9747573e7feb1ae9742e72d2a31d74c2da3caa43abd5586a108

foo@bar:~$ docker run -p 1113:80 -d strm/helloworld-http
422efc18f418772cb96ea6088f2f801854ad4da21436da2c485f3ef80cca20ec

Notice that docker prints the ID of each container after each run command, also notice that we deployed 3 instances of the app, each accessible from outside its housing container through ports :1111, :1112, :1113. So for example, to navigate to the first instance of the app, you'll need to head to localhost:1111, and so on.

Now let's play with the conf file to set it up to balance an incoming load over our 3 instances.

http {

    upstream allinstances{
        server 127.0.0.1:1111;
        server 127.0.0.1:1112;
        server 127.0.0.1:1113;
    }

    server {
        listen 8080;
        location / {

            proxy_pass http://allinstances/;

        }
    }

}

events { }

Looks like we've added a new directive to our deck, upstream, where our proxy_pass now points at.

upstream defines a cluster that you can proxy requests to. It's commonly used for defining a web server cluster for load balancing.

Basically, this tells Nginx to Round-Robin each incoming request so that each server serves an equal number of requests. Each time you hit the refresh button, you are going to be greeted with a different server.

You could get creative with the location directive, maybe you'd want to split users down to two proxy_passes, so /odd would navigate to 1111 or 1113, and /even would navigate to port 1112.

What if your application is saving user data in memory? You'd then need to make a user's session "sticky" by hashing IP addresses of the users so that a given user is guaranteed to hit the same server as long as his IP address did not change:

upstream allinstances{
    ip_hash; # << Will hash the user's IP address and resolve to a single server
    server 127.0.0.1:1111;
    server 127.0.0.1:1112;
    server 127.0.0.1:1113;
}

After adding the ip_hash command, no matter how much you refresh the page, you'll always be served by the same server.

I think you now have the basics that can get you up and going. In our next article we will be packaging the whole setup into containers (including Nginx) and deploying it through a single docker-compose command.

I'd like to end this one with a small but powerful quote by Oscar Wilde, “Experience is the name everyone gives to their mistakes.”

Keep up the good work 🚀.

One-Tap Deployments with Nginx and Docker: Introduction to Reverse Proxies

Paula Fahmy — Fri, 20 Aug 2021 19:46:04 +0000

Yes, you read the title right, and it is what you think. If you've got minimal knowledge about Docker, you've certainly spelled out the famous Docker command docker-compose up, toss it with a .yaml file, grouping an Nginx image along with your application's image and you've got yourself a running server.
Of course, there would be some configurations left to do for the machine to start receiving requests from the outside world, but we'll focus more on how to get the engine running internally.

What we're up to?

Ok, so here's what we're up to, we've got a web application, and we want to deploy and serve the whole setup, hassle-free with one click (disclaimer: not including those to configure the setup 😄).
As you might already know, to be able to access the app from the outside, we need a "webserver", these can be any of (but not limited to) the following:

Apache Server
IIS
Nginx (we'll choose this one)

I'm going to start by giving you a brief introduction about Nginx and what it can actually do.

What is Nginx

"Nginx is a web server that can also be used as a reverse proxy, load balancer, mail proxy, and HTTP cache." Igor Sysoev, the creator of the software, has publicly released it in 2004, and with its open-source license, you can certainly use it for free.
In the last paragraph, I introduced to this peaceful article a couple of new terminologies that you either have not heard about before or might have heard about them without knowing what they actually are. Let's discuss some of them.

Proxies

A Proxy is basically a server that requests on behalf of the client (you), in other words, the destination server (for instance, google.com) would receive the request not from you, but from the proxy server you're using.
I could think of multiple reasons why any network setup would benefit from this technology.

So what are the benefits of a Proxy?

On the top of my head, a proxy would instantly hide your IP address, keeping you anonymous to the receiving end.
A proxy could also cache the results of your requests, so instead of traveling all the way to the destination server, a proxy in the middle would go: "Hmmm, I think you've requested the weather 5 mins ago, here you go, it is still burning hot at 42°, no need to ask Google again."

Keep in mind, Nginx is not a proxy, read on...

Reverse Proxies

A Reverse Proxy on the other hand is the opposite of a proxy.
In case of a Proxy, the Server doesn't know the client, but in case of a Reverse Proxy, the client doesn't know the server, it is basically the other way around.

So what are the benefits of a Proxy?

Load Balancing, which could be configured in multiple ways to ensure that running servers would distribute tasks in order to serve more users. In the previous example, Google had two servers, but only one responded, the other one could've been serving another user, or it might've been having a nap, it doesn't matter as long as the request has been served.
Caching works the other way around too. Google's Reverse Proxy would go: "Hmmm, I think you've just asked about the weather, nope, still 42°." without even passing the request to the actual Google servers.

So the main catch here is that (for most of the scenarios) a Proxy is installed and utilized by the Client whereas a Reverse Proxy is installed and utilized by the Server.

Before we continue, I want to point out that Hussein Nasser made an awesome video explaining the differences between Proxies and Reverse Proxies in an intuitive way, be sure to quickly watch it for an even better grasp.

The final architecture we're after

After that brief intro, I think we are now aware that Nginx would be the server of choice, and what comes free with Nginx you ask? Yes, Load Balancing. So let me try to capture the architecture we'll be going after in the following diagram:

As you might have figured out already, the architecture contains basically 3 main components:

The client (end-user)
A Database (hosted somewhere we don't care about for our context)
Our Backend Server:
- This will be running 3 docker containers,
  - Each having an instance of our backend application
    - Each app is accessible through an internal port number
- We'll also be running an Nginx Server pointing at each of the 3 instances in an attempt to access them through a load-balanced behavior (we'll discuss multiple approaches) from outside the Linux machine.

In the upcoming article, I'll talk in detail about Nginx, and how to correctly configure it to our needs. See you on the other side of the world 🚀😄.

Asynchronous C#: Cherry on the top 🍒 (Tips and Tricks)

Paula Fahmy — Sat, 22 May 2021 06:20:28 +0000

In Part 1 and Part 2 of the series, we took a nice dive to get us started in writing efficient async code in C#, I wanted to finalize the series with a couple of Tips and Tricks that will certainly come in handy in most development cases.

Buckle up your seatbelts 🚀..

✔ Tip #1

static async Task BoilWaterAsync()
{
    Console.WriteLine("Starting the kettle");
    await Task.Delay(3000);
    Console.WriteLine("Kettle Finished Boiling");
}

static async Task PourWaterAsync()
{
    var boilWaterTask = BoilWaterAsync();
    await boilWaterTask;
    Console.WriteLine("Pouring boiling water.");
}

static async Task Main(string[] args)
{
    // Notice we are not awaiting the task!
    PourWaterAsync();
    Console.WriteLine("Program Ended");
}

In our first example, PourWaterAsync() represents a Task that is not awaited, although, the task consists of inner tasks that are indeed being awaited.

Running this example will result in the following output:

Starting the kettle
Program Ended

The task Task.Delay(3000) has started, but despite awaiting it, it did not get to reach the finishing line, and the kettle did not finish boiling.
This behavior has resulted due to skipping the await keyword in the top-level Main() function.

Of course, rewriting these two lines:

var boilWaterTask = BoilWaterAsync();
await boilWaterTask;

to be:

await BoilWaterAsync();

.. would give the same result.
Always remember to "await" any task till reaching the very last calling point.

✔ Tip #2

public void Main(string[]args)
{
    var task = BoilWaterAsync();

    // DON'T
    var result = task.Result;

    // A NO-NO
    task.Wait();

    // PLEASE DON'T ⛔
    task.GetAwaiter().GetResult();
}

The above three DON'Ts will cause the application's main thread to be blocked till the tasks are finished, the app might stop responding or processing new requests till the synchronous wait is completed.

✅ DO:
Embrace the asynchronous nature of the task, await it, and return the result. Tasks being propagated throughout your code is normal, just try to delay doing so as much as you can.

✔ Tip #3

Let's say we are implementing an interface, one of its methods requires a Task to be returned, BUT the execution of the method itself does not require an asynchronous setup, it would not block the main thread and can run synchronously without problems.

interface MyInterface
{
    Task<string> DoSomethingAndReturnAString();
}

class MyClass : MyInterface
{
    public Task<string> DoSomethingAndReturnAString()
    {
        // Some logic that does not need the await keyword
        return "result"; // Of course a compiler error, expecting Task<string> not a string
    }
}

We can solve this issue with two approaches:

Solution 1 (a bad one 👎):

Convert the method to be async (even though we do not need to await anything), and now we could return a string normally, right? DON'T ever do that!

The moment you mark a method as async, the compiler transforms your code into a state machine that keeps track of things like yielding execution when an await is reached and resuming execution when a background job has finished. In fact, if you checked the IL (Intermediate Language) generated from your code after marking a method as async, you'll notice that the function has turned into an entire class for that matter.

So even on synchronous method marked with async (without await inside), a state machine will still be generated anyways and the code which could potentially be inlined and executed much faster will be generating additional complexity for state machine management.

📝 That's why it's so important to mark methods as async if and only if there is await inside.

Solution 2 (much better 👍):

Instead: return Task.FromResult("result");

Let's take another example:

We have an HTTP client retrieving some text from an external web source,

public Task<string> GetFromWebsite()
{
    var client = new HttpClient();
    var content = client.GetStringAsync("my.website.com");

    •••
}

If the objective is to only start retrieving the string from the website, then the best way to do it is to return the task of GetStringAsync() as is, and do not await it here, it boils down to the same reason of skipping the aimless creation of a state machine.

public Task<string> GetFromWebsite()
{
    var client = new HttpClient();
    return client.GetStringAsync("my.website.com");
}

The only case you'd want to await the call is that you want to perform some logic on the result inside the method:

// Notice that we marked the method as async
public async Task<string> GetFromWebsiteAndValidate()
{
    var client = new HttpClient();
    var result = await client.GetStringAsync("my.website.com");

    // Perform some logic on the result

    return result;
}

Remember, if you used the word "and" while describing what a method does, something might not be right.
Example:

"My method is doing x and y and z" (NO-NO ⛔)
"I have 3 methods, one for doing x, another for y, and the last for z" (YES ✔)

This will make your life much easier when trying to apply unit tests to your code.

So a rule of thumbs 👍 to note down here:
Only await when you absolutely need the result of the task.
The async keyword does not run the method on a different thread, or do any other kind of hidden magic, hence, only mark a method as async when you need to use the keyword await in it.

A couple of notes to always remember:

An async function can return either on of the three types: void, Task, or Task<T>.
A function is "awaitable" because it returns a Task or a Task<T>, not because it is marked async, so we can await a function that is not async (a one just returning Task).
You cannot await a function returning void, hence, you should always return a Task unless there is an absolute reason not to do so (a caller to the function expects a void return type), or that the function itself is a top-level function and there is no way other functions will be able to call it..

✔ Tip #4

We established that long-running tasks should always execute asynchronously, these tasks can fall down into two main categories, I/O-Bound and CPU-Bound. A task is said to be I/O bound when the time taken for it to complete is determined principally by the period spent waiting for input/output operations to be completed. In contrast, a CPU-Bound task is a task that's time of completion is determined principally by the speed of the central processor, examples for these would be:

I/O Bound Tasks:
- Requesting data from the network
- Accessing the database
- Reading/Writing to a file system
CPU Bound Tasks: Generally performing an expensive calculation such as:
- Graphics Rendering
- Video Compression
- Heavy mathematical computations

Generally, whenever you got an I/O Bound Task or Task<T> at hands, await it in an async method. For CPU-bound code, you await an operation that is started on a background thread with the Task.Run method.

Note 📝:
Make sure you analyzed the execution of your CPU-Bound code, and be mindful of the context switching overhead when multithreading, it might be not so costly after all in comparison.

Okay, that's all I have for y'all today.
Keep Coding 😉

Asynchronous C#: Making a simple Cup of Tea (Part 2)

Paula Fahmy — Sat, 22 May 2021 06:18:30 +0000

Last time, we had an introductory walkthrough to C#'s way of "asynchronizing" code. We talked about the difference between "multithreading" and "multiprocessing", and we gave an example to illustrate the subject where we made a simple cup of tea.

Ok, let's open the hood once more and get our hands dirty. The code now supports asynchronous operation and our UI does not freeze when we wait for a task. Next up, let's introduce some minor changes to allow our program to finish preparing our tea faster.

Some notes to remember from the previous part of the article before we move on:

Calling an async function (generally: a function returning a Task or a Task<>) results in the creation of a "hot task", a task that runs immediately once created.
At some point, we'll have to await the task to get its result.

Addressing Synchronous code Issues

Issue #2: Slow Execution

static async Task MakeTeaAsync()
{
    var water = await BoilWaterAsync(); // takes 3 seconds
    var cups = await PrepareCupsAsync(2); // 3 seconds for each cup (6 seconds in total)
    Console.WriteLine($"Pouring {water} into {cups}");

    cups = "cups with tea";

    var warmMilk = await WarmupMilkAsync(); // this line takes 5 seconds
    // ~14 seconds in total..
    Console.WriteLine($"Adding {warmMilk} into {cups}");
}

Since we can split "awaiting" the task from creating it:

static async Task MakeTeaAsync()
{
    Task<string> waterBoilingTask = BoilWaterAsync();
    string water = await waterBoilingTask;

    Task<string> preparingCupsTask = PrepareCupsAsync(2);
    string cups = await preparingCupsTask;

    Console.WriteLine($"Pouring {water} into {cups}");

    cups = "cups with tea";

    Task<string> warmingMilkTask = WarmupMilkAsync();
    string warmMilk = await warmingMilkTask;

    Console.WriteLine($"Adding {warmMilk} into {cups}");
}

It is important to note down the following:

The composition of an asynchronous operation followed by synchronous work is an asynchronous operation. Stated another way, if any portion of an operation is asynchronous, the entire operation is asynchronous.

Now let's reorder the logic.
Since the tasks are independent of each other, we can launch them all together at once. We know for a fact that we can't pour the milk unless we have the boiled water poured on top of the tea first.

static async Task MakeTeaAsync()
{
    var waterBoilingTask = BoilWaterAsync();
    var preparingCupsTask = PrepareCupsAsync(2);
    var warmingMilkTask = WarmupMilkAsync();

    var cups = await preparingCupsTask;
    var water = await waterBoilingTask;

    Console.WriteLine($"Pouring {water} into {cups}");
    cups = "cups with tea";

    var warmMilk = await warmingMilkTask;
    Console.WriteLine($"Adding {warmMilk} into {cups}");
}

Start the kettle
Waiting for the kettle
Taking cup #1 out.
Putting tea and sugar in the cup
Pouring milk into a container
Putting the container in microwave
Warming up the milk
Taking cup #2 out.
Putting tea and sugar in the cup
Kettle Finished Boiling
Finished warming up the milk
Finished preparing the cups
Pouring Hot water into cups
Adding Warm Milk into cups with tea
-------------------------------
Time Elapsed: 6.1258995999999994 seconds

Now that's a considerable boost in performance, about a 230% speed increase to be specific.
All we did was start the kettle, start preparing the cups, and start warming the milk all in parallel. Preparing cup #1 would take 3 seconds, and instead of waiting, we started warming the milk to buy some time.

Synchronous Operation	Asynchronous Operation

I think we can enhance a bit more, how about we refactor PrepareCupsAsync()? We can prepare multiple cups in parallel!

static async Task<string> PrepareCupsAsync(int numberOfCups)
{
    Task[] eachCupTask = Enumerable.Range(1, numberOfCups).Select(index => 
    {
        Console.WriteLine($"Taking cup #{index} out.");
        Console.WriteLine("Putting tea and sugar in the cup");
        return Task.Delay(3000);
    }).ToArray();

    await Task.WhenAll(eachCupTask);

    Console.WriteLine("Finished preparing the cups");

    return "cups";
}

Using LINQ, we created a new IEnumerable of Tasks. All the created tasks ran immediately the moment we enumerated the IEnumerable using the .ToArray() call. Finally, we waited for the tasks altogether using WhenAll().
In other use cases, you may find it useful to use the result of only the first task to finish disregarding the other tasks. In such cases, you'd want to use .WhenAny().

IMPORTANT NOTE:

Although it's less code, use caution when mixing LINQ with asynchronous code. Because LINQ uses deferred (lazy) execution, async calls won't happen immediately as they do in a foreach loop unless you force the generated sequence to iterate with a call to .ToList() or .ToArray().

Now let's check the output:

Start the kettle
Waiting for the kettle
Taking cup #1 out.
Putting tea and sugar in the cup
Taking cup #2 out.
Putting tea and sugar in the cup
Pouring milk into a container
Putting the container in microwave
Warming up the milk
Kettle Finished Boiling
Finished preparing the cups
Pouring Hot water into cups
Finished warming up the milk
Adding Warm Milk into cups with tea
-------------------------------
Time Elapsed: 5.1878251 seconds

We went down from 6 seconds to 5 seconds, and that's the best we could get out of the flow because warming milk takes 5 seconds itself.

Pop Quiz! 📃
Q: Let's say your friends are coming over for a movie night 🍿, and you are making 10 cups of tea instead of just 2 PrepareCupsAsync(10), how much time do you think it'd take?

Start the kettle
Waiting for the kettle
Taking cup #1 out.
Putting tea and sugar in the cup
•••
Taking cup #10 out.
Putting tea and sugar in the cup
Pouring milk into a container
Putting the container in microwave
Warming up the milk
Kettle Finished Boiling
Finished preparing the cups
Pouring Hot water into cups
Finished warming up the milk
Adding Warm Milk into cups with tea
-------------------------------
Time Elapsed: 5.1923364 seconds

Yep, you guessed it right, it'd still take no more than 5 seconds. That is how scalable our code has been refactored to be.

Is Async/Await multithreaded?

Unlike other languages, Javascript for example, which uses async single threads, .NET framework is multithreaded, and in this instance, it can be both single and multithreaded, or either. Unless you're really trying to share data between multiple threads, you usually do not need to worry about it, but for mere pleasure, let's investigate which thread is actually working on each piece of code.

I added this simple helper method to state the ID of the current thread when writing to console..

public static void WriteLineWithCurrentThreadId(string textToPrint) 
            => Console.WriteLine($"Thread #{Thread.CurrentThread.ManagedThreadId} | {textToPrint}");

.. and then I replaced each Console.WriteLine() with WriteLineWithCurrentThreadId().
Here are the results:

Thread #1 | Start the kettle
Thread #1 | Waiting for the kettle
Thread #1 | Taking cup #1 out.
Thread #1 | Putting tea and sugar in the cup
Thread #1 | Taking cup #2 out.
Thread #1 | Putting tea and sugar in the cup
Thread #1 | Pouring milk into a container
Thread #1 | Putting the container in microwave
Thread #1 | Warming up the milk
Thread #4 | Kettle Finished Boiling
Thread #5 | Finished preparing the cups
Thread #5 | Pouring Hot water into cups
Thread #4 | Finished warming up the milk
Thread #4 | Adding Warm Milk into cups with tea
-------------------------------
Time Elapsed: 5.2266067000000005 seconds

So what is happening in here?
We have a bunch of threads lying around in a pool, a thread pool, all the threads are pretty much the same, they're all available and in the same context, some of them are currently working on something, others are idle, waiting for a task to be assigned to.
Our console application will just grab whichever one might be available. And occasionally they switch sometimes they don't, and after an await it's going to pick whatever thread that's available from the same context from the thread pool, and then continue on that.
In the case of a WPF program, there's only one thread that can write to the UI. So in that instance, the continuation runs on exactly the same thread to make sure that it can update the windows correctly.

Phew! That was a lot to take in, right?
Be sure to read the article a couple of times, and try to take the source code for a test drive to see the effects yourself, also check the last part of the series, I wrote down some tips and tricks that could be applied in almost any coding situation.

Best of luck 🙌.

Asynchronous C#: Making a simple Cup of Tea

Paula Fahmy — Sat, 22 May 2021 06:17:25 +0000

Years ago, programs ran sequentially, line by line and function by function. Only one task processing at a given unit of time. If a function relied on another function, it had to wait till it got the result from that function before continuing to process, even if it meant that the application's main thread would get blocked for an amount of time, waiting for some network call to return a response or for a piece of work that requires a heavy calculation to yield a result.

For the past couple of years, a typical device running almost any type of operating systems have at least a two, eight, or even 16 cores chip, where each core can focus on a task (or multiple tasks at once in some cases), resulting in the ability to process more bits and bytes in a fewer number of precious microseconds, allowing what's called "Asynchrony", or Asynchronous Programming of a given group of tasks.

Asynchrony refers to the occurrence of events independent of the main program flow, they typically take place concurrently with program execution, without the program blocking to wait for results. Doing so provides a degree of parallelism, effectively using the available resources to achieve a target sooner than the synchronous version of the same piece of code.

Threads vs Processes

Whenever we talk about asynchrony, we have to mention either one of these two terms, so what are the differences between the two?

A process is an executing instance of a program, it has its own memory space, registers, etc. On the other hand, a thread is essentially one of the components of a given process, meaning that a process can have multiple threads running concurrently.
The conversation can't end without addressing "multi-processing" and "multi-threading", let me share a nice comparison between them from guru99.com.

Topic	MultiProcessing	MultiThreading
Definition	Is a system that has more than two processors	Is a program execution technique that allows a single process to have multiple code segments
What is it about	Improves the reliability of the system	Each thread runs parallel to each other
Resources	The creation of a process is slow and resource-consuming	The creation of a thread is economical in time and resource.

Be sure to check out the full comparison: Multithreading vs Multiprocessing at Guru99.

So long story short, the main difference between the two is whether they share memory or not. Processes do not share memory, thus operating independently while threads (of the same process) on the other hand, share the same memory allocated to their housing process.

A great real-life example would be how you're currently reading this article on Chrome, odds are you currently have more than one tab lying around in your browser, each in its own process, a tab would not care about its neighboring tab, and a tab could (God forbid) crash without the whole app crashing, that's "multiprocessing".
Now try to reload the page (and let's assume your connection isn't that fast), notice how you can move or resize the window normally while waiting for the page to load, that's "multithreading", your app is responsive even though it is waiting for a task (or a thread) to return a result.

Async and Await

Introduction

In C# 5, Microsoft introduced a simplified approach to asynchronous programming in .NET Framework, Where all the heavy lifting that was done by the developer is now done by the compiler.

The framework is wrapped in what's called: "Task asynchronous programming model" or TAP for short. The model is an abstraction layer over asynchronous code. You write your logic as a sequence of steps normally, and the compiler performs some transformations in the background because these statements return a Task<>.

Asynchronous methods mainly look something like this:

public async Task DoSomethingAsync()
{
  // In the Real World, we would actually do something...
  // For this example, we're just going to (asynchronously) wait 100ms.
  await Task.Delay(100);
}

Synchronous Example

A perfect example that illustrates asynchronous work would be preparing a cup of tea, the job consists of four main tasks:

Preparing the cups by putting tea and sugar
Boiling the water
Warming up some fresh milk
Adding all the ingredients together in one nice cup of tea.

One person (or thread) can handle all these tasks. He can prepare the cups asynchronously by starting the next task before the first one completes. As soon as you start the kettle, you can begin warming up the milk. Once the water boils, you can pour it into the cup and then add some milk.

static string BoilWater()
{
    Console.WriteLine("Start the kettle");
    Console.WriteLine("Waiting for the kettle");
    Task.Delay(3000).Wait();

    Console.WriteLine("Kettle Finished Boiling");

    return "Hot water";
}

static string PrepareCups(int numberOfCups)
{
    for (int i = 0; i < numberOfCups; i++)
    {
        Console.WriteLine($"Taking cup #{i + 1} out.");
        Console.WriteLine("Putting tea and sugar in the cup");
        Task.Delay(3000).Wait();
    }

    Console.WriteLine("Finished preparing the cups");

    return "cups";
}

static string WarmupMilk()
{
    Console.WriteLine("Pouring milk into a container");
    Console.WriteLine("Putting the container in microwave");
    Console.WriteLine("Warming up the milk");
    Task.Delay(5000).Wait();

    Console.WriteLine("Finished warming up the milk");

    return "Warm Milk";
}

static void MakeTea()
{
    var water = BoilWater();
    var cups = PrepareCups(2);
    Console.WriteLine($"Pouring {water} into {cups}");

    cups = "cups with tea";

    var warmMilk = WarmupMilk();
    Console.WriteLine($"Adding {warmMilk} into {cups}");
}

static void Main(string[] args)
{
    // App's main entry point.
    MakeTea();
    // Stopwatch logic is hidden for simplicity
}

As you can see, preparing the cups would take 3 seconds for each cup (6 for both cups), boiling the water would take another 3 seconds, warming up some milk would take 5 seconds, resulting in a total of 14 seconds, here is the output of our program.

Start the kettle
Waiting for the kettle
Kettle Finished Boiling
Taking cup #1 out.
Putting tea and sugar in the cup
Taking cup #2 out.
Putting tea and sugar in the cup
Finished preparing the cups
Pouring Hot water into cups
Pouring milk into a container
Putting the container in microwave
Warming up the milk
Finished warming up the milk
Adding Warm Milk into cups with tea
-------------------------------
Time Elapsed: 14.1665602 seconds

Of course, waiting for the cups to be prepared might risk boiled water to cool down, the exact same case can take place while waiting for the milk to get warm, the nice hot cup of tea might have to sit and wait on the counter till the milk is ready, this represents our first concern.
Another problem might arise the moment this console application is converted to a GUI application. Try to cancel, minimize, or even interact with the window and you'll instantly notice something is not right, our application will freeze the second we "wait" for a task to finish, warming up a simple cup of milk would not result in the best user experience.

What happened in our current version is analogous to a chef being focused on exactly one job, tapping his feet on the ground, looking at his watch every now and then, so eager, waiting for it to get done. He won't respond to his fellow chef asking for the current time, he won't even answer to his boss. That's not the best behavior to get out of our chef (or the thread, technically speaking).

As you can see, upon converting the console app into a windows forms application (GUI), clicking on the "Make Tea" button instantly stalls the window. The block is not released until the synchronous wait is completed.

Addressing Synchronous code Issues

Now, let's address each issue.

Issue #1: Frozen UI (generally, the main thread)

When we write client applications, we want the UI to be as responsive as possible, the last thing we want is our app freezing here and there while it's downloading data from the web. We need to modify our app to utilize asynchrony.

Don't Block, Await Instead

Let's start with the helping functions:

static async Task<string> BoilWaterAsync()
{
    Console.WriteLine("Start the kettle");
    Console.WriteLine("Waiting for the kettle");
    await Task.Delay(3000);

    Console.WriteLine("Kettle Finished Boiling");

    return "Hot water";
}

static async Task<string> PrepareCupsAsync(int numberOfCups)
{
    for (int i = 0; i < numberOfCups; i++)
    {
        Console.WriteLine($"Taking cup #{i + 1} out.");
        Console.WriteLine("Putting tea and sugar in the cup");
        await Task.Delay(3000);
    }

    Console.WriteLine("Finished preparing the cups");

    return "cups";
}

static async Task<string> WarmupMilkAsync()
{
    Console.WriteLine("Pouring milk into a container");
    Console.WriteLine("Putting the container in microwave");
    Console.WriteLine("Warming up the milk");
    await Task.Delay(5000);

    Console.WriteLine("Finished warming up the milk");

    return "Warm Milk";
}

static async Task MakeTeaAsync()
{

    var water = await BoilWaterAsync();
    var cups = await PrepareCupsAsync(2);
    Console.WriteLine($"Pouring {water} into {cups}");

    cups = "cups with tea";

    var warmMilk = WarmupMilkAsync();
    Console.WriteLine($"Adding {warmMilk} into {cups}");
}

Finally, we'll need to modify our entry point too

static async Task Main(string[] args)
{
    // App's main entry point.
    await MakeTea();
    // Stopwatch logic is hidden for simplicity
}

And when we try running the app again, we get this output:

Start the kettle
Waiting for the kettle
Kettle Finished Boiling
Taking cup #1 out.
Putting tea and sugar in the cup
Taking cup #2 out.
Putting tea and sugar in the cup
Finished preparing the cups
Pouring Hot water into cups
Pouring milk into a container
Putting the container in microwave
Warming up the milk
Finished warming up the milk
Adding Warm Milk into cups with tea
-------------------------------
Time Elapsed: 14.1202222 seconds

Something is not just right here. The elapsed time is roughly the same as our initial synchronous version!

Ok, here is the thing, this code doesn't block. While we're waiting for the water to boil, the chef would still start the kettle, stare at it while it heats up, but at least now, he'll respond to his partners, the UI thread is now responsive while waiting for a task to finish.

When you write server programs, you don't want threads blocked. Those threads could be serving other requests. Using synchronous code when asynchronous alternatives exist hurts your ability to scale out less expensively. You pay for those blocked threads.

For some use cases, this is all we need for our app to be acceptable for the user.

Remember, we are still addressing the first issue, the code still needs to take advantage of some features of TAP asynchronous model, but first, let's take a quick look under the hood.

Awaitable and Tasks

I highlighted exactly what was altered in order for the BoilWater() method to become BoilWaterAsync()

static async Task BoilWaterAsync()
{
    Console.WriteLine("Start the kettle");
    Console.WriteLine("Waiting for the kettle");
    await Task.Delay(3000); // We also removed the .Wait() call

    Console.WriteLine("Kettle Finished Boiling");

    return "Hot water";
}

Now let's take a couple of notes:

As we observed the results, the method executed just like any other method, synchronously, until it hits the "await keyword", this is where things can get asynchronous.

An await keyword expects an "awaitable" (in our case, the Task<> resulted from the Delay method), then it examines whether the awaitable has already completed or not, if await sees that the awaitable has not completed, then it acts asynchronously, waits for the awaitable to continue till it finally completes, only then, the method just continues running synchronously again, just like a regular method.
Hold on to this point in your head, I promise it's going to get clearer.

Now, let me modify the MakeTeaAsync() method once again, functionality stays the same:

static async Task MakeTeaAsync()
{

    //var water = await BoilWaterAsync();
    Task waterTask = BoilWaterAsync();
    string water = await waterTask;
    var cups = await PrepareCupsAsync(2);
    Console.WriteLine($"Pouring {water} into {cups}");

    cups = "cups with tea";

    var warmMilk = WarmupMilkAsync();
    Console.WriteLine($"Adding {warmMilk} into {cups}");
}

Recall that BoilWaterAsync() returns a Task<string>, not just a string. A task is an object that represents some work that should be done, some sort of a promise, there should be a result at some point in the future. A Task is an awaitable, and hence it can be "awaited" using the keyword (you guessed it), await.

Pop Quiz! 📃
Q: Why did we use Task<> as the return type?
A: Because we might need to await the task to finish at some point.

Q: Why do we need to await the Task?
A: Because we need a result extracted from the Task object.

One important concept to notice, the following line:

Task<string> waterTask = BoilWaterAsync();

.. caused the creation of what's called a "hot" task 🔥, which is a task that starts running immediately the moment it gets created, so if we decide to add more logic to the function

static async Task MakeTeaAsync()
{
    •••
    
    Task waterTask = BoilWaterAsync();
    
    // Some long-running synchronous for loop
    // 
    // ... still looping aimlessly
    // 
    // ummm, okay, done 👍
    
    string water = await waterTask;
    
    •••
}

.. by the time we reach the await keyword, the Task might have already started, and finished. await will just have to extract the result from the Task, and we'd be good to go, synchronously of course (the rest of the function). This called Task Composition.

The previous code snippet showed us that we can use Task or Task<> objects to hold running tasks, then we await each task before using its result.

One final note to write down, context switching...
After the awaitable (waterTask) is completed, the remainder of the async function (MakeTeaAsync) will execute on a "context" that was captured before the await returned, but what exactly is a "context"?

If you’re on a UI thread, then it’s a UI context.
If you’re responding to an ASP.NET request, then it’s an ASP.NET request context.
Otherwise, it’s usually a thread pool context.

Here is a quick example (taken from Stephen Cleary's blog post):

// WinForms example
private async void DownloadFileButton_Click(object sender, EventArgs e)
{
    // Since we asynchronously wait, the UI thread is not blocked by the file download.
    await DownloadFileAsync(fileNameTextBox.Text);

    // Since we resume on the UI context, we can directly access UI elements.
    resultTextBox.Text = "File downloaded!";
}

// ASP.NET example
protected async void MyButton_Click(object sender, EventArgs e)
{
    // Since we asynchronously wait, the ASP.NET thread is not blocked by the file download.
    // This allows the thread to handle other requests while we're waiting.
    await DownloadFileAsync(...);

    // Since we resume on the ASP.NET context, we can access the current request.
    // We may actually be on another *thread*, but we have the same ASP.NET request context.
    Response.Write("File downloaded!");
}

To sum up, I'd like to (again) quote Stephen Cleary:

"I like to think of “await” as an “asynchronous wait”. That is to say, the async method pauses until the awaitable is complete (so it waits), but the actual thread is not blocked (so it’s asynchronous)."

Next up, we'll have another attempt to refactor our tea maker in order for it to be more time-efficient and further utilize C#'s asynchrony.

See you soon. 👋

Forem: Paula Fahmy

EF Core Change Tracking: The Bug Factory You Accidentally Built

How the Story Usually Starts

The Bug You Have Seen and Ignored

What Change Tracking Actually Is

Why AsNoTracking() Exists

Commands and Queries Are Not the Same Thing

Why SaveChanges() Does Nothing on Detached Entities

The Relationship Trap That Causes Duplicate Keys

Attach vs Update vs Already Tracked

Tracked Entity (Best Case)

Attach

Update

Practical Demo Scenarios

1. Tracked Update Works

2. AsNoTracking Causes Silent No-Op

3. AsNoTracking + Add Causes Duplicate Key Failure

4. Attach Updates Only Modified Columns

5. Update Forces Full-Row Update

The Real Fix: Stop Toggling Tracking

Splitting Repositories by Intent

Read-Only Repository

Read-Write Repository

Why This Is Not Just Clean Code Overhead

Lessons Learned

Understanding the Magic of Logarithms in Binary Search

Interview Questions: Singleton Pattern vs the Static Keyword

Introduction

The static Keyword

Design Patterns

Singleton Design Pattern

Singleton Implementation in C#

Naïve Singleton

Why isn't our solution sophisticated enough?

Sophisticated Singleton

Eager vs Lazy Initialization

Use Cases of Singletons

Takeaway 📒

What are the similarities and differences between the two approaches?

Outro

One-Tap Deployments with Nginx and Docker: Serving your Web Cluster w/ Compose 🐳

One-Tap Deployments with Nginx and Docker: Configuring for Load Balancing ⚖

Serving Local Files

🧾 Let's Summarize

Serving a hosted URL

Accessing multiple instances through load balancing

One-Tap Deployments with Nginx and Docker: Introduction to Reverse Proxies

What we're up to?

What is Nginx

Proxies

Reverse Proxies

The final architecture we're after

Asynchronous C#: Cherry on the top 🍒 (Tips and Tricks)

✔ Tip #1

✔ Tip #2

✔ Tip #3

Solution 1 (a bad one 👎):

Solution 2 (much better 👍):

✔ Tip #4

Asynchronous C#: Making a simple Cup of Tea (Part 2)

Addressing Synchronous code Issues

Issue #2: Slow Execution

Is Async/Await multithreaded?

Asynchronous C#: Making a simple Cup of Tea

Threads vs Processes

Async and Await

Introduction

Synchronous Example

Addressing Synchronous code Issues

Issue #1: Frozen UI (generally, the main thread)

Awaitable and Tasks

The `static` Keyword