DEV Community: victor mwangi

How I Am Building an AI Meeting Assistant in ASP.NET Core (And Avoided Timeout Nightmares)

victor mwangi — Wed, 03 Jun 2026 23:12:50 +0000

For my 4rd-year Software Engineering final project at university, I’m building an AI Meeting Assistant.
The core feature is simple: A user uploads a 20-minute audio recording of a meeting. My backend downloads it from Backblaze B2, sends it to an selfhosted transcription service to transcribe the speech, and then passes that text to Google Gemini to generate structured meeting minutes that are sent to you email.
There was just one massive problem: It takes over a minute to process.
If I ran this logic inside my standard API Controller, the user’s browser would just show a loading spinner for 90 seconds, eventually hitting a 504 Gateway Timeout.
The solution? ASP.NET Core Background Services. Here is how I implemented a background worker to handle the heavy AI lifting, and the 3 massive "Gotchas" I ran into along the way.

To understand why Background Services are necessary, think of a fast-food restaurant:
The Controller (The Cashier): The cashier takes your order, hands the ticket to the kitchen, and gives you a receipt. They don't cook the food. If the cashier goes to the back to grill your burger, the line of customers out the door gets angry.
The BackgroundService (The Kitchen Staff): The kitchen staff doesn't interact with customers. They sit in the back, continuously checking the ticket machine. When a new ticket pops up, they cook the food.
In ASP.NET Core, Controllers are short-lived (created and destroyed for every HTTP request). But a BackgroundService is long-lived. It is created once when the app starts, and runs continuously until the app shuts down.

Building the Transcription Worker
In .NET, creating a background worker is incredibly easy. You just create a class that inherits from BackgroundService and override the ExecuteAsync method.
Here is the exact skeleton of the TranscriptionWorker I built for my project:

public class TranscriptionWorker : BackgroundService
{
    private readonly IServiceProvider _serviceProvider;
    private readonly ILogger<TranscriptionWorker> _logger;

    public TranscriptionWorker(IServiceProvider serviceProvider, ILogger<TranscriptionWorker> logger)
    {
        _serviceProvider = serviceProvider;
        _logger = logger;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        _logger.LogInformation("Transcription Background Worker started.");

        while (!stoppingToken.IsCancellationRequested)
        {
            try
            {
                // 1. Check the database for newly uploaded audio files
                using var scope = _serviceProvider.CreateScope();
                var context = scope.ServiceProvider.GetRequiredService<AppDbContext>();

                var pendingAudio = await context.AudioFiles
                    .FirstOrDefaultAsync(a => a.Status == Status.Pending, stoppingToken);

                if (pendingAudio != null)
                {
                    // 2. Hand it off to the processing service (Groq -> Gemini)
                    var processor = scope.ServiceProvider.GetRequiredService<IAudioProcessingService>();
                    await processor.ProcessAudioAsync(pendingAudio.Id);
                }
            }
            catch (Exception ex)
            {
                _logger.LogError(ex, "Error in TranscriptionWorker loop.");
            }

            // 3. Go to sleep for 30 seconds before checking again
            await Task.Delay(TimeSpan.FromSeconds(30), stoppingToken);
        }
    }
}

To turn it on, I just registered it in my Program.cs:

builder.Services.AddHostedService<TranscriptionWorker>();

Now, when a user uploads an audio file, my API instantly saves it to the database with a Pending status and replies to the user: "Upload successful! We'll notify you when the minutes are ready." Meanwhile, the worker silently picks it up in the background.

If you are building a .NET app that integrates with AI APIs, file processing, or heavy database tasks, stop doing it in the HTTP request pipeline. Give BackgroundService a try!
Have you used Background Services in your projects? What kind of tasks are you running in the background? Let me know in the comments below!

Discovering Google Lighthouse . A Small Tool That Changed How I See Web Development

victor mwangi — Fri, 29 May 2026 00:32:50 +0000

Today I discovered something I honestly should have explored a long time ago: Google Lighthouse.
Funny enough, revamping my portfolio is one of those projects I kept pushing forward with the classic “I’ll do it tomorrow” mindset — and somehow tomorrow kept winning. But today I finally sat down and started improving it, and during that process, I came across Lighthouse.
For anyone who hasn’t heard of it yet, Google Lighthouse is an open-source automated tool designed to help developers improve the quality of web pages. You can run it on almost any page — whether it’s public or behind authentication.
What immediately caught my attention is that it audits things like:
Performance
Accessibility
SEO
Best Practices
And probably a few more things I’m still discovering
You can run Lighthouse directly inside Chrome DevTools, through the command line, or even as a Node.js module.
The process is simple:
You give Lighthouse a URL, it scans the page, runs a series of audits, and then generates a detailed report showing how your website performs.
What makes it powerful is that it doesn’t just tell you what’s wrong it also explains:
_

