DEV Community: dorinandreidragan

🔥 Missed Microsoft Build 2025? Catch the Recorded Sessions! 🎥🚀

dorinandreidragan — Fri, 23 May 2025 18:22:55 +0000

Didn’t watch everything live? The Microsoft Developer YouTube channel has plenty of recorded sessions—and more may be added!

🎬 Check Out These Playlists Packed with Insights:

🎙️ Popular Speakers to Check Out:

Scott Hanselman

Burke Holland

Pierce Boggan

Agent Mode in Action: AI Coding with Vibe and Spec-Driven Flows | BRK102

Not all sessions are available, but there’s plenty to explore! 🚀

If You Can’t Observe It 🔭, You Can’t Operate It

dorinandreidragan — Wed, 14 May 2025 14:16:28 +0000

This is episode 4 of A Hands-On Guide to Modern Software Development series.

Modern applications are like living systems — always running, always changing. And if you can't see what’s happening inside them, you're flying blind.

In this episode, we’ll integrate OpenTelemetry with our ASP.NET minimal API and trace everything from database calls to cache hits — all visualized in Jaeger. We’ll also learn how to spot inefficiencies, validate cache behavior, and instrument our code for insights.

Why Observability?

Here’s why:

Traces help you understand how requests flow across services (and through layers like DB, cache, etc.).
Metrics provide high-level health signals like request rates and error counts.
Logs give you contextual breadcrumbs when something breaks.

In this episode, we’ll focus on distributed tracing using OpenTelemetry + Jaeger.

Why OpenTelemetry

Standardized: One format for traces, metrics, and logs.
Vendor-neutral: Export to Jaeger, Prometheus, and others.
Well-supported: Actively developed, .NET-friendly.
Instrument once: Works across libraries and runtimes.

Our Goal

We want to evolve our architecture from this:

To this:

The key additions:

OpenTelemetry SDK: Adds instrumentation to our app.
OpenTelemetry Collector: Gathers telemetry and forwards it to backends.
Jaeger: Visualizes trace data in a web UI.

Step-by-Step Setup

Let’s break this down:

1. Configure OpenTelemetry Collector

Create src/telemetry/otel-collector.yml:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: otel-collector:4317
      http:
        endpoint: otel-collector:4318

exporters:
  otlp:
    endpoint: "jaeger:4317"
    tls:
      insecure: true

processors:
  batch:

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

This sets up an OTLP pipeline to receive traces and forward them to Jaeger:

otel-collector: Container name used for internal Docker networking.
jaeger: Same — used as hostname inside the Docker network.
tls.insecure: true: Disables TLS checks (safe for local development).

2. Update `docker-compose.yml`

Add two new services:

jaeger:
  image: jaegertracing/jaeger:2.5.0
  container_name: jaeger
  ports:
    - "16686:16686" # Jaeger UI

otel-collector:
  image: ghcr.io/open-telemetry/opentelemetry-collector-releases/opentelemetry-collector-contrib:0.125.0
  container_name: otel_collector
  command: ["--config=/etc/otel-collector.yml"]
  volumes:
    - ./src/telemetry/otel-collector.yml:/etc/otel-collector.yml
  ports:
    - "4317:4317"
  depends_on:
    jaeger:
      condition: service_started

Then run:

docker-compose up -d

Explanations:

otel-collector: Reads config from the mounted file and listens on port 4317 for OTLP traces from the web API.
jaeger: Exposes port 16686 so you can access the Jaeger UI at localhost.

Instrument the API with OpenTelemetry

These packages need to be added to the BooksInventory.WebApi project:

dotnet add package OpenTelemetry.Extensions.Hosting --version 1.12.0
dotnet add package OpenTelemetry.Instrumentation.AspNetCore --version 1.12.0
dotnet add package Npgsql.OpenTelemetry --version 9.0.3

dotnet add package OpenTelemetry.Instrumentation.Console --version 1.12.0
dotnet add package OpenTelemetry.Instrumentation.OpenTelemetryProtocol --version 1.12.0

Now modify Program.cs:

// after service registrations

var service = ResourceBuilder
    .CreateDefault()
    .AddService("BooksInventory.WebApi")
    .AddAttributes(
    [
        new("service.name", "BooksInventory.WebApi"),
        new("service.namespace", "BooksInventory.WebApi"),
    ]);

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .SetResourceBuilder(service)
        .AddAspNetCoreInstrumentation()
        .AddNpgsql()
        .AddOtlpExporter()
        .AddConsoleExporter());

// before this code
var app = builder.Build();

Let’s break it down:

Resource Definition: "BooksInventory.WebApi" provides trace context, identifying spans in Jaeger.
HTTP Tracing: AddAspNetCoreInstrumentation() tracks requests, latency, and status codes.
Database Tracing: AddNpgsql() captures PostgreSQL queries and connection details.
Trace Export: AddOtlpExporter() sends traces via OTLP protocol to the collector.
Local Debugging: AddConsoleExporter() logs traces to the console for quick validation.

Now make sure you initialize the database and start the web API:

dotnet ef database update --project src/BooksInventory.WebApi/BooksInventory.WebApi.csproj
dotnet run --project src/BooksInventory.WebApi/BooksInventory.WebApi.csproj

✅ Tip: Execute some requests to see traces printed in the console. This helps you verify instrumentation before wiring up Jaeger.

# ------------------------------------
# Span from PostgreSQL instrumentation
# ------------------------------------
Activity.TraceId:            a867a3ea03726e71f6fe56b1e8a421d1
Activity.SpanId:             103bacdf7a8e1da0
Activity.Tags:
    db.statement: INSERT INTO "Books" ("Author", "ISBN", "Title")
VALUES (@p0, @p1, @p2)
RETURNING "Id";
    db.system: postgresql
    db.connection_string: Host=localhost;Port=5432;Database=books_inventory;Username=user
    db.user: user
    db.name: books_inventory

# ------------------------------------
# Span from AspNetCore instrumentation
# ------------------------------------
Activity.TraceId:            a867a3ea03726e71f6fe56b1e8a421d1
Activity.SpanId:             1e5c7b4469f16e70
Activity.Tags:
    server.address: localhost
    server.port: 5000
    http.request.method: POST
    url.scheme: http
    url.path: /addBook

This proves that tracing is working — we see both HTTP-level and database-level spans captured and logged.

Visualize Traces in Jaeger

Visit http://localhost:16686 — you’ll land on the Jaeger UI. Once traces are generated, you can inspect them using Jaeger’s UI. Below is an example of how it looks in action:

Execute the following REST operations to validate cache behavior:

POST /addBook → Inserts a new book into the DB.
GET /books/{id} (first request) → Cache miss, fetches from DB.
GET /books/{id} (second request) → Cache hit, retrieves from Redis (no DB call).

This confirms caching is working — first retrieval queries the DB, while subsequent requests serve data directly from cache.

Debugging with Tracing: Real-World Benefits

⚠️ Found: Inefficient DELETE

Jaeger reveals that our DELETE endpoint was doing two DB round-trips:

Looking at the code for delete in Program.cs:

app.MapDelete("/books/{id}", async (int id, BooksInventoryDbContext db, HybridCache cache) =>
{
    // SELECT: 1st roundtrip to db.
    var book = await db.Books.FindAsync(id);
    if (book is null)
    {
        return Results.NotFound(new { Message = "Book not found", BookId = id });
    }

    // DELETE: 2nd roundtrip to db.
    db.Books.Remove(book);
    await db.SaveChangesAsync();

    // Remove the entry from the cache.
    await cache.RemoveAsync($"book_{id}");

    return Results.NoContent();
});

👉 We can do better:

app.MapDelete("/books/{id}", async (int id, BooksInventoryDbContext db, HybridCache cache) =>
{
    // DELETE: only one roundtrip to db.
    var rowsAffected = await db.Books
        .Where(b => b.Id == id)
        .ExecuteDeleteAsync();

    if (rowsAffected == 0)
    {
        return Results.NotFound(new { Message = "Book not found", BookId = id });
    }

    // Remove the entry from the cache.
    await cache.RemoveAsync($"book_{id}");

    return Results.NoContent();
});

Let's check the trace:

Yes! The deletion now requires only one database call—a clear optimization.

Bonus: Cache Behavior Verification with Redis CLI

Want to confirm your cache is working?

Check Redis keys after a GET request:

docker exec -it redis redis-cli KEYS "*"

1) "BooksInventoryCache:book_3"
2) "BooksInventoryCache:book_2"

Watch Redis keyspace notifications in real-time:

# Enable keyspace notifications
docker exec -it redis redis-cli CONFIG SET notify-keyspace-events KEA

