DEV Community: ToolBench

ASP.NET Core Output Caching: How to Make Web APIs Faster in .NET

ToolBench — Mon, 17 Aug 2026 12:48:43 +0000

ASP.NET Core Output Caching: How to Make Web APIs Faster in .NET

When an API receives the same request repeatedly, performing the same database query and rebuilding the same response every time can waste valuable resources.

For example, imagine this endpoint:

GET /api/products

If thousands of users request the same product catalog, your application might repeatedly:

HTTP Request
      ↓
Controller
      ↓
Database Query
      ↓
Business Logic
      ↓
JSON Response

For data that doesn't change frequently, this can create unnecessary database load.

ASP.NET Core provides Output Caching to help solve this problem.

Instead of executing the complete request pipeline every time, the application can temporarily store the generated response and reuse it for subsequent requests.

In this tutorial, we'll look at how Output Caching works, how to configure it, how to invalidate cached responses, and when you should avoid using it.

What Is Output Caching?

Output caching stores the generated response from an endpoint.

For example:

First request
    ↓
GET /api/products
    ↓
Execute controller
    ↓
Query database
    ↓
Generate response
    ↓
Store response in cache

Later:

Second request
    ↓
GET /api/products
    ↓
Cached response
    ↓
Return immediately

The database doesn't need to be queried again while the cached response is valid.

Output Caching vs Response Caching

These two concepts are often confused.

Response Caching

Response caching mainly relies on HTTP caching semantics and headers.

Output Caching

Output caching is controlled by ASP.NET Core and allows your application to decide which responses should be cached and for how long.

Output caching provides more control over server-side response caching.

1. Add Output Caching

Start by registering the output-cache services.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();

builder.Services.AddOutputCache();

var app = builder.Build();

app.UseOutputCache();

app.MapControllers();

app.Run();

The important pieces are:

AddOutputCache()
    ↓
Configure caching
    ↓
UseOutputCache()
    ↓
Apply caching policies

2. Cache an API Endpoint

You can apply output caching to an endpoint using the OutputCache attribute.

For example:

[ApiController]
[Route("api/products")]
public class ProductsController : ControllerBase
{
    [HttpGet]
    [OutputCache(Duration = 60)]
    public IActionResult GetProducts()
    {
        return Ok(new[]
        {
            new { Id = 1, Name = "Laptop" },
            new { Id = 2, Name = "Keyboard" },
            new { Id = 3, Name = "Mouse" }
        });
    }
}

The response can now be cached for 60 seconds.

During that period, subsequent requests can receive the cached response instead of executing the controller again.

3. Why This Can Improve Performance

Without caching:

Request 1 → Database
Request 2 → Database
Request 3 → Database
Request 4 → Database
Request 5 → Database

With output caching:

Request 1 → Database → Cache
Request 2 → Cache
Request 3 → Cache
Request 4 → Cache
Request 5 → Cache

This can significantly reduce repeated work for suitable endpoints.

The biggest benefit is often reduced load on downstream dependencies such as databases and external APIs.

4. Configure a Default Cache Policy

Instead of adding attributes to every endpoint, you can define policies.

For example:

builder.Services.AddOutputCache(options =>
{
    options.AddPolicy("ProductsPolicy", policy =>
    {
        policy.Expire(TimeSpan.FromMinutes(5));
    });
});

Then apply the policy:

[OutputCache(PolicyName = "ProductsPolicy")]
[HttpGet]
public IActionResult GetProducts()
{
    return Ok(products);
}

This makes caching rules easier to manage as your application grows.

5. Cache by Query String

Consider an endpoint:

GET /api/products?category=laptop

and:

GET /api/products?category=mobile

These requests should not necessarily receive the same cached response.

You can configure caching based on query-string values.

For example:

builder.Services.AddOutputCache(options =>
{
    options.AddPolicy("ProductsPolicy", policy =>
    {
        policy
            .Expire(TimeSpan.FromMinutes(5))
            .SetVaryByQuery("category");
    });
});

Now the cache can maintain separate responses for different category values.

Conceptually:

/products?category=laptop
    ↓
Cache A

/products?category=mobile
    ↓
Cache B

6. Cache by Header

Sometimes the response depends on a request header.

For example:

Accept-Language

If your API returns localized content, caching should take the language into account.

A policy can vary based on request headers.

options.AddPolicy("LocalizedPolicy", policy =>
{
    policy
        .Expire(TimeSpan.FromMinutes(5))
        .SetVaryByHeader("Accept-Language");
});

Now English and Hindi responses, for example, can be cached separately.

7. Be Careful With User-Specific Data

This is one of the most important Output Caching considerations.

Suppose you have:

GET /api/profile

and the response is:

{
    "name": "User A",
    "email": "usera@example.com"
}

If you cache this incorrectly, another user could potentially receive the wrong cached response.

That's a serious security problem.

Be very careful when caching endpoints containing:

User profiles
Account information
Payments
Orders
Private documents
Authorization-specific information
Personalized dashboards

Caching should never accidentally share private data between users.

8. Public vs Personalized Endpoints

A useful rule is:

Public data
    ↓
Usually good candidate for caching

User-specific data
    ↓
Requires careful cache variation

For example:

GET /api/products

might be an excellent caching candidate.

But:

GET /api/my-orders

requires much more careful consideration.

Before enabling caching, ask:

Can two different users safely receive the same response?

If the answer is no, don't use a simple shared output-cache policy.

9. Cache Expiration

The cache duration should depend on how frequently the data changes.

For example:

Product categories
    → 30 minutes

Product catalog
    → 5 minutes

Frequently changing stock
    → Very short duration

Real-time account balance
    → Usually don't cache this way

There is no universal cache duration.

The correct value depends on your application's consistency requirements.

10. Cache Invalidation

Caching introduces an important question:

What happens when the underlying data changes?

Imagine:

Product price = ₹50,000

The response is cached.

Then the database changes:

Product price = ₹45,000

If the cache is still valid, users might continue seeing:

₹50,000

until the cache expires or is invalidated.

This is why cache invalidation is one of the most important parts of a caching strategy.

11. Evict Cached Responses

When application data changes, you may need to remove related cached responses.

For example, after updating a product:

Update product
    ↓
Save database changes
    ↓
Evict relevant cached response

This ensures the next request generates fresh data.

ASP.NET Core provides output-cache APIs that can be used to control cache eviction.

The exact strategy depends on how your endpoints and policies are structured.

12. Cache Only What Actually Benefits From Caching

Caching everything is not a good strategy.

Consider:

GET /api/products

If this endpoint takes 500 ms because of expensive database work, caching may provide a large benefit.

But if another endpoint takes:

2 ms

caching it may add complexity without meaningful performance improvement.

A good caching strategy focuses on endpoints that are:

Frequently requested
Relatively expensive
Safe to cache
Not changing constantly

13. Output Caching and Database Performance

Consider an API receiving:

10,000 requests/minute

If every request performs the same database query, the database receives:

10,000 queries/minute

If the response can safely be cached for one minute, the application might perform dramatically fewer database queries.

Conceptually:

10,000 API requests
       ↓
   Output Cache
       ↓
Small number of DB queries

This can reduce:

Database CPU
Network traffic
Query execution
Application CPU
API response latency

14. Output Caching and External APIs

Caching isn't only useful for databases.

Suppose your API calls an external service:

Your API
   ↓
External API
   ↓
Response

If the same external data is requested repeatedly, output caching can reduce unnecessary calls.

This can be particularly useful when an external API has:

Rate limits
Usage costs
Slow response times
Network latency

However, make sure cached data is still acceptable for your business requirements.

15. Don't Cache Sensitive Responses

Avoid blindly caching responses containing sensitive information.

Examples include:

Payment information
Authentication responses
Personal information
Security tokens
Private account data

Caching mistakes can become security vulnerabilities.

Before caching an endpoint, understand exactly what data the response contains.

16. Output Caching in a Multi-Instance Application

Consider an application running with multiple instances:

Load Balancer
      ↓
┌─────┼─────┐
↓     ↓     ↓
API1  API2  API3

Now caching becomes a distributed-system consideration.

If each instance maintains its own cache, you could have:

API1 → Cache A
API2 → Cache B
API3 → Cache C

The cached data may not be identical between instances.

For larger systems, you should understand how your deployment architecture handles cache storage and consistency.

17. Cache-Control Is Not the Same Thing

Don't confuse server-side Output Caching with browser caching.

Browser caching is controlled through HTTP caching headers and client behavior.

Output caching is an application-side mechanism for reusing generated responses.

A complete caching architecture can involve multiple layers:

Browser
   ↓
CDN
   ↓
Reverse Proxy
   ↓
ASP.NET Core Output Cache
   ↓
Application
   ↓
Database

Each layer has different responsibilities.

18. Measure Before and After

Don't assume caching automatically makes everything faster.

Measure your application.

Look at:

Response time
Database CPU
Database query count
API throughput
Application CPU
Memory usage

For example:

Before caching
Average response: 450 ms

After caching
Average response: 35 ms

The actual improvement depends on your workload.

19. Common Output Caching Mistakes

Mistake 1: Caching User-Specific Data

This can cause data leakage.

Mistake 2: Cache Duration Is Too Long

Users may receive stale information.

Mistake 3: Cache Duration Is Too Short

The application may receive little benefit from caching.

Mistake 4: Caching Everything

This adds unnecessary complexity.

Mistake 5: Ignoring Cache Invalidation

Data updates may not become visible immediately.

Mistake 6: Not Measuring Performance

Caching should be driven by actual performance data.

A Practical Example

Suppose your application has:

GET /api/products
GET /api/categories
GET /api/orders
GET /api/profile

A sensible starting point could be:

/products
    → Cache for 5 minutes

/categories
    → Cache for 30 minutes

/orders
    → Carefully evaluate

/profile
    → Avoid shared output caching

The exact values should depend on your application's requirements.

Production Checklist

Before enabling Output Caching, ask:

[ ] Is this endpoint safe to cache?
[ ] Is the response public or user-specific?
[ ] How frequently does the data change?
[ ] What cache duration makes sense?
[ ] Does the response vary by query string?
[ ] Does it vary by headers?
[ ] What happens when the underlying data changes?
[ ] Do we need cache invalidation?
[ ] Are multiple application instances involved?
[ ] Have we measured performance before and after caching?

Final Thoughts

Output caching can be one of the simplest ways to reduce repeated work in an ASP.NET Core application.

But the goal isn't:

"Cache everything."

The goal is:

"Cache the right responses for the right amount of time."

Start with endpoints that are:

Frequently requested
Expensive to generate
Relatively stable
Safe to share

Then measure the results.

A good caching strategy can reduce database load, improve API response times, and help your application handle more traffic without simply adding more infrastructure.

The most important rule is:

Performance should never come at the cost of correctness or security.

A Small Developer Tool for Everyday Development

While working with APIs and debugging applications, developers frequently need quick utilities for formatting JSON, decoding JWTs, comparing API responses, converting data formats, and handling other small development tasks.

That's why I built ToolBench — a collection of free browser-based developer tools designed for everyday development work.

Explore it here:

https://toolbenchapp.com/

It can be a handy companion when you're working with .NET APIs, JSON, authentication tokens, and other common development tasks.

How are you handling caching in your ASP.NET Core applications?

Are you using Output Caching, Redis, a CDN, browser caching, or a combination of these?

Share your approach in the comments.

ASP.NET Core Background Services: How to Run Reliable Background Tasks in .NET

ToolBench — Thu, 13 Aug 2026 12:30:08 +0000

ASP.NET Core Background Services: How to Run Reliable Background Tasks in .NET

Not every task in a web application should run inside an HTTP request.

Sending emails, processing files, generating reports, consuming messages from a queue, cleaning old records, and synchronizing data are all examples of work that can run in the background.

If we perform these operations directly inside a controller, we can create slow requests, unnecessary timeouts, and poor user experiences.

ASP.NET Core provides a clean solution for this through BackgroundService and IHostedService.

In this tutorial, we'll build a practical background worker, understand how it works, and look at some production considerations.

Why Do We Need Background Services?

Consider an API endpoint that generates a large report.

A simple implementation might look like this:

[HttpPost("generate-report")]
public async Task<IActionResult> GenerateReport()
{
    await GenerateLargeReportAsync();

    return Ok();
}

The client has to wait until the entire report is generated.

If the operation takes 30 seconds, the HTTP request remains open for 30 seconds.

That's not ideal.

A better architecture is:

Client
   ↓
API
   ↓
Queue background work
   ↓
Return response
   ↓
Background Worker
   ↓
Generate Report

The API can respond quickly while the background worker handles the long-running operation.

BackgroundService vs IHostedService

ASP.NET Core provides two common ways to implement background work.

IHostedService

IHostedService is the lower-level interface.

