DEV Community: qodors

WHY YOUR REACT APP RE-RENDERS TOO MUCH (AND WHAT ACTUALLY FIXES IT)

qodors — Thu, 20 Aug 2026 11:05:45 +0000

A React page feels slow, so someone opens the code and starts adding memo, useMemo, and useCallback everywhere.

Usually that makes the code harder to read before it makes the page faster.

React rendering a component again is normal. React does that when state, props, or context change so it can work out what the screen should look like now. It can run a component function again without changing anything in the browser.

It becomes worth looking into when a small update makes expensive parts of the page run again for no useful reason. A user opens a help panel, but a large table, charts, and filters also run. That is where the page starts to feel slow.

Most of the time, the cause is simple: state is sitting too high in the component tree.

WHAT A RE-RENDER ACTUALLY MEANS

Developers often open React DevTools, see a component render several times, and assume something is broken. Often, it is not.

A render means React ran the component function again. It does not automatically mean the browser rebuilt every element on the page. React still compares the new result with what was already on screen and only updates the DOM where it needs to.

What matters is whether that render is doing expensive work.

A button rendering again is rarely worth worrying about. A table with thousands of rows, a large chart, or a costly filter running again after an unrelated click is worth checking.

STATE SITTING TOO HIGH IN THE PAGE

Here is a common setup:

function ProductPage({ products }) {
  const [isHelpOpen, setIsHelpOpen] = useState(false);
  return (
 <>
   <button onClick={() => setIsHelpOpen(true)}>
     Need help?
   </button>
     {isHelpOpen && (
        <HelpPanel onClose={() => setIsHelpOpen(false)} />
      )}
      <ProductList products={products} />
      </>
 );
}

Opening the help panel changes state in ProductPage. React renders ProductPage again, and ProductList runs again too, even though the products did not change.

That may be fine for a small list. It becomes a problem when ProductList is large or does work that takes time.

Move the state down to the component that uses it:

function HelpButton() {
 const [isHelpOpen, setIsHelpOpen] = useState(false);
 return (
  <>
     <button onClick={() => setIsHelpOpen(true)}>
      Need help?
     </button>
        {isHelpOpen && (
        <HelpPanel onClose={() => setIsHelpOpen(false)} />
        )}
      </>
   );
} 
function ProductPage({ products }) {
  return (
   <>
      <HelpButton />
      <ProductList products={products} />
     </>
  );
}

Now opening help updates HelpButton and HelpPanel. ProductPage does not need to update, so ProductList does not run again.

In many React screens, moving state down the tree fixes the issue without any memoization.

MEMO ONLY HELPS WHEN PROPS STAY THE SAME

React.memo can skip a render when a component receives the same props as last time.

But it cannot do much if you pass new objects and functions into that component every time its parent renders.

const ProductList = memo(function ProductList({ products, options }) {
  // Expensive list rendering
});
Then a parent does this:

<ProductList
   products={products}
   options={{ showStock: true }}
/>

The object looks the same, but it is a new object on every render. memo sees a different options reference and runs ProductList again.

The simplest fix is often to pass the actual value instead of wrapping it in an object:

<ProductList
  products={products}
  showStock={true}
/>

If the component really needs an object and its values do not change often, keep that object stable:

const options = useMemo(() => ({
 showStock
}), [showStock]);
<ProductList
  products={products}
  options={options}
/>

Do this when the component is expensive and you have checked that it helps. Do not add useMemo around every object in the app. For cheap components, the extra code is usually not worth it.

BE CAREFUL WITH LARGE CONTEXT OBJECTS

Context is useful. It is also easy to put too much into one place.

const AppContext = createContext(null);
function AppProvider({ children }) {
 const [user, setUser] = useState(null);
 const [theme, setTheme] = useState("dark");
 const [notifications, setNotifications] = useState([]);
   return (
   <AppContext.Provider
      value={{ user, setUser, theme, setTheme, notifications }}
   >
      {children}
   </AppContext.Provider>
   );
}

Any component that reads this context will re-render when the provider value changes.

Add a notification, and a component that only needs the theme can still render again because both values live in the same context. The object passed to value is also new whenever AppProvider renders.

You do not need a separate context for every value. But avoid keeping every unrelated value in one large context object.

For example:

const ThemeContext = createContext(null);
const UserContext = createContext(null);
const NotificationContext = createContext(null);

Theme, user data, and notifications often change for different reasons. Keeping them separate stops one update from affecting every consumer of one large context.

For state used by one screen or one small part of a screen, regular component state is often easier than context.

DO NOT ADD MEMOIZATION BEFORE CHECKING THE PAGE

memo, useMemo, and useCallback are useful tools. They are not a default setting for React code.

A page with memoization everywhere is harder to change. You have dependency arrays to keep right, object references to think about, and more chances to keep an old value by mistake.

Use the React DevTools Profiler first.

Record the interaction that feels slow: typing in a filter, opening a panel, switching tabs, or selecting an item. Check which components rendered and how long they took.

You may find that the real problem is a large list that needs pagination or virtualization. You may find a calculation that should be memoized. Or you may find state that only needs to move down one component.

The profiler shows which component took time during the slow interaction, so you know where to start.

OUR TAKE

At Qodors, we often see state sitting high in a page and memoization added later to deal with all the extra renders.

Moving that state closer to where it is used usually solves more of the problem.

A component rendering again is not a failure. But if opening a help drawer causes a large product table to run expensive work again, that is worth fixing. Keep state close to the part of the page that owns it, then profile the page before adding memoization.

That keeps the code easier to work with and removes the updates users can actually feel.

QUICK REFERENCE

A React re-render does not always mean the DOM changed
Look for expensive components running after unrelated state changes
Keep state close to the component that uses it
New object and function props can stop memo from helping
Do not keep every unrelated value in one large context object
Use React DevTools Profiler before adding memo, useMemo, or useCallback
Use memoization for expensive work you have measured

Do not try to stop every React render. Find the interaction that feels slow, check what ran during it, and remove the work that did not need to happen.

React #ReactJS #JavaScript #Frontend #WebDevelopment #ReactPerformance #ReactHooks #TypeScript #WebDev #QodorsEdge

Written by the team at Qodors — we build and improve full-stack products for a living. → https://www.qodors.com/?utm_source=devto&utm_medium=post&utm_campaign=react_rerenders

You're Using useEffect Too Much. Most of It Belongs in Render, Not an Effect.

qodors — Thu, 13 Aug 2026 06:40:38 +0000

UseEffect is one of the most commonly misunderstood React hooks.

Developers often reach for it whenever they need to calculate something, update state, respond to a change, or run some logic after rendering.

The code usually looks reasonable:

useEffect(() => {
  setFullName(`${firstName} ${lastName}`);
}, [firstName, lastName]);

It works.

But the question isn't whether it works.

The better question is:

Does this actually need an effect?

In many React components, the answer is no.

A large amount of useEffect code exists only because developers are using effects to derive values that React can calculate directly during render.

That creates unnecessary state, extra renders, synchronization problems, and code that is harder to reason about.

The mental model should be simple:

Render is for calculating the UI. Event handlers are for responding to user actions. Effects are for synchronizing with external systems.

Let's look at what people commonly write — and what it should be.

1. Don't Use an Effect to Calculate Derived Values

What people write:

const [total, setTotal] = useState(0);
useEffect(() => {
  setTotal(price * quantity);
}, [price, quantity]);

What it should be:

const total = price * quantity;

total isn't really state.

It is a value derived from price and quantity.

The first version creates an unnecessary sequence:

Render

↓

Effect runs

↓

setTotal()

↓

Render again

The second version simply calculates the value when React renders.

There is no synchronization problem because there is nothing to synchronize.

2. Filtering Data Doesnt Usually Need useEffect

What people write:

const [filteredUsers, setFilteredUsers] = useState([]);
useEffect(() => {
  setFilteredUsers(
    users.filter(user =>
     user.name.toLowerCase().includes(search.toLowerCase()
     )
     );
}, [users, search]);

What it should be:

const filteredUsers = users.filter(user =>
  user.name.toLowerCase().includes(search.toLowerCase())
);

The filtered list is completely determined by users and search.

So why store it separately?

You're creating a second source of truth for information that already has a source of truth.

If the calculation is genuinely expensive, you can consider:

const filteredUsers = useMemo(() => {
  return users.filter(user =>
    user.name.toLowerCase().includes(search.toLowerCase())
);
}, [users, search]);

But don't reach for useMemo automatically either.

First write the straightforward version. Optimize when there is an actual performance problem.

3.Mapping and Formatting Data Belongs in Render**

What people write:

const [itemsWithLabels, setItemsWithLabels] = useState([]);
useEffect(() => {
  setItemsWithLabels(
    items.map(item => ({
      ...item,
      label: ${item.name} - $${item.price}
      }))
    );
}, [items]);

What it should be:

const itemsWithLabels = items.map(item => ({
 ...item,
  label: ${item.name} - $${item.price}
}));

This is just a transformation.

React already has the data.

You don't need an effect to transform data that exists inside the component.

4. Don't Use Effects to Keep State in Sync

This is another common pattern:

const [selectedUser, setSelectedUser] = useState(null);
useEffect(() => {
 setSelectedUser(
    users.find(user => user.id === selectedId)
   );
}, [users, selectedId]);

It may look like you're keeping selectedUser synchronized.

But there is nothing to synchronize.

You can simply write:

const selectedUser = users.find(
  user => user.id === selectedId
);

Now there is one source of truth.

selectedId determines the selected user.

That relationship is obvious from the code.

The more state you create unnecessarily, the more state you eventually have to synchronize.

5. Don't Use an Effect for Logic Caused by a User Action

Imagine a button that submits an order.

A developer might write:

const [submitted, setSubmitted] = useState(false);
useEffect(() => {
  if (submitted) {
    sendAnalytics();
}
}, [submitted]);
function handleSubmit() {
  setSubmitted(true);
}

But why introduce state just to trigger an effect?

The action already happened inside handleSubmit.

What it should be:


function handleSubmit() {
  sendAnalytics();
  submitOrder();
}

This makes the reason for the action obvious.

When something happens because the user clicked a button, submitted a form, selected an option, or triggered another interaction, the event handler is usually the right place for that logic.

Don't turn an event into state just so an effect can react to it.

6. So When Should You Actually Use useEffect?

This doesn't mean useEffect is bad.

It means useEffect has a specific job.

Use it when your component needs to synchronize with something outside React.

For example:

useEffect(() => {
 const connection = createConnection(serverUrl, roomId);
   connection.connect();
   return () => {
    connection.disconnect();
   };
}, [serverUrl, roomId]);

Here, an external connection exists outside React.

The component needs to connect when the relevant values change and clean up the connection when necessary.

That's a legitimate effect.

Other examples can include:

WebSocket connections
Browser APIs
Subscriptions
Timers
Third-party widgets
External libraries
Other systems whose lifecycle React needs to synchronize with The important question is not:

“Do I need to run this after render?”

The better question is:

“What external system am I synchronizing with?”

If you can't identify one, take another look at the effect.

7. Dont Confuse useEffect With “After Render Logic”
One reason developers overuse effects is the mental model:

“If something needs to happen after rendering, put it in useEffect.”

That's too broad.

A component can contain normal calculations that don't need to wait for an effect.

For example:

const greeting = Hello, ${name};

There is no reason to wait until after rendering to calculate this.

Likewise:

const isAdult = age >= 18;

Or:

const cartTotal = cart.reduce(
  (total, item) => total + item.price,
    0
);

These are normal render-time calculations.

They describe what the UI should look like based on the current inputs.

That's exactly what rendering is for.

8. Unnecessary Effects Make Data Flow Harder to Understand

Consider:

const [message, setMessage] = useState("");
useEffect(() => {
  setMessage(`${firstName} ${lastName}`);
 }, [firstName, lastName]);

To understand where message comes from, you now have to look in two places:

Where the state is declared.
Where the effect updates it.

With:


const message = ${firstName} ${lastName};

the relationship is immediately visible.

This is one of the biggest benefits of avoiding unnecessary effects:

The data flow becomes easier to follow.

Good React code should make it obvious where a value comes from and why it changes.

9. More Effects Can Mean More Synchronization Problems

Suppose a component has several pieces of derived state:

const [total, setTotal] = useState(0);
const [filteredItems, setFilteredItems] = useState([]);
const [selectedItem, setSelectedItem] = useState(null);
useEffect(() => {
   setTotal(...);
}, [items]);
useEffect(() => {
  setFilteredItems(...);
}, [items, search]);
useEffect(() => {
 setSelectedItem(...);
}, [items, selectedId]);

Now you've created multiple synchronization relationships.

Every new dependency can affect the behavior of these effects.

Instead, you might have:

const total = ...;
const filteredItems = ...;
const selectedItem = ...;

Now those values are derived directly from the current state and props.

No synchronization layer is required.

10. Render First. Optimize Later.

Another reason developers put calculations into effects is performance anxiety.

They think:

“I don't want this calculation to happen on every render.”

But moving a calculation into an effect doesn't automatically make the application faster.

In fact, it can make the update flow more complicated.

Start with:

const result = calculateSomething(data);
If the calculation is expensive and profiling shows that it matters, then consider:
const result = useMemo(
  () => calculateSomething(data),
  [data]
);

The important distinction is:

**Render logic calculates values.

useMemo can optimize expensive calculations.

useEffect synchronizes with external systems.**

These are three different responsibilities.

A Simple React Decision Tree
Before writing useEffect, ask yourself:
**
Is this value derived from props or state?**
If yes:

Calculate it during render.

Is this happening because the user clicked, submitted, selected, or interacted with something?
If yes:

**Put it in the event handler.

Is this an expensive calculation?**
If yes:

**Start with normal render logic and consider useMemo only if optimization is actually needed.

Are you connecting to, subscribing to, or controlling something outside React?**
If yes:

useEffect may be the right tool.

This simple decision tree can eliminate a lot of unnecessary effects.

Our Take
At Qodors, the approach is simple.

We don't treat useEffect as the default place for logic that needs to happen after render.

If a value can be calculated from props or state, we calculate it during render. If something happens because of a user interaction, we handle it in the event handler. We use useEffect when the component genuinely needs to synchronize with something outside React.

Derived data does not need its own state.

Filtering, sorting, formatting, calculating totals, combining values, and selecting items can usually happen directly during render.

Using an effect for these cases often creates an unnecessary render cycle:

render → effect → setState → render again

The code may work, but it introduces additional complexity and creates another piece of state that can become out of sync.

For expensive calculations, useMemo can be considered when there is an actual performance reason. But useMemo should optimize a calculation — it should not be used as a replacement for understanding where that calculation belongs.

The goal isn't to use fewer hooks just for the sake of using fewer hooks.

The goal is to make the data flow obvious.

Modern React development is not about putting every piece of logic into useEffect. It's about understanding what belongs in render, what belongs in an event handler, and what genuinely needs synchronization with an external system.

Quick Reference

Derived value from props/state → calculate it during render
Filtering / sorting / mapping data → calculate it during render
Expensive calculation → consider useMemo only when there is a real performance need
User interaction → handle it in the event handler
API / subscription / timer / external system synchronization → useEffect may be appropriate
Setting state inside an effect just to derive another value → usually a sign that you don't need the effect
useEffect is not a general-purpose “run this after render” mechanism → use it for synchronization and side effects
If your component has useEffect everywhere → stop and ask whether each effect is actually synchronizing with something outside React

So, should you stop using useEffect?

No. You should stop using it for things that don't need it.

If React can calculate something during render, let React calculate it.

If the user triggers an action, handle it where the action happens.

And when you genuinely need to synchronize with something outside React, that's where useEffect earns its place.

Less effect-driven code usually means fewer synchronization problems, clearer data flow, and React components that are much easier to understand.

React #JavaScript #TypeScript #ReactJS #FrontendDevelopment #WebDevelopment #SoftwareEngineering #Programming #ReactHooks #UseEffect #QodorsEdge

Written by the team at Qodors — we build and simplify modern React systems for a living. → www.qodors.com

Still Adding ConfigureAwait(false) To Everything?

qodors — Wed, 05 Aug 2026 05:05:39 +0000

You have probably seen ConfigureAwait(false) added after almost every await in older .NET codebases. It became one of those rules developers followed without questioning — add it everywhere, and async code will be safer and faster.

Maybe a code analyzer warns you when it is missing. Maybe you inherited a project where every async method uses it. Maybe a senior developer introduced the pattern years ago when it was considered the recommended approach.

But modern .NET is different.

The real question is:

Should you still add ConfigureAwait(false) to everything?

The short answer:

In ASP.NET Core application code, mostly no.

In library code, still yes.

The reason these answers are different is not because ConfigureAwait(false) is outdated. It is because the environment where your code runs has changed.

In modern .NET, using it everywhere is often just a habit. Understanding when it actually matters leads to cleaner and more maintainable code.

Application Code vs Library Code
APP CODE (ASP.NET Core)
No context to capture → Not needed

await GetDataAsync();

LIBRARY CODE
Unknown caller → Stay safe

await GetDataAsync().ConfigureAwait(false);

Not a performance optimization

The important difference is simple:

Application code knows where it runs. Library code does not know who will call it.

That is why the recommendation changes.

What ConfigureAwait(false) Actually Does
When you use await in C#, the runtime needs to decide where your code should continue after an asynchronous operation completes.

By default, .NET can try to continue execution on the same context where the async operation started.

Example:

var result = await GetDataAsync();

Process(result);
The continuation after await may attempt to return to the captured context.

ConfigureAwait(false) changes this behavior.

Example:

var result = await GetDataAsync()
     .ConfigureAwait(false);
  Process(result);

It tells .NET:

"Do not capture the current context. Continue execution wherever a thread is available."

The important part is the context.

Why ConfigureAwait(false) Became a Common Rule
The popularity of ConfigureAwait(false) came from older .NET application models.

Classic ASP.NET, WinForms, and WPF applications used synchronization contexts.

These contexts controlled where asynchronous code resumed.

In those environments, returning to the original context was important, but it also created problems.

One of the biggest issues was async deadlocks.

For example:

var data = GetDataAsync().Result;

or:


GetDataAsync().Wait();

The flow looked like this:

An async operation starts.
The current thread blocks waiting for completion.
The operation completes.
The continuation tries to return to the original context.
The original context is blocked.

The result:

A deadlock.

ConfigureAwait(false) helped avoid these problems by preventing the continuation from requiring the original context.

That is why developers started following:

"Always use ConfigureAwait(false)."

For that generation of .NET applications, that advice made sense.

Why ASP.NET Core Changed the Rule
ASP.NET Core changed the way asynchronous code behaves.

Unlike classic ASP.NET, ASP.NET Core does not use the same synchronization context model.

This means there is usually no request context that needs to be captured and restored.

In an ASP.NET Core controller or service:


var users = await GetUsersAsync();

already works efficiently.

Adding:

var users = await GetUsersAsync()
      .ConfigureAwait(false);

does not provide a meaningful improvement.

It does not:

Make API calls faster
Improve database performance
Reduce memory usage
Increase scalability

The continuation will already run efficiently using the thread pool.

Adding .ConfigureAwait(false) everywhere only makes code longer.

When Should You Still Use ConfigureAwait(false)?

Library code is where ConfigureAwait(false) still has value.

If you are creating:

NuGet packages
Shared libraries
SDKs
Internal reusable components
Open-source libraries

you do not control the environment where your code will run.

Your library may be used by:

A WPF desktop application
A WinForms application
A legacy ASP.NET project
Another framework that uses synchronization context

Because the caller is unknown, your library should avoid depending on its context.

Inside a Library Method
Example:

public async Task<string> GetDataAsync()
{
   var response = await _http.GetAsync(url)
        .ConfigureAwait(false);
    var body = await response.Content.ReadAsStringAsync()
         .ConfigureAwait(false);
      return body;
}

Here, ConfigureAwait(false) makes the library safer because it does not assume anything about the application calling it.

The library stays independent.

The Simple Rule to Follow
The easiest rule is:

Application code knows its environment.

Library code does not.

For ASP.NET Core application code:

await MethodAsync();

is usually enough.

For reusable library code:


await MethodAsync()
     .ConfigureAwait(false);

is still recommended.

The decision is not about performance.

It is about ownership of the execution environment.

Common Misunderstanding About ConfigureAwait(false)
Many developers treat ConfigureAwait(false) like a performance switch.

They believe:

"If I add it to every await, my ASP.NET Core application will become faster."

That is not true.

In ASP.NET Core, there is usually no synchronization context to remove.

So adding it everywhere only creates:

DotNet #CSharp #AsyncAwait #ConfigureAwait #DotNetCore #BackendDevelopment #Async #Programming #SoftwareEngineering #QodorsEdge

Written by the team at Qodors — we build and untangle .NET systems for a living. → www.qodors.com

Fast at Lunch. Slow at Scale: Why Your App Gets Slow When Real Data Arrives

qodors — Wed, 29 Jul 2026 05:05:35 +0000

A page that feels instant with a few users can become painfully slow when your business grows. The code hasn’t changed. The server hasn’t changed. The database hasn’t suddenly become bad.

The difference is scale.

More users. More records. More requests. More data moving through the same code paths.

Most performance problems don’t appear when you build the feature. They appear months later when real customers start using it with real data. A page that loaded in milliseconds during development can take seconds in production because the application was never tested against realistic conditions.

The problem is usually not the server.

It is how the application talks to the database.

The Scale Problem Hides in Normal Code
Performance bugs are dangerous because they often look like clean, simple code.

A developer writes a query that works perfectly:

var orders = await _db.Orders.ToListAsync();

The page loads quickly. The feature works. Everyone moves on.

But what happens when the table grows from 100 records to 100,000?

The same query now pulls thousands of rows, transfers unnecessary data, and forces the application to process information it does not need.

The code was correct.

The assumption was wrong.

Small data hides expensive decisions.

Problem #1: One Query Per Row
One of the most common scaling issues is making the database work repeatedly inside a loop.

Example:

var customers = await _db.Customers.ToListAsync();
foreach (var customer in customers)
{
   Console.WriteLine(customer.Orders.Count);
}

At first glance, this looks harmless.

Load customers. Loop through them. Read their orders.

But if related data is not loaded properly, the application may execute:

One query to load customers
One additional query for every customer’s orders

With 10 customers, that might be 11 queries.

With 10,000 customers, it becomes 10,001 queries.

This is the N+1 query problem.

The database is not slow because one query is expensive. It is slow because the application keeps asking the database the same type of question again and again.

The fix is to load related data intentionally.

Using Include:

var customers = await _db.Customers
    .Include(c => c.Orders)
    .ToListAsync();

Now the required data is loaded together instead of creating hundreds or thousands of database trips.

One well-planned query is usually better than thousands of small ones.

Problem #2: Loading Data You Never Use
Another common mistake is loading everything because it feels easier.

Example:

var users = await _db.Users.ToListAsync();

But the page only displays:

User name
Email
Status

The database returns:

Profile information
Address details
Metadata
Large text fields
Other unnecessary columns

The query works, but the application is moving more data than required.

As data grows, this becomes expensive.

A better approach is projection:

var users = await _db.Users
   .Select(u => new
   {
      u.Name,
      u.Email,
      u.Status
  })
      .ToListAsync();

Now the database returns only what the page needs.

Less data means:

Faster queries
Less memory usage
Faster responses
Better scalability

Performance improvements often come from removing unnecessary work, not adding more infrastructure.

Problem #3: Filtering Data Inside the Application

A common scaling mistake is pulling large amounts of data into the application and filtering afterward.

Example:

var orders = await _db.Orders.ToListAsync();
var completedOrders = orders
 .Where(o => o.Status == "Completed");

The application downloads every order first.

Then it filters.

The database already knows how to filter efficiently, so the work should happen there.

Better:

var completedOrders = await _db.Orders
  .Where(o => o.Status == "Completed")
    .ToListAsync();

Now the database only returns the required records.

The difference becomes massive as data grows.

Filtering 100 records feels the same.

Filtering 10 million records is a completely different problem.

Why It Works in Development but Fails in Production
Most performance problems survive because development environments do not represent real usage.

A developer tests with:

50 customers
100 orders
Few users

Production has:

Thousands of customers
Millions of records
Hundreds of simultaneous users

The code behaves differently because the environment changed.

The application was not slow.

The workload became real.

This is why performance testing with realistic data matters.

A query that looks fine with sample data can become the biggest bottleneck after months of growth.

How to Find These Problems Before Users Do
Performance issues are invisible if you only look at application code.

You need visibility into what is happening behind the scenes.
**
Monitor Database Queries**
Check:

Number of queries per request
Query execution time
Duplicate queries
Large data transfers

If one page load creates hundreds of similar queries, investigate.

Measure Real Page Performance
Do not only test the homepage.

Test:

Large dashboards
Search pages
Reports
Customer history pages
Admin panels

These are usually where scaling problems appear first.

Test With Production-Like Data
A small database gives false confidence.

Create test environments with:

Realistic record counts
Multiple users
Large relationships
Heavy usage scenarios

The goal is to discover problems before customers do.

Our Take
At Qodors, when an application becomes slow after growth, the first question is not always “Do we need a bigger server?”

Often, the better question is:

“Are we making the database do unnecessary work?”

A slow application is frequently the result of small decisions:

Querying inside loops
Loading unused information
Filtering after fetching everything

Each decision looks harmless during development.

Together, they create serious performance problems at scale.

The solution is not always more hardware.

It is better data access patterns.

Build applications that are designed for the data you will have tomorrow, not only the data you have today.

Quick Checklist
Check for queries running inside loops
Load only the fields your page needs
Filter data in the database, not the application
Monitor query count per page request
Test with realistic production-sized data
Measure performance before users report problems

Fast applications are not created by accident.

They are built by making intentional decisions about how code, databases, and users interact.

DotNet #CSharp #Backend Development #Performance |#Database #QodorsEdge

Written by the team at Qodors — we find and fix application performance problems for a living. → www.qodors.com

The N+1 Query Problem in EF Core (And How to Spot It Before Production Does)

qodors — Sat, 25 Jul 2026 05:41:36 +0000

A page that felt fine in testing is slow in production. Same code, same query, but now it crawls. You open the SQL log and there it is — not one query, but two hundred. One to load the list, then one more for every single row in it. That's the N+1 query problem, and it's one of the most common performance bugs in EF Core.

What is the N+1 query problem? It's when your code runs one query to get a list, then one extra query per item in that list to load something related. Ten items, eleven queries. A thousand items, a thousand and one. The database was never the problem. The number of trips to it was.

How It Sneaks In
The code that causes it looks completely normal.

var orders = await _db.Orders.ToListAsync();
foreach (var order in orders)
{
  Console.WriteLine(order.Customer.Name);
}

One query to load the orders. Looks fine. But order.Customer wasn't loaded with the orders, so the first time you touch it, EF Core quietly goes back to the database and fetches that customer. Once per order, inside the loop. Load 200 orders, and you've just fired 201 queries without writing a single extra line that looks like a query.

This is lazy loading doing exactly what it was told. Every time you reach for a related thing that isn't already loaded, EF Core fetches it on the spot. In a loop, that turns into hundreds of trips.

Why It Hides Until Production
The reason this one bites so often is that it passes every check on the way in.

With ten test rows, eleven queries run in a few milliseconds and nobody notices. The code reads cleanly. It reviews cleanly. The page loads fine on your machine. Then real data shows up — a customer with two thousand orders instead of ten — and the same code fires two thousand queries for one page load. Nothing changed in the code. The data got bigger, and the hidden cost got bigger with it.

How to Fix It
The fix is to tell EF Core up front what related data you need, so it loads everything in one trip instead of many.

Use Include to load the related data with the main query:

var orders = await _db.Orders
        .Include(o => o.Customer)
        .ToListAsync();

Now the customer comes back with the order in the same round trip. The loop touches order.Customer and it's already there — no extra queries. One query instead of 201.

Or project only what you need:

var orders = await _db.Orders

.Select(o => new {
       o.Id,
       CustomerName = o.Customer.Name
})
    .ToListAsync();

If you only need the customer's name, don't load the whole customer. Pull just the fields you'll use into a shape you control. One query, and less data over the wire on top of it.

Both fix the N+1. Include when you need the full related object, projection when you only need a few fields.

How to Actually Spot It
You can't fix what you can't see, and N+1 is invisible in the C# — it only shows up in the SQL. So make the SQL visible.

Log the queries EF Core runs. Turn on EF Core logging in development and watch the output while you click through a page. If one page load produces a wall of near-identical queries that differ only by an ID, that's N+1.

Watch the query count, not just the time. In development a page can feel fast and still be running fifty queries. The count is the warning sign, long before the clock is. If a single request is firing dozens of queries, something is looping over the database.

Test with realistic data. Most N+1 bugs get through because they're tested against a handful of rows. Seed a dev database with volumes closer to production — thousands of rows, customers with long histories — and the slow pages show themselves before your users find them.

Our Take
At Qodors, when a .NET app is slow for no obvious reason, N+1 is one of the first things we look for, and it's there more often than not. It's rarely a crash or an error. It's a page that got slower as the app got more real, running code that looks perfectly normal.

It ties into something we've written about before. Pull the whole table and filter in memory instead of in the database, and you get a related problem — too much work happening in the app instead of the database. N+1 is the opposite: too many small trips instead of one good one. Both come down to the same habit, letting the code decide how to talk to the database instead of deciding it on purpose.

The fix isn't clever. Load what you need, when you ask for the list, in one query. Then look at your SQL logs often enough that the next N+1 shows up in development, not in a support ticket.

Quick Checklist

Touching a related property inside a loop is the classic N+1 setup — check for it
Use Include to load related data in the same query when you need the full object
Use Select projection when you only need a few fields
Turn on EF Core query logging in development and watch for walls of near-identical queries
Count queries per page load, not just response time — the count warns you first
Test against production-sized data, not ten rows, or N+1 stays hidden until launch

The N+1 query problem isn't hard to fix. It's hard to see. Make your SQL visible in development, and the bug that used to reach production shows up in development instead.

DotNet #CSharp #EFCore #EntityFramework #Performance #NPlusOne #BackendDevelopment #DotNetCore #SQL #QodorsEdge

Written by the team at Qodors — we hunt down .NET performance bugs for a living. → www.qodors.com

EF Core Is Already a Repository. Stop Wrapping It in Another One.

qodors — Wed, 22 Jul 2026 09:35:31 +0000

Open a lot of .NET projects and you'll find the repository pattern sitting on top of Entity Framework Core. IProductRepository, GetById, Add, Save, the whole set. Underneath, every method just calls the EF Core DbContext and passes the result straight back. The wrapper adds a name and nothing else.

So do you need the repository pattern with EF Core? For most apps, no. EF Core already gives you one. DbSet is a repository. It already does the thing the pattern is for.

The reason this keeps happening is that the repository pattern got taught alongside EF, so people assume you need one to use the other. You don't.

What the Pattern Was For
The repository pattern came before EF Core. It started in a time when data access meant hand-written SQL, SqlCommand, and mapping DataReader rows to objects by hand. Wrapping all of that behind an interface was worth it. It hid a real mess, and it let you swap what was underneath without the rest of the app noticing.

EF Core already does that. DbContext is the unit of work. DbSet is the repository. SaveChanges() is the commit. The pattern you're adding is one the tool already gives you.

What the Wrapper Actually Does
Here's the shape you see in most codebases:

public class ProductRepository : IProductRepository
{
   private readonly AppDbContext _db;
   public ProductRepository(AppDbContext db) => _db = db;
   public async Task<Product?> GetById(int id) =>
          await _db.Products.FindAsync(id);
   public async Task<List<Product>> GetAll() =>
          await _db.Products.ToListAsync();
   public void Add(Product product) => _db.Products.Add(product);
}

Read what each method does. GetById calls FindAsync. GetAll calls ToListAsync. Add calls Add. It's a passthrough. Every line hands the call straight to EF Core and returns whatever comes back. You wrote an interface, a class, and a registration to rename methods that already existed. This is what people mean by a generic repository over EF Core, and it's the most common version you'll find.

Where It Starts to Hurt
The renaming is harmless enough. The real cost shows up the moment someone needs a query the repository didn't plan for.

Say you need products in a category, over a price, ordered by date, with the supplier included. With EF Core in the service you write that in one LINQ query and move on. Behind a repository you can't, because the service only sees the methods on the interface. So you do one of these:

Add a new method to the interface for this exact query, and do it again for the next one
Add a generic Find(Expression>) and hand IQueryable back out — at which point the repository is hiding nothing and you've just made EF harder to reach
Pull the whole table with GetAll() and filter in memory, which is how a repository quietly turns into a performance problem

Every one of those is worse than just using the DbContext. The wrapper that was supposed to simplify data access is now the thing standing between you and the query you need to write.

The We Can Swap the Database Argument
The usual defense is that the repository lets you swap the database later without touching the app. It almost never happens, and the abstraction doesn't deliver it anyway.

EF Core is already the layer that lets you change database providers. Switching from SQL Server to PostgreSQL is a provider and connection-string change, not a rewrite of your data access. The repository on top adds nothing to that. And if you ever moved to something EF doesn't support, your repository interfaces — built around EF's own behavior — wouldn't still work anyway. You'd be rewriting them too.

You're holding an abstraction for a swap that probably won't come, and that the abstraction wouldn't actually save you from.

Testing Is the One Fair Reason
The one real reason left is testing. Mocking a DbContext is awkward, so people put a repository in front of it to get a clean interface to mock. That's a real pain, and it's the strongest case for the pattern.

But there are lighter ways to handle it. The EF Core in-memory provider and SQLite in-memory both let you test against a real DbContext without a repository in the way, and they catch things a mock never will — because a mock only tests that you called the method you thought you called, not that the query actually works. If your only reason for the repository is testing, compare it to just testing the DbContext directly. Often that's the better test anyway.

Our Take
At Qodors, the generic Repository on top of EF Core is one of the most common things we find that's there out of habit. It doesn't break anything. It just sits there — a layer everyone has to go through, adding method names on top of methods that already worked.

The tell is simple. Open the repository and read the method bodies. If every one is a single line handing the call to the DbContext, the layer isn't abstracting anything. It's a rename with extra files.

There are real repository implementations that do genuine work — ones that combine sources, add caching, or hold logic that isn't just a query. Those earn their place. The passthrough wrapper around a single DbSet isn't one of them. Before you add a repository to an EF Core project, check whether you're solving a problem or repeating a pattern from a tutorial.

Quick Checklist

Read your repository method bodies — if they're one-line passthroughs to DbContext, the layer isn't doing anything
DbSet is already a repository and DbContext is already a unit of work
Database-swap portability comes from EF Core's providers, not from your wrapper
If the repository blocks a query, you'll hand IQueryable back out or filter in memory — both worse than direct EF
Testing is the fair reason — but the in-memory or SQLite provider often tests better than a mock
A repository that caches, combines sources, or holds real logic earns its place; a passthrough doesn't

EF Core came with a repository and a unit of work already built in. Wrapping it in another one to get names you like is a lot of files for a rename. Use the one it already gives you.

DotNet #CSharp #EFCore #EntityFramework #SoftwareArchitecture #RepositoryPattern #BackendDevelopment #DotNetCore #CleanCode #QodorsEdge

Written by the team at Qodors — we untangle over-abstracted .NET codebases for a living. → www.qodors.com

You Probably Don't Need MediatR

qodors — Tue, 21 Jul 2026 09:53:29 +0000

MediatR shows up in a lot of .NET codebases by default now. Someone starts a project, adds it in the first week, and every request goes through a handler from then on. Ask why it's there and the answer is usually "it's clean" or "it's what we always do." That's a habit, not a reason.

For a lot of apps, MediatR adds extra layers that cost you more than you get back.

What People Think It Gives Them
The pitch is decoupling. Your controller doesn't call a service directly — it sends a request object, and somewhere a handler picks it up and deals with it. The controller doesn't know who handles it. On paper that sounds like clean separation.

The other selling point is the pipeline. You can wrap every request in behaviors — logging, validation, transactions — without touching each handler. One place to add the stuff that cuts across everything.

Both are real features. Whether you're actually getting the benefit, or just paying for the setup, is the part worth thinking about.

What It Actually Costs
Start with navigation. In a normal service call you hit F12 on the method and you're looking at the code. With MediatR you hit F12 on Send() and you land inside the library. To find the handler you go searching by the request type name, because there's no link the compiler can follow between the thing sending the request and the thing handling it. Across a whole codebase, every developer pays that small tax every time they try to follow the flow.

Then there's the extra code. A request that could've been _orderService.Cancel(id) becomes a command class, a handler class, a registration, and a Send() call. You've turned one method into four moving parts. For a genuinely complex operation that might be worth it. For "cancel an order," it's a lot of code for nothing.

And the decoupling often isn't real. Your controller still needs the request object, the request object still goes to exactly one handler, and if you change what the operation does you change both. Nothing is actually swappable. You've got the extra layers of loose coupling with none of the flexibility, because each request has one handler and always will.

The Pipeline Argument Is the Strongest One
If there's a reason to reach for MediatR, it's the behaviors, so it's worth being straight about it.

Wrapping every request in validation, logging, and transaction handling from one place is genuinely useful, and doing the same thing without MediatR takes more work. Middleware handles some of it, but not the per-request-type control you get from a pipeline behavior.

Here's the catch. .NET already gives you most of this. Middleware covers the stuff that cuts across requests. Filters cover it at the action level. Validation has standard ways that don't need a mediator at all. So the pipeline is a real benefit, but for a lot of apps it's solving a problem the framework already handles.

When It Actually Earns Its Place
MediatR isn't bad. It's a well-built library, and there are codebases where it fits.

If you've really gone with CQRS and you have a proper split between commands and queries, each handled its own way, the request/handler model fits that. If you've got a large team and forcing one consistent shape for every operation is worth something, the uniformity helps. If your pipeline is complex enough that behaviors save real work, that's a fair trade.

Those are specific cases. The problem isn't people using MediatR there. It's people adding it to a plain CRUD API on day one because it's become the default, then living with the extra layers for the life of the project without ever needing what it offers.

Our Take
At Qodors, when we pick up an existing .NET codebase, MediatR is often there and often it's doing nothing. Every endpoint sends a command, every command has one handler, and no behavior in the pipeline is doing anything a filter or a bit of middleware couldn't. The abstraction is there, the benefit isn't.

Newer developers feel it most. They open the project, see requests going off into handlers with no direct call to follow, and spend their first weeks learning the plumbing instead of the domain. That cost is real, and it gets paid on every codebase that added the library without needing it.

Before you add MediatR to a new project, ask what it does that a plain service class won't. If you can point at a real pipeline need or an actual CQRS split, add it. If the answer is that it's cleaner, look again. A service you can jump straight to beats a request you have to go hunting for.

Quick Checklist
Adding MediatR? Name the specific thing it does that a service class won't
One handler per request forever isn't decoupling — it's an extra layer with no payoff
The stuff that cuts across requests often fits in middleware or filters you already have
Pipeline behaviors are the real benefit — reach for it when you actually need them
A real CQRS split or a big team enforcing one shape are fair reasons; "it's clean" isn't
Count the navigation cost — every developer pays it every time they trace a request

MediatR solves real problems. Most CRUD apps don't have those problems. If you're reaching for it out of habit instead of a reason you can name, a plain service class will serve you better and read clearer.

DotNet #CSharp #MediatR #SoftwareArchitecture #CQRS #BackendDevelopment #SoftwareEngineering #DotNetCore #CleanCode #QodorsEdge

Written by the team at Qodors — we untangle over-abstracted .NET codebases for a living. → www.qodors.com

AsNoTracking: The EF Core Setting Your Read Queries Are Missing

qodors — Fri, 10 Jul 2026 08:38:53 +0000

Most of the queries in a typical app are reads. You fetch data, show it, and never change it. EF Core doesn't know that. By default it assumes every entity you load might be modified and saved back, so it keeps track of all of them. That tracking has a cost, and on read-only queries you're paying it for nothing.

AsNoTracking() turns it off for a query. The data comes back the same, minus the bookkeeping.

What Tracking Actually Does
When EF Core runs a normal query, it doesn't just hand you objects. It takes a snapshot of every entity and holds a reference to it in the change tracker. That's how SaveChanges() knows what changed — it compares the current state of each tracked entity against the snapshot it took when the entity was loaded.

That's what you want when you're updating. When you load a customer, change their email, and call SaveChanges(), the tracker is what figures out that one field changed and writes the UPDATE.

When you're loading a list of orders to render on a page, none of it matters. You're not saving anything, but EF Core still builds the snapshots and holds the references anyway, doing comparison work it will never use.

Where the Cost Shows Up

var orders = await _db.Orders
     .Where(o => o.CreatedAt > lastWeek)
     .ToListAsync();

This tracks every order it returns. Ten rows, fine. A few thousand rows on a reporting screen, and the tracking overhead becomes real — extra memory for the snapshots, extra CPU building them, and a change tracker now holding references to thousands of entities it'll never save.

Add AsNoTracking() and that goes away:

var orders = await _db.Orders
     .AsNoTracking()
     .Where(o => o.CreatedAt > lastWeek)
     .ToListAsync();

Same SQL. Same data back. EF Core skips the snapshot and doesn't retain the entities. On large read queries the difference in memory and time is measurable, and it costs you one method call.

The Bug That Tracking Hides
There's a second reason this matters, and it's not about performance.

Because the change tracker holds references to everything it loads, it also returns the same instance if you query the same row twice in one context. Sometimes that's convenient. Sometimes it hides a problem — you edit a tracked entity somewhere, and a completely separate read query later hands back your modified version instead of what's actually in the database, because the tracker gave you the cached instance.

With AsNoTracking(), every query goes to the database and gives you a fresh object. For read paths, that's usually what you actually want.

When You Should Not Use It
AsNoTracking() is for reads. The moment you plan to change an entity and save it, you need tracking on, because that's the mechanism that detects the change.

var customer = await _db.Customers
     .FirstAsync(c => c.Id == id);
customer.Email = newEmail;
await _db.SaveChanges();   // works because customer is tracked

Put AsNoTracking() on that query and SaveChanges() does nothing — EF Core isn't tracking the entity, so it has no idea anything changed. No error, no update, the email silently stays the same. The code looks correct, which is what makes it hard to find.

So the line is simple: reading and displaying, use AsNoTracking(). Loading something to modify and save, don't.

Doing It Everywhere Without Repeating Yourself
If most of your app is reads, adding AsNoTracking() to every query gets tedious and easy to forget. You can flip the default for a whole context:

optionsBuilder.UseSqlServer(connectionString)
     .UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking);

