DEV Community: qodors

Still Writing Slow SQL Queries? 10 Ways to Improve Performance

qodors — Wed, 09 Sep 2026 13:01:06 +0000

A SQL query can return the right data and still do much more work than it needs to. A query that works well with a small dataset may become slow as the application grows.

When a query starts taking longer, developers often try adding an index, changing a JOIN, or increasing server resources. Those changes can help, but they do not always address the actual problem. The first step should be finding out what the database is really doing.

The SQL query optimizer uses the query, indexes, statistics, joins, filters, and estimated costs to choose an execution plan. Good query design gives the optimizer a better chance of choosing an efficient plan.

Here are 10 practical ways to find and fix common SQL performance problems.

1. Check the Execution Plan First
Before changing a slow query, look at its execution plan.

The plan can show whether the database is scanning a large table, using an index, performing an expensive join, or spending most of its time on a particular operation.

For example:

SELECT *
FROM Orders
WHERE CustomerId = 1024;

The query looks simple. But the execution plan can tell you whether the database is finding the matching rows efficiently or scanning the whole table.

Instead of guessing what might be wrong, start by looking at the actual work being done.

2. Avoid SELECT*
Only request the columns the application needs.

Instead of:

SELECT *
FROM Customers
WHERE Country = 'India';

use:

SELECT CustomerId, Name, Email
FROM Customers
WHERE Country = 'India';

Returning unnecessary columns means more data may need to be read, processed, and sent back to the application.

This matters even more when a table contains large text fields, JSON data, or other wide columns.

3. Use Indexes for Frequent Filters
Indexes can make a big difference when they match the way your application searches or sorts data.

For example:

SELECT OrderId, OrderDate
FROM Orders
WHERE CustomerId = 1024;

If CustomerId is frequently used for filtering, an appropriate index can help the database find the required rows without scanning the entire table.

But adding indexes to every column is not a solution. Indexes use storage and also add work when rows are inserted, updated, or deleted.

Create indexes around real query patterns and then check the execution plan to see whether they actually help.

4. Be Careful With Functions in WHERE Conditions
Using a function on a column in a filter can sometimes make efficient index usage more difficult.

For example:

SELECT *
FROM Orders
WHERE YEAR(OrderDate) = 2026;

A range condition can give the database a better opportunity to use an index:

SELECT *
FROM Orders
WHERE OrderDate >= '2026-01-01'
   AND OrderDate < '2027-01-01';

This does not mean the second query will always be faster. The result depends on the database engine, indexes, and data.

Check the execution plan and measure both versions before making the change.

5. Optimize JOIN Conditions
Joins are a normal part of application queries, but they can become expensive when large amounts of data are involved.

For example:

SELECT o.OrderId, c.Name
FROM Orders o
JOIN Customers c
    ON o.CustomerId = c.CustomerId;

The columns used for the join should be appropriate for the database design and indexing strategy. Also check whether the join is actually needed.

Filters can help reduce the amount of data that has to be processed. A query may become expensive when the database works through thousands of unnecessary rows even though only a few rows are returned.

6. Limit the Data You Return
Sometimes the database query itself is not the main problem. The application may simply be asking for too much data.

For a search page, there is usually no reason to return every matching record at once. Pagination keeps the result size manageable.

For example, SQL Server supports OFFSET/FETCH:

SELECT ProductId, Name, Price
FROM Products
ORDER BY ProductId
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY;

The right pagination approach depends on the database, indexes, and application requirements.

The basic idea is simple: if the user needs 50 records, do not make the database process and transfer thousands of records unnecessarily.

7. Keep Statistics Up to Date
The optimizer uses statistics about data distribution when it chooses an execution plan.

When those statistics are outdated, the optimizer may estimate the number of matching rows incorrectly. It might expect a query to return a few rows when the actual result contains millions.

That kind of incorrect estimate can lead to a poor execution plan.

Keeping statistics up to date is especially important for tables where data changes frequently. Database maintenance should be part of the overall performance strategy.

8. Watch Out for N+1 Queries
A query can be fast by itself and still cause a serious performance problem when the application runs it hundreds or thousands of times.