# Subscribe to a key's activity
docker exec -it redis redis-cli PSUBSCRIBE "__keyspace@0__:BooksInventoryCache:book_3"

You’ll first see an output like this — it confirms that you're now listening to changes on a key (e.g. PUT, DELETE):

Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "__keyspace@0__:BooksInventoryCache:book_3"
3) (integer) 1

Now trigger a PUT or DELETE, and you’ll see events like:

1) "pmessage"
2) "__keyspace@0__:BooksInventoryCache:book_3"
3) "__keyspace@0__:BooksInventoryCache:book_3"
4) "hset"
1) "pmessage"
2) "__keyspace@0__:BooksInventoryCache:book_3"
3) "__keyspace@0__:BooksInventoryCache:book_3"
4) "expire"

This confirms your cache is being updated live — and gives you deep visibility into cache dynamics.

Beyond Tracing: Expanding Observability

Tracing is just the beginning—full observability requires metrics, logs, and visualization:

Signal	Backend	Purpose
Traces	Jaeger	Track request flow & latency
Metrics	Prometheus	Monitor service performance
Logs	OpenSearch	Debug incidents & errors
🔭 Views	Grafana	Unified observability dashboard

Next Steps

HybridCache Instrumentation
- Extend HybridCache with OpenTelemetry for better traceability.
FusionCache Integration
- Leverage FusionCache for built-in OpenTelemetry support.
Expand Monitoring
- Metrics → Add Prometheus.
- Logs → Integrate OpenSearch.
- Dashboards → Visualize everything in Grafana.
Identify Race Conditions
- Use Locust load tests + tracing to detect cache-DB sync issues.
Observability in Tests
- Validate tracing in integration tests using Testcontainers + OpenTelemetry.

Observability is not just about seeing—but about understanding.

If You Can’t Observe It 🔭, You Can’t Operate It.

Check out the full code and episodes in the GitHub repository.

HybridCache & Redis: Cache Smarter, Not Harder for ASP.NET APIs 🚀

dorinandreidragan — Thu, 01 May 2025 10:02:09 +0000

Cache Smarter, Not Harder

If your ASP.NET API slows down under frequent database queries, smarter caching can make all the difference. In this article, we'll show you how to integrate HybridCache and Redis to boost performance efficiently. You'll learn how a two-tier caching strategy—a fast in-memory layer complemented by a distributed Redis cache—can cut down on latency and offload your database. We'll walk through the code changes and testing improvements that help you cache smarter, not harder.

This article builds on the previous two articles where we covered testing minimal Web APIs and adding PostgreSQL with Testcontainers.

HybridCache: A Smarter Approach to API Caching

HybridCache bridges the gaps between IMemoryCache and IDistributedCache by offering a unified API for both in-process and out-of-process caching. It combines a fast, local in-memory cache with a durable distributed cache—in our project, powered by Redis—giving you the best of both worlds.

Key Benefits:

Unified API: Write caching logic once to work with both local memory and a durable distributed cache.
Built-In Stampede Protection: Prevents multiple simultaneous cache misses from triggering duplicate, expensive operations.
Configurable Serialization: Uses System.Text.Json by default, with easy options to switch to other serializers if needed.
Simplified Code: Replace complex caching patterns with a single, elegant GetOrCreateAsync method.

For example, instead of manually managing cache keys, serialization, and concurrency, you simply write:

return await cache.GetOrCreateAsync(
    $"someinfo:{name}:{id}",
    async cancel => await SomeExpensiveOperationAsync(name, id, cancel),
    token: token
);

This streamlined approach helps you cache smarter, not harder, making your ASP.NET API more responsive and easier to maintain. See HybridCache library in ASP.NET Core.

Upgraded API Endpoints for Smart Caching

Before diving into the code, here’s a quick overview of our caching strategy for each endpoint:

GET Endpoints:

These endpoints are read-heavy, so caching saves the cost of frequent database queries. When a book is requested, we first check the in-memory cache for lightning-fast results. In case of an application restart (which clears the in-memory cache), our durable Redis layer (used as a distributed cache) ensures data persistence. This two-tier (HybridCache) approach improves responsiveness without sacrificing consistency.
DELETE Endpoints:

Deleting data requires us to invalidate any cached copies. This ensures that once a book is removed from the database, no stale data is served from either cache layer—even in a distributed environment.
PUT Endpoints:

Update operations need to synchronize both the database and cache. When a book is updated, the cache should also reflect these changes (either by refreshing or invalidating the stale data), so that future GET requests always see the most recent version.
POST and Search/Get-All Endpoints:

For POST requests, we avoid caching because creating new records introduces consistency challenges in distributed caches. Similarly, for search and get-all endpoints, caching dynamic query results (especially when pagination is involved) can lead to stale or inconsistent data. Instead, we rely on pagination to manage load and ensure freshness.

Now, let’s see how we implemented these strategies in our code:

Prerequisites for Caching

Get the Libraries

Install the required NuGet packages.

dotnet add package Microsoft.Extensions.Caching.Hybrid --version 9.4.0
dotnet add package Microsoft.Extensions.Caching.StackExchangeRedis --version 9.0.2

Register the Services

In Program.cs add the services to the dependency injection (DI) container:

// Add StackExchangeRedisCache service for Redis
builder.Services.AddStackExchangeRedisCache(options =>
{
    options.Configuration = builder.Configuration.GetConnectionString("RedisConnection");
    options.InstanceName = "BooksInventoryCache:";
});

// Add HybridCache service
builder.Services.AddHybridCache();

GET Endpoint: Fast and Durable Retrieval

For GET requests, we cache the book data with HybridCache. On a cache miss, the data is fetched from PostgreSQL, then stored in both the in-memory and Redis layers (used for durability in distributed scenarios).

app.MapGet("/books/{id}", async (int id, BooksInventoryDbContext db, HybridCache cache) =>
{
    var book = await cache.GetOrCreateAsync($"book_{id}", async (cancellationToken) =>
    {
        return await db.Books.FindAsync([id], cancellationToken);
    });

    return book is not null
        ? Results.Ok(book)
        : Results.NotFound(new { Message = "Book not found", BookId = id });
});

Explanation:

Cache Miss: The first request fetches the book from the database and then caches it.

Cache Hit: Subsequent requests serve the book data from the much faster in-memory cache—falling back to Redis if the app has restarted.

DELETE Endpoint: Ensuring Consistency by Invalidation

When deleting a book, it's crucial to remove its cached version to prevent serving stale data later on.

app.MapDelete("/books/{id}", async (int id, BooksInventoryDbContext db, HybridCache cache) =>
{
    var book = await db.Books.FindAsync(id);
    if (book is null)
    {
        return Results.NotFound(new { Message = "Book not found", BookId = id });
    }

    db.Books.Remove(book);
    await db.SaveChangesAsync();

    // Remove the entry from the cache
    await cache.RemoveAsync($"book_{id}");

    return Results.NoContent();
});

Explanation:

Once the book is deleted from the database, we explicitly remove the cache entry from Redis. This helps ensure that even in a distributed scenario—with multiple app instances—the cache remains consistent.

PUT Endpoint: Updating and Refreshing the Cache

When updating a book, we make sure the cache reflects the latest changes by either refreshing or invalidating the cached value.

app.MapPut("/books/{id}", async (int id, AddBookRequest request, BooksInventoryDbContext db, HybridCache cache) =>
{
    var book = await db.Books.AsNoTracking().FirstOrDefaultAsync(b => b.Id == id);
    if (book is null)
    {
        return Results.NotFound(new { Message = "Book not found", BookId = id });
    }

    book = book with
    {
        Title = request.Title,
        Author = request.Author,
        ISBN = request.ISBN
    };

    db.Books.Update(book);
    await db.SaveChangesAsync();

    // Update the cache
    await cache.SetAsync($"book_{id}", book);

    return Results.Ok(book);
});

Explanation:

After successfully updating the record, we update the existing cache entry so that the next GET will fetch updated information.

POST & Search/Get-All Endpoints: Caching Exclusions

For POST requests, we avoid caching new entries because:

The creation process might involve multiple distributed components.
Ensuring immediate consistency is challenging.

Similarly, Search and Get-All endpoints aren’t cached due to:

The dynamic nature of query results.
The added complexity and risk of stale data when working with numerous filters and pagination.

Instead, we rely on efficient pagination to limit data volume, ensuring a balanced load without the pitfalls of caching complex queries.

Below is the updated section that covers our testing approach in depth, from containerized fixtures to automated and manual cache verification. This revised piece explains how we integrated Testcontainers for Redis, outlines our composite fixture setup (including the individual PostgreSql and Redis fixtures), and highlights the cool benefits of verifying two-level caching with HybridCache.