Now queries are no-tracking by default, and you opt back in on the queries that actually write, using .AsTracking(). For a read-heavy app this is often the better default — you stop paying for tracking everywhere and only turn it on where you need it.

Just make sure the team knows the default changed. Someone who assumes tracking is on will write the update code above and watch SaveChanges() quietly do nothing.

Our Take
At Qodors, when we profile a read-heavy .NET app that's using more memory than it should, tracking is a regular offender. It rarely shows up as a crash or an obvious error. It shows up as a service that holds more memory than the data justifies, or a request that's slower than the size of its result set explains.

It connects to something we've written about before — a query returning far more rows than it should because of the wrong IQueryable/IEnumerable return type. Fix that so you're loading the right rows, then add AsNoTracking() so you're not paying to track the read-only ones. The two together cover a large share of the EF Core performance problems we see.

It's default behavior that happens to be correct for writes and wasteful for reads, running in an app that mostly reads.

Quick Checklist
Add AsNoTracking() to queries that only read and display data
Leave tracking on for any query where you'll modify the entity and call SaveChanges()
For read-heavy apps, consider QueryTrackingBehavior.NoTracking as the context default and opt back in with .AsTracking()
If SaveChanges() silently does nothing, check whether the entity was loaded with AsNoTracking()
Watch for stale data from the change tracker returning a cached instance on read paths
Pair it with correct IQueryable return types so you're tracking fewer, and the right, rows