It provides:

StartAsync()
StopAsync()

You have more control, but you also need to manage more of the implementation yourself.

BackgroundService

BackgroundService is an abstract class that implements IHostedService.

It is usually easier when your worker needs to continuously run background operations.

For many applications, BackgroundService is the simplest choice.

1. Create Your First Background Service

Create a class:

public class MyBackgroundService : BackgroundService
{
    private readonly ILogger<MyBackgroundService> _logger;

    public MyBackgroundService(
        ILogger<MyBackgroundService> logger)
    {
        _logger = logger;
    }

    protected override async Task ExecuteAsync(
        CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            _logger.LogInformation(
                "Background service is running.");

            await Task.Delay(
                TimeSpan.FromSeconds(10),
                stoppingToken);
        }
    }
}

The important method is:

ExecuteAsync()

This method runs when the hosted service starts.

The CancellationToken tells your worker when the application is shutting down.

2. Register the Background Service

builder.Services.AddHostedService<MyBackgroundService>();

That's it.

When your ASP.NET Core application starts, the background service starts with it.

When the application shuts down, ASP.NET Core signals the cancellation token.

3. Run a Task on a Schedule

Suppose you need to perform a cleanup operation every hour.

You could write:

public class CleanupService : BackgroundService
{
    private readonly ILogger<CleanupService> _logger;

    public CleanupService(
        ILogger<CleanupService> logger)
    {
        _logger = logger;
    }

    protected override async Task ExecuteAsync(
        CancellationToken stoppingToken)
    {
        using var timer = new PeriodicTimer(
            TimeSpan.FromHours(1));

        while (await timer.WaitForNextTickAsync(
            stoppingToken))
        {
            try
            {
                _logger.LogInformation(
                    "Starting cleanup.");

                await CleanupAsync(stoppingToken);

                _logger.LogInformation(
                    "Cleanup completed.");
            }
            catch (Exception ex)
            {
                _logger.LogError(
                    ex,
                    "Error occurred during cleanup.");
            }
        }
    }

    private async Task CleanupAsync(
        CancellationToken cancellationToken)
    {
        // Cleanup logic
        await Task.CompletedTask;
    }
}

PeriodicTimer makes scheduled asynchronous work easier to manage.

4. Why CancellationToken Matters

One of the most important things in a background service is graceful shutdown.

Avoid this:

while (true)
{
    await DoWorkAsync();
}

The worker has no way to respond to application shutdown.

Instead:

while (!stoppingToken.IsCancellationRequested)
{
    await DoWorkAsync(stoppingToken);
}

Now ASP.NET Core can tell the worker:

"The application is shutting down."

The worker can stop gracefully.

5. Don't Block the Thread

Avoid blocking calls such as:

Thread.Sleep(5000);

inside asynchronous background work.

Prefer:

await Task.Delay(
    TimeSpan.FromSeconds(5),
    stoppingToken);

This allows the thread to be used efficiently while waiting.

The same principle applies to database and HTTP operations.

Prefer:

await repository.GetDataAsync(
    stoppingToken);

instead of synchronous operations that block a thread.

6. Using Dependency Injection in Background Services

A common requirement is to use a service from your dependency-injection container.

For example:

public class OrderProcessingService : BackgroundService
{
    private readonly IServiceScopeFactory _scopeFactory;

    public OrderProcessingService(
        IServiceScopeFactory scopeFactory)
    {
        _scopeFactory = scopeFactory;
    }

    protected override async Task ExecuteAsync(
        CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            using var scope =
                _scopeFactory.CreateScope();

            var orderService =
                scope.ServiceProvider
                    .GetRequiredService<IOrderService>();

            await orderService.ProcessOrdersAsync(
                stoppingToken);

            await Task.Delay(
                TimeSpan.FromMinutes(1),
                stoppingToken);
        }
    }
}

This is important because background services are generally registered as singletons.

If the service you need is scoped, create a scope before resolving it.

7. BackgroundService and Entity Framework Core

Suppose your application needs to periodically process database records.

You might have:

public class OrderProcessingWorker
    : BackgroundService
{
    private readonly IServiceScopeFactory _scopeFactory;
    private readonly ILogger<OrderProcessingWorker> _logger;

    public OrderProcessingWorker(
        IServiceScopeFactory scopeFactory,
        ILogger<OrderProcessingWorker> logger)
    {
        _scopeFactory = scopeFactory;
        _logger = logger;
    }

    protected override async Task ExecuteAsync(
        CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            try
            {
                using var scope =
                    _scopeFactory.CreateScope();

                var dbContext =
                    scope.ServiceProvider
                        .GetRequiredService<AppDbContext>();

                var pendingOrders =
                    await dbContext.Orders
                        .Where(x => x.Status == "Pending")
                        .ToListAsync(stoppingToken);

                foreach (var order in pendingOrders)
                {
                    order.Status = "Processed";
                }

                await dbContext.SaveChangesAsync(
                    stoppingToken);
            }
            catch (Exception ex)
            {
                _logger.LogError(
                    ex,
                    "Error processing orders.");
            }

            await Task.Delay(
                TimeSpan.FromMinutes(1),
                stoppingToken);
        }
    }
}

The important part is that the database context is resolved inside a scope.

Don't keep a scoped DbContext alive for the entire lifetime of the background service.

8. Process Work from a Queue

A more scalable approach is to use a queue.

For example:

API Request
    ↓
Add work to queue
    ↓
Background Worker
    ↓
Process work

A simple in-memory queue can use:

Channel<T>

For example:

public interface IBackgroundTaskQueue
{
    ValueTask QueueAsync(
        Func<CancellationToken, ValueTask> workItem);

    ValueTask<Func<CancellationToken, ValueTask>>
        DequeueAsync(
            CancellationToken cancellationToken);
}

You can implement the queue using Channel.

This allows the API to add work without performing the expensive operation during the request.

9. Example: Queue an Email

Imagine an API that needs to send an email after creating an account.

Instead of:

await emailService.SendEmailAsync();

inside the HTTP request, you can queue the operation.

The flow becomes:

POST /api/users
      ↓
Create user
      ↓
Queue email
      ↓
Return 201 Created
      ↓
Background worker
      ↓
Send email

This can make the API response much faster.

10. Important: In-Memory Queues Have a Limitation

An in-memory queue is simple, but it has an important limitation.

If your application restarts:

Application
    ↓
Memory queue
    ↓
Application crashes

The queued work can be lost.

That's why in-memory background queues are generally more suitable for simple tasks where losing queued work is acceptable.

For important business operations, consider a durable messaging system such as:

Azure Service Bus
RabbitMQ
Amazon SQS
Kafka
Other persistent queue technologies

The choice depends on your architecture and reliability requirements.

11. Background Services Don't Automatically Scale Like API Requests

Suppose you deploy your API with five instances:

Instance 1
Instance 2
Instance 3
Instance 4
Instance 5

If each instance runs the same BackgroundService, you now have five workers.

That may be completely fine for some workloads.

But it can also create duplicate processing.

For example, you might accidentally have:

Instance 1 → Process order #100
Instance 2 → Process order #100
Instance 3 → Process order #100

Now the same order may be processed multiple times.

For distributed applications, you may need:

Distributed locks
Database coordination
Queue-based processing
Idempotent operations
A dedicated worker service

12. Make Background Operations Idempotent

Idempotency is extremely important for background processing.

Suppose a payment operation is accidentally executed twice.

That's a serious problem.

Instead of assuming:

Process once

design your operation so repeated execution doesn't create duplicate side effects.

For example:

if (await IsAlreadyProcessedAsync(orderId))
{
    return;
}

await ProcessOrderAsync(orderId);

await MarkAsProcessedAsync(orderId);

This pattern becomes especially important when working with queues and distributed systems.

13. Handle Exceptions Carefully

Don't allow an exception to silently terminate important background processing.

Use logging:

try
{
    await ProcessAsync(stoppingToken);
}
catch (OperationCanceledException)
    when (stoppingToken.IsCancellationRequested)
{
    // Application is shutting down.
}
catch (Exception ex)
{
    _logger.LogError(
        ex,
        "Background processing failed.");
}

This allows expected shutdown cancellation to be treated differently from actual failures.

14. Add Useful Logging

Good background workers should provide enough information to troubleshoot problems.

For example:

_logger.LogInformation(
    "Starting order processing.");

_logger.LogInformation(
    "Found {Count} pending orders.",
    orders.Count);

_logger.LogError(
    exception,
    "Failed to process OrderId {OrderId}",
    orderId);

Avoid logging sensitive information such as passwords, tokens, or payment information.

15. When Should You Use a BackgroundService?

BackgroundService is a good choice for tasks such as:

Periodic cleanup
Cache refresh
Scheduled synchronization
Processing lightweight background work
Polling an external system
Internal application maintenance
Simple queue processing

But it may not be the best choice for every workload.

If your application requires:

Guaranteed delivery
High-volume processing
Distributed workers
Retry policies
Dead-letter queues
Persistent messages

a dedicated message broker or background-job system may be more appropriate.

A Practical Architecture

A production application might look like this:

Client
   ↓
ASP.NET Core API
   ↓
Durable Queue
   ↓
Worker Service
   ↓
Database / External Services

The API handles HTTP requests.

The queue stores work reliably.

The worker processes the work.

This separation makes the system easier to scale.

BackgroundService Checklist

Before deploying a background worker, ask:

[ ] Does the worker support graceful cancellation?
[ ] Are async APIs used instead of blocking calls?
[ ] Are scoped dependencies resolved inside a scope?
[ ] Are exceptions logged?
[ ] Can the operation safely be retried?
[ ] Is the operation idempotent?
[ ] Can work be lost if the application restarts?
[ ] Will multiple application instances process the same work?
[ ] Do you need a durable queue?
[ ] Do you have monitoring for failed background jobs?

Final Thoughts

Background processing is an important part of building production-ready ASP.NET Core applications.

The key is to avoid putting every operation inside an HTTP request.

Use BackgroundService for appropriate application-level background work.

For critical or distributed workloads, consider moving toward a durable queue and dedicated worker architecture.

A useful mental model is:

Fast API request
      +
Reliable background processing
      =
Better application architecture

The goal isn't simply to move code into a background thread.

The goal is to design background work that is reliable, observable, cancellable, and safe to retry.

A Small Developer Tool for Everyday .NET Work

While working with APIs and background services, developers often need quick utilities for formatting JSON, decoding JWTs, comparing API responses, converting data formats, and handling other small development tasks.

That's why I built ToolBench — a collection of free browser-based developer tools designed for everyday development work.

Explore the tools here:

https://toolbenchapp.com/

It can be a handy companion when you're debugging APIs, working with JSON, or troubleshooting development issues.

What kind of background processing do you use in your .NET applications?

BackgroundService, Azure Service Bus, Hangfire, RabbitMQ, or something else?

Share your approach in the comments.

ASP.NET Core API Performance: 12 Practical Ways to Make Your Web API Faster

ToolBench — Wed, 12 Aug 2026 12:23:08 +0000

A slow API doesn't always mean you need a bigger server.

In many ASP.NET Core applications, performance problems come from things such as inefficient database queries, unnecessary serialization, excessive network calls, missing caching, or returning much more data than the client actually needs.

The good news is that many of these problems can be fixed at the application level.

In this tutorial, we'll look at 12 practical techniques for improving ASP.NET Core Web API performance, with examples you can apply to real projects.

1. Use Async APIs Properly

One of the most important rules in ASP.NET Core is to avoid blocking threads while waiting for I/O operations.

Instead of:

public User GetUser(int id)
{
    return _repository.GetUser(id);
}

Prefer:

public async Task<User?> GetUserAsync(int id)
{
    return await _repository.GetUserAsync(id);
}

For database calls:

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

This allows ASP.NET Core to handle other requests while the application is waiting for the database or another I/O operation.

Avoid this

var users = GetUsersAsync().Result;

or:

var users = GetUsersAsync().GetAwaiter().GetResult();

Blocking asynchronous operations defeats many of the benefits of async programming.

2. Don't Return More Data Than You Need

Imagine your User table contains:

Id
Name
Email
Phone
Address
DateOfBirth
ProfileImage
CreatedDate
UpdatedDate
...

But your API only needs:

Id
Name
Email

Don't retrieve the entire entity unnecessarily.

Instead of:

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

Use projection:

var users = await _context.Users
    .Select(u => new UserDto
    {
        Id = u.Id,
        Name = u.Name,
        Email = u.Email
    })
    .ToListAsync();

This can reduce:

Database work
Memory usage
Network traffic
JSON serialization
Response size

General rule

Retrieve only the columns you actually need.

3. Use Pagination

Returning thousands of records from an endpoint is rarely a good idea.

Avoid:

GET /api/products

returning 100,000 records.