Enhanced Testing with Testcontainers and Automated Validation

To ensure our caching strategy functions as expected in a real-world scenario, we containerized our dependencies and wrote automated tests to inspect every caching layer. Here’s how we did it:

Containerized Testing with Composite Fixtures

We use a composite fixture to spin up both PostgreSQL and Redis containers automatically. This setup uses Testcontainers to simulate a production-like environment—even for the distributed cache.

1. Adding the Redis Testcontainer Package:

To add Redis container support for integration tests, we installed the following NuGet package:

dotnet add package Testcontainers.Redis --version 4.4.0

2. Our Fixture Composition:

Each container is encapsulated in its own fixture:

PostgreSqlContainerFixture:

Configures and starts a PostgreSQL container using the postgres:15-alpine image.
RedisContainerFixture:

Configures and starts a Redis container using the redis:7-alpine image.
CompositeFixture:

Combines these fixtures into one:

  public class CompositeFixture : IAsyncLifetime
  {
    public PostgreSqlContainerFixture Postgres { get; private set; }
    public RedisContainerFixture Redis { get; private set; }

    public CompositeFixture()
    {
        Postgres = new PostgreSqlContainerFixture();
        Redis = new RedisContainerFixture();
    }

    public async Task InitializeAsync()
    {
        await Task.WhenAll(
            Postgres.InitializeAsync(),
            Redis.InitializeAsync()
        );
    }

    public async Task DisposeAsync()
    {
        await Task.WhenAll(
            Postgres.DisposeAsync(),
            Redis.DisposeAsync()
        );
    }
  }

3. CustomWebApplicationFactory and Test Injection:

Our CustomWebApplicationFactory now accepts the composite fixture as a parameter. This allows dependency injection of both containers to configure connection strings and services seamlessly.

For example, the constructor of our integration tests shows the composite fixture being injected:

[Collection(nameof(IntegrationTestsCollection))]
public class BooksInventoryCacheTests : IAsyncLifetime
{

    private readonly CustomWebApplicationFactory factory;
    private readonly HttpClient client;
    private readonly BooksInventoryDbContext db;
    private readonly IDistributedCache redis;
    private readonly CompositeFixture fixture;

    public BooksInventoryCacheTests(CompositeFixture fixture)
    {
        this.fixture = fixture;
        this.factory = new CustomWebApplicationFactory(fixture);
        this.client = this.factory.CreateClient();

        // Create a scope to retrieve scoped instances of DB context and Redis cache
        // for direct database and cache interactions during tests
        var scope = this.factory.Services.CreateScope();
        this.db = scope.ServiceProvider.GetRequiredService<BooksInventoryDbContext>();
        this.redis = scope.ServiceProvider.GetRequiredService<IDistributedCache>();
    }
    // ...
}

This setup, along with similar implementations for PostgreSqlContainerFixture and RedisContainerFixture, ensures our tests run in a consistent and realistic environment.

Automated Cache Behavior Verification

It's a super cool part of our implementation—by verifying HybridCache’s two-level caching behavior, we get intimate visibility into its inner guts.

BooksInventoryCacheTests

In-Memory Cache Verification: The test simulates a warmup (fetching a book for the first time) that stores a value in the in-memory cache. Then, we deliberately update the underlying data in PostgreSQL and Redis to see if the in-memory layer still returns the original data, confirming that the in-memory cache is effective.

  [Fact]
  public async Task InMemoryCacheHit_AfterWarmup()
  {
      var book = new Book
      {
          Title = "t1",
          Author = "a1",
          ISBN = "isbn1"
      };
      db.Books.Add(book);
      await db.SaveChangesAsync();

      // Cache warm-up (should populate both in-memory and Redis cache)
      await this.client.GetAsync($"/books/{book.Id}");

      // Mutate db and Redis to differ from the in-memory cache.
      await db.UpdateBookAsync(book with { Title = "t1_db_updated" });
      await redis.UpdateBookAsync(book with { Title = "t1_redis_updated" });

      // Request the book again (should return stale value from in-memory cache).
      var response = await this.client.GetAsync($"/books/{book.Id}");

      // Assert
      var bookFromInMemory = await response.DeserializeAsync<Book>();
      bookFromInMemory!.Title.Should().Be("t1");

      Book bookFromDb = await db.GetByIdAsync(book.Id);
      bookFromDb!.Title.Should().Be("t1_db_updated");

      var json = await redis.GetStringAsync(book.Id.GetCacheKey());
      json.Should().Contain("t1_redis_updated");
  }

Redis Cache Verification (Durability):To test Redis involvement, we simulate an application restart by disposing our factory. The in-memory cache is lost, so the following GET request should fall back on Redis, returning the cached (old) value even after the database update.

  [Fact]
  public async Task RedisCacheHit_AfterWarmUp()
  {
      var book = new Book
      {
          Title = "t1",
          Author = "a1",
          ISBN = "isbn1"
      };
      db.Books.Add(book);
      await db.SaveChangesAsync();

      // Cache warm-up (should populate both in-memory and Redis cache)
      await this.client.GetAsync($"/books/{book.Id}");

      // App restart (should clear the in-memory cache)
      this.factory.Dispose();
      using var newFactory = new CustomWebApplicationFactory(this.fixture);
      using var newClient = newFactory.CreateClient();

      // Mutate db to differ from redis cache.
      await db.UpdateBookAsync(book with { Title = "t1_db_updated" });

      // Request the book again (should return stale value from redis cache).
      var response = await newClient.GetAsync($"/books/{book.Id}");

      // Assert
      var bookFromRedis = await response.DeserializeAsync<Book>();
      bookFromRedis!.Title.Should().Be("t1");
      Book bookFromDb = await db.GetByIdAsync(book.Id);
      bookFromDb!.Title.Should().Be("t1_db_updated");
  }

BooksInventoryTests

Other tests (like adding, updating, and deleting books) also interact with the caching layers indirectly by verifying the API responses. They ensure that our endpoints work seamlessly with HybridCache and the underlying containers, confirming both data consistency and performance gains.

Manual Cache Verification Using a REST Client 🖥️

Add Redis to our development environment. Update the docker-compose.yml:

services:
  # ... existing PostgreSQL service ...
  redis:
    image: redis:7.0-alpine
    container_name: books_inventory_redis
    ports:
      - "6379:6379"
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5
    volumes:
      - redis-data:/data

volumes:
  redis-data:

Start the infrastructure:

   docker-compose up -d

Update database:

   dotnet ef database update --project src/BooksInventory.WebApi/BooksInventory.WebApi.csproj

Start the Web API:

   dotnet run --project src/BooksInventory.WebApi/BooksInventory.WebApi.csproj

Inspect caching behavior manually:

Add a new book via the /addBook endpoint. The log should look like this:

  info: Microsoft.EntityFrameworkCore.Database.Command[20101]
      Executed DbCommand (10ms) [Parameters=[@p0='?', @p1='?', @p2='?'], CommandType='Text', CommandTimeout='30']
      INSERT INTO "Books" ("Author", "ISBN", "Title")
      VALUES (@p0, @p1, @p2)
      RETURNING "Id";

First GET Request: Should log a database SELECT, indicating a cache miss. The log should look like this:

  info: Microsoft.EntityFrameworkCore.Database.Command[20101]
      Executed DbCommand (1ms) [Parameters=[@__p_0='?' (DbType = Int32)], CommandType='Text', CommandTimeout='30']
      SELECT b."Id", b."Author", b."ISBN", b."Title"
      FROM "Books" AS b
      WHERE b."Id" = @__p_0
      LIMIT 1

Subsequent GET Requests: No SELECT log should appear, confirming that the response is served from cache.

Conclusion & Next Steps 🎯

In this article, we explored how to boost your ASP.NET API's performance by leveraging HybridCache with Redis. We walked through our two-level caching strategy, updated API endpoints for fast retrieval and consistency, and demonstrated our robust, containerized testing approach. By using HybridCache, you get a unified caching API with built-in stampede protection and configurable serialization—making it far easier to cache smarter, not harder.

Next up: Observability! We'll integrate OpenTelemetry to monitor cache hits, misses, and performance.

Ready to cache smarter, not harder 🚀? Clone the GitHub repository, try it out, and share your experience! Did you find interesting ways to use HybridCache? I'd love to hear about them in the comments or in a GitHub discussion.

VSCode + MCP: Chat with Your API using GitHub Copilot

dorinandreidragan — Tue, 15 Apr 2025 12:36:25 +0000

TL;DR

In this article, you’ll learn how to:

Build a FastAPI Books API
Expose it with MCP
Chat with it in VS Code using GitHub Copilot Agent Mode
Bonus: Extend into AI-powered interactions with Ollama + OpenWebUI

Introduction

Why would you ever want to chat with your API in VS Code using MCP?

Because you can! 💪😂

And honestly why not? The possibilities are endless.

This article walks you through setting up a simple REST API, publishing it with MCP, and using GitHub Copilot Chat in Agent Mode for interaction. And for those curious minds, there’s a bonus setup to push the boundaries even further.

What is MCP, and Why Use It?

What is MCP? It’s like the USB-C of AI — standardizing how apps connect to LLMs. Though sadly, it doesn't charge your laptop... yet.

Want the nerdy details? Dive into the official docs — they’re surprisingly readable.

Setting Up the Environment

Let’s harness uv, the "Usain (V)Bolt of Python package managers", to set up your project. (Seriously, try install something. It's done before you finish typing).

Initialize your project:

   uv init

Add dependencies:

   uv add fastapi fastapi-mcp mcp pydantic requests uvicorn

Configure your environment:

Create a config.py file:

   WEB_API_PORT = 5000
   WEB_API_URL = f"http://localhost:{WEB_API_PORT}"

Optional: Your project tree might look like this:

📂 mcp-vscode-rest
├── .vscode/
│   └── mcp.json
├── books_server.py
├── mcp_books_server.py
└── config.py

Now your environment is ready to support the Books Management API and MCP integration!

Building the Books Management API

Time to build a simple Books API using FastAPI.

Endpoints:

/books (POST): Add a new book.
/books (GET): Retrieve all books.
/books/id/{book_id} (GET): Get details of a specific book by ID.
/books/id/{book_id} (DELETE): Remove a book by ID.
/books/search (GET): Search for books by author, title, or category.

Key Features:

Validation with pydantic models (Book, BookResponse).
In-memory storage for simplicity (library dictionary).
Error handling using HTTPException.

Here’s an example of the add_book endpoint in the books_server.py file:

@app.post("/books", response_model=Dict[str, str], operation_id="add_book")
async def add_book(book: Book = Body(...)):
    if not book.title.strip() or not book.author.strip():
        raise HTTPException(
            status_code=400, detail="Title and author must be non-empty."
        )

    book_id = len(library) + 1
    library[book_id] = {
        "title": book.title.strip(),
        "author": book.author.strip(),
        "category": book.category.strip().lower() if book.category else None,
    }
    return {"message": f"Book added successfully with ID {book_id}"}

Full implementation: GitHub repo

Publishing Your FastAPI Endpoints with MCP

FastAPI-MCP is a zero-configuration tool for automatically exposing FastAPI endpoints as Model Context Protocol (MCP) tools. With just a few lines of glue code, your FastAPI app gets MCP superpowers.

In mcp_books_server.py:

import config
from fastapi_mcp import FastApiMCP
from books_server import app
import uvicorn

BASE_URL = config.WEB_API_URL

mcp = FastApiMCP(
    app,
    name="Books Server",
    description="A simple book management server",
    base_url=BASE_URL,
    describe_all_responses=True,
    describe_full_response_schema=True,
)

mcp.mount()

if __name__ == "__main__":
    uvicorn.run(app, port=5000)

Your API is now discoverable and describable via MCP. No extra boilerplate needed.

Check out the FastAPI MCP GitHub repository for more details.

Chatting with Your API in VS Code

Ready to talk to your API like it’s ChatGPT? Let’s go.

1. Configure MCP in VS Code

Create the .vscode/mcp.json file in your project folder to define the MCP server.

{
  "servers": {
    "mcp-books-server": {
      "type": "sse",
      "url": "http://localhost:5000/mcp"
    }
  }
}

This file tells VS Code where to find the MCP server and how to connect.

2. Start the MCP Server

uv run mcp_books_server.py

3. Use VS Code to Interact with MCP

Open the .vscode/mcp.json file and click the Start link above the server config. Voila! You’re live.

4. Test Your API

Try out scenarios like:

Adding Books: generate 3 books about programming and 2 about machine learning.

Do you see the beauty and potential of that?

Searching by Category: find the books in machine learning category.

This is awesome! (Of course not me in the profile picture below 🤓)

GitHub Copilot Chat will send real API calls and show you the responses inline. It’s like Postman with AI vibes.

BONUS Setup: AI-Enhanced Flow

Want to go next level?

Try chaining: FastAPI → MCP → Ollama → OpenWebUI

Now you’re building smart API agents that can learn from feedback, log context, and evolve with your product. More on that in an upcoming lightning post! So stay tuned!

Heads-Up: MCP's Awesomeness (with Quirks)

MCP is powerful — but sometimes it trips over its own genius. Ask it to juggle deletes and category filters and suddenly it's confused like when doing a git rebase for the first time.

Stick with it, it's part of the future, and it's worth the ride. 🚀

Your Turn

Try it out, have fun, and let me know how it works for you.

Check out the full project on GitHub.

Get Ready for Testcontainers: Taking Minimal Web API Testing to the Next Level 🚢

dorinandreidragan — Wed, 09 Apr 2025 20:11:05 +0000

In the first article of this series, we explored how to test minimal web APIs in ASP.NET using an in-memory dictionary. But now, it's time to level up!

Instead of relying on a simple in-memory store, we’ll integrate a PostgreSQL database and use Testcontainers to run isolated, repeatable integration tests in containers. In this article, we will:

Set up testing with Testcontainers.
Adjust our tests to use a real database.
Watch our tests fail and fix them step-by-step.
Create and apply migrations using dotnet ef.

🧪 From In-Memory to Containers

In the first iteration, we tested using:

A ConcurrentDictionary to store books.
Lightweight xUnit tests with no external dependencies.

Now, we’re upgrading to:

Centralized NuGet package versioning for cleaner dependency management.
Testcontainers to isolate tests in containers.
PostgreSQL using EF Core for persistence.

🧰 Centralizing Package Versions with Directory.Packages.props

First, ensure that you manage package versions centrally across all projects. Run this command in the root of your repository:

dotnet new packagesprops

This creates a Directory.Packages.props file. Then, add the following content:

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="coverlet.collector" Version="6.0.2" />
    <PackageVersion Include="FluentAssertions" Version="8.2.0" />
    <PackageVersion Include="Microsoft.AspNetCore.Mvc.Testing" Version="9.0.3" />
    <PackageVersion Include="Microsoft.NET.Test.Sdk" Version="17.12.0" />
    <PackageVersion Include="xunit" Version="2.9.2" />
    <PackageVersion Include="xunit.runner.visualstudio" Version="2.8.2" />
  </ItemGroup>
</Project>

See Central Package Management | Microsoft Learn for more details.

🔌 Project Setup

Ensure your project files no longer include version information, since this is now defined in Directory.Packages.props. Your *.csproj files should look like this:

📘 Web API (`BooksInventory.WebApi.csproj`)

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net9.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>
</Project>

🧪 Tests (`BooksInventory.WebApi.Tests.csproj`)

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <IsPackable>false</IsPackable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="coverlet.collector" />
    <PackageReference Include="FluentAssertions" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Testing" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" />
    <PackageReference Include="xunit" />
    <PackageReference Include="xunit.runner.visualstudio" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\..\src\BooksInventory.WebApi\BooksInventory.WebApi.csproj" />
  </ItemGroup>
</Project>

After updating, run a dotnet restore to ensure your solution picks up the centralized versioning.

🧪 Writing Tests with Testcontainers

This section shows how to write tests using Testcontainers while leveraging xUnit features for management of asynchronous initialization and shared setups. We use the following concepts from xUnit:

IAsyncLifetime: For asynchronous setup and teardown of test resources.
CollectionDefinition: To group tests that share the same setup/teardown logic.
Collection: To associate test classes with the shared collection, ensuring tests run in an isolated, consistent environment.

See Shared Context between Tests | xUnit.net for more details.

Adding Required NuGet Packages

For the Test Project:

Add the Testcontainers NuGet package via:

dotnet add package TestContainers.PostgreSql --version 4.3.0

For the Web API Project:

Add the following packages to integrate EF Core with PostgreSQL:

dotnet add package Npgsql.EntityFrameworkCore.PostgreSQL --version 9.0.4
dotnet add package Microsoft.EntityFrameworkCore.Design --version 9.0.4
dotnet add package Microsoft.EntityFrameworkCore --version 9.0.4

🏗 Setting Up the Database Context

First, update your Book record to include an immutable Id property and use init accessors for all properties. The updated version looks like this:

public record Book
{
    public int Id { get; init; }
    public required string Title { get; init; }
    public required string Author { get; init; }
    public required string ISBN { get; init; }
}

Note: After updating the Book class, ensure that any code referencing it is modified accordingly so that the project compiles.

Then, add the BooksInventoryDbContext class to the Web API project:

using Microsoft.EntityFrameworkCore;

namespace BooksInventory.WebApi;

public class BooksInventoryDbContext : DbContext
{
    public DbSet<Book> Books { get; set; }

    public BooksInventoryDbContext(DbContextOptions<BooksInventoryDbContext> options)
        : base(options)
    {
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Book>()
            .HasKey(u => u.Id);
        modelBuilder.Entity<Book>()
            .HasIndex(u => u.Title)
            .IsUnique();
    }
}

🚀 Integration Test Setup

To prepare for integration testing, we introduce several helper classes and attributes.

PostgreSqlContainerFixture

This fixture starts a PostgreSQL container using Testcontainers and applies all pending migrations to initialize the database schema.

public class PostgreSqlContainerFixture : IAsyncLifetime
{
    public PostgreSqlContainer Postgres { get; private set; }

    public PostgreSqlContainerFixture()
    {
        Postgres = new PostgreSqlBuilder()
            .WithImage("postgres:latest")
            .Build();
    }

    public async Task InitializeAsync()
    {
        await Postgres.StartAsync();

        // Ensure that the database schema is created by applying migrations.
        var options = new DbContextOptionsBuilder<BooksInventoryDbContext>()
            .UseNpgsql(Postgres.GetConnectionString())
            .Options;

        using var context = new BooksInventoryDbContext(options);
        await context.Database.MigrateAsync();
    }

    public Task DisposeAsync() => Postgres.DisposeAsync().AsTask();
}

Usage Explanation:

The PostgreSqlContainerFixture sets up a PostgreSQL container for the test run and applies migrations so that the database mirrors the production schema.

CustomWebApplicationFactory

By extending WebApplicationFactory, this class configures the test host to use PostgreSQL instead of the default in-memory store. The override in ConfigureWebHost replaces the default DB context registration with one that uses the container’s connection string.

public class CustomWebApplicationFactory : WebApplicationFactory<Program>
{
    private readonly string postgreSqlConnectionString;

    public CustomWebApplicationFactory(string postgreSqlConnectionString)
    {
        this.postgreSqlConnectionString = postgreSqlConnectionString;
    }

    protected override void ConfigureWebHost(IWebHostBuilder builder)
    {
        // Overwrite the existing DB context registration so that tests use the PostgreSQL container.
        builder.ConfigureServices(services =>
        {
            services.AddDbContext<BooksInventoryDbContext>(options =>
            {
                options.UseNpgsql(this.postgreSqlConnectionString);
            });
        });
    }
}

Usage Explanation:

This abstraction hides the details of database registration during tests, keeping test classes clean while ensuring that the Web API connects to the proper PostgreSQL instance.

Test Collection and Class Setup

We then define a collection to share our PostgreSQL container fixture and apply it to our test classes:

[CollectionDefinition(nameof(IntegrationTestsCollection))]
public class IntegrationTestsCollection : ICollectionFixture<PostgreSqlContainerFixture> {}

[Collection(nameof(IntegrationTestsCollection))]
public class BooksInventoryTests : IAsyncLifetime
{
    private readonly CustomWebApplicationFactory factory;
    private readonly HttpClient client;
    private readonly BooksInventoryDbContext dbContext;

    public BooksInventoryTests(PostgreSqlContainerFixture fixture)
    {
        this.factory = new CustomWebApplicationFactory(fixture.Postgres.GetConnectionString());
        this.client = this.factory.CreateClient();

        // Create a scope to retrieve a scoped instance of the DB context.
        // This allows direct interaction with the database for setup and teardown.
        var scope = this.factory.Services.CreateScope();
        dbContext = scope.ServiceProvider.GetRequiredService<BooksInventoryDbContext>();
    }

    public async Task InitializeAsync()
    {
        // Clean the database to ensure test isolation.
        dbContext.Books.RemoveRange(dbContext.Books);
        await dbContext.SaveChangesAsync();
    }

    // Dispose resources to maintain isolation after each test run.
    public Task DisposeAsync()
    {
        this.client.Dispose();
        this.factory.Dispose();
        return Task.CompletedTask;
    }

    // ... your tests go here
}

Usage Explanation:

[CollectionDefinition] and [Collection] Attributes: These group test classes that share the same PostgreSQL fixture so that the container is started once per collection.
IAsyncLifetime: Implements asynchronous setup and cleanup of test resources.

Phew! That’s a lot of setup, but it’s crucial for ensuring that our tests run in a clean, isolated environment.

❌ Watch the Tests Fail

At this point, running the tests will fail because the application is still using an in-memory store.

✅ Update `Program.cs` to Use EF Core

Now let's update Program.cs to make the application use EF Core with PostgreSQL.

using BooksInventory.WebApi;

var builder = WebApplication.CreateBuilder(args);

// Register the PostgreSQL service with EF Core.
// This replaces any default in-memory service configuration.
builder.Services.AddDbContext<BooksInventoryDbContext>(options =>
{
    options.UseNpgsql(builder.Configuration.GetConnectionString("DefaultConnection"));
});

var app = builder.Build();

// Inject the DB context to add a new book asynchronously.
app.MapPost("/addBook", async (AddBookRequest request, BooksInventoryDbContext db) =>
{
    var book = new Book
    {
        Title = request.Title,
        Author = request.Author,
        ISBN = request.ISBN
    };
    db.Books.Add(book);
    await db.SaveChangesAsync();
    return Results.Ok(new AddBookResponse(book.Id));
});

// Inject the DB context to get a book asynchronously.
app.MapGet("/books/{id}", async (int id, BooksInventoryDbContext db) =>
{
    var book = await db.Books.FindAsync(id);
    return book is not null
        ? Results.Ok(book)
        : Results.NotFound(new { Message = "Book not found", BookId = id });
});

app.Run();

public record AddBookRequest(string Title, string Author, string ISBN);
public record AddBookResponse(int BookId);
public record Book
{
    public int Id { get; init; }
    public required string Title { get; init; }
    public required string Author { get; init; }
    public required string ISBN { get; init; }
};

// Explicitly define Program as partial for integration tests.
public partial class Program { }

Additional Instructions:

Update appsettings.Development.json with the following connection string:

  "ConnectionStrings": {
    "DefaultConnection": "Host=localhost;Port=5432;Database=books_inventory;Username=user;Password=password"
  }

🧱 Add Migrations

Now that the application has been updated to use PostgreSQL, add the initial migrations with:

dotnet ef migrations add InitialCreate --project src/BooksInventory.WebApi/BooksInventory.WebApi.csproj

This command generates the migration files necessary to set up your PostgreSQL database schema.

After adding the migrations, run your tests using:

dotnet test

If your tests fail, is mostly because you should update them to reflect the change we've made. For example:

// this won't work anymore
result!.BookId.Should().NotBeNullOrEmpty();

// should be change to this
result!.BookId.Should().BeGreaterThan(0);

Also, if you see a warning like this:

/usr/lib/dotnet/sdk/9.0.105/Microsoft.Common.CurrentVersion.targets(2413,5): warning MSB3277:
      Found conflicts between different versions of "Microsoft.EntityFrameworkCore.Relational" that could not be resolved.

You can fix it just by adding the Microsoft.EntityFrameworkCore.Relational package to the BooksInventory.WebApi project with the right version:

dotnet add src/BooksInventory.WebApi package Microsoft.EntityFrameworkCore.Relational --version 9.0.4

Your tests should now run smoothly within the containerized environment.

⚙️ Developer Setup for Manual Testing

For manual testing in a development environment, be sure to apply the migrations after starting the database. Use the following docker-compose.yml in your root folder, to start PostgreSQL:

services:
  database:
    image: postgres:15-alpine
    container_name: books_inventory_db
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
      POSTGRES_DB: books_inventory
    ports:
      - "5432:5432"
    volumes:
      - postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "user", "-d", "books_inventory"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  postgres-data:

Start the database container:

   docker compose up -d

Apply migrations:

Right after the service is up, run:

   dotnet ef database update --project src/BooksInventory.WebApi/BooksInventory.WebApi.csproj

If you see an error message such as:

   Failed executing DbCommand (10ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
   SELECT "MigrationId", "ProductVersion"
   FROM "__EFMigrationsHistory"
   ORDER BY "MigrationId";

this is normal since this error appears when no migrations have been applied yet. You may safely ignore it.

Test the database connection:

Install the PostgreSQL client (for example, on Ubuntu use sudo apt install postgresql-client), then connect using:

   psql -h localhost -U user -d books_inventory

   # Enter "password" as password when prompted.

Verify the Database Schema:

In the psql terminal, run:

\dt

The expected output should be similar to:

    Schema |         Name          | Type  | Owner
   --------+-----------------------+-------+-------
    public | Books                 | table | user
    public | __EFMigrationsHistory | table | user
   (2 rows)

Manual Testing in VSCode Using a REST Client

For a quick manual test of your API endpoints:

Open the project in VSCode.
Use the REST client extension and create an *.http file with the following content:

  # Base URL
  @baseUrl = http://localhost:5000

  # Test POST /addBook
  POST {{baseUrl}}/addBook HTTP/1.1
  Content-Type: application/json

  {
      "Title": "The Pragmatic Programmer",
      "Author": "Andy Hunt and Dave Thomas",
      "ISBN": "9780135957059"
  }

  ###

  # Test GET /books/{id} (replace {id} with a valid BookId from the POST response)
  GET {{baseUrl}}/{id} HTTP/1.1
  Accept: application/json

Start your web app: dotnet run --project src/BooksInventory.WebApi/BooksInventory.WebApi.csproj.
Send these requests to verify that the API routes are functioning as expected.

🚢 Final Thoughts

By following these steps, we’ve:

Set up Testcontainers for isolated, reproducible integration tests.
Switched our storage from an in-memory dictionary to a real PostgreSQL database.
Applied migrations to ensure that our tests run against a schema identical to production.

Next Steps:

Setting up a CI pipeline.
Explore integrating Redis for caching.
Add RabbitMQ for messaging.
Implement OpenTelemetry for distributed tracing.

Stay tuned for more in-depth articles into system design and testing strategies!

Your Turn: Try this approach in your own projects and see how much smoother your testing workflow becomes. Got a cool testing trick? Share it in the comments or hit me up on GitHub here. 📬

testing minimal web apis with asp.net

dorinandreidragan — Wed, 02 Apr 2025 17:09:30 +0000

Testing Web APIs doesn’t need to be a chore. No sprawling frameworks. No over-engineered test setups. Just sharp, focused integration tests that give you confidence.

Let’s build them.

set up a minimal API worth testing ️

Forget databases. Forget layers of abstraction. You’re staring at a minimal book inventory API that lives entirely in memory. It’s lean. Perfect for test-driving.

Run this in your terminal:

dotnet new sln --name BooksInventory

mkdir src tests
dotnet new web -o src/BooksInventory.WebApi
dotnet new xunit -o tests/BooksInventory.WebApi.Tests

dotnet sln add src/BooksInventory.WebApi
dotnet sln add tests/BooksInventory.WebApi.Tests

dotnet add tests/BooksInventory.WebApi.Tests package FluentAssertions
dotnet add tests/BooksInventory.WebApi.Tests package Microsoft.AspNetCore.Mvc.Testing

know what you’re testing

This API does two things. That’s it:

POST /addBook — accepts a title, author, and ISBN; returns a new BookId.
GET /books/{id} — returns the book’s details, or a 404 if it doesn’t exist.

Here’s the entire API, no fluff:

using System.Collections.Concurrent;

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

var books = new ConcurrentDictionary<string, Book>();

app.MapPost("/addBook", (AddBookRequest request) =>
{
    var bookId = Guid.NewGuid().ToString();
    var book = new Book(request.Title, request.Author, request.ISBN);

    if (!books.TryAdd(bookId, book))
    {
        return Results.Problem("Failed to add book due to a concurrency issue.");
    }

    return Results.Ok(new AddBookResponse(bookId));
});

app.MapGet("/books/{id}", (string id) =>
{
    if (books.TryGetValue(id, out var book))
    {
        return Results.Ok(book);
    }
    return Results.NotFound(new { Message = "Book not found", BookId = id });
});

app.Run();

public record AddBookRequest(string Title, string Author, string ISBN);
public record AddBookResponse(string BookId);
public record Book(string Title, string Author, string ISBN);

// Make Program partial for test visibility
public partial class Program { }

write integration tests that matter 🧪

You're not mocking. You're not faking. You’re hitting the real thing using WebApplicationFactory.

using FluentAssertions;
using Microsoft.AspNetCore.Mvc.Testing;

namespace BooksInventory.WebApi.Tests;

public class BookInventoryTests : IClassFixture<WebApplicationFactory<Program>>
{
    private readonly HttpClient _client;

    public BookInventoryTests(WebApplicationFactory<Program> factory)
    {
        _client = factory.CreateClient();
    }

    [Fact]
    public async Task AddBook_ReturnsBookId()
    {
        var request = new AddBookRequest("AI Engineering", "Chip Huyen", "1098166302");
        var content = request.GetHttpContent();

        var response = await _client.PostAsync("/addBook", content);

        response.EnsureSuccessStatusCode();
        var result = await response.DeserializeAsync<AddBookResponse>();
        result?.Should().NotBeNull();
        result!.BookId.Should().NotBeNullOrEmpty();
    }

    [Fact]
    public async Task GetBook_ReturnsBookDetails()
    {
        var addRequest = new AddBookRequest("AI Engineering", "Chip Huyen", "1234567890");
        var addResponse = await _client.PostAsync("/addBook", addRequest.GetHttpContent());
        var bookId = (await addResponse.DeserializeAsync<AddBookResponse>())?.BookId;

        var getResponse = await _client.GetAsync($"/books/{bookId}");

        getResponse.EnsureSuccessStatusCode();
        var book = await getResponse.DeserializeAsync<Book>();
        book.Should().BeEquivalentTo(
            new Book(
                addRequest.Title,
                addRequest.Author,
                addRequest.ISBN));
    }
}

kill boilerplate with sharp extensions

Don't repeat yourself. Don’t clutter tests with serialization logic. Add these extensions and move on.

using System.Text;
using System.Text.Json;

public static class HttpContentExtensions
{
    private static readonly JsonSerializerOptions SerializerOptions = new()
    {
        PropertyNameCaseInsensitive = true
    };

    public static async Task<T?> DeserializeAsync<T>(this HttpResponseMessage response)
    {
        return JsonSerializer.Deserialize<T>(
            await response.Content.ReadAsStringAsync(),
            SerializerOptions);
    }

    public static HttpContent GetHttpContent<T>(this T obj) where T : class
    {
        return new StringContent(
            JsonSerializer.Serialize(obj),
            Encoding.UTF8, "application/json");
    }
}

skip the tests? hit it with rest client

Not every check needs a test method. Sometimes you just want to click. The REST Client extension in VS Code makes that painless.

Create a .http file like this:

POST {{baseUrl}}/addBook HTTP/1.1
Content-Type: application/json

{
    "Title": "The Pragmatic Programmer",
    "Author": "Andy Hunt and Dave Thomas",
    "ISBN": "9780135957059"
}

###

# test GET /books/{id} (replace {id} with an actual ID)
GET {{baseUrl}}/books/{id} HTTP/1.1
Accept: application/json

No Postman. No curl. Just fire and read. Right in your editor.

integration testing should feel like a power move ⚡

You don’t need a test framework war chest to validate your minimal API.

You need:

Real HTTP calls through WebApplicationFactory
Clean assertions from FluentAssertions
A few smart helpers to keep your test files tight
The REST Client for fast manual pokes when you feel like it

That’s it. Want to see the full source or send improvements? It’s on GitHub right here. Go break something. Then test it better.

Simplify Config Updates with Ansible's Lineinfile

dorinandreidragan — Thu, 27 Mar 2025 06:40:10 +0000

Managing configuration files across servers can be tricky. Ansible's lineinfile module makes it easy to automate these changes while ensuring consistency and safety.

Quick Steps

Define Variables: Create a dictionary with file path and configuration options:

   vars:
     app_cfg_file: /etc/app/app.cfg
     app_cfg:
       max_connections: 200
       timeout: 30
       log_level: "INFO"

Update Configurations: Use lineinfile to modify the file:

   - name: Update config options
     lineinfile:
       path: "{{ app_cfg_file }}"
       regexp: "^{{ item.key }}="
       line: "{{ item.key }}={{ item.value }}"
       backup: yes
       insertbefore: BOF
     loop: "{{ app_cfg | dict2items }}"

Why Use It?

Idempotent: Only changes what's necessary.
Safe: Backups are timestamped for easy recovery.
Efficient: Automates tedious manual edits.

Conclusion

With lineinfile, automating consistent updates across servers becomes a breeze. Give it a try!

🚀 Master Technical Topics with This Game-Changing Prompt

dorinandreidragan — Wed, 19 Mar 2025 11:58:46 +0000

Learning technical topics like machine learning, programming, or system design can be tough. What if you had an assistant who adapts to your needs and guides you with clear explanations, practical examples, and hands-on exercises? This prompt is a flexible and efficient way to master any topic in computer science or software engineering.

🎯 The Prompt

Use this customizable prompt to supercharge your learning process:

Before we start, I want you to ask me how I would like to approach learning. 
Specifically, ask me:

1. Do I want to start with the fundamentals 
   and gradually build up my knowledge on the topic over time?  
2. Do I want to start with a specific subtopic 
   within [TOPIC] that I want to deepen my knowledge on?  

Once I give you my preference, proceed with the learning approach. 
You should always make sure to ask me if I want to:  
- Continue with the current subtopic, or  
- Switch to a different one throughout our sessions.

Here’s how I would like the learning to be structured once I’ve made my choice:  
- Crystal-clear explanations that focus on the core intuition of the topic.  
- Analogies and real-world examples to make abstract concepts concrete.  
- Diagrams and illustrations whenever helpful.  
- Code examples in [LANGUAGES] or another relevant language.  
- Practical applications to reinforce my understanding.
- Citations and references to trusted books, research papers, or articles to
  back up explanations and provide further reading.

Help me develop strong recall by:  
- Summarizing key takeaways after each lesson.  
- Asking me questions to test my understanding.  
- Suggesting practice problems with increasing difficulty.

Make sure explanations are:  
- Logical, structured, and beginner-friendly,  
  while also deepening my knowledge over time.  
- Engaging, without assuming prior knowledge beyond the basics.  

If I struggle with a concept, break it down even further!
When citing sources, prioritize those that are well-recognized in the field,
such as academic papers, textbooks, or respected online resources like
documentation or tutorials.

Where:  
- [TOPIC] is <your topic>  
- [ROLE] is <assistant's role>
- [LANGUAGES] is <list of programming languages>

🔧 Customize the Prompt

Here’s how you can adapt the prompt for different learning goals:

Learning Deep Learning
- [TOPIC]: Deep Learning
- [ROLE]: Expert in machine learning in the style of Andrew Ng
- [LANGUAGES]: Python
System Design Interview Prep
- [TOPIC]: System Design
- [ROLE]: Expert in system design in the style of Alex Xu
- [LANGUAGES]: Python and SQL
Mastering Object-Oriented Programming
- [TOPIC]: Object-Oriented Programming
- [ROLE]: Expert in OOP in the style of Robert C. Martin aka Uncle Bob
- [LANGUAGES]: Java

💡 Why This Prompt Works

Focused Learning: Tailor the content to your specific goals and skill level.
Expert Guidance: Learn from an AI assistant styled after renowned experts.
Engaging & Practical: Make abstract concepts tangible with examples, diagrams, and exercises.
Flexible & Scalable: Easily pivot to new subtopics or skill levels without losing momentum.
Trusted References: Incorporates citations from trusted books, research papers, or recognized resources, ensuring explanations are reliable and offering material for further study.

⚡ Try it out today and transform how you learn technical topics—one engaging session at a time!

📓 How to Use Jupyter Notebooks in VSCode with Poetry Virtual Environments 🚀

dorinandreidragan — Fri, 21 Feb 2025 17:48:12 +0000

If you're a developer using Jupyter Notebooks and Poetry, you might face an issue where VSCode doesn't automatically recognize the Poetry virtual environments. This guide will show you how to solve this problem by updating the VSCode user settings accordingly.

Step 1: Create a New Project with Poetry

Navigate to your project directory and create a new project using Poetry:

mkdir my_jupyter_project
cd my_jupyter_project
poetry init

Follow the prompts to set up your pyproject.toml file.

Step 2: Install and Activate the Virtual Environment

To create and activate the virtual environment, run:

poetry install
poetry shell

This will create a virtual environment and activate it, isolating your project's dependencies.

Step 3: Open VSCode and Install the Jupyter Extension

Open your project folder in VSCode:

code .

Make sure to install the Jupyter extension in VSCode if you haven't already. You can find it in the Extensions view by searching for "Jupyter".

Step 4: Configure VSCode User Settings ⚙️

Ensure that VSCode is configured to recognize Poetry virtual environments. Add the following settings to your settings.json file:

"python.venvPath": "/home/YourUsername/.cache/pypoetry/virtualenvs",
"python.venvFolders": ["/home/YourUsername/.cache/pypoetry/virtualenvs"]

Replace YourUsername with your actual username.

Step 5: Create and Run a Jupyter Notebook 📓

With the virtual environment set up, you can now create a Jupyter Notebook:

Open the Command Palette (Ctrl+Shift+P) and type Jupyter: Create New Blank Notebook.
Select the appropriate kernel (your Poetry virtual environment) from the kernel picker in the top-right corner of the notebook.
Start coding in your Jupyter Notebook and enjoy the power of Poetry and Jupyter combined! 🎉

By following these steps, you can efficiently manage your Jupyter Notebook projects using Poetry within VSCode, ensuring that your dependencies are well-organized and isolated. Happy coding! 💻✨

🔑 Fixing APT Cache Update Errors: GPG Keys Made Easy!

dorinandreidragan — Thu, 23 Jan 2025 16:18:21 +0000

Updating the APT cache is essential for keeping your system in top shape. But it can sometimes feel like navigating a maze. Here’s how you can make sure your APT cache updates without a hitch, even when dealing with specific sources.

Common Scenarios and Challenges

When configuring APT to use specific repositories, you might run into a few bumps in the road:

Missing or Incorrect GPG Keys 🔑: APT needs valid GPG keys to verify packages. If the keys are missing or incorrect, you'll get errors like:

The following signatures couldn't be verified because the public key is not available: NO_PUBKEY ABCD1234EFGH5678
GPG error: http://example.repo.com stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY ABCD1234EFGH5678

Incorrect Permissions 🚫: Permissions on key directories and files need to be just right, or APT will throw a fit.
Manual Configuration Errors 📝: We've all made typos or misconfigurations in the sources.list file or keyring directories. It happens!

Step-by-Step Solution

Ensure Your /etc/apt/sources.list File is Correct 📄 First things first, let's make sure your sources.list file is in good shape. Open it up:

   sudo nano /etc/apt/sources.list

Add the correct repository URL. For this example, let's use a hypothetical non-Ubuntu repository:

   deb http://example.repo.com/debian/ stable main

Create the trusted.gpg.d Folder with Correct Permissions 📂 If the trusted.gpg.d folder doesn't exist or has funky permissions, let's fix that:

   sudo mkdir -p /etc/apt/trusted.gpg.d
   sudo chmod 755 /etc/apt/trusted.gpg.d

Retrieve the Public Key from the Keyserver 🌐 Time to fetch the GPG key. Think of it as getting the secret handshake:

   gpg --keyserver hkps://keyserver.ubuntu.com:443 --recv-keys ABCD1234EFGH5678

Export the Key to the Default Keyring and Set Permissions 🔐 Now, let's export that key to the default keyring and make sure it's got the right permissions:

   gpg --export ABCD1234EFGH5678 | sudo tee /etc/apt/trusted.gpg.d/example-repo.gpg > /dev/null
   sudo chmod 644 /etc/apt/trusted.gpg.d/example-repo.gpg

Update the APT Cache 🔄 Finally, let's see if all our hard work paid off. Update the APT cache:

   sudo apt update

Conclusion

And there you have it! By following these steps, you can ensure that your APT cache updates smoothly from specified sources. It's all about getting the sources.list file right, setting the correct permissions, and making sure those GPG keys are in place.

Note: The repository URL and GPG key used in this example are hypothetical and should be replaced with actual values relevant to your specific use case.

🔋⚡ Ensuring High Availability with Two-Server Setup Using Keepalived

dorinandreidragan — Thu, 28 Nov 2024 14:32:45 +0000

Ensuring High Availability with Two-Server Setup Using Keepalived

Ensuring high availability with limited resources can be challenging. I recently wanted to prove you can do it using Keepalived and just two servers 💪✨. To prove it, I used Vagrant. Here's a quick rundown of my journey! 🚀

Step 1: Creating the Vagrantfile

First, I created a Vagrantfile to define my virtual machines. This file specified the configuration for two Ubuntu 22.04 VMs, each with a unique MAC address and a static IP address in the same subnet.

Vagrant.configure("2") do |config|
  # Array of predefined MAC addresses
  mac_addresses = ["080027000001", "080027000002"]

  # Array of static IP addresses for the VMs
  ip_addresses = ["192.168.56.11", "192.168.56.12"]

  mac_addresses.each_with_index do |mac, index|
    config.vm.define "vm#{index + 1}" do |vm|
      vm.vm.box = "ubuntu/jammy64"
      vm.vm.network "private_network", ip: ip_addresses[index], mac: mac
      vm.vm.provider "virtualbox" do |vb|
        vb.name = "vm#{index + 1}"
        vb.memory = "512"
        vb.cpus = 1
      end

      # Provision Keepalived and Nginx
      vm.vm.provision "shell", inline: <<-SHELL
        sudo apt-get update
        sudo apt-get install -y keepalived nginx
        # Example Keepalived configuration
        sudo bash -c 'cat > /etc/keepalived/keepalived.conf <<EOF
vrrp_instance VI_1 {
    state #{index == 0 ? 'MASTER' : 'BACKUP'}
    interface enp0s8
    virtual_router_id 51
    priority #{index == 0 ? 100 : 90}
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        192.168.56.10
    }
}
EOF'
        sudo systemctl restart keepalived

        # Configure a simple web page to show role (MASTER or BACKUP)
        sudo bash -c 'echo "<html><body><h1>Server Role: #{index == 0 ? 'MASTER' : 'BACKUP'}</h1></body></html>" > /var/www/html/index.html'
        sudo systemctl restart nginx
      SHELL
    end
  end
end

Step 2: Spinning Up the VMs

With the Vagrantfile ready, I used Vagrant commands to create and start the virtual machines.

vagrant up

This command created and configured the VMs as specified in the Vagrantfile. Once the VMs were up and running, I could SSH into them to verify the setup.

vagrant ssh vm1
vagrant ssh vm2

Step 3: Configuring Keepalived

The heart of this setup was the Keepalived configuration. The Vagrantfile already included provisioning scripts to install and configure Keepalived on both VMs. Here’s a recap of the configuration:

On the MASTER server:

vrrp_instance VI_1 {
    state MASTER
    interface enp0s8
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        192.168.56.10
    }
}