Tracking is on by default because EF Core can't tell a read from a write. On the queries where you're only reading, tell it. That's the whole optimization.

DotNet #CSharp #EFCore #EntityFramework #Performance #BackendDevelopment #SoftwareEngineering #DotNetCore #SQL #QodorsEdge

Written by the team at Qodors — we profile and fix slow, memory-hungry .NET apps. → www.qodors.com

IQueryable vs IEnumerable: The Mistake That Loads Your Whole Table

qodors — Thu, 09 Jul 2026 10:40:48 +0000

You wrote a clean LINQ query. It filters down to ten rows. It runs fine in dev, and then in production it's slow and your database CPU is higher than it should be for such a small result.

The query looks right. The problem is where the filtering happens. With IEnumerable, the filter runs in your app after the whole table is already loaded from the database. With IQueryable, the filter becomes part of the SQL and runs in the database. Same LINQ, completely different amount of data moving across the wire.
Get this wrong on a large table and you're pulling every row into memory to throw almost all of them away.

The Two Interfaces
Both let you write .Where(), .Select(), .OrderBy(). That's why they get mixed up. The difference is when and where the query executes.
IEnumerable works on objects already in memory. When you call .Where() on it, the filtering happens in your application, in C#, row by row. If the data came from a database, it's already been loaded in full before your filter ever runs.
IQueryable builds an expression tree instead of running anything immediately. EF Core takes that tree and translates it into SQL. Your .Where() becomes a SQL WHERE clause, and the database does the filtering before it sends anything back.
Same method names. One filters in the database, the other filters in your app after the table is already loaded.