Imagine an application loading 1,000 customers first. It then runs another query for each customer to retrieve their orders.

Instead of making one efficient database operation, the application creates a large number of database round trips.

Look for ways to retrieve related data through joins, batching, or carefully designed queries.

N+1 problems are common in APIs and applications that use ORMs because the database calls may be hidden behind application code.

9. Review Subqueries and Complex Conditions
A complex query is not automatically a bad query. But when a query contains several subqueries, nested conditions, OR expressions, joins, or aggregations, it is worth looking closely at the execution plan.

For example:

SELECT *
FROM Products
WHERE CategoryId IN (
    SELECT CategoryId
    FROM Categories
    WHERE IsActive = 1
);

Another possible approach is:

SELECT p.*
FROM Products p
JOIN Categories c
    ON p.CategoryId = c.CategoryId
WHERE c.IsActive = 1;

Changing an IN subquery to a JOIN does not automatically make the query faster.

The database engine, optimizer, indexes, and amount of data all affect the result. Test both versions and compare their execution plans before deciding which one is better for your workload.

10. Measure Before and After the Change
Query optimization should always end with measurement.

Suppose a query takes four seconds and a new index brings it down to 500 milliseconds. That looks like a clear improvement. But the index also uses storage and may make inserts or updates more expensive.

For important changes, compare things such as:

Execution time
Logical reads
CPU usage
Number of rows processed
Execution plans

This gives you a clearer picture of whether the change actually improved the workload.

Database performance is not just about making one query look better. A change that improves one query can sometimes create another problem elsewhere.

Our Take
At Qodors, we have seen developers rewrite SQL queries before checking what is actually slowing them down.

The SQL query optimizer already evaluates the query and chooses an execution strategy. Instead of trying to work around it, make sure it has the right indexes, updated statistics, clear queries, and realistic data to work with.

Start by checking the execution plan. From there, review the indexes and statistics, look for unnecessary data, check your joins, and watch for repeated database calls.

Then measure the change.

A shorter or cleaner query is not always faster. A more complex query is not necessarily slower either. The execution plan and actual performance tell you what is really happening.

For SQL performance work, use the data to guide your decisions instead of guessing.

Quick Reference

Check the execution plan before changing a slow query.
Avoid SELECT * when you only need specific columns.
Create indexes based on real query patterns.
Be careful when using functions on filtered columns.
Review expensive joins on large tables.
Return only the data the application needs.
Keep database statistics up to date.
Watch for N+1 query patterns.
Test alternative query structures instead of assuming one is faster.
Measure performance before and after important changes.

Do not optimize SQL by guessing. Find where the database is spending its time, make one focused change, and measure what happens.

SQL #SQLServer #Database #DatabasePerformance #SQLQuery #QueryOptimization #SQLPerformance #Backend #BackendDevelopment #QodorsEdge

Why Your Backend Slows Down at Scale — And How Microservices Fix It

qodors — Wed, 02 Sep 2026 04:52:06 +0000

Your backend may work perfectly when the application is small. Requests are fast, the database responds quickly, and one server can handle most of the traffic. As the number of users grows and more features are added, some APIs can start taking longer to respond.

The problem is not always the server. A backend can slow down when too many tasks depend on the same application, database, or resources. A traffic spike in one feature can also affect other parts of the system when everything is tightly connected.

This is where microservices architecture can help. Instead of keeping the whole backend as one large application, you can split it into smaller services that handle specific business responsibilities. However, the architecture needs to match the actual requirements of the product.

WHAT ACTUALLY MAKES A BACKEND SLOW AT SCALE
A backend usually starts feeling slow when one application has too much work to handle at the same time.

For example, an e-commerce backend may handle:

User authentication
Product searches
Orders
Payments
Notifications
Reports

If all of these run inside one application, a traffic spike in product searches can affect other features as well. The database can become another bottleneck when hundreds of requests are waiting for queries, connections, or locks.

Heavy tasks such as report generation, email processing, image processing, and large data operations can also add more work to the same application. Before changing the architecture, it is better to check API response times, database queries, CPU usage, memory, and background tasks to find the actual bottleneck.