On the BACKUP server:

vrrp_instance VI_1 {
    state BACKUP
    interface enp0s8
    virtual_router_id 51
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        192.168.56.10
    }
}

Step 4: Testing the Setup

With everything configured, it was time to test the setup. I started by verifying that the virtual IP (VIP) was correctly assigned to the MASTER server.

ip a show enp0s8

I then accessed the web server using the VIP to ensure it was reachable.

curl http://192.168.56.10

If the setup is correct, you should see the page that indicates which server (MASTER or BACKUP) is responding.

Step 5: Simulating Failover

To test the failover functionality, I stopped the Keepalived service on the MASTER server.

sudo systemctl stop keepalived

I then checked the BACKUP server to see if it had taken over the VIP.

ip a show enp0s8

Sure enough, the BACKUP server had taken over, and the web server was still accessible via the VIP.

Lessons Learned

This experience proved that high availability can be achieved with just two servers using Keepalived. Here are some key takeaways:

Simplicity and Power: Keepalived is a powerful tool that is relatively simple to set up and configure.
High Availability on a Budget: Even with just two servers, you can achieve a high level of availability.
Practical Testing: Always test your setup thoroughly to ensure that failover works as expected.

Conclusion

When it comes to ensuring high availability with limited resources, Keepalived is a great tool to have in your arsenal. I hope this article has inspired you to explore high availability setups further.