Instead, support pagination:

GET /api/products?page=1&pageSize=20

Example:

public async Task<List<ProductDto>> GetProducts(
    int page = 1,
    int pageSize = 20)
{
    return await _context.Products
        .AsNoTracking()
        .Skip((page - 1) * pageSize)
        .Take(pageSize)
        .Select(p => new ProductDto
        {
            Id = p.Id,
            Name = p.Name,
            Price = p.Price
        })
        .ToListAsync();
}

Pagination prevents a single request from consuming excessive resources.

4. Use `AsNoTracking()` for Read-Only Queries

Entity Framework Core tracks entities by default.

Tracking is useful when you plan to modify an entity.

But if you're only reading data, tracking may be unnecessary.

For example:

var products = await _context.Products
    .ToListAsync();

For read-only operations:

var products = await _context.Products
    .AsNoTracking()
    .ToListAsync();

This tells EF Core that you don't need change tracking for these entities.

Good use cases

AsNoTracking() is particularly useful for:

GET endpoints
Reporting
Dashboards
Search APIs
Read-only queries

5. Avoid N+1 Queries

One of the most common database performance problems is the N+1 query problem.

Imagine this:

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

foreach (var order in orders)
{
    var customer = await _context.Customers
        .FindAsync(order.CustomerId);
}

If you have 1,000 orders, this can result in many database queries.

Instead, fetch the required data as part of one query.

For example:

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

Or, even better when you only need specific fields:

var orders = await _context.Orders
    .Select(o => new OrderDto
    {
        Id = o.Id,
        Total = o.Total,
        CustomerName = o.Customer.Name
    })
    .ToListAsync();

Projection is often preferable when you don't need the complete related entities.

6. Add Database Indexes

Sometimes the API is slow because the database has to scan a large table.

Suppose your API frequently searches:

var user = await _context.Users
    .FirstOrDefaultAsync(u => u.Email == email);

An index on Email can make this query significantly more efficient.

In EF Core:

modelBuilder.Entity<User>()
    .HasIndex(u => u.Email);

You should consider indexes for columns frequently used in:

WHERE conditions
JOIN conditions
ORDER BY
UNIQUE lookups

However, don't blindly add indexes to every column.

Indexes also have storage and write-performance costs.

7. Use Response Caching Where Appropriate

Some API responses don't change frequently.

For example:

GET /api/countries

There may be little reason to query the database for every request.

Caching can help.

For example, using ASP.NET Core's output caching:

builder.Services.AddOutputCache();

Then:

app.UseOutputCache();

And on an endpoint:

[OutputCache(Duration = 60)]
[HttpGet("countries")]
public async Task<IActionResult> GetCountries()
{
    var countries = await _service.GetCountriesAsync();

    return Ok(countries);
}

Now repeated requests can be served from the cache instead of repeatedly executing the same application logic.

Good candidates for caching

Country lists
Product categories
Configuration data
Public reference data
Frequently requested read-only resources

Don't blindly cache user-specific or highly dynamic responses.

8. Compress HTTP Responses

If your API returns large JSON responses, compression can reduce network traffic.

ASP.NET Core supports response compression.

builder.Services.AddResponseCompression();

Then:

app.UseResponseCompression();

For example, a large JSON response can become significantly smaller when compressed.

This is particularly useful when:

Responses are large
Clients have slower connections
APIs are accessed over the internet
Payloads contain repetitive JSON structures

9. Avoid Unnecessary Serialization

Serialization can become expensive when you're returning large object graphs.

Consider:

return Ok(hugeObject);

If hugeObject contains:

Hundreds of properties
Nested objects
Collections
Related entities

the serializer has to process all of them.

Instead, create a focused DTO:

public record ProductResponse(
    int Id,
    string Name,
    decimal Price);

Then:

return Ok(new ProductResponse(
    product.Id,
    product.Name,
    product.Price));

This gives you better control over your API contract and usually reduces payload size.

10. Use `HttpClientFactory`

If your API calls another API, avoid creating a new HttpClient for every request.

Avoid:

public async Task<string> GetData()
{
    using var client = new HttpClient();

    return await client.GetStringAsync(url);
}

Instead, use IHttpClientFactory.

builder.Services.AddHttpClient();

Inject:

public class WeatherService
{
    private readonly HttpClient _client;

    public WeatherService(IHttpClientFactory factory)
    {
        _client = factory.CreateClient();
    }
}

Then:

public async Task<string> GetWeatherAsync()
{
    return await _client.GetStringAsync(
        "https://example.com/weather");
}

This allows .NET to manage HTTP connections more effectively.

11. Use Cancellation Tokens

Imagine a user sends an API request and then closes the browser.

If the server continues performing an expensive database operation unnecessarily, resources are wasted.

You can propagate cancellation:

[HttpGet]
public async Task<IActionResult> GetUsers(
    CancellationToken cancellationToken)
{
    var users = await _context.Users
        .AsNoTracking()
        .ToListAsync(cancellationToken);

    return Ok(users);
}

The cancellation token can also be passed through your service layer:

public async Task<List<UserDto>> GetUsersAsync(
    CancellationToken cancellationToken)
{
    return await _context.Users
        .AsNoTracking()
        .Select(u => new UserDto
        {
            Id = u.Id,
            Name = u.Name
        })
        .ToListAsync(cancellationToken);
}

This is especially valuable for expensive operations.

12. Measure Before Optimizing

This might be the most important point.

Don't optimize code simply because it "looks slow."

First identify where the actual bottleneck is.

Measure:

API response time
        ↓
Controller
        ↓
Service
        ↓
Database
        ↓
External APIs
        ↓
Serialization
        ↓
Network

Useful metrics include:

Average response time
P95 latency
P99 latency
Database query duration
Error rate
Request throughput
CPU usage
Memory usage

For example, an API might have:

Average: 120 ms
P95:     450 ms
P99:     2.4 sec

The average looks reasonable, but the P99 indicates that some requests are significantly slower.

That's why measuring only the average isn't enough.

Putting the Techniques Together

Here's an example of a cleaner, performance-conscious endpoint:

[HttpGet]
public async Task<IActionResult> GetProducts(
    int page = 1,
    int pageSize = 20,
    CancellationToken cancellationToken = default)
{
    var products = await _context.Products
        .AsNoTracking()
        .OrderBy(p => p.Id)
        .Skip((page - 1) * pageSize)
        .Take(pageSize)
        .Select(p => new ProductDto
        {
            Id = p.Id,
            Name = p.Name,
            Price = p.Price
        })
        .ToListAsync(cancellationToken);

    return Ok(products);
}

This small example already applies several performance principles:

Async database access
Cancellation support
No unnecessary change tracking
Pagination
Projection
Deterministic ordering
Smaller response objects

A Simple ASP.NET Core Performance Checklist

Before deploying an API, ask:

[ ] Are database operations asynchronous?
[ ] Are read-only queries using AsNoTracking() where appropriate?
[ ] Are API responses paginated?
[ ] Are only required columns selected?
[ ] Are database indexes appropriate?
[ ] Have N+1 queries been eliminated?
[ ] Are large responses compressed?
[ ] Can frequently requested data be cached?
[ ] Are external API calls using IHttpClientFactory?
[ ] Are cancellation tokens propagated?
[ ] Are response DTOs appropriately sized?
[ ] Have performance metrics been measured?

Final Thoughts

ASP.NET Core already provides excellent performance out of the box, but application-level decisions can still make a huge difference.

The biggest improvements often don't come from complicated optimization techniques.

They come from simple decisions:

Query less data.

Make fewer database calls.

Avoid unnecessary work.

Cache what makes sense.

Return smaller responses.

Measure real bottlenecks.

If you build these habits into your development process, your APIs can remain fast and scalable as traffic and data grow.

A Small Developer Tool That Can Save Time

While building and debugging APIs, developers frequently need quick utilities for formatting JSON, comparing API responses, decoding JWTs, converting data formats, and handling other everyday development tasks.

I built ToolBench as a collection of free browser-based developer tools for exactly these small but frequent tasks. Everything runs directly in the browser, making it convenient when you need a quick utility without installing another application.

What is the biggest performance issue you've encountered in an ASP.NET Core API?

Share your experience in the comments — database queries, caching, serialization, external APIs, or something else?

10 Entity Framework Core Performance Tips Every .NET Developer Should Know

ToolBench — Tue, 11 Aug 2026 12:12:40 +0000

Entity Framework Core makes it incredibly easy to work with databases in .NET applications.

You can write C# instead of SQL, work with strongly typed entities, use LINQ for queries, and let EF Core handle much of the database interaction for you.

But there's an important catch:

Writing code that works is not the same as writing code that performs well.

A LINQ query can look perfectly clean in C# while generating an inefficient SQL query behind the scenes. As your database grows from thousands to millions of records, small mistakes can turn into serious performance problems.

In this article, we'll look at 10 practical Entity Framework Core performance techniques that can make a real difference in ASP.NET Core applications.

We'll cover:

How to avoid unnecessary columns
Why AsNoTracking() matters
Pagination
Avoiding N+1 queries
Eager loading
Projection with Select()
Database indexes
Avoiding unnecessary ToList()
Query compilation and caching
How to inspect the SQL generated by EF Core

Let's get started.

📖 Table of Contents

Understand What EF Core Is Actually Doing
Select Only the Columns You Need
Use AsNoTracking() for Read-Only Queries
Always Consider Pagination
Avoid the N+1 Query Problem
Be Careful With Include()
Prefer Projection with Select()
Use Database Indexes
Don't Call ToList() Too Early
Inspect the SQL Generated by EF Core
Combine Techniques for Real Applications
Common EF Core Performance Mistakes
Practical Checklist
EF Core Interview Questions
Frequently Asked Questions
Final Thoughts

1. Understand What EF Core Is Actually Doing

Before optimizing EF Core, you need to understand one fundamental concept.

When you write:

var employees = await context.Employees
    .Where(e => e.Department == "IT")
    .ToListAsync();

EF Core doesn't simply execute C# code against the database.

Instead, EF Core translates the LINQ expression into SQL.

Conceptually:

C# LINQ
   ↓
EF Core
   ↓
SQL Query
   ↓
Database
   ↓
Results
   ↓
EF Core
   ↓
C# Objects

Your C# code might look simple:

context.Employees
    .Where(e => e.Department == "IT")

But the database ultimately needs something similar to:

SELECT *
FROM Employees
WHERE Department = 'IT';

This is why understanding the SQL generated by EF Core is so important.

A query that looks elegant in C# isn't automatically efficient.

2. Select Only the Columns You Need

One of the easiest ways to improve database performance is to avoid retrieving unnecessary columns.

Consider:

var employees = await context.Employees
    .ToListAsync();

This may retrieve every column from the Employees table.

But suppose your API only needs:

Id
Name
Department

There is no reason to retrieve:

Salary
Address
DateOfBirth
ProfileImage
CreatedDate
UpdatedDate

Instead, use projection.

var employees = await context.Employees
    .Select(e => new
    {
        e.Id,
        e.Name,
        e.Department
    })
    .ToListAsync();

Now the database only needs to return the required fields.

This can significantly reduce:

Network traffic
Database I/O
Memory usage
Object materialization
API response processing

Real-World Example

Imagine an employee table contains 40 columns and 500,000 records.

If your API only needs three columns, retrieving complete entities unnecessarily can become expensive.

Projection allows the database to do less work.

Better API Design

You can also project directly into a DTO:

var employees = await context.Employees
    .Select(e => new EmployeeDto
    {
        Id = e.Id,
        Name = e.Name,
        Department = e.Department
    })
    .ToListAsync();

This is generally preferable for API responses because you're explicitly controlling the data exposed by your application.

3. Use `AsNoTracking()` for Read-Only Queries

EF Core normally keeps track of entities it retrieves.

This tracking is useful when you're going to modify those entities.

For example:

var employee = await context.Employees
    .FirstAsync(e => e.Id == id);

employee.Salary = 100000;

await context.SaveChangesAsync();

EF Core needs to know that the entity changed.

But what if you're only reading data?

For example:

var employees = await context.Employees
    .AsNoTracking()
    .ToListAsync();

AsNoTracking() tells EF Core:

I only need these entities for reading. Don't track them for changes.

This can reduce tracking overhead for read-heavy workloads.

When Should You Use It?

Good candidates include:

Search endpoints
Reporting APIs
Dashboard queries
Product listings
Read-only pages
Lookup data

For example:

var products = await context.Products
    .AsNoTracking()
    .Where(p => p.IsActive)
    .ToListAsync();

When Should You Avoid It?

Don't blindly use AsNoTracking() when you intend to modify the entity and call SaveChanges().

For example:

var employee = await context.Employees
    .AsNoTracking()
    .FirstAsync(e => e.Id == id);

employee.Salary = 90000;