WHEN A MONOLITH STARTS TO HURT
A monolith is not automatically a problem. For a small or medium application, it can be easier to develop, test, deploy, and maintain because everything is managed as one application.

The problem starts when different parts of the application have very different scaling or deployment needs.

For example, an order API may perform several operations before returning a response:

[HttpPost("order")]
public async Task<IActionResult> CreateOrder(OrderRequest request)
{
     var order = await _orderService.CreateAsync(request);
     await _emailService.SendConfirmationAsync(order);
     await _reportService.UpdateSalesReportAsync(order);
     return Ok(order);
}

The API is now waiting for email and reporting work even though the user mainly needs the order to be created. As traffic increases, this extra work can make the request slower.

Moving slower tasks to background processing or another service can keep the main request focused on the work that needs an immediate response.

HOW MICROSERVICES FIX THE SCALING PROBLEM
With microservices, the backend is divided into smaller services based on business responsibilities.

For example:

                   API Gateway
                        |
         --------------------------------
         |              |               |
    User Service   Order Service   Product Service
         |              |               |
       User DB       Order DB       Product DB

Each service can be developed, deployed, and scaled separately. If product searches receive much more traffic than orders, the Product Service can be scaled without increasing the number of Order Service instances.

A simple product API could look like this:

[HttpGet("products")]
public async Task<IActionResult> GetProducts()
{
    var products = await _productService.GetProductsAsync();
    return Ok(products);
}

This approach gives a scalable backend architecture where resources can be added to the part of the system that actually needs them. It can also make deployments more focused because a change in one service does not always require the complete backend to be deployed.

MICROSERVICES DESIGN NEEDS CLEAR BOUNDARIES
Splitting a backend into smaller services does not automatically make it a good microservices system. Each service should have a clear responsibility and handle a specific business area.

For example:

                   API Gateway
                        |
         --------------------------------
         |              |               |
    User Service   Order Service   Product Service
         |              |               |
      User DB        Order DB       Product DB
                        |
                   Message Queue
                        |
                Notification Service

The User Service manages user-related operations, the Order Service handles orders, and the Product Service manages products. Each service can have its own database and scale independently when needed.

The Message Queue can be used to send tasks from the Order Service to the Notification Service without making the user wait for notification processing.

Good microservices design should follow clear business boundaries. Avoid splitting the backend into too many small services, especially when they constantly depend on each other.

USE BACKGROUND PROCESSING FOR HEAVY TASKS
Not every performance problem needs a microservice. Tasks like emails, notifications, and reports can run in the background so the user does not have to wait for them.

For example:

var order = await _orderService.CreateAsync(request);
await _backgroundTaskQueue.QueueAsync(
   new SendEmailJob(order.Id));
return Ok(order);

A BackgroundService can process the queued job separately:

await foreach (var job in
    _backgroundTaskQueue.ReadAllAsync(stoppingToken))
{
    await SendEmailAsync(job.OrderId);
}

Here, IBackgroundTaskQueue represents a custom background queue used to store jobs for later processing.

DATABASES CAN STILL BE THE BOTTLENECK
Moving to microservices does not automatically solve database performance problems. If several services depend on an overloaded database, the database can still become the main bottleneck.

Check slow queries, missing indexes, unnecessary data loading, connection limits, and large transactions. For example, if an API only needs 50 active products, there is no reason to load thousands of records:

var products = await _db.Products
   .AsNoTracking()
   .Where(x => x.IsActive)
   .OrderBy(x => x.Name)
   .Take(50)
   .ToListAsync();

The query only returns the records the API needs, which reduces unnecessary database work.

Good database practices remain an important part of backend architecture, even when the application is built using microservices.

HOW TO KNOW WHEN TO SPLIT THE BACKEND
Before starting microservices development, look for a real reason to separate part of the backend.

Consider splitting a service when:

One part needs much more scaling than the rest.
Different teams need to work independently.
Deploying one feature requires deploying the entire application.
A specific module has different performance requirements.
Problems in one area regularly affect unrelated features.

For example, an e-commerce application may receive millions of product searches while order traffic remains relatively low. In that case, the product functionality may benefit from independent scaling.