Feel free to share your own experiences or ask questions in the comments below. Use your resources wisely and keep your systems running smoothly! 🛠️💡💻⚙️

🎧 Troubleshooting Sound Card Issues on Ubuntu Desktop

dorinandreidragan — Wed, 27 Nov 2024 16:40:27 +0000

Hey everyone,

I recently ran into some sound issues on my Ubuntu Desktop, and I thought I'd share how I managed to fix them. If you're having trouble with your sound card, this guide might help you out.

Step 1: Check for ALSA and PulseAudio 🔍

First things first, let's see if ALSA and PulseAudio are installed on your system. Open a terminal and run these commands:

dpkg -l | grep alsa
dpkg -l | grep pulseaudio

If nothing shows up, it means you need to install them.

Step 2: Install ALSA and PulseAudio 🛠️

Here's how you can install ALSA and PulseAudio:

Update Your Package List:

sudo apt update

Install ALSA:

sudo apt install alsa-base alsa-utils

Install PulseAudio:

sudo apt install pulseaudio

Step 3: Restart Your System 🔄

After installing these packages, restart your system. This helps to make sure all changes take effect.

Step 4: Check Audio Settings 🎛️

Once your system is back up, check your audio settings:

Click on the sound icon in your system tray.
Make sure the correct output device is selected.
Ensure the volume is not muted and is turned up.