Where It Goes Wrong
Here's the line that causes it:

public IEnumerable<Order> GetOrders()
{
    return _db.Orders;   // returns IEnumerable
}

The method returns IEnumerable. The moment you expose it as IEnumerable, any .Where() a caller adds runs in memory, not in SQL:

`var recent = GetOrders().Where(o => o.CreatedAt > lastWeek);`

That .Where() looks like it filters in the database. It doesn't. GetOrders() already returned an IEnumerable, so EF Core loads the entire Orders table into memory, and then C# filters it down to last week's rows. On a table with a few hundred rows you'd never notice. On a table with two million, it's a disaster.
Now the version that does what you expect:

public IQueryable<Order> GetOrders()
{
    return _db.Orders;   // returns IQueryable
}

var recent = GetOrders().Where(o => o.CreatedAt > lastWeek).ToList();

Because GetOrders() returns IQueryable, the .Where() gets folded into the query, and EF Core generates SQL like this:

SELECT [o].[Id], [o].[CustomerId], [o].[CreatedAt], [o].[Total]
FROM [Orders] AS [o]
WHERE [o].[CreatedAt] > @lastWeek

The database filters first and sends back only the rows you asked for. Same calling code. One returns two million rows over the wire, the other returns a handful.

The Trap Is the Return Type
The mistake almost always hides in a method signature. Someone writes a repository or service method that returns IEnumerable because it feels safer or more general. Every caller that adds a filter after that point is filtering in memory, and nobody notices until the table grows.
AsEnumerable() and ToList() do the same thing on purpose. The moment you call either, everything after it runs in memory:

var recent = _db.Orders
.ToList()                              // whole table loaded here
    .Where(o => o.CreatedAt > lastWeek);   // filters in memory

Move the .Where() before the .ToList() and it runs in SQL. The order matters, and it's easy to get backwards.

When You Actually Want IEnumerable
This isn't "always use IQueryable." Once the data is in memory, IEnumerable is the right type, and forcing IQueryable where it doesn't belong just adds confusion.
If you've already loaded a list and you're filtering it in code, that's IEnumerable and that's correct. If you're working with an in-memory collection that never touched a database, there's no SQL to translate to, so IQueryable buys you nothing. And there are queries EF Core can't translate to SQL — certain method calls or custom C# logic — where you have to pull the data into memory first and finish the work there. That's a real case, just do it deliberately, not by accident through a return type.
The point isn't to fear IEnumerable. It's to know which one you're holding and where the filtering will run.

Our Take
At Qodors, when a .NET app has queries that are slow out of proportion to the data they return, this is one of the first things we look at. The query reads fine. The LINQ is correct. The problem is a method three layers down that returns IEnumerable, quietly loading a whole table so the app can filter it in memory.
It hides well because it doesn't fail. Small tables in development behave normally, tests pass, and it only turns into a problem when real data volume shows up. By then it looks like a database performance issue, and people go tuning indexes when the fix is a return type change from IEnumerable to IQueryable.
Check what your repository and service methods return. If they hand back IEnumerable from an EF Core query, your filtering probably isn't happening where you think it is.