await context.SaveChangesAsync();

The entity isn't being tracked, so EF Core won't automatically detect that change in the usual way.

Use tracking when you actually need change tracking.

4. Always Consider Pagination

One of the most common database performance mistakes is returning every record.

Imagine an endpoint:

GET /api/products

Your database contains 2 million products.

This is a terrible idea:

var products = await context.Products
    .ToListAsync();

You're asking the application to retrieve potentially millions of rows.

Instead, use pagination.

int page = 1;
int pageSize = 20;

var products = await context.Products
    .OrderBy(p => p.Id)
    .Skip((page - 1) * pageSize)
    .Take(pageSize)
    .ToListAsync();

For page 1:

Skip = 0
Take = 20

For page 2:

Skip = 20
Take = 20

For page 3:

Skip = 40
Take = 20

Why Pagination Matters

Pagination reduces:

Database result size
Network traffic
Application memory usage
Serialization time
API response size

For large datasets, pagination should be considered part of API design rather than an afterthought.

5. Avoid the N+1 Query Problem

The N+1 query problem is one of the most important EF Core performance issues to understand.

Suppose you have:

Orders
  ↓
Customer

You retrieve 100 orders:

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

Then inside a loop, you retrieve the customer:

foreach (var order in orders)
{
    var customer = await context.Customers
        .FirstAsync(c => c.Id == order.CustomerId);
}

You might accidentally execute:

1 query for Orders
+
100 queries for Customers
=
101 database queries

That's the N+1 problem.

Better Approach

Use an appropriate query that retrieves the required information together.

For example:

var orders = await context.Orders
    .Select(o => new
    {
        o.Id,
        o.OrderDate,
        CustomerName = o.Customer.Name
    })
    .ToListAsync();

Now EF Core can translate this relationship into SQL and retrieve the required data more efficiently.

The important lesson is:

Be careful when accessing related data inside loops.

6. Be Careful With `Include()`

Include() is useful when you need related entities.

For example:

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

This tells EF Core to load the related customer.

That can be appropriate.

But don't automatically add Include() everywhere.

For example:

var orders = await context.Orders
    .Include(o => o.Customer)
    .Include(o => o.Items)
    .Include(o => o.Payments)
    .Include(o => o.ShippingAddress)
    .ToListAsync();

You may end up retrieving a very large amount of related data.

Instead, ask:

Do I actually need these related entities?

If your API only needs the customer name, projection may be better:

var orders = await context.Orders
    .Select(o => new
    {
        o.Id,
        o.OrderDate,
        CustomerName = o.Customer.Name
    })
    .ToListAsync();

The goal isn't to avoid Include().

The goal is to use it intentionally.

7. Prefer Projection with `Select()`

Projection is one of the most useful techniques in EF Core.

Consider:

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

You're loading complete entities.

But perhaps your UI only needs:

Id
Name
Email

Instead:

var users = await context.Users
    .Select(u => new UserDto
    {
        Id = u.Id,
        Name = u.Name,
        Email = u.Email
    })
    .ToListAsync();

This approach has several benefits.

1. Less Data

Only required columns are retrieved.

2. Better API Contracts

The API explicitly defines what it returns.

3. Less Memory

The application doesn't need to materialize unnecessary entity properties.

4. Better Security

You're less likely to accidentally expose fields that shouldn't be returned.

For example, don't return an entire user entity if it contains:

PasswordHash
SecurityStamp
InternalNotes
ResetToken

Instead, explicitly select what the API needs.

8. Use Database Indexes

EF Core query optimization isn't only about C#.

Your database design matters enormously.

Suppose you frequently execute:

var employees = await context.Employees
    .Where(e => e.Email == email)
    .FirstOrDefaultAsync();

If Email isn't indexed, the database may need to scan a large number of rows.

A database index can make lookups much faster.

For example, using EF Core configuration:

modelBuilder.Entity<Employee>()
    .HasIndex(e => e.Email)
    .IsUnique();

This creates an index on the email column.

Composite Indexes

Sometimes queries filter on multiple columns.

For example:

var orders = await context.Orders
    .Where(o =>
        o.CustomerId == customerId &&
        o.Status == "Completed")
    .ToListAsync();

A composite index may be useful:

modelBuilder.Entity<Order>()
    .HasIndex(o => new
    {
        o.CustomerId,
        o.Status
    });

But don't create indexes for every column.

Indexes have costs too.

They can:

Consume storage
Increase insert/update overhead
Increase maintenance cost

Indexes should be based on actual query patterns.

9. Don't Call `ToList()` Too Early

This is another common LINQ and EF Core mistake.

Consider:

var employees = await context.Employees
    .ToListAsync();

var result = employees
    .Where(e => e.Department == "IT")
    .ToList();

The first ToListAsync() executes the database query immediately.

That means the application retrieves all employees before filtering them.

A better approach is:

var result = await context.Employees
    .Where(e => e.Department == "IT")
    .ToListAsync();

Now the filtering happens at the database level.

Conceptually:

Less Efficient

Database
   ↓
All Employees
   ↓
Application
   ↓
Filter

Better

Database
   ↓
Filter
   ↓
Only IT Employees
   ↓
Application

This is one of the most important concepts when working with IQueryable.

10. Inspect the SQL Generated by EF Core

Never assume your LINQ query produces the SQL you expect.

EF Core provides ways to inspect generated SQL.

For example:

var query = context.Employees
    .Where(e => e.Department == "IT");

Console.WriteLine(query.ToQueryString());

This can show the SQL generated for the query.

This is incredibly useful when diagnosing:

Slow queries
Unexpected joins
Missing filters
Excessive columns
Unexpected SQL generation

Example

You may write:

var result = context.Employees
    .Where(e => e.Salary > 80000)
    .OrderBy(e => e.Name);

Instead of guessing what happens, inspect the generated SQL.

Then you can take the SQL to your database tools and analyze the execution plan.

Remember

EF Core is an abstraction over the database.

When performance matters, you should understand both:

C# / LINQ

and:

SQL / Database Execution

Being comfortable with both makes you a much stronger .NET developer.

11. Combine Techniques for Real Applications

The biggest performance improvements usually come from combining multiple techniques.

Suppose you're building an employee search API.

A good query might look like:

var employees = await context.Employees
    .AsNoTracking()
    .Where(e => e.IsActive)
    .Where(e => e.Department == department)
    .OrderBy(e => e.Name)
    .Select(e => new EmployeeDto
    {
        Id = e.Id,
        Name = e.Name,
        Department = e.Department
    })
    .Skip((page - 1) * pageSize)
    .Take(pageSize)
    .ToListAsync();

This single query demonstrates several useful techniques:

AsNoTracking() for read-only data
Filtering at the database
Ordering
Projection
Pagination
Async database access

That's much better than retrieving thousands of complete entities and processing them inside application code.

12. Common EF Core Performance Mistakes

Here are some mistakes worth checking in your own projects.

❌ Loading Everything

context.Products.ToListAsync();

when the application only needs 20 records.

❌ Selecting Complete Entities

context.Users.ToListAsync();

when the API only needs three properties.

❌ Filtering After `ToList()`

context.Users
    .ToList()
    .Where(...);

❌ Unnecessary Tracking

Using tracked entities for large read-only reports.

❌ N+1 Queries

Executing database queries inside loops.

❌ Too Many Includes

Loading a huge object graph when only a few fields are required.

❌ Ignoring Database Indexes

Filtering and sorting frequently on columns that aren't appropriately indexed.

❌ Ignoring Generated SQL

Assuming that clean LINQ automatically means efficient SQL.

13. Practical EF Core Performance Checklist

Before releasing an API that uses EF Core, ask yourself:

☐ Am I selecting only the columns I need?

☐ Is this query read-only?

☐ Should I use AsNoTracking()?

☐ Does this endpoint need pagination?

☐ Am I accidentally creating N+1 queries?

☐ Do I really need every Include()?

☐ Can I use projection with Select()?

☐ Are frequently filtered columns indexed?

☐ Am I calling ToList() too early?

☐ Have I inspected the generated SQL?

☐ Have I tested the query with realistic data volumes?

☐ Have I checked the database execution plan?

The last two are especially important.

A query that performs well with 1,000 records may behave very differently with 10 million records.

Always test performance using data volumes that resemble production.

14. EF Core Interview Questions

What is `AsNoTracking()`?

AsNoTracking() tells EF Core not to track returned entities for changes. It is commonly useful for read-only queries.

Why is `Select()` useful for performance?

It allows you to retrieve only the fields required by the application instead of loading complete entities.

What is the N+1 query problem?

It occurs when an application executes one query to retrieve a collection and then executes additional queries for each item in that collection.

Why is `ToList()` important?

ToList() materializes the query and generally causes the database query to execute immediately.

Calling it too early can cause unnecessary data to be retrieved.

Does EF Core automatically create indexes?

EF Core creates indexes for certain conventions, such as primary keys, but application-specific indexes often need to be configured intentionally.

What is projection?

Projection means selecting only the data required from an entity, often using Select().

Why should generated SQL be inspected?

Because the LINQ expression you write doesn't always make the resulting SQL obvious. Inspecting SQL helps identify inefficient queries, joins, missing filters, and other database performance issues.

15. Frequently Asked Questions

Is EF Core slower than writing SQL manually?

Not necessarily.

EF Core can generate efficient SQL for many common scenarios, but developers still need to understand how their queries translate to SQL.

For highly specialized queries, raw SQL or other database-specific approaches can sometimes be appropriate.

The important thing is to measure rather than assume.

Should I always use `AsNoTracking()`?

No.

Use it when you don't need change tracking.

If you're retrieving an entity specifically to modify and save it, normal tracking may be appropriate.

Should I avoid `Include()`?

No.

Include() is useful when you genuinely need related entities.

The problem is using it without considering how much data you're loading.

Is `Select()` always faster?

Not automatically.

Projection can reduce the amount of data retrieved, but the actual performance depends on the query, database, indexes, relationships, and data size.

Measure important queries.

How can I find slow EF Core queries?

Start by logging SQL generated by EF Core and inspecting the queries using your database's execution-plan tools.

Application performance monitoring and database monitoring can also help identify slow queries in production.

16. Final Thoughts

Entity Framework Core allows .NET developers to work with databases using familiar C# and LINQ.

But abstraction doesn't eliminate the need to understand what's happening underneath.

The most important performance lessons from this article are:

Retrieve only the data you need.
Use AsNoTracking() for appropriate read-only queries.
Paginate large datasets.
Watch out for N+1 queries.
Use Include() intentionally.
Prefer projection when you only need specific fields.
Design appropriate database indexes.
Don't materialize queries too early.
Inspect the SQL generated by EF Core.
Test with realistic production-sized data.

The biggest mistake is optimizing based on assumptions.

Instead of thinking:

"This LINQ query looks simple, so it must be fast."

Think:

"What SQL will this generate, how will the database execute it, and how will it behave when the data grows?"

That mindset will help you write significantly better ASP.NET Core applications.

🚀 Explore More Free Developer Tools

As developers, we spend a surprising amount of time working with API responses, configuration files, tokens, test data, and different data formats while building applications.

That's one of the reasons I built ToolBenchApp.

👉 https://toolbenchapp.com/

ToolBenchApp is a growing collection of free, browser-based developer tools designed to simplify everyday development tasks.

For .NET and API developers, some particularly useful tools include:

JSON Formatter & Validator
JSON ↔ XML Converter
JSON ↔ CSV Converter
JWT Decoder
Base64 Encoder/Decoder
UUID Generator
URL Encoder/Decoder
SQL Formatter
YAML Formatter
Text Difference Checker
HTML Formatter
Regex Tester

For example, when debugging an ASP.NET Core API, you can quickly format a JSON response, inspect a JWT, compare two API payloads, or format SQL without installing another application.

I'm continuously adding new utilities to ToolBenchApp based on practical developer needs. If there's a small developer task you repeatedly perform and would like to turn into a free browser-based tool, I'd love to hear your suggestion.

Happy coding! 🚀

10 ASP.NET Core Middleware Concepts Every .NET Developer Should Know

ToolBench — Mon, 10 Aug 2026 12:47:30 +0000

ASP.NET Core middleware is one of those concepts that every .NET developer uses, but many developers don't fully understand what happens behind the scenes.

Authentication, authorization, exception handling, logging, CORS, HTTPS redirection, rate limiting, and even your own custom logic can all be implemented through middleware.

Once you understand how middleware works, ASP.NET Core applications become much easier to design, debug, and maintain.

In this tutorial, we'll go beyond the basic definition and explore 10 important ASP.NET Core middleware concepts with practical examples, including how middleware executes, how to create custom middleware, how Use, Run, and Map differ, how ordering affects your application, and how to avoid common mistakes.