Step 5: Test Your Sound 🔊

Now, it's time to test your sound. You can play some audio using a media player or run this command:

speaker-test -c 2

This will play a test sound through your speakers.

Additional Troubleshooting 🛠️

If you're still having issues, try these additional steps:

Restart Audio Services:

sudo systemctl restart alsa
sudo systemctl restart pulseaudio

Check ALSA Mixer: Open a terminal and type alsamixer. Use the arrow keys to navigate and make sure all channels are unmuted and turned up.

By following these steps, I was able to get my sound working again. Hopefully, this helps you too! If you still have problems, it might be a hardware issue, and you might need to look into it further.

Happy troubleshooting! 🎉

DEV Community: dorinandreidragan

🔥 Missed Microsoft Build 2025? Catch the Recorded Sessions! 🎥🚀

🎬 Check Out These Playlists Packed with Insights:

🎙️ Popular Speakers to Check Out:

Scott Hanselman

Burke Holland

Pierce Boggan

If You Can’t Observe It 🔭, You Can’t Operate It

Why Observability?

Why OpenTelemetry

Our Goal

Step-by-Step Setup

1. Configure OpenTelemetry Collector

2. Update docker-compose.yml

Instrument the API with OpenTelemetry

Visualize Traces in Jaeger

Debugging with Tracing: Real-World Benefits