Quick Checklist

Return IQueryable from repository/service methods that wrap EF Core queries, so callers filter in SQL
Watch every ToList() and AsEnumerable() — everything after it runs in memory
Keep .Where() and .Select() before you materialize with ToList()
Use IEnumerable for data that's already in memory — that's what it's for
If a query genuinely can't translate to SQL, pull it into memory on purpose, not by accident
When a query is slow for the rows it returns, check the return types up the call chain
IQueryable and IEnumerable share the same LINQ methods, which is exactly why the bug is easy to write and hard to spot.
One filters in the database. The other loads the table first and filters in your app.

Know which one your method returns. That one decision is the difference between a query that touches ten rows and one that drags two million across the wire.

DotNet #CSharp #EFCore #LINQ #EntityFramework #BackendDevelopment #SoftwareEngineering #DotNetCore #Performance #QodorsEdge

Written by the team at Qodors — we fix .NET apps with queries slower than they should be. → www.qodors.com

Dependency Injection in .NET Is Easy to Get Wrong

qodors — Wed, 01 Jul 2026 09:53:11 +0000

Almost every weird intermittent bug I've dealt with in a .NET app traced back to one place: a service registered with the wrong lifetime in Program.cs. Not the logic inside the service. The single line that said how long it should live.

DI itself is built into .NET and easy to start with. You register your services, ask for them in a constructor, and the framework hands them over. The part that trips people up isn't wiring it together. It's the lifetimes.

Get a lifetime wrong and the app still starts, requests still succeed, and everything looks healthy. The damage shows up later as stale data, or state bleeding between users, or memory that climbs and never drops back down.

The Three Lifetimes

There are three, and the whole thing hinges on understanding them.

*Transient *— you get a new instance every time you ask for one. Two things in the same request that both need it get two separate copies.

*Scoped *— you get one instance per request. Everything in a single HTTP request shares the same instance, and the next request gets a fresh one.

*Singleton *— you get one instance for the entire lifetime of the app. Every request, every user, shares the exact same object.

builder.Services.AddTransient<IEmailSender, EmailSender>();
builder.Services.AddScoped<IOrderService, OrderService>();
builder.Services.AddSingleton<ICacheProvider, CacheProvider>();

That's the whole API. Three methods. Picking the wrong one of the three is where most of the trouble comes from.
The Captive Dependency

This is the one that gets almost everybody at some point.

You have a singleton. Inside it, you inject something scoped. It compiles, it runs, and it looks fine. But you've just trapped a scoped service inside a singleton.

The singleton is created once and lives forever. The scoped service it grabbed gets held onto for that whole time, instead of being created fresh per request like it's supposed to. So now a service that was meant to live for one request is stuck living for the entire app.

public class CacheProvider : ICacheProvider   // registered as Singleton
{
    private readonly AppDbContext _db;         // this is Scoped

    public CacheProvider(AppDbContext db)      // now the DbContext is captive
    {
        _db = db;
    }
}

DbContext is the classic victim. It's registered scoped for a reason. It's not built to be shared across requests, it tracks changes and holds a connection, and when you trap it inside a singleton you get stale data, threading errors, and connection problems that are miserable to track down.

The rule that keeps you safe: a service can only depend on things that live as long as it does, or longer. A singleton can depend on a singleton. A scoped service can depend on scoped or singleton. But a singleton depending on scoped is the trap.

The good news is that .NET can catch this for you. There's a scope validation check that throws at startup when a singleton depends on something scoped, and it's on by default in the Development environment. Don't turn it off. If it throws, it's telling you about a real bug before it reaches production.
Singletons Holding State

The other common mistake is making something a singleton without thinking about what it holds.

A singleton is shared across every request at the same time. If it has mutable state — a field it writes to, a dictionary it updates, a list it appends to — then multiple requests are hitting that state at once, on different threads. That's a race condition, and it shows up as data from one user leaking into another user's request, or numbers that don't add up.

If a service is a singleton, either it holds no state, or the state it holds is safe for many threads to touch at once. A stateless helper is fine as a singleton. A cache built on a thread-safe collection is fine. A service that quietly keeps per-user data in a plain field is not.
So Which One Do You Pick

For most things, the answer is scoped, and that's also the default for a reason.

Scoped fits how web requests work. One instance per request, fresh state each time, cleaned up when the request ends. Your services that touch the database, handle business logic, or deal with the current user should almost always be scoped.

Use transient for small, cheap, stateless things where a new instance every time costs nothing. Use singleton for things that are genuinely shared and either hold no state or are built to be thread-safe — configuration, a connection factory, an in-memory cache.

When you're not sure, scoped is the safe default. Reaching for singleton to "save memory" is where people get into trouble, and the memory you save is almost never worth the bugs you buy.
Our Take

At Qodors, when we're brought into a .NET app with weird intermittent bugs — stale data, state bleeding between users, memory that only grows — DI lifetimes are near the top of the list we check. It's rarely the code inside the service that's broken. It's how the service was registered.

What makes it hard is that the wrong lifetime doesn't fail loudly. The app starts, requests succeed, everything looks healthy. The problem only surfaces under real concurrent traffic, and by then it looks like a dozen unrelated bugs instead of one registration mistake.

Turn on scope validation, default to scoped, and think for a second before you make anything a singleton. Most DI problems never happen if you do those three things.
Quick Checklist

Default to scoped unless you have a clear reason not to
Never inject a scoped service into a singleton (the captive dependency)
A service can only depend on things that live as long as it does, or longer
Keep scope validation on in Development — don't silence it
Singletons must be stateless or genuinely thread-safe
DbContext stays scoped — don't trap it in a singleton

The wrong lifetime is a one-line mistake that hides for weeks. It doesn't break the build and it doesn't throw in testing. It waits for real traffic, then hands you a pile of bugs that look unrelated until you trace them back to a single registration.

Default to scoped, keep scope validation on, and be deliberate about singletons.

DotNet #CSharp #DependencyInjection #AspNetCore #BackendDevelopment #SoftwareEngineering #DotNetCore #StartupCTO #QodorsEdge

Written by the team at Qodors — we fix .NET apps with weird intermittent bugs. → www.qodors.com

Stop Using .Result and .Wait() in Your .NET Code

qodors — Wed, 24 Jun 2026 12:00:41 +0000

Your app works fine in testing. You deploy it, a few users come on, and then it just... hangs. No error, no crash. The request sits there until it times out.

You check the logs. Nothing useful. You restart the app and it's fine again for a while, then it locks up again under load.

If you've got .Result or .Wait() anywhere in your code, that's very likely your problem. They look harmless. They're not.
What These Actually Do

.Result and .Wait() take an async method and force it to run synchronously. You've got a Task and you want the value now, without making your method async, so you write:

var data = GetDataAsync().Result;

It compiles. It works on your machine. It looks like a quick way to avoid turning half your code async.

What it actually does is block the current thread and tell it to sit and wait until the async operation finishes. And in certain setups, that wait never ends.
The Deadlock

Here's how it locks up.

In older ASP.NET (and some desktop apps), there's a synchronization context that controls which thread continues after an await. When the async work finishes, it tries to come back to the original thread to continue.

But that original thread is the one you blocked with .Result. It's sitting there waiting for the async work to complete. The async work is waiting for that thread to be free so it can finish. Neither one gives way.

The request hangs. No exception, no log line, nothing. Just a thread stuck forever, and eventually a timeout. Do this enough times under load and you run out of threads, and the whole app stops responding.