What Is Middleware?
How the Middleware Pipeline Works
Use() vs Run() vs Map()
Creating Custom Middleware
Middleware Ordering
Exception Handling Middleware
Request Logging Middleware
Authentication and Authorization Middleware
Conditional Middleware
Short-Circuiting the Pipeline
Middleware with Dependency Injection
Common Middleware Mistakes
Performance Best Practices
Middleware Interview Questions
Frequently Asked Questions
Final Thoughts

1. What Is Middleware?

Middleware is a component that participates in handling an HTTP request and response.

You can think of middleware as a series of checkpoints through which every request passes.

For example, a request might travel through:

Client
  ↓
Exception Handling
  ↓
HTTPS Redirection
  ↓
Logging
  ↓
Authentication
  ↓
Authorization
  ↓
Routing
  ↓
Controller
  ↓
Response

Each middleware component can:

Inspect the request
Modify the request
Perform some operation
Call the next middleware
Modify the response
Stop the request from continuing

This makes middleware extremely powerful.

2. How the Middleware Pipeline Works

Let's start with a simple example.

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

app.Use(async (context, next) =>
{
    Console.WriteLine("Before next middleware");

    await next();

    Console.WriteLine("After next middleware");
});

app.Run(async context =>
{
    Console.WriteLine("Endpoint");

    await context.Response.WriteAsync("Hello World!");
});

app.Run();

When a request arrives, the output is:

Before next middleware
Endpoint
After next middleware

Notice something important.

The middleware doesn't simply execute from top to bottom.

The call to:

await next();

passes execution to the next middleware.

When that middleware finishes, execution returns to the previous middleware.

You can visualize it like this:

Middleware A
    ↓
Middleware B
    ↓
Endpoint
    ↑
Middleware B
    ↑
Middleware A

This is sometimes called the middleware pipeline or onion model.

Understanding this behavior is essential when working with logging, authentication, exception handling, and response manipulation.

3. `Use()` vs `Run()` vs `Map()`

One of the most common ASP.NET Core interview questions is the difference between Use(), Run(), and Map().

`Use()`

Use() adds middleware that can call the next component.

app.Use(async (context, next) =>
{
    Console.WriteLine("Before");

    await next();

    Console.WriteLine("After");
});

Because it receives next, it can continue the pipeline.

`Run()`

Run() adds terminal middleware.

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello");
});

There is no next parameter.

Once this middleware executes, the pipeline ends.

For example:

app.Use(async (context, next) =>
{
    Console.WriteLine("Middleware 1");

    await next();
});

app.Run(async context =>
{
    Console.WriteLine("Terminal middleware");
});

Anything registered after Run() won't execute.

`Map()`

Map() allows you to create a separate pipeline based on the request path.

app.Map("/admin", adminApp =>
{
    adminApp.Run(async context =>
    {
        await context.Response.WriteAsync("Admin Area");
    });
});

Now:

/admin

will enter the mapped pipeline.

This is useful when different URL paths require completely different processing.

4. Creating Custom Middleware

One of the most useful skills for an ASP.NET Core developer is creating custom middleware.

Suppose you want to measure how long every request takes.

You could create:

public class RequestTimingMiddleware
{
    private readonly RequestDelegate _next;

    public RequestTimingMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        var stopwatch = Stopwatch.StartNew();

        await _next(context);

        stopwatch.Stop();

        Console.WriteLine(
            $"{context.Request.Path} took {stopwatch.ElapsedMilliseconds} ms");
    }
}

You can register it with:

app.UseMiddleware<RequestTimingMiddleware>();

Now every request passes through your middleware.

Why Use Custom Middleware?

Custom middleware is useful for cross-cutting concerns such as:

Request logging
Correlation IDs
Exception handling
Performance measurement
Security headers
Request validation
Custom authentication
Tenant identification
Audit logging

The important principle is:

Middleware is best suited for logic that applies across many requests.

Don't put business-specific logic into middleware when it belongs inside a service or controller.

5. Middleware Ordering Matters

This is one of the most important concepts to understand.

Consider:

app.UseAuthentication();

app.UseAuthorization();

app.MapControllers();

The order is intentional.

Authentication establishes who the user is.

Authorization then determines whether that user is allowed to access the resource.

Finally, the request reaches the endpoint.

Conceptually:

Request
  ↓
Authentication
  ↓
Authorization
  ↓
Controller

If you change the order incorrectly, your application may behave unexpectedly.

For example:

app.UseAuthorization();

app.UseAuthentication();

This is generally incorrect because authorization may execute before the user has been authenticated.

General rule

When working with middleware, always ask:

"Does this middleware depend on something that runs before it?"

That question helps prevent many pipeline-related bugs.

6. Exception Handling Middleware

Production applications should not expose raw exception details to users.

Instead of allowing an exception to travel directly to the client, use exception-handling middleware.

ASP.NET Core provides built-in support:

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/error");
}

You can also implement your own middleware.

public async Task InvokeAsync(HttpContext context)
{
    try
    {
        await _next(context);
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex);

        context.Response.StatusCode = 500;

        await context.Response.WriteAsJsonAsync(new
        {
            message = "An unexpected error occurred."
        });
    }
}

This gives you a central place to handle unexpected failures.

Important

Don't return sensitive exception details in production.

Avoid responses such as:

{
  "error": "SqlException: Login failed for user..."
}

Instead, return a safe message and log the detailed exception internally.

7. Request Logging Middleware

Logging every request can be extremely useful when troubleshooting production applications.

A simple middleware might look like this:

public class RequestLoggingMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<RequestLoggingMiddleware> _logger;

    public RequestLoggingMiddleware(
        RequestDelegate next,
        ILogger<RequestLoggingMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        var stopwatch = Stopwatch.StartNew();

        await _next(context);

        stopwatch.Stop();

        _logger.LogInformation(
            "HTTP {Method} {Path} returned {StatusCode} in {Elapsed}ms",
            context.Request.Method,
            context.Request.Path,
            context.Response.StatusCode,
            stopwatch.ElapsedMilliseconds);
    }
}

This can produce logs such as:

HTTP GET /api/products returned 200 in 42ms

This is much more useful than randomly placing Console.WriteLine() statements throughout your application.

8. Authentication and Authorization Middleware

Authentication and authorization are related but different concepts.

Authentication

Authentication answers:

Who are you?

For example:

User → JWT Token → Authentication → User Identity

Authorization

Authorization answers:

Are you allowed to access this resource?

For example:

Authenticated User
       ↓
Required Role = Admin
       ↓
Allowed / Forbidden

In ASP.NET Core, you'll commonly see:

app.UseAuthentication();

app.UseAuthorization();

And then protect endpoints with:

[Authorize]
public IActionResult GetOrders()
{
    return Ok();
}

Or with roles:

[Authorize(Roles = "Admin")]
public IActionResult DeleteUser(int id)
{
    return Ok();
}

This separation is fundamental when designing secure APIs.

9. Conditional Middleware

Sometimes you don't want middleware to execute for every request.

ASP.NET Core provides ways to conditionally add middleware.

For example:

app.UseWhen(
    context => context.Request.Path.StartsWithSegments("/api"),
    branch =>
    {
        branch.UseMiddleware<RequestTimingMiddleware>();
    });

Now the middleware only runs for requests beginning with:

/api

You can also use MapWhen() when you want to create a completely separate pipeline.

app.MapWhen(
    context => context.Request.Query.ContainsKey("debug"),
    branch =>
    {
        branch.Run(async context =>
        {
            await context.Response.WriteAsync("Debug pipeline");
        });
    });

Conditional middleware can be useful when different parts of your application require different processing.

10. Short-Circuiting the Pipeline

Middleware doesn't always have to call next().

It can stop the pipeline completely.

For example:

app.Use(async (context, next) =>
{
    if (!context.Request.Headers.ContainsKey("X-API-KEY"))
    {
        context.Response.StatusCode = 401;

        await context.Response.WriteAsync("API key required.");

        return;
    }

    await next();
});

If the API key doesn't exist, the request ends immediately.

The controller will never execute.

This is called short-circuiting.

Short-circuiting is useful for:

Authentication checks
API key validation
IP restrictions
Maintenance mode
Rate limiting
Request validation

However, don't overuse it.

If the logic belongs to authorization, validation, or business logic, use the appropriate ASP.NET Core mechanism instead of creating unnecessary custom middleware.

11. Middleware with Dependency Injection

Middleware can also use services registered with ASP.NET Core's dependency injection container.

For example:

public class AuditMiddleware
{
    private readonly RequestDelegate _next;

    public AuditMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(
        HttpContext context,
        IAuditService auditService)
    {
        await _next(context);

        await auditService.RecordAsync(
            context.Request.Path,
            context.Response.StatusCode);
    }
}

Notice that IAuditService is injected into InvokeAsync().

This is useful when middleware needs application services.

For example:

builder.Services.AddScoped<IAuditService, AuditService>();

Then the middleware can use it.

Important Lifetime Consideration

Be careful when injecting scoped services into middleware.

Conventional middleware instances can live longer than a single request, so injecting scoped services into the middleware constructor can create lifetime problems.

Prefer injecting request-scoped services into InvokeAsync() when appropriate.

12. Common Middleware Mistakes

Let's look at mistakes that frequently appear in real applications.

Mistake 1: Forgetting `await next()`

Consider:

app.Use(async (context, next) =>
{
    Console.WriteLine("Logging");

    // next() is never called
});

The pipeline stops here.

Unless the middleware intentionally short-circuits the request, this is a bug.

Mistake 2: Incorrect Middleware Order

For example:

app.UseAuthorization();

app.UseAuthentication();

Authentication should normally happen before authorization.

Always understand the dependencies between middleware components.

Mistake 3: Putting Business Logic in Middleware

Avoid doing this:

if (order.Total > 10000)
{
    // complex business rules
}

Middleware should generally handle cross-cutting concerns.

Business rules belong in appropriate application/domain services.

Mistake 4: Logging Sensitive Information

Don't blindly log:

Passwords
Access tokens
Refresh tokens
Credit card information
Sensitive personal information

Logging should help diagnose problems without creating a security problem.

Mistake 5: Doing Expensive Work on Every Request

Middleware runs frequently.

If your application receives 10,000 requests, middleware may execute 10,000 times.

Avoid unnecessary database calls, network calls, or expensive calculations in globally registered middleware.

13. Middleware Performance Best Practices

Performance matters because middleware can affect every request.

Keep Middleware Lightweight

Good middleware:

Request
 ↓
Small operation
 ↓
next()

Avoid unnecessarily expensive processing.

Avoid Blocking Calls

Prefer:

await service.ProcessAsync();

instead of synchronous blocking operations.

Avoid patterns such as:

service.ProcessAsync().Result;

or:

service.ProcessAsync().Wait();

These can cause thread-pool starvation and performance problems.

Use Structured Logging

Instead of:

_logger.LogInformation(
    $"Request {path} took {time}ms");

Prefer structured logging:

_logger.LogInformation(
    "Request {Path} took {Elapsed}ms",
    path,
    time);

Structured logs are easier to search and analyze in logging platforms.

14. Middleware vs Filters

A common interview question is:

What's the difference between middleware and MVC filters?

Middleware operates at the HTTP pipeline level.

Filters are more closely associated with MVC/controller or endpoint execution.

Think of it like:

HTTP Request
     ↓
Middleware
     ↓
Routing
     ↓
Endpoint
     ↓
MVC Filters
     ↓
Controller

Use middleware for application-wide concerns.

Use filters when the behavior is specifically related to MVC/controller or action execution.

15. Middleware Interview Questions

Here are some questions worth knowing for .NET interviews.

1. What is middleware in ASP.NET Core?

Middleware is software that participates in processing HTTP requests and responses within the ASP.NET Core pipeline.

2. What is `next()`?

next() passes control to the next middleware component.

3. What happens if `next()` isn't called?

The pipeline is short-circuited unless the middleware intentionally handles the response itself.

4. What is the difference between `Use()` and `Run()`?

Use() can call the next middleware.

Run() is terminal middleware and doesn't continue the pipeline.

5. Why does middleware order matter?

Because middleware executes in the order it is registered, and some components depend on others running first.

6. How do you create custom middleware?

Create a class that accepts RequestDelegate and exposes an Invoke or InvokeAsync method.

7. What is short-circuiting?

Stopping the request pipeline before subsequent middleware executes.

8. When should middleware be used?

For cross-cutting concerns such as logging, exception handling, authentication, security headers, and request processing.

Frequently Asked Questions

Is middleware executed for every request?

Middleware registered globally generally participates in every request unless the pipeline is branched or the middleware itself chooses to short-circuit or skip processing.

Can middleware modify the response?

Yes.

Middleware can inspect or modify the response before or after calling the next component.

Can middleware access services?