⚠️ Found: Inefficient DELETE

Bonus: Cache Behavior Verification with Redis CLI

Beyond Tracing: Expanding Observability

Next Steps

HybridCache & Redis: Cache Smarter, Not Harder for ASP.NET APIs 🚀

Cache Smarter, Not Harder

HybridCache: A Smarter Approach to API Caching

Upgraded API Endpoints for Smart Caching

Prerequisites for Caching

Get the Libraries

Register the Services

GET Endpoint: Fast and Durable Retrieval

DELETE Endpoint: Ensuring Consistency by Invalidation

PUT Endpoint: Updating and Refreshing the Cache

POST & Search/Get-All Endpoints: Caching Exclusions

Enhanced Testing with Testcontainers and Automated Validation

Containerized Testing with Composite Fixtures

Automated Cache Behavior Verification

BooksInventoryCacheTests

BooksInventoryTests

Manual Cache Verification Using a REST Client 🖥️

Conclusion & Next Steps 🎯

VSCode + MCP: Chat with Your API using GitHub Copilot

TL;DR

Introduction

What is MCP, and Why Use It?

Setting Up the Environment

Building the Books Management API

Publishing Your FastAPI Endpoints with MCP

Chatting with Your API in VS Code

1. Configure MCP in VS Code

2. Start the MCP Server

3. Use VS Code to Interact with MCP

4. Test Your API

BONUS Setup: AI-Enhanced Flow

Heads-Up: MCP's Awesomeness (with Quirks)

Your Turn

Get Ready for Testcontainers: Taking Minimal Web API Testing to the Next Level 🚢

🧪 From In-Memory to Containers

🧰 Centralizing Package Versions with Directory.Packages.props

🔌 Project Setup

📘 Web API (BooksInventory.WebApi.csproj)

🧪 Tests (BooksInventory.WebApi.Tests.csproj)

🧪 Writing Tests with Testcontainers

Adding Required NuGet Packages

🏗 Setting Up the Database Context

🚀 Integration Test Setup

PostgreSqlContainerFixture

CustomWebApplicationFactory

Test Collection and Class Setup

❌ Watch the Tests Fail

✅ Update Program.cs to Use EF Core

🧱 Add Migrations

⚙️ Developer Setup for Manual Testing

Manual Testing in VSCode Using a REST Client

🚢 Final Thoughts

testing minimal web apis with asp.net

set up a minimal API worth testing ️

know what you’re testing

write integration tests that matter 🧪

kill boilerplate with sharp extensions

skip the tests? hit it with rest client

integration testing should feel like a power move ⚡

2. Update `docker-compose.yml`

📘 Web API (`BooksInventory.WebApi.csproj`)

🧪 Tests (`BooksInventory.WebApi.Tests.csproj`)

✅ Update `Program.cs` to Use EF Core