The worst part is it often doesn't show up in testing. One request at a time on your machine works fine. It's only under real traffic, with the thread pool under pressure, that it falls apart. So it passes your tests and breaks in production.
The Fix Is Boring

Don't block. Go async the whole way.

var data = await GetDataAsync();

That's it. Make your method async, return a Task, and await the call instead of reaching for .Result.

The rule people say for this is "async all the way." If a method calls something async, it should be async too, and so should the method that calls it, up the chain. Once one part of your code is async, that tends to spread upward, and that's fine. That's how it's supposed to work.

public async Task<Customer> GetCustomerAsync(int id)
{
    var customer = await _repository.GetByIdAsync(id);
    return customer;
}

No blocking, no deadlock, and the thread is free to handle other requests while it waits.
"But I Can't Make This Method Async"

This is the usual reason people reach for .Result. A constructor can't be async. A property getter can't be async. Some old interface you have to implement isn't async.

Most of the time the real fix is to move the async work somewhere it belongs. Don't do database calls in a constructor. Don't run async work inside a property. If you've got async work stuck inside something that can't be async, that's usually a sign the work is in the wrong place, not a sign you need to block.

There are a few genuine exceptions. The Main method in older console apps sometimes had to block (modern .NET lets Main be async, so this is mostly gone). And there are rare spots in framework-level code where you're truly stuck. But those are rare. If you're reaching for .Result in your normal request-handling code, it's almost never one of those cases.
A Note on ConfigureAwait

You'll see advice to use ConfigureAwait(false) to avoid the deadlock:

var data = await GetDataAsync().ConfigureAwait(false);

This tells the await it doesn't need to come back to the original thread, which sidesteps the deadlock. It's worth using in library code. But treat it as a safety net, not a fix. The actual fix is to not block in the first place. If your code is properly async all the way through, you don't have the deadlock to work around.
Our Take

At Qodors, when a .NET app hangs under load with no error in the logs, .Result and .Wait() are one of the first things we grep for. It's a common one, and it's nasty precisely because it hides during testing and only shows up when real users arrive.

The fix is rarely complicated. It's usually just making a chain of methods async that should have been async from the start. It feels like more work than slapping .Result on the end of a call, and that's exactly why people skip it. Then they spend a week chasing a production hang that a single await would have prevented.

Async all the way isn't a style preference. It's how the thing is meant to be used.
Quick Checklist

Search your codebase for .Result and .Wait() — find every one
Anywhere in request-handling code, replace blocking with await
Make the calling methods async Task up the chain
If async work is stuck in a constructor or property, move it out
Use ConfigureAwait(false) in library code as a safety net, not a substitute for going async

.Result and .Wait() are quick to type and they'll pass your tests. Then they hang in production with no error to point you at the cause.

Go async properly and the problem never shows up. That's the whole trade.

DotNet #CSharp #AsyncAwait #AspNetCore #BackendDevelopment #SoftwareEngineering #Performance #DotNetCore #StartupCTO #QodorsEdge

Written by the team at Qodors — we fix .NET apps that hang under load. → www.qodors.com

Entity Framework Is Slow. It's Not EF's Fault.

qodors — Sat, 20 Jun 2026 12:00:56 +0000

Your API was quick in development. Then traffic picks up and a few endpoints start taking three seconds to respond.

You open the code, see Entity Framework everywhere, and figure that's the culprit. Time to rip it out and write proper SQL.

Don't. Before you throw away the thing saving you thousands of lines of code, look at what it's actually doing. Most of the time EF isn't slow. It's doing exactly what your code asked, and your code asked for something expensive.
EF Does What You Tell It

Entity Framework writes SQL for you. That's the point, and it's useful. The downside is that one clean-looking line of C# can turn into a query that hammers your database, and nothing in the code tells you that's happening.

The SQL is hidden, so the cost is hidden too. That's usually where things go wrong.

Below are the four things that actually slow EF down. None of them are EF being slow.
1. The N+1 Problem

This is the big one. Almost every slow EF app has it somewhere.

You load a list of orders, loop through them, and read order.Customer for each one:

var orders = context.Orders.ToList();
foreach (var order in orders)
{
    Console.WriteLine(order.Customer.Name);
}

EF didn't load the customers when it loaded the orders. So the first line runs one query, and then every time you touch order.Customer it goes back to the database for that one customer. A hundred orders, a hundred and one queries.

Tell EF to load the customers with the orders and the problem goes away:

var orders = context.Orders
    .Include(o => o.Customer)
    .ToList();

Same data on screen, one query instead of a hundred and one.
2. Loading Whole Entities for Two Fields

Say you need a list of customer names and emails for a page. The easy version:

var customers = context.Customers.ToList();

EF pulls every column of every customer and builds a full object for each. Addresses, notes, timestamps, everything. You needed a name and an email.

Project down to what you'll actually use:

var customers = context.Customers
    .Select(c => new { c.Name, c.Email })
    .ToList();

Now it's two columns. Less data read, less memory spent building objects you were never going to look at.

3. Tracking You Don't Need

EF tracks every entity it loads so it can figure out what changed when you call SaveChanges. That's needed when you're updating something. It's pure overhead when you're just reading data to show it on a screen and you'll never touch it again.

For read-only queries, switch tracking off:


var products = context.Products
    .AsNoTracking()
    .ToList();

On a large result set this matters, because EF stops building and holding all the change-tracking state it was never going to use.

Filtering in C# Instead of the Database

This one is easy to miss and it hurts badly:


var activeUsers = context.Users
    .ToList()
    .Where(u => u.IsActive);

The ToList() runs first. That pulls every user into memory, and only then does the Where filter them in C#. Two million users, fifty active, and you've loaded all two million to keep fifty.

Move the filter ahead of ToList() so it ends up in the SQL:

var activeUsers = context.Users
    .Where(u => u.IsActive)
    .ToList();

Now the database filters and hands you fifty rows. Same two lines, swapped order, completely different behaviour under load.
See What EF Is Doing

You don't have to guess about any of this. EF can log the SQL it generates. Turn it on in your DbContext setup:

optionsBuilder.LogTo(Console.WriteLine, LogLevel.Information);

Run the app, hit the slow endpoint, read the output. The same SELECT firing over and over in a loop is your N+1. A query dragging out thirty columns when you needed two is your projection problem. It's all there.

Most teams never look. They treat EF as a black box and blame it when things get slow. It isn't a black box. The SQL is sitting in the logs the whole time.
When Raw SQL Is Actually Worth It

EF isn't always the right call. A heavy reporting query with several joins, grouping and aggregation can genuinely be faster and clearer as hand-written SQL or a stored procedure. Use raw SQL there. EF doesn't have to handle everything.

But that's a small part of a normal app. The everyday reads and writes that make up most of your code are fine in EF once you've stopped tripping over the four things above. Rewriting your whole data layer because a handful of queries are slow is a huge amount of work to fix something that usually lives in four or five places.

Find the slow queries first. Then decide.
Our Take

At Qodors, when a client says EF is slow and wants it gone, the first thing we ask for is the generated SQL. Nobody writes raw SQL until we've seen that.

It's almost always the same short list. An N+1 that needs an Include. A query loading full entities where a projection would do. Read-only queries that should be AsNoTracking. A filter sitting on the wrong side of a ToList(). Fixing those is usually a day of work, and it gets you most of the speed people were hoping a full rewrite would buy.

EF is a tool. Hand it careless code and it produces expensive queries. That's worth understanding before you decide the framework is the problem.
Before You Rip Out EF

Turn on SQL logging and read what EF actually generates
Look for the same query firing in a loop, then fix it with Include
Check whether you're loading full entities where a Select would do
Make sure read-only queries use AsNoTracking
Check for any .Where sitting after a .ToList() instead of before it

EF will happily generate bad SQL if your code asks for it. The fix is almost never ripping it out. Read the queries first. Most teams find the framework was never the problem.

DotNet #EntityFramework #CSharp #EFCore #AspNetCore #BackendDevelopment #SoftwareEngineering #Performance #StartupCTO #QodorsEdge

Written by the team at Qodors — we make slow .NET systems fast without rewrites. → www.qodors.com