Yes. Middleware can use ASP.NET Core dependency injection.

Should business logic be placed in middleware?

Generally, no. Middleware should focus on cross-cutting concerns rather than application-specific business rules.

Can middleware stop a request?

Yes. Middleware can short-circuit the pipeline by not calling next() and returning a response directly.

Final Thoughts

Middleware is one of the foundations of ASP.NET Core.

Once you understand how the pipeline works, many ASP.NET Core features become easier to understand.

The most important concepts to remember are:

Middleware forms a request-processing pipeline.
Use() can continue the pipeline.
Run() is terminal.
Map() can create branches.
Middleware order matters.
Middleware can short-circuit requests.
Custom middleware is useful for cross-cutting concerns.
Authentication should generally run before authorization.
Middleware should remain lightweight.
Business logic should live in appropriate services.

If you're preparing for a .NET interview, don't just memorize these definitions. Build a small ASP.NET Core API and implement your own logging, exception handling, API-key validation, and request-timing middleware.

That's when the pipeline really starts to make sense.

🚀 Explore More Free Developer Tools

As developers, we often switch between different tools while building and debugging applications. Formatting API responses, decoding JWTs, comparing configuration files, generating UUIDs, or converting data shouldn't require opening several different websites.

That's one reason I built ToolBenchApp.

👉 https://toolbenchapp.com/

ToolBenchApp is a growing collection of free, browser-based developer tools designed to make everyday development tasks faster and simpler.

Some of the available tools include:

JSON Formatter & Validator
JWT Decoder
JSON ↔ XML Converter
JSON ↔ CSV Converter
Base64 Encoder/Decoder
UUID Generator
URL Encoder/Decoder
SQL Formatter
YAML Formatter
Text Difference Checker
HTML Formatter
Regex Tester

If you're working with ASP.NET Core APIs, tools like the JSON Formatter, JWT Decoder, and Text Diff Checker can be particularly useful during development and debugging.

I'm continuously adding new utilities based on what developers actually need, so if there's a tool you'd like to see on ToolBenchApp, feel free to share your idea.

Happy coding! 🚀

Mastering LINQ in C#: 12 Practical Examples Every .NET Developer Should Know

ToolBench — Fri, 07 Aug 2026 13:03:00 +0000

If you're a .NET developer, you've probably written countless for and foreach loops to filter, search, sort, and transform collections.

Before LINQ (Language Integrated Query) was introduced in .NET 3.5, developers had to write repetitive looping logic for almost every data operation. While those approaches still work, they often make the code longer, harder to read, and more difficult to maintain.

LINQ changed that by introducing a clean, expressive, and powerful way to query data directly within C#.

Whether you're working with:

Lists
Arrays
Dictionaries
XML
Entity Framework Core
SQL Server
APIs

LINQ is one of the most valuable features you can master.

In this article, we'll explore 12 practical LINQ examples that every .NET developer should know, along with real-world use cases, best practices, performance tips, and common pitfalls.

📖 Table of Contents

What is LINQ?
Why Use LINQ?
LINQ Query Syntax vs Method Syntax
Sample Project
Example 1 – Where()
Example 2 – Select()
Example 3 – OrderBy()
Example 4 – FirstOrDefault()
More LINQ Methods (Part 2)
Best Practices
Common Mistakes
Interview Questions
FAQs

What is LINQ?

LINQ stands for Language Integrated Query.

It allows developers to query collections using a consistent syntax directly within C#.

Instead of manually looping through data, you simply describe what you want.

Traditional approach:

List<Employee> result = new();

foreach (var employee in employees)
{
    if(employee.Department=="IT")
    {
        result.Add(employee);
    }
}

LINQ approach:

var result = employees.Where(e => e.Department == "IT");

The second example is:

Easier to read
Easier to maintain
Less error-prone
More expressive

Why Use LINQ?

Here are a few reasons why LINQ has become an essential part of modern .NET development.

✅ Less Code

Tasks that once required several lines of loops and conditionals can often be written in a single, readable statement.

✅ Better Readability

LINQ reads almost like English.

employees
.Where(e => e.Department=="IT")
.OrderBy(e => e.Name)
.Select(e => e.Name);

Even someone new to the project can quickly understand the intent.

✅ Consistent API

The same LINQ methods work across:

Arrays
Lists
Dictionaries
Entity Framework
XML
In-memory collections

Once you learn LINQ, you can use it almost everywhere in .NET.

Query Syntax vs Method Syntax

LINQ provides two styles.

Query Syntax

var result =
from employee in employees
where employee.Department=="IT"
select employee;

Method Syntax

var result =
employees.Where(e => e.Department=="IT");

Which one should you use?

Microsoft supports both, but method syntax is generally preferred because:

It's more concise.
It supports all LINQ operations.
Most production codebases use it.
Entity Framework examples are primarily written using method syntax.

Throughout this article, we'll use method syntax.

Sample Data

We'll use the following Employee class throughout the examples.

public class Employee
{
    public int Id { get; set; }

    public string Name { get; set; }

    public string Department { get; set; }

    public decimal Salary { get; set; }

    public int Age { get; set; }
}

Sample data:

var employees = new List<Employee>
{
    new Employee { Id=1, Name="Alice", Department="HR", Salary=50000, Age=28 },
    new Employee { Id=2, Name="Bob", Department="IT", Salary=85000, Age=34 },
    new Employee { Id=3, Name="Charlie", Department="Finance", Salary=72000, Age=31 },
    new Employee { Id=4, Name="David", Department="IT", Salary=95000, Age=38 },
    new Employee { Id=5, Name="Emma", Department="HR", Salary=61000, Age=27 }
};

Now let's explore practical examples.

1. Filter Data Using `Where()`

The Where() method filters a collection based on a condition.

var itEmployees =
employees.Where(e => e.Department=="IT");

Output

Bob
David

Real-world use case

Imagine you're building an employee management portal.

Instead of loading every employee, you only want to display developers from the IT department.

Where() makes this incredibly simple.

Best Practice

Avoid writing multiple nested Where() calls when a single condition is enough.

Instead of:

employees
.Where(e=>e.Department=="IT")
.Where(e=>e.Salary>80000)

Write:

employees.Where(e =>
e.Department=="IT"
&& e.Salary>80000);

It's easier to read and avoids unnecessary method chaining.

2. Project Data Using `Select()`

Sometimes you don't need the entire object.

Suppose you're creating a dropdown list that only needs employee names.

var names =
employees.Select(e => e.Name);

Output:

Alice
Bob
Charlie
David
Emma

Why is this important?

Returning only the required fields reduces memory usage and improves performance.

This becomes even more important when using Entity Framework because SQL queries retrieve only the selected columns.

3. Sort Data Using `OrderBy()`

Need employees sorted by salary?

var result =
employees.OrderBy(e=>e.Salary);

Highest salary?

var highest =
employees.OrderByDescending(e=>e.Salary);

Sorting is commonly used in:

Reports
Product listings
Dashboards
Search results
Admin portals

4. Find the First Matching Record

Suppose you're searching for an employee by ID.

var employee =
employees.FirstOrDefault(e=>e.Id==2);

If found:

Bob

If no employee exists, the result is null.

Why use `FirstOrDefault()` instead of `First()`?

First() throws an exception if no record exists.
FirstOrDefault() safely returns null.

In most applications, FirstOrDefault() is the safer choice because it allows you to handle missing data gracefully.

➡️ In Part 2, we'll cover:

Any()
All()
Count()
GroupBy()
Distinct()
Max()
Min()
Average()
Sum()
Join()
Performance tips and deferred execution

🚀 Explore More Free Developer Tools

As developers, we often switch between multiple websites to format JSON, decode JWTs, compare text, generate UUIDs, or convert data between formats. I wanted a faster, privacy-friendly alternative, so I built ToolBenchApp.

👉 https://toolbenchapp.com/

ToolBenchApp is a growing collection of free browser-based developer tools designed to simplify everyday development tasks. Everything runs directly in your browser, helping you work faster without unnecessary downloads or uploads.

Some of the tools currently available include:

JSON Formatter & Validator
JSON ↔ XML Converter
JSON ↔ CSV Converter
JWT Decoder
Base64 Encoder/Decoder
UUID Generator
URL Encoder/Decoder
SQL Formatter
YAML Formatter
Text Difference Checker
HTML Formatter
Regex Tester
And many more...

I'm continuously adding new tools based on feedback from the developer community. If there's a utility you'd like to see, let me know—I’d love to build it.

Happy coding! 🚀

10 Modern C# Features Every .NET Developer Should Know in 2026

ToolBench — Wed, 05 Aug 2026 12:45:25 +0000

C# has evolved tremendously over the past few years. With every new release, Microsoft introduces features that make code cleaner, safer, and easier to maintain. Yet many developers still rely on patterns that were common years ago, missing out on language improvements that can significantly boost productivity.

In this article, we'll explore 10 modern C# features that every .NET developer should know in 2026. Whether you're building ASP.NET Core APIs, desktop applications, cloud services, or microservices, these features can help you write more expressive and maintainable code.

📖 Table of Contents

String Interpolation
Null-Coalescing Operator (??)
Null-Conditional Operator (?.)
Pattern Matching
Switch Expressions
Expression-Bodied Members
Using Declarations
Records
Global Using Directives
File-Scoped Namespaces
Bonus Features
Final Thoughts

1. String Interpolation

Instead of concatenating strings:

string message = "Welcome " + user.Name + "!";

Use string interpolation:

string message = $"Welcome {user.Name}!";

Why use it?

Cleaner and easier to read
Less error-prone
Great for logging and debugging
Preferred in modern C# codebases

2. Null-Coalescing Operator (`??`)

Instead of:

string name;

if (user.Name != null)
{
    name = user.Name;
}
else
{
    name = "Guest";
}

Use:

string name = user.Name ?? "Guest";

This reduces boilerplate while making your intent obvious.

3. Null-Conditional Operator (`?.`)

Without it:

if (user != null && user.Address != null)
{
    Console.WriteLine(user.Address.City);
}

With it:

Console.WriteLine(user?.Address?.City);

This helps prevent NullReferenceException and keeps your code concise.

4. Pattern Matching

Instead of checking and casting separately:

if (employee is Manager)
{
    var manager = (Manager)employee;
    Console.WriteLine(manager.Department);
}

Use pattern matching:

if (employee is Manager manager)
{
    Console.WriteLine(manager.Department);
}

Pattern matching improves readability and reduces repetitive casting.

5. Switch Expressions

Traditional switch statements are often verbose.

Modern C# allows:

string role = userType switch
{
    1 => "Admin",
    2 => "Manager",
    3 => "Employee",
    _ => "Guest"
};

It's concise, expressive, and easier to maintain.

6. Expression-Bodied Members

Instead of:

public string GetFullName()
{
    return $"{FirstName} {LastName}";
}

Use:

public string GetFullName() => $"{FirstName} {LastName}";

Perfect for simple methods and properties.

7. Using Declarations

Old approach:

using (var connection = new SqlConnection(connectionString))
{
    connection.Open();
}

Modern approach:

using var connection = new SqlConnection(connectionString);

connection.Open();

This reduces unnecessary indentation while ensuring proper resource disposal.

8. Records

For immutable models and DTOs:

public record Employee(int Id, string Name);

Benefits

Value-based equality
Less boilerplate
Immutability by default
Excellent for API request and response models

9. Global Using Directives

Instead of repeating the same using statements in every file:

global using System;
global using System.Collections.Generic;
global using System.Linq;

This keeps files cleaner and reduces repetition across your project.

10. File-Scoped Namespaces

Traditional syntax:

namespace DemoProject
{
    public class UserService
    {
    }
}

Modern syntax:

namespace DemoProject;

public class UserService
{
}

Less indentation means cleaner, easier-to-read source files.

Bonus Features Worth Exploring

Modern C# continues to evolve. Here are a few more features worth adding to your toolkit:

required members
init properties
Target-typed new
nameof
Raw string literals
Collection expressions
IAsyncEnumerable
Primary constructors (C# 12)

Why These Features Matter

Adopting modern C# features isn't about writing fewer lines of code—it's about writing better code.

These features help you:

Improve readability
Reduce boilerplate
Prevent common bugs
Simplify refactoring
Improve maintainability
Write cleaner APIs and services

Even introducing one or two of these features into your daily workflow can make a noticeable difference over time.

Final Thoughts

One of the biggest strengths of C# is its continuous evolution. Each new version introduces features that make development more enjoyable without breaking existing applications.

You don't need to adopt everything overnight. Start by using one or two of these features in your next project, then gradually expand your toolkit as they become second nature.

Which modern C# feature has had the biggest impact on your codebase? I'd love to hear your thoughts—and if there's a feature you think deserves a spot on this list, share it in the comments!

🚀 Explore More Free Developer Tools

If you regularly work with .NET, APIs, JSON, JWTs, formatting, encoding, or debugging, you might find ToolBenchApp useful.

👉 https://toolbenchapp.com/

ToolBenchApp is a growing collection of free browser-based developer tools designed to simplify everyday development tasks. Whether you need to format JSON, decode JWTs, compare text, generate UUIDs, or convert data between common formats, the goal is to help developers stay productive without switching between multiple tools.

I'm continuously improving ToolBenchApp based on feedback from the developer community, so if there's a tool you'd like to see added, I'd love to hear your suggestions.

⭐ If you found this article helpful, consider leaving a ❤️ and sharing it with other .NET developers. Happy coding!

15 VS Code Shortcuts That Save Me Hours Every Month

ToolBench — Tue, 04 Aug 2026 13:40:53 +0000

Visual Studio Code has become the go-to editor for millions of developers. Whether you're building web applications, backend services, mobile apps, or cloud solutions, chances are VS Code is part of your daily workflow.

When I first started using VS Code, I relied almost entirely on the mouse. Over time, I discovered that learning a handful of keyboard shortcuts dramatically improved my productivity.

Here are 15 shortcuts I use almost every day, along with examples of when they come in handy.

1. Quick Open Files

Windows/Linux

Ctrl + P

macOS

Cmd + P

Instantly search and open any file in your project.

Instead of navigating through folders, simply type:

user.service.ts

and press Enter.

2. Command Palette

Ctrl + Shift + P

Think of this as VS Code's control center.

You can:

Rename symbols
Change themes
Run extensions
Format documents
Open settings

If you can't remember where an option lives, chances are it's available here.

3. Multi-Cursor Editing

Alt + Click

Need to edit several lines at once?

Place multiple cursors and type simultaneously.

Perfect for:

Updating repeated variable names
Editing JSON
Modifying configuration files

4. Rename Symbol

F2

Instead of manually replacing every occurrence of a variable or method, press F2.

VS Code intelligently updates references across your project.

5. Format Document

Shift + Alt + F

One shortcut instantly formats your code.

Works especially well with:

TypeScript
JavaScript
C#
JSON
HTML
CSS

6. Find Across the Project

Ctrl + Shift + F

Search every file in your workspace.

Extremely useful when:

Refactoring code
Finding API endpoints
Locating configuration values

7. Replace Across Files

Ctrl + Shift + H

Perfect for large-scale refactoring.

Example:

Replace

OldApiService

with

UserApiService

across hundreds of files in seconds.

8. Duplicate a Line

Shift + Alt + Down Arrow

This duplicates the current line.

Great for:

Creating similar objects
Repeating configuration blocks
Experimenting with code

9. Move a Line Up or Down

Alt + Up Arrow

Alt + Down Arrow

Rearrange code without cutting and pasting.

10. Toggle Terminal

Ctrl + `

Quickly open or close the integrated terminal.

Ideal for running:

npm install
dotnet run
git commands
Angular CLI
Docker commands

without leaving VS Code.

11. Go to Definition

F12

Jump directly to the implementation of:

Methods
Classes
Interfaces
Variables

This is invaluable when navigating large codebases.

12. Peek Definition

Alt + F12

Instead of opening another file, peek at the definition in a small popup.

Perfect for quick inspections.

13. Comment or Uncomment Code

Ctrl + /

A simple but frequently used shortcut.

Ideal when debugging or temporarily disabling code.

14. Toggle Sidebar

Ctrl + B

Need more screen space?

Hide the Explorer and focus on your code.

15. Open Recently Used Files

Ctrl + Tab

Quickly switch between recently opened files.

Especially useful when working across multiple services or components.

Bonus Productivity Tips

Here are a few habits that complement these shortcuts:

Enable Auto Save for fewer interruptions.
Install GitLens to view Git history inline.
Use Error Lens to surface errors directly in your code.
Configure Prettier for automatic formatting.
Learn your debugger shortcuts—they're just as valuable as editing shortcuts.

Small workflow improvements compound over time.

Final Thoughts

You don't need to memorize every VS Code shortcut overnight. Start with three or four that solve your biggest daily pain points, and gradually add more as they become second nature.

Even saving a few seconds on repetitive tasks adds up over weeks and months, letting you focus more on solving problems and writing great code.

Which VS Code shortcut has had the biggest impact on your workflow? Or is there a hidden gem that more developers should know? Share it in the comments—I’m always looking to improve my own workflow too.

🚀 Explore More Free Developer Tools

If you frequently work with JSON, APIs, formatting, encoding, validation, or debugging, you might enjoy ToolBenchApp.

👉 https://toolbenchapp.com/

ToolBenchApp is a growing collection of free browser-based developer tools built to simplify everyday development tasks. Whether you're formatting JSON, validating data, decoding JWTs, generating UUIDs, comparing text, or converting between common formats, the goal is to help developers work faster without leaving the browser.

I'm continuously expanding the platform based on real developer needs, so if there's a tool you'd like to see, I'd love to hear your ideas.

12 Git Commands Every Developer Should Know (With Practical Examples)

ToolBench — Mon, 03 Aug 2026 11:30:12 +0000

12 Git Commands Every Developer Should Know (With Practical Examples)

Whether you're working on a solo side project or collaborating with a large engineering team, Git is one of the most important tools in a developer's toolkit.

Many developers know just enough Git to get by—git add, git commit, and git push. But learning a few additional commands can save hours of debugging, prevent mistakes, and make collaboration much smoother.

In this article, we'll walk through 12 Git commands that every developer should understand, complete with practical examples and common use cases.

1. Check the Status of Your Repository

git status

This command shows:

Modified files
New files
Deleted files
Files staged for commit
Current branch

Example:

On branch feature/login

Changes not staged for commit:
modified: src/app.ts

Untracked files:
README.md

This is often the first command you should run before committing changes.

2. Stage Files

Stage a single file:

git add app.js

Stage everything:

git add .

Only staged files become part of your next commit.

3. Commit Changes

git commit -m "Add user authentication"

A good commit message explains what changed, not just that something changed.

Good examples:

✅ Fix login validation

✅ Add pagination to Products API

❌ Changes

❌ Update

4. View Commit History

git log

For a cleaner view:

git log --oneline

Example:

d91a31c Fix JWT validation
94ab621 Add user profile endpoint
c2f70f1 Initial project setup

5. Create a New Branch

git checkout -b feature/payment

Or using the newer command:

git switch -c feature/payment

Creating feature branches keeps your main branch stable.

6. Switch Between Branches

git switch main

git checkout main

Always verify you're on the correct branch before making changes.

7. Pull Latest Changes

git pull origin main

This downloads and merges the latest commits from the remote repository.

Pull regularly to reduce merge conflicts.

8. Push Your Changes

git push origin feature/payment

Your teammates can't review your work until it's pushed.

9. See What Changed

git diff

Compare staged changes:

git diff --staged

This is extremely useful before committing.

10. Undo the Last Commit (Without Losing Changes)

If you committed too early:

git reset --soft HEAD~1

Your changes remain staged, allowing you to edit and recommit.

11. Stash Temporary Work

Need to switch branches without committing unfinished work?

git stash

Restore it later:

git stash pop

Git Stash is perfect when an urgent production issue interrupts your current task.

12. View Remote Repositories

git remote -v

Example:

origin https://github.com/company/project.git

Useful when working with multiple remotes or verifying repository URLs.

Bonus Tips

Here are a few habits that can improve your Git workflow:

Commit small, focused changes.
Pull before pushing.
Write meaningful commit messages.
Avoid committing generated files unless necessary.
Review changes with git diff before every commit.
Use feature branches instead of committing directly to main.
Resolve merge conflicts carefully instead of rushing through them.

A Typical Git Workflow

git pull origin main
git checkout -b feature/profile
git add .
git commit -m "Add profile page"
git push origin feature/profile

Then create a Pull Request for code review.

This workflow keeps collaboration organized and makes changes easier to review.

Final Thoughts

Git is much more than a version control system—it's a collaboration tool that helps teams build software safely and efficiently.

You don't need to memorize every Git command, but mastering the essentials can make your daily development workflow faster, reduce mistakes, and give you more confidence when working on real-world projects.

Which Git command do you use the most? Are there any lesser-known Git tricks that have saved you time? Share them in the comments—I’m always looking to learn new workflows from the community.

🚀 Explore More Free Developer Tools

If you regularly work with JSON, APIs, encoding, formatting, validation, or debugging, you might find ToolBenchApp useful:

👉 https://toolbenchapp.com/

ToolBenchApp is a growing collection of free browser-based developer tools designed to simplify everyday development tasks. Whether you need to format JSON, decode JWTs, compare text, generate UUIDs, or convert data between formats, the goal is to help developers stay productive without leaving the browser.

I'm continuously improving the platform based on developer feedback, so if there's a tool you'd like to see added, I'd love to hear your suggestions.

7 REST API Best Practices Every Backend Developer Should Follow

ToolBench — Wed, 29 Jul 2026 13:33:01 +0000

7 REST API Best Practices Every Backend Developer Should Follow

Designing a REST API isn't just about making endpoints work—it's about creating an interface that's intuitive, reliable, secure, and easy for other developers to integrate with.

Whether you're building a personal project or a production-grade application, following REST API best practices can save countless hours of debugging and future maintenance.

Here are seven practices that have consistently helped me build better APIs.

1. Use Meaningful Resource Names

Your endpoints should represent resources, not actions.

✅ Good

GET /api/users
GET /api/users/15
POST /api/users
PUT /api/users/15
DELETE /api/users/15

❌ Avoid

GET /api/getUsers
POST /api/createUser
POST /api/deleteUser

Using nouns instead of verbs makes your API more predictable and aligns with REST principles.

2. Return the Right HTTP Status Codes

HTTP status codes tell clients exactly what happened.

Some common examples:

Status Code	Meaning
200	Request succeeded
201	Resource created
204	Success with no response body
400	Invalid request
401	Authentication required
403	Permission denied
404	Resource not found
409	Conflict
500	Internal server error

Returning 200 OK for every response—even errors—makes debugging much harder.

3. Keep Your Responses Consistent

Imagine one endpoint returns:

{
  "id": 1,
  "name": "John"
}

While another returns:

{
  "userId": 1,
  "fullName": "John"
}

Both represent the same resource but use different naming conventions.

Instead, choose one style and use it consistently across your API.

Consistency makes client-side development much easier.

4. Return Useful Error Messages

Instead of returning:

{
  "error": "Invalid request"
}

Provide something developers can actually act on:

{
  "status": 400,
  "message": "Email address is required.",
  "field": "email"
}

Good error messages reduce debugging time and improve the developer experience.

5. Validate Input Early

Never assume incoming data is valid.

Always validate:

Required fields
Email formats
Number ranges
Date formats
String lengths
Business rules

Fail fast with a clear response instead of allowing invalid data to reach your database.

6. Version Your API

As your application evolves, your API will change too.

Versioning prevents breaking existing clients.

Example:

/api/v1/users
/api/v2/users

This allows older applications to continue working while newer clients adopt the latest version.

7. Document Your API

A well-designed API still needs good documentation.

Include:

Endpoint URLs
Request methods
Authentication requirements
Sample requests
Sample responses
Error codes

Tools like Swagger (OpenAPI) make it much easier for developers to understand and test your API.

Bonus Tips

Here are a few additional practices that can make your APIs even better:

Use pagination for large datasets.
Support filtering and sorting where appropriate.
Avoid exposing internal database IDs if they shouldn't be public.
Implement rate limiting for public APIs.
Use HTTPS for all production endpoints.
Log errors without exposing sensitive information to clients.

Example: A Well-Designed Endpoint

GET /api/v1/products?category=laptops&page=2&pageSize=10

Possible response:

{
  "page": 2,
  "pageSize": 10,
  "totalItems": 54,
  "totalPages": 6,
  "items": [
    {
      "id": 21,
      "name": "Laptop Pro",
      "price": 999.99
    }
  ]
}

This structure provides useful metadata and makes pagination straightforward for frontend developers.

Final Thoughts

A great REST API is more than just a collection of endpoints—it's a contract between your application and its consumers.

By using meaningful resource names, returning the correct status codes, validating input, maintaining consistent response structures, versioning your API, and providing clear documentation, you'll create APIs that are easier to use, easier to maintain, and more enjoyable for other developers to integrate with.

What REST API best practice has made the biggest difference in your projects? I'd love to hear your thoughts and experiences in the comments.

Explore More Free Developer Tools

If you frequently work with APIs, JSON, encoding, formatting, or debugging, you might find ToolBenchApp useful:

👉 https://toolbenchapp.com/

ToolBenchApp is a growing collection of free browser-based developer tools built to simplify everyday development tasks. From JSON formatting and validation to JWT decoding, text comparison, UUID generation, and other handy utilities, the goal is to help developers spend less time on repetitive tasks and more time building great software.

I'm continuously adding new tools based on community feedback, so if there's something you'd like to see, feel free to share your ideas!

10 JSON Mistakes That Break APIs (And How to Avoid Them)

ToolBench — Tue, 28 Jul 2026 12:26:20 +0000

JSON has become the standard format for exchanging data between applications. Whether you're building REST APIs, integrating third-party services, or working with frontend frameworks like React, Angular, or Vue, you'll interact with JSON almost every day.

Despite its simple syntax, even small mistakes in JSON can cause API requests to fail, configuration files to break, or applications to crash.

In this article, we'll go through 10 common JSON mistakes developers make and how to avoid them.

1. Forgetting Double Quotes Around Property Names

JSON requires every property name to be enclosed in double quotes.

❌ Incorrect

{
  name: "John",
  age: 28
}

✅ Correct

{
  "name": "John",
  "age": 28
}

Many developers accidentally write JavaScript object syntax instead of valid JSON.

2. Using Single Quotes

JSON only supports double quotes.

❌ Incorrect

{
  'name': 'John'
}

✅ Correct

{
  "name": "John"
}

3. Leaving a Trailing Comma

Trailing commas are common in JavaScript but are invalid in JSON.

❌ Incorrect

{
  "name": "John",
  "age": 28,
}

✅ Correct

{
  "name": "John",
  "age": 28
}

4. Missing Commas Between Properties

A missing comma is one of the most common reasons JSON validation fails.

❌ Incorrect

{
  "name": "John"
  "age": 28
}

✅ Correct

{
  "name": "John",
  "age": 28
}

5. Invalid Data Types

JSON supports only these data types:

String
Number
Boolean
Object
Array
null

Trying to include unsupported values like functions or undefined makes the JSON invalid.

❌ Incorrect

{
  "name": "John",
  "value": undefined
}

Instead, use:

{
  "name": "John",
  "value": null
}

6. Sending Numbers as Strings

Sometimes APIs expect a number, but developers accidentally send a string.

❌

{
  "age": "30"
}

✅

{
  "age": 30
}

This small mistake can cause validation errors on the server.

7. Invalid Nested Objects

Complex JSON often becomes difficult to read.

Instead of writing everything on one line:

{"user":{"address":{"city":"London","zip":"12345"}}}

Format it properly:

{
  "user": {
    "address": {
      "city": "London",
      "zip": "12345"
    }
  }
}

Readable JSON is much easier to debug.

8. Mixing Arrays and Objects

Arrays use square brackets.

Objects use curly braces.

Incorrect structure:

{
  "skills": {
    "Java",
    "C#"
  }
}

Correct structure:

{
  "skills": [
    "Java",
    "C#"
  ]
}

9. Not Validating JSON Before Sending It

Many API errors happen because invalid JSON is sent to the server.

Before calling an API:

Validate your JSON.
Format it for readability.
Check the data types.
Ensure all required fields exist.

This simple habit can save a lot of debugging time.

10. Ignoring API Documentation

Even if your JSON is valid, it may still fail if it doesn't match the API's expected structure.

For example:

Expected:

{
  "email": "john@example.com"
}

Sent:

{
  "emailAddress": "john@example.com"
}

The JSON is valid, but the API doesn't recognize the property.

Always compare your request with the API documentation.

Quick Checklist Before Sending JSON

✅ Property names use double quotes

✅ No trailing commas

✅ Valid data types

✅ Arrays use []

✅ Objects use {}

✅ Required properties are included

✅ Numbers are not sent as strings

✅ JSON is validated

Final Thoughts

Most JSON-related issues aren't caused by complex bugs—they're caused by tiny syntax mistakes that are easy to overlook.

By validating your JSON, formatting it for readability, and following API documentation carefully, you can avoid hours of unnecessary debugging.

What JSON mistake has cost you the most time? Share your experience in the comments—your story might help another developer avoid the same issue.

## Explore More Developer Tools

If you regularly work with JSON, APIs, formatting, encoding, decoding, or data conversion, check out ToolBenchApp:

👉 https://toolbenchapp.com/

ToolBenchApp is a growing collection of free browser-based developer tools designed to simplify everyday development tasks. Whether you need to format JSON, decode JWTs, compare text, generate UUIDs, or convert data between formats, the goal is simple: help developers save time and stay focused on building great software.

If there's a tool you'd like to see added, I'd love to hear your suggestions!

Understanding HTTP Status Codes Every Developer Should Know (With Real API Examples)

ToolBench — Mon, 13 Jul 2026 12:46:28 +0000

Understanding HTTP Status Codes Every Developer Should Know (With Real API Examples)

If you've ever integrated an API, you've almost certainly encountered responses like 200 OK, 404 Not Found, or 500 Internal Server Error.

At first, these numbers can seem confusing. But once you understand what each status code means, debugging becomes much easier.

In this article, we'll explore the most common HTTP status codes, when they're returned, and how to respond to them as a developer.

What Are HTTP Status Codes?

HTTP status codes are standardized responses sent by a server after it receives a request from a client (such as a web browser, mobile app, or frontend application).

Every response contains two important pieces of information:

The status code
The response body (if any)

Example:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "message": "User retrieved successfully"
}

The status code immediately tells you whether the request succeeded or failed.

The Five Categories of Status Codes

HTTP status codes are grouped into five categories.

Range	Meaning
1xx	Informational
2xx	Success
3xx	Redirection
4xx	Client Errors
5xx	Server Errors

Let's look at the ones you'll encounter most often.

200 OK

This is the response every developer wants to see.

It means the request was successful and the server returned the expected data.

Example:

GET /api/users/15

Response

200 OK

Response body

{
  "id": 15,
  "name": "John",
  "email": "john@example.com"
}

Use this when:

Fetching users
Loading products
Retrieving reports
Reading configuration data

201 Created

Returned after successfully creating a new resource.

Example:

POST /api/users

Response

201 Created

{
    "id": 101,
    "name": "Alice"
}

Typical use cases:

User registration
Creating blog posts
Adding products
Creating orders

204 No Content

Sometimes an operation succeeds but doesn't need to return any data.

Example:

DELETE /api/users/15

Response

204 No Content

This is commonly used after successful delete operations.

400 Bad Request

The server couldn't process the request because it was invalid.

Common reasons:

Missing required fields
Invalid JSON
Incorrect data types
Validation failures

Example:

{
    "email":"not-an-email"
}

Possible response

{
    "error":"Invalid email address"
}

Always validate user input before sending requests.

401 Unauthorized

Authentication is required.

Typical causes:

Missing JWT token
Expired access token
Invalid credentials

Example:

Authorization header missing

Response

401 Unauthorized

403 Forbidden

The user is authenticated but doesn't have permission.

Example:

A normal user tries to access an admin endpoint.

403 Forbidden

Think of it like this:

401 = "Who are you?"
403 = "I know who you are, but you're not allowed."

404 Not Found

Probably the most recognized status code.

It means the requested resource doesn't exist.

Example

GET /api/products/99999

Response

404 Not Found

Possible reasons:

Wrong URL
Deleted resource
Incorrect API version
Typo in endpoint

409 Conflict

Returned when a request conflicts with existing data.

Example:

Creating a user with an email address that's already registered.

{
    "email":"john@example.com"
}

Response

409 Conflict

422 Unprocessable Entity

The request is syntactically correct, but the provided data doesn't satisfy business rules.

Example:

{
    "age": -5
}

Response

{
    "error":"Age must be greater than zero."
}

Many modern REST APIs use this status code for validation errors.

500 Internal Server Error

This indicates something went wrong on the server.

Examples include:

Null reference exceptions
Database connection failures
Unexpected exceptions
Configuration issues

Example response

500 Internal Server Error

If you're building APIs, avoid exposing stack traces to clients. Instead, log the error internally and return a meaningful message.

503 Service Unavailable

The server is temporarily unavailable.

Possible reasons:

Scheduled maintenance
High traffic
Database outage
Dependency failure

Unlike a 500 error, a 503 often indicates the service may recover shortly.

Quick Reference

Status	Meaning
200	Success
201	Resource created
204	Success, no response body
400	Bad request
401	Authentication required
403	Permission denied
404	Resource not found
409	Conflict
422	Validation/business rule failure
500	Internal server error
503	Service temporarily unavailable

Best Practices

Use the correct status code instead of always returning 200.
Return clear, consistent error messages.
Validate input before processing requests.
Log server-side exceptions for troubleshooting.
Avoid exposing sensitive implementation details in error responses.
Document expected status codes in your API documentation.

Final Thoughts

Understanding HTTP status codes is one of the simplest ways to become more effective at debugging APIs and building reliable applications. Choosing the right response code also makes your APIs easier for other developers to integrate with and troubleshoot.

Which HTTP status code do you encounter most often in your day-to-day development? Share your experience in the comments—I’d love to hear your stories and debugging tips.

Explore More Developer Tools

If you regularly work with APIs, JSON, encoding, formatting, or debugging, check out ToolBenchApp: https://toolbenchapp.com/.

It's a growing collection of free browser-based developer tools designed to simplify everyday development tasks—whether you're formatting JSON, validating data, decoding JWTs, comparing text, or converting common formats. If you have ideas for a tool that would make your workflow easier, I'd love to hear your suggestions.

DEV Community: ToolBench

ASP.NET Core Output Caching: How to Make Web APIs Faster in .NET

ASP.NET Core Output Caching: How to Make Web APIs Faster in .NET

What Is Output Caching?

Output Caching vs Response Caching

Response Caching

Output Caching

1. Add Output Caching

2. Cache an API Endpoint

3. Why This Can Improve Performance

4. Configure a Default Cache Policy

5. Cache by Query String

6. Cache by Header

7. Be Careful With User-Specific Data

8. Public vs Personalized Endpoints

9. Cache Expiration

10. Cache Invalidation

11. Evict Cached Responses

12. Cache Only What Actually Benefits From Caching

13. Output Caching and Database Performance

14. Output Caching and External APIs

15. Don't Cache Sensitive Responses

16. Output Caching in a Multi-Instance Application

17. Cache-Control Is Not the Same Thing

18. Measure Before and After

19. Common Output Caching Mistakes

Mistake 1: Caching User-Specific Data

Mistake 2: Cache Duration Is Too Long

Mistake 3: Cache Duration Is Too Short

Mistake 4: Caching Everything

Mistake 5: Ignoring Cache Invalidation

Mistake 6: Not Measuring Performance

A Practical Example

Production Checklist

Final Thoughts

A Small Developer Tool for Everyday Development

ASP.NET Core Background Services: How to Run Reliable Background Tasks in .NET

ASP.NET Core Background Services: How to Run Reliable Background Tasks in .NET

Why Do We Need Background Services?

BackgroundService vs IHostedService

IHostedService

BackgroundService

1. Create Your First Background Service

2. Register the Background Service

3. Run a Task on a Schedule

4. Why CancellationToken Matters

5. Don't Block the Thread

6. Using Dependency Injection in Background Services

7. BackgroundService and Entity Framework Core

8. Process Work from a Queue

9. Example: Queue an Email

10. Important: In-Memory Queues Have a Limitation

11. Background Services Don't Automatically Scale Like API Requests

12. Make Background Operations Idempotent

13. Handle Exceptions Carefully

14. Add Useful Logging

15. When Should You Use a BackgroundService?

A Practical Architecture

BackgroundService Checklist

Final Thoughts

A Small Developer Tool for Everyday .NET Work

ASP.NET Core API Performance: 12 Practical Ways to Make Your Web API Faster

1. Use Async APIs Properly

Avoid this

2. Don't Return More Data Than You Need

General rule

3. Use Pagination

4. Use AsNoTracking() for Read-Only Queries

Good use cases

5. Avoid N+1 Queries

6. Add Database Indexes

7. Use Response Caching Where Appropriate

Good candidates for caching

8. Compress HTTP Responses

9. Avoid Unnecessary Serialization

10. Use HttpClientFactory

11. Use Cancellation Tokens

12. Measure Before Optimizing

Putting the Techniques Together

A Simple ASP.NET Core Performance Checklist

4. Use `AsNoTracking()` for Read-Only Queries

10. Use `HttpClientFactory`

3. Use `AsNoTracking()` for Read-Only Queries

6. Be Careful With `Include()`

7. Prefer Projection with `Select()`

9. Don't Call `ToList()` Too Early

❌ Filtering After `ToList()`

What is `AsNoTracking()`?

Why is `Select()` useful for performance?

Why is `ToList()` important?

Should I always use `AsNoTracking()`?

Should I avoid `Include()`?

Is `Select()` always faster?

3. `Use()` vs `Run()` vs `Map()`

`Use()`

`Run()`

`Map()`