Why the issue matters
How it affects users
And how you can fix it _ As a beginner software engineer and developer, I’m slowly realizing that writing code is only one part of building great applications. Performance, accessibility, maintainability, and user experience matter just as much. And honestly, tools like Lighthouse make the learning process feel less overwhelming because they point you in the right direction. One thing I’ll say though don’t fall into the trap of chasing a perfect Lighthouse score instead of building useful projects. A lot of developers start optimizing numbers before validating whether the product itself solves a real problem. Lighthouse is a guide, not the final goal. For my portfolio specifically, Lighthouse exposed a few weaknesses immediately:
Large unoptimized images
Accessibility issues
Slow-loading assets
Missing metadata Things I probably would have ignored before. Small discoveries like this make development more exciting for me because every new tool feels like learning how to sharpen my sword a little better.

Until next time, fellow coffee addicts.

Maybe next time I’ll uncover another trick to become a better developer.

Adios ☕

Stop Using useEffect for Data Fetching: Understanding TanStack Query

victor mwangi — Wed, 27 May 2026 16:28:02 +0000

If you are still fetching data inside a useEffect hook, manually managing loading states, and storing server responses inside local component state, your frontend architecture is carrying unnecessary complexity.

Managing asynchronous API data — also called Server State — is one of the hardest problems in frontend development. Trying to handle it with traditional client-side state tools like Redux, Zustand, or plain React state often leads to repetitive, fragile, and difficult-to-maintain codebases.

That is where TanStack Query changes everything.

It is not just a data-fetching library. It acts as:

An intelligent cache
A server-state manager
A synchronization layer between your frontend and backend
A background updater for stale data
Let’s break down how it actually works.

Client State vs Server State

Before understanding TanStack Query, you need to separate two completely different categories of state.

1. Client State

This is synchronous state that exists entirely inside the browser.

Examples:

Modal visibility
Theme toggles
Sidebar state
Form inputs

This data is fully controlled by the frontend.

2. Server State

This is asynchronous state that lives remotely on a backend server or database.

Examples:

Product lists
User profiles
Notifications
Dashboard analytics
Orders from an API

Server state has unique challenges:

You do not own the data
Multiple users can modify it
It can become outdated instantly
It requires async network requests
It needs synchronization

Using useState + useEffect forces server state to behave like client state.

That creates problems like:

Duplicate requests
Boilerplate loading logic
Manual error handling
Race conditions
No caching
Difficult synchronization

TanStack Query solves these automatically.

Declarative Data Fetching with useQuery

TanStack Query replaces imperative fetching with a declarative approach.

The core building blocks are:

Query Key
Query Function

Example:

_**

import { useQuery } from '@tanstack/react-query';

function ProductList() {
  const { data, isLoading, isError, error } = useQuery({
    queryKey: ['products'],
    queryFn: async () => {
      const res = await fetch('https://api.yourdomain.com/products');

      if (!res.ok) {
        throw new Error('Failed to fetch products');
      }

      return res.json();
    },
  });

  if (isLoading) {
    return <div>Loading products...</div>;
  }

  if (isError) {
    return <div>Error: {error.message}</div>;
  }

  return (
    <ul>
      {data.map((product) => (
        <li key={product.id}>{product.name}</li>
      ))}
    </ul>
  );
}_

**
Why This Is Powerful

Instead of manually controlling the fetch lifecycle, you simply describe:

“This component depends on the products query.”

TanStack Query handles everything else automatically.

Network Request Deduplication

Imagine three different components all requesting the same product list:

Sidebar
Dashboard
Analytics widget

Without TanStack Query:

3 components
3 fetch calls
3 HTTP requests

With TanStack Query:

queryKey: ['products']

TanStack Query recognizes the identical query key and:

Sends only ONE network request
Shares the response across all components
Prevents network waterfalls

This significantly improves performance.

Understanding the Cache Architecture

TanStack Query uses a strategy called:

Stale-While-Revalidate

The workflow looks like this:

Serve cached data immediately
Fetch fresh data in the background
Update the UI automatically if data changed

This creates extremely fast-feeling applications because users instantly see cached content instead of loading spinners.

Client State vs Server State

Before understanding TanStack Query, you need to separate two completely different categories of state.

Client State

This is synchronous state that exists entirely inside the browser.

Examples:

Modal visibility
Theme toggles
Sidebar state
Form inputs

This data is fully controlled by the frontend.

Server State

This is asynchronous state that lives remotely on a backend server or database.

Examples:

Product lists
User profiles
Notifications
Dashboard analytics
Orders from an API

Server state has unique challenges:

You do not own the data
Multiple users can modify it
It can become outdated instantly
It requires async network requests
It needs synchronization

Using useState + useEffect forces server state to behave like client state.

That creates problems like:

Duplicate requests
Boilerplate loading logic
Manual error handling
Race conditions
No caching
Difficult synchronization

TanStack Query solves these automatically.

Declarative Data Fetching with useQuery

TanStack Query replaces imperative fetching with a declarative approach.

The core building blocks are:

Query Key
Query Function

Example:

import { useQuery } from '@tanstack/react-query';

function ProductList() {
  const { data, isLoading, isError, error } = useQuery({
    queryKey: ['products'],
    queryFn: async () => {
      const res = await fetch('https://api.yourdomain.com/products');

      if (!res.ok) {
        throw new Error('Failed to fetch products');
      }

      return res.json();
    },
  });

  if (isLoading) {
    return <div>Loading products...</div>;
  }

  if (isError) {
    return <div>Error: {error.message}</div>;
  }

  return (
    <ul>
      {data.map((product) => (
        <li key={product.id}>{product.name}</li>
      ))}
    </ul>
  );
}

_
Why This Is Powerful

Instead of manually controlling the fetch lifecycle, you simply describe:

“This component depends on the products query.”

TanStack Query handles everything else automatically.

Network Request Deduplication

Imagine three different components all requesting the same product list:

Sidebar
Dashboard
Analytics widget

Without TanStack Query:

3 components
3 fetch calls
3 HTTP requests

With TanStack Query:

queryKey: ['products']

TanStack Query recognizes the identical query key and:

Sends only ONE network request
Shares the response across all components
Prevents network waterfalls

This significantly improves performance.

Understanding the Cache Architecture

TanStack Query uses a strategy called:

Stale-While-Revalidate

The workflow looks like this:

Serve cached data immediately
Fetch fresh data in the background
Update the UI automatically if data changed

This creates extremely fast-feeling applications because users instantly see cached content instead of loading spinners.
Understanding staleTime

Default:

staleTime: 0

Meaning:

Data becomes stale immediately after fetching.

Example optimization:

staleTime: 1000 * 60 * 5

This means:

Data is considered fresh for 5 minutes
No refetch happens during that period
Components reuse cached memory

Best for:

Country lists
User settings
Static configurations
Understanding gcTime (Garbage Collection)

Previously called cacheTime.

Default:

gcTime: 1000 * 60 * 5

Meaning:

When no component uses a query anymore:

The query becomes inactive
A garbage collection timer starts
Cache is deleted after 5 minutes

This prevents memory leaks.

Automatic Background Refetching

TanStack Query automatically keeps your application synchronized.

It refetches data when:

1. Components Mount Again

When a component using the query reappears.

2. Window Focus Changes

If the user switches tabs and comes back, the data revalidates automatically.

3. Network Reconnects

If the internet disconnects and reconnects, TanStack Query immediately synchronizes stale data.

4. Polling Intervals

Example:

refetchInterval: 10000

This refetches data every 10 seconds.

Useful for:

Real-time dashboards
Notifications
Live analytics
Mutating Data with useMutation

Fetching data is only half the story.

What happens after:

POST requests
PUT updates
DELETE operations

The browser cache immediately becomes outdated.

Example:

import {
  useMutation,
  useQueryClient,
} from '@tanstack/react-query';

const queryClient = useQueryClient();

const addProductMutation = useMutation({
  mutationFn: async (newProduct) => {
    const res = await fetch(
      'https://api.yourdomain.com/products',
      {
        method: 'POST',
        body: JSON.stringify(newProduct),
      }
    );

    return res.json();
  },

  onSuccess: () => {
    queryClient.invalidateQueries({
      queryKey: ['products'],
    });
  },
});
Cache Invalidation

Instead of manually updating arrays in state:

setProducts(...)

You invalidate the query:

queryClient.invalidateQueries({
  queryKey: ['products'],
});

TanStack Query then:

Marks the cache as stale
Automatically refetches fresh data
Synchronizes the UI with the database

This removes fragile state management logic entirely.

Using TanStack Query DevTools

Debugging async cache systems with console.log becomes painful quickly.

Install the DevTools:

npm install @tanstack/react-query-devtools

Setup:

import {
  QueryClient,
  QueryClientProvider,
} from '@tanstack/react-query';

import {
  ReactQueryDevtools,
} from '@tanstack/react-query-devtools';

const queryClient = new QueryClient();

export default function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <MainApplication />

      <ReactQueryDevtools
        initialIsOpen={false}
      />
    </QueryClientProvider>
  );
}_

Query Lifecycle States

Inside the DevTools panel, queries appear in different lifecycle states:

State Meaning
Fresh Data is still trusted
Stale Data exists but needs revalidation
Fetching Active network request
Inactive No component currently uses the query

This gives you full visibility into your async cache architecture.

Mastering Dependency Injection in .NET: A Software Engineer's Secret Weapon

victor mwangi — Wed, 27 May 2026 15:39:10 +0000

Imagine you are building a modern car. Instead of welding the engine directly to the chassis, you bolt it in. Why? Because if the engine breaks—or if you want to upgrade from a gas engine to an electric one—you don’t want to tear the whole car apart. You just unbolt the old one and slot the new one in.

In software engineering, Dependency Injection (DI) is that bolt.

If you are building applications in .NET, DI isn’t just a "nice-to-have" design pattern; it’s a core part of the framework. Let’s break down what DI is, why you need it, and how to master it in .NET.

What on Earth is Dependency Injection?

**
Before we talk about injection, let’s talk about dependencies. If Class A uses Class B to get its job done, Class A depends on Class B. Class B is a dependency.

Without DI, Class A creates Class B itself. Look at this tightly coupled mess:

_C#
public class Car
{
private Engine _engine;

public Car()
{
    // The car is trapped! It can only ever use this specific V8Engine.
    this._engine = new V8Engine(); 
}

}_
With Dependency Injection, we invert that control (hence Inversion of Control, or IoC). Instead of the Car creating the Engine, we "inject" the engine through the constructor:

_C#
public class Car
{
private readonly IEngine _engine;

// The car doesn't care what kind of engine it gets, as long as it implements IEngine
public Car(IEngine engine)
{
    _engine = engine;
}

}_
**

Why Should You Care? (The Benefits)

**Maintainability: If you need to change how Engine works, you don't risk breaking Car.

Testability: This is the big one. When writing unit tests for Car, you don't want to spin up a real database or hit a real API. With DI, you can inject a MockEngine and test the Car in isolation.

Flexibility: Want to swap your SQL database for MongoDB? Just change the registration in one central place, and the rest of your app keeps running seamlessly.

Service Lifetimes in .NET: The Big Three
The built-in .NET IoC container manages the creation and disposal of your dependencies. When you register a service, you have to tell .NET how long that service should live.

Choosing the wrong lifetime is the #1 cause of bugs in .NET DI. Here is the breakdown:

1. Transient (AddTransient)
How it works: A brand-new instance is created every single time it is requested.

Best used for: Lightweight, stateless services (like a quick formatting helper or a validation service).

2. Scoped (AddScoped)
How it works: An instance is created once per HTTP request (in web apps). All components handling that specific web request will share that same instance.

Best used for: Services that hold state for a single request, like your Entity Framework Core DbContext.

3. Singleton (AddSingleton)
How it works: An instance is created the first time it’s requested and lives forever until the application shuts down. Every subsequent request uses that exact same instance.

Best used for: Caching services, configuration settings, or anything that is expensive to create and needs to be shared globally.

⚠️ Danger Zone Warning: Never inject a Scoped service into a Singleton service. Because the Singleton lives forever, the Scoped service will get trapped inside it forever, effectively turning it into a Singleton. This is called a Captive Dependency, and it causes massive database connection bugs!

Wire It Up: A Real-World .NET Example
Let's look at how to actually implement this in a modern .NET Web API or Minimal API (Program.cs).

Step 1: Define the Contract and Implementation
_C#
public interface IEmailService
{
void SendEmail(string to, string subject);
}

public class SendGridEmailService : IEmailService
{
public void SendEmail(string to, string subject)
{
Console.WriteLine($"Email sent to {to} via SendGrid!");
}
}_
Step 2: Register it in Program.cs
Open your Program.cs file. This is where the magic happens. We register our IEmailService with the service collection.

_C#
var builder = WebApplication.CreateBuilder(args);

// Register your dependency here!
builder.Services.AddScoped();

var app = builder.Build();_
Step 3: Inject and Use It
Now, .NET will automatically look at the constructor of your Controllers or Minimal API endpoints, see that it requires an IEmailService, and pass it in.

_C#
app.MapPost("/register", (string email, IEmailService emailService) =>
{
// .NET automatically provided 'emailService' for us!
emailService.SendEmail(email, "Welcome to our App!");
return Results.Ok("User registered successfully");
});

app.Run();_
Wrapping Up
Dependency Injection isn't just an academic concept; it's the glue that keeps professional .NET applications clean, testable, and scalable. By shifting the responsibility of object creation from your classes to the .NET framework, you write code that is ready for change.

Next time you write a class, don't reach for the new keyword right away. Ask yourself: "Should this be injected instead?"

What are your thoughts on .NET's built-in DI container? Have you ever run into a captive dependency nightmare? Let's chat in the comments below!

Happy coding! 🚀