The goal is not to create more services. The goal is to make the backend easier to scale, maintain, deploy, and change.

OUR TAKE
At Qodors, we believe backend architecture should follow the actual needs of the product rather than adopting microservices simply because the application is growing. A well-designed monolith can work well when its responsibilities, database queries, and infrastructure are properly managed.

When a specific part of the backend needs independent scaling, deployment, or ownership, microservices architecture can provide a practical solution. The important step is to identify the real bottleneck first and then choose an architecture that solves that problem without adding unnecessary complexity.

QUICK REFERENCE

Find the real backend bottleneck before changing the architecture.
Use microservices when parts of the system need independent scaling.
Give every service a clear business responsibility.
Move heavy, non-urgent work to background processing.
Keep database queries and resource usage under control.

Microservices are not about splitting everything into small services. They are about separating the parts that need to scale, deploy, or operate independently. A simple architecture that works well is often better than a complex one that adds unnecessary work.

Microservices #MicroservicesArchitecture #BackendDevelopment #BackendArchitecture #ScalableBackend #SoftwareDevelopment #MicroservicesDevelopment #SoftwareEngineering #WebDevelopment #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=Backend_Scale

Still Using Task.Run() in ASP.NET Core? Fix Your C# Async Await the Right Way

qodors — Thu, 27 Aug 2026 04:50:14 +0000

Your ASP.NET Core API is slow, so you add Task.Run() and expect things to get better.

It may look like a quick fix, but Task.Run() does not make every operation faster. In many cases, it only moves the same work to a thread-pool thread. For database queries, HTTP requests, and other I/O work, this does not solve the actual problem.

This is why it is important to understand how async and await work in your code. The goal is not to make every method async. It is to avoid blocking a thread while the application waits for an operation to finish.

What Do async and await Actually Do?
Many developers think async creates a new thread, but it does not create a new thread by itself.

When an ASP.NET Core endpoint waits for a database query, it does not need to keep a thread busy while waiting for the response.

public async Task<IActionResult> GetProducts()
{
    var products = await _db.Products.ToListAsync();
    return Ok(products);
}

The database may take some time to return the products, but the application does not need to keep a thread busy during that time. Once the database operation finishes, the method continues from await.

This allows an ASP.NET Core application to handle requests without keeping a thread busy during the wait.

The important thing is to understand what the code is waiting for, not just whether it uses await.

Why Task.Run() Is Often the Wrong Fix
Consider this code:

public async Task<IActionResult> GetProducts()
{
    var products = await Task.Run(() =>
        _db.Products.ToList());

    return Ok(products);
}

Although the code uses await, the database call itself is still synchronous. Task.Run() only moves ToList() to a thread-pool thread. That thread stays busy while the synchronous database call runs.

For normal I/O work in ASP.NET Core, there is usually no reason to do this. Instead, use the async method provided by the library:

public async Task<IActionResult> GetProducts()
{
    var products = await _db.Products.ToListAsync();
    return Ok(products);
}

The better approach is to call the database's async method directly. This avoids wrapping the synchronous call in Task.Run(). Look at the operation behind await instead of adding Task.Run() just because a method looks slow.

Use Async for I/O Work
A web API often spends a lot of time waiting for other systems. It may query a database, call another API, read a file, or work with cloud storage. In these situations, an async API lets the application wait without keeping a thread busy.

Common I/O operations include:

Database queries
HTTP requests
File operations
Network calls
Cloud storage

An HTTP request can be handled directly with the async API:

var response = await httpClient.GetAsync(url);

There is no need to put the HTTP call inside Task.Run().

The same applies to Entity Framework Core:

var user = await _db.Users
    .FirstOrDefaultAsync(x => x.Id == id);

The application can wait for the database response without blocking a thread.

What About CPU-Heavy Work?
CPU-heavy work is different because the application is not waiting for another system. The CPU is actively doing the work.

For instance:

public byte[] GenerateReport()
{
    // Expensive CPU calculation
}

In some situations, you may choose to move this work to another thread:

public async Task<byte[]> GenerateReportAsync()
{
    return await Task.Run(() => GenerateReport());
}

However, Task.Run() does not make the calculation itself faster. The CPU still has to perform the same amount of work.

For CPU-heavy work, Task.Run() can be useful when you intentionally want to move that work to another thread. It should not be used as a general solution for database queries or HTTP requests.

Avoid .Result and .Wait() in Async Code
Another common issue appears when an async method is called but the result is then requested synchronously:


var result = GetDataAsync().Result;

The same problem can happen with:

GetDataAsync().Wait();

The method may be asynchronous, but .Result and .Wait() block while waiting for it to finish. Instead, let the async operation continue with await:

var result = await GetDataAsync();

This keeps the code easier to follow and avoids unnecessary blocking.

A simple rule is: if you have an async operation, use await instead of waiting for it synchronously with .Result or .Wait().

Do You Really Need async Here?
Another important point is that not every method needs to be asynchronous.

Consider this:

public async Task<int> Add(int a, int b)
{
    return await Task.FromResult(a + b);
}

There is no real async work happening here. The method is only adding two numbers, so making it async adds unnecessary code.

A simple method is better:


public int Add(int a, int b)
{
    return a + b;
}

Use async when the method has something meaningful to wait for, such as a database query, HTTP request, or file operation. For simple calculations that finish immediately, a normal synchronous method is usually clearer.

Keep the Async Flow Going
An ASP.NET Core application often has several layers:

Controller
↓
Service
↓
Repository
↓
Database

If the database operation is async, keep that async flow through the application layers rather than turning it into a synchronous call somewhere in the middle.

public async Task<User?> GetUserAsync(int id)
{
    return await _db.Users
        .FirstOrDefaultAsync(x => x.Id == id);
}

The service can await the result:

var user = await _userService.GetUserAsync(id);

The controller can then return the result:

return Ok(user);

Try not to call an async method and then use .Result or .Wait() in another layer. Keeping the async flow consistent makes the code easier to maintain and avoids unnecessary blocking in an ASP.NET Core application.

Find Out Why the API Is Slow
If your ASP.NET Core API is slow, adding Task.Run() should not be the first thing you try. First, find out where the time is actually going.

Check things such as:

Database query time
External API response time
CPU usage
Thread-pool usage
Memory usage
Garbage collection
Number of requests
Slow synchronous code

The SQL query may be slow, an external API may take two seconds to respond, or another part of the application may be using too much CPU.

Find the actual problem before changing the async code. Async code can handle waiting better, but it cannot make a slow database query run faster.

Our Take
At Qodors, we often see Task.Run() added when a method is slow or when a developer wants to make synchronous code async. A common case is a database call being wrapped in Task.Run() even though the database library already provides an async method.

Moving the synchronous call to another thread does not fix the database operation. It only changes where that work runs.

For normal ASP.NET Core API work, use the async methods provided by the library. With Entity Framework Core, that means methods such as ToListAsync() and FirstOrDefaultAsync(). For HTTP calls, use the async methods available in HttpClient.

Before adding Task.Run(), first ask:

Am I doing CPU-heavy work, or am I waiting for I/O?

If the application is waiting for I/O, use the proper async API. If the work is CPU-heavy, Task.Run() may be useful when there is a clear reason to move that work.

Quick Reference

async does not create a new thread by itself.
Use await for async operations.
Do not wrap normal database calls in Task.Run().
Use EF Core methods such as ToListAsync() and FirstOrDefaultAsync().
Avoid .Result and .Wait() in async code.
Do not make every small method async.
Task.Run() does not make CPU work faster.
Keep async calls going through your application layers.
Find the real performance problem before changing your code.
Use Task.Run() only when there is a clear reason for it.

Don't add Task.Run() just because an ASP.NET Core API feels slow. First find out what the application is waiting for, use async APIs for database and HTTP work, and avoid blocking calls such as .Result and .Wait(). When the work is CPU-heavy, use Task.Run() only when it actually fits the situation.

CSharp #DotNet #ASPNetCore #AsyncAwait #CSharpProgramming #DotNetCore #WebAPI #API #Backend #QodorsEdge

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