DEV Community: Harpreet Singh

GitHub Copilot's New AI Credits Explained (Without the Corporate Buzzwords)

Harpreet Singh — Tue, 02 Jun 2026 04:38:29 +0000

The internet seems to have collectively lost its mind over GitHub Copilot's new AI Credits system.

After reading dozens of Reddit threads, GitHub documentation, and angry comments, I've realized most developers aren't upset because the pricing changed.

They're upset because nobody understands it.

So here's the simplest explanation I can give.

The Old Copilot

Life was easy.

You paid your monthly subscription.

You used Copilot.

Nobody cared how many prompts you sent.

Nobody checked a dashboard.

Nobody thought about "consumption."

Copilot was basically Netflix.

Pay once. Watch as much as you want.

The New Copilot

Now you get a monthly credit allowance.

Every AI interaction consumes some amount of those credits.

The amount depends on:

Which model you use
How much context you send
Whether you're using chat, agent mode, or code review
How much work the model performs

In other words:

Not all prompts cost the same.

Why People Are Freaking Out

Imagine buying unlimited coffee for years.

One day the coffee shop says:

"Good news! We're introducing Coffee Credits."

Now every drink has a different price.

Small coffee = 1 credit

Large coffee = 5 credits

Fancy coffee = 20 credits

Nobody knows the price until after they order.

That's basically how developers feel right now.

The Hidden Problem

The issue isn't that credits exist.

Most AI products already have usage-based pricing.

The issue is predictability.

Developers want answers to simple questions:

How many prompts do I get?
How much will a coding session cost?
How many days will my credits last?

Right now many developers have no idea.

And uncertainty feels expensive.

What Actually Burns Credits Fast?

Based on community reports, the biggest credit consumers appear to be:

Agent Mode

When an AI agent explores files, analyzes code, runs multiple reasoning steps, and generates large changes, consumption can increase quickly.

Large Context Windows

Sending an entire codebase is dramatically different from sending a single function.

Premium Models

Not all models are priced equally.

Some reasoning-focused models consume significantly more credits than lightweight models.

Repeated Iteration

"Try again."

"One more thing."

"Can you improve this?"

Those innocent follow-up requests add up.

What Most Developers Will Probably Do

I suspect we'll see three groups emerge.

Group 1: Casual Users

These people will barely notice.

Autocomplete and occasional chat requests won't come close to exhausting their allowance.

Group 2: Heavy AI Users

These are developers who spend all day with agents, code reviews, architecture discussions, and large refactors.

They're going to hit limits much faster than expected.

Group 3: AI Optimizers

This group will start mixing tools.

ChatGPT for planning
Claude for reasoning
Copilot for IDE integration
Local models for experimentation

Essentially treating AI like a toolbox instead of a single platform.

My Take

The new system isn't necessarily bad.

But GitHub has accidentally introduced something developers hate:

Budgeting.

For years, Copilot felt like a utility.

Now it feels like a cloud service.

And cloud services always lead to the same question:

"Wait... how much did that cost?"

The real challenge for GitHub isn't pricing.

It's making developers feel confident that they understand the pricing.

Because right now, most of us are staring at AI credits the same way we stare at AWS bills:

Slightly confused.

A little concerned.

And afraid to click refresh.

GitHub Copilot Just Invented Loot Boxes for Coding

Harpreet Singh — Tue, 02 Jun 2026 04:20:47 +0000

Remember when GitHub Copilot was simple?

You paid your monthly subscription.
You wrote code.
The AI occasionally hallucinated.
Everyone moved on with their lives.

Now I need a finance degree to understand whether asking Claude to rename a variable will cost me three credits, thirty credits, or my firstborn child.

GitHub's new AI Credits system officially landed this month, replacing the old request-based model with token-based billing. On paper, it sounds reasonable:

"Pay for what you use."

In reality, it feels more like:

"Good luck figuring out what you used."

Developers across Reddit are posting screenshots showing massive chunks of their monthly allowance disappearing after only a handful of agent requests, code reviews, or debugging sessions.

The funniest part?

For the last two years, AI companies trained us to write better prompts.

"Give more context."
"Provide the entire codebase."
"Let the agent reason deeply."
"Use autonomous workflows."

Now the bill arrives and suddenly every extra token feels like ordering guacamole at the airport.

We're being financially punished for following the best practices they taught us.

The old Copilot experience was predictable:

Pay monthly
Use it constantly
Never think about accounting

The new experience:

Open billing dashboard
Watch credits evaporate
Start calculating token economics
Wonder if asking a follow-up question is worth it

Some developers have already started moving heavy reasoning work back to ChatGPT, Claude, Cursor, Cline, or local models while using Copilot only for IDE convenience.

And honestly?

That's probably the unintended consequence.

GitHub spent years convincing us that AI should be embedded into every step of software development.

Now they're teaching us to ration prompts like we're living through the Great Token Depression.

The most ironic outcome is that Copilot might accidentally make developers better engineers.

Because before every prompt we'll ask:

"Do I really need AI for this?"

And for the first time since 2023, the answer might be:

"No, I can probably write the damn function myself."

The Worst Time to Quit Software Engineering Might Be Right Now

Harpreet Singh — Thu, 28 May 2026 01:18:28 +0000

I understand why so many people are questioning software engineering right now.

Every week there’s another headline saying AI will replace developers.

Junior engineers are worried there won’t be jobs.
Senior engineers are wondering how long their experience will stay valuable.
And honestly, if you spend enough time on tech Twitter or LinkedIn, it can start feeling like the industry is collapsing in real time.

But after using AI heavily in my day-to-day work as a software engineer, I’ve started seeing things differently.

AI didn’t make me feel less useful.

It made me feel more capable.

Before AI became part of my workflow, a lot of engineering time disappeared into things that were mentally draining but necessary:

repetitive refactoring
debugging small issues
writing boilerplate
digging through documentation
trying to remember syntax
cleaning up legacy code
writing SQL queries
optimizing simple functions
translating vague tickets into technical tasks

None of these tasks were impossible.

They were just time-consuming.

Now, a lot of that friction is reduced dramatically.

One of the biggest changes I noticed was backlog cleanup.

Tasks that used to sit untouched because nobody wanted to deal with them suddenly became manageable.

Not because AI magically solved everything.

But because it helped reduce the “mental startup cost” of difficult tasks.

Sometimes all you need is:

a starting point
a refactored example
help understanding unfamiliar code
a faster debugging path
quick documentation summaries

That momentum matters more than people realize.

A task that feels overwhelming at 9AM suddenly becomes achievable when AI helps break it down.

I also noticed we started delivering faster as a team.

Not in a “replace developers with AI” kind of way.

I Built a VS Code Extension to Detect Missing i18n Keys Before Production

Harpreet Singh — Thu, 09 Apr 2026 01:56:34 +0000

if you’ve ever shipped a UI bug where users see something like this:

settings.labels.confirm_action_final_v2_FIXED

…then you already know how painful localization bugs can be.

Missing i18n keys are one of those problems that seem small until they hit production. They slip through code review, hide inside large translation files, and usually appear when it’s too late.

After dealing with this frustration too many times, I decided to build a better solution.

The Problem

In multilingual apps, it’s easy to:

Reference translation keys that don’t exist
Leave hardcoded untranslated strings in components
Break localization during refactoring without noticing

Most teams catch these issues manually, which is slow, error-prone, and honestly exhausting.

The Solution: Localization Scanner for VS Code

I created a VS Code extension that scans your project and detects:

Missing translation keys
Broken localization references
Hardcoded untranslated UI strings

Instead of manually searching JSON files and comparing keys, the extension flags issues directly inside VS Code while you work.

Why I Built It

I wanted something that would:

Save debugging time
Prevent embarrassing production bugs
Help teams catch localization issues earlier in development

Localization should be automatic and reliable not a guessing game.

Who It’s For

This tool is useful if you build apps with:

React
Vue
Next.js
Any frontend app using i18n translation files
What’s Next

I’m actively improving the extension and would love feedback from developers working on multilingual apps.

What’s the most frustrating localization bug you’ve dealt with?

How to find missing i18n keys without losing your mind (or your job)

Harpreet Singh — Thu, 12 Mar 2026 00:03:54 +0000

Look, we’ve all been there. You just pushed a massive feature, you’re feeling like a genius, and then the "urgent" Slack message hits.

Your manager sends a screenshot from the production site, and instead of a nice "Submit" button, the users are seeing:

It’s embarrassing. It looks like the code is leaking. And honestly, trying to keep your source code and your en.json file in sync manually is a one-way ticket to burnout. I got tired of the manual "Find in Files" dance, so I built a tool to handle it.

Introducing Localization Scanner

I created this VS Code extension because I wanted something that stayed out of the way until I actually needed it. It’s basically a safety net for your i18n workflow.

What it actually does for you:

Finds the "Ghosts": It scans your code and tells you exactly which keys you used that don't actually exist in your translation files.

The "Did I really type that?" Detector: It finds hardcoded strings that you forgot to wrap in a translation function. It’s smart enough to know that className="mb-4" isn't a translation, but "Are you sure you want to delete this?" definitely is.

Respects your RAM: I hate extensions that slow down my IDE. This has zero performance impact because it only runs when you hit the refresh button.

Click and Fix: You see a missing key in the sidebar, you click it, and it takes you right to the line where you missed it.

Check it out
If you're working with React, Vue, or Next.js and you’re tired of shipping raw JSON keys to your users, give this a go. It’s open source and easy to set up with a tiny scan.json file.

Marketplace

GitHub

Please download it, use it, and leave a nice review. If I see a 5-star rating, I might actually finish my other 14 pending side projects. If you leave a bad one, I’m telling my mom. lol. But seriously, your feedback keeps me going!

Let me know if it saves you from a "broken UI" bug report. I'd love to hear your feedback or see a PR if you want to add more features!

vscodextensions #i18n #webdev #typescript #javascript #programming

Blob Storage as a Database: Dumb Idea or Underrated Trick?

Harpreet Singh — Mon, 20 Oct 2025 01:53:31 +0000

Subtitle: Why I Tried Storing Structured Data in Blobs and What Actually Happened

1. The Hook

Everyone tells you not to use Azure Blob Storage as a database. Naturally, I decided to try it anyway.

I had a use case that didn’t justify spinning up SQL or Cosmos DB just some structured, semi-static JSON data I needed to persist cheaply and access globally. Blob Storage seemed too simple to ignore.

So I asked myself: Could I push Blob Storage to act like a database? Spoiler: it kind of worked.

2. The Concept

Here’s the basic idea:

Each record is a blob (for example, a JSON file).
Each container is a logical table.
The blob name acts as a primary key (like users/user-123.json).
Blob versioning gives you time-travel or history for free.

A minimal .NET example:

var blob = containerClient.GetBlobClient($"users/{userId}.json");
await blob.UploadAsync(BinaryData.FromObjectAsJson(user));

You can later read it back:

var blob = containerClient.GetBlobClient($"users/{userId}.json");
var data = await blob.DownloadContentAsync();
var user = data.Value.Content.ToObjectFromJson<User>();

No schema, no migrations, no SQL. Just blobs.

3. The Benefits (Why It’s Not Completely Dumb)

Ridiculously cheap: fractions of a cent per GB.
Globally replicated: can integrate with CDN.
Schema-flexible: store any JSON structure.
Built-in versioning: blob versioning acts like record history.
Excellent for static or rarely-mutating data: configurations, static datasets, logs, or precomputed AI outputs.

Real-world use case: I stored pre-rendered dashboard snapshots in Blob Storage and served them directly through a CDN. Instant load times, no compute, no database calls.

4. The Pain Points (Why It Is Kinda Dumb)

No query engine: You can’t filter or search without loading everything.
No transactions or concurrency handling.
High latency: Every read/write is a network call.
Limited atomic operations.
Metadata scaling: Listing blobs becomes slow and costly after tens of thousands.

At around 50,000 blobs, listing performance dropped noticeably. I ended up adding a lightweight Redis index to keep track of blob keys.

5. The Hybrid Trick

Here’s where it got interesting.

What if Blob Storage isn’t the database, but a tier of one?

For example:

App -> Redis index -> Blob for data payload -> CDN edge cache

This hybrid approach works beautifully:

Redis stores keys and metadata for fast lookups.
Blob Storage holds large, immutable payloads.
CDN handles global caching.

Now you’ve got something fast, cheap, and resilient without pretending Blob Storage is SQL Server.

6. The Verdict

Blob Storage won’t replace your relational database. It’s not built for dynamic queries, transactions, or real-time updates.

But as a cold-storage layer, append-only log, or versioned config repository, it’s surprisingly elegant. And when combined with in-memory indexes or CDN caching, it can punch far above its weight.

Blob Storage isn’t dumb. It’s just misunderstood.

Used wisely, it can make your architecture simpler, cheaper, and more scalable.

7. Optional Extras

If you want to take this further:

Benchmark upload/download speed with .OpenReadAsync() and parallel uploads.
Use Azure Functions to auto-index blob metadata.
Explore Blob Storage versioning for immutable event sourcing.

Final Thoughts

I wouldn’t recommend building your startup’s core database on blobs. But if you have structured, infrequently-changing data that doesn’t need queries it might just be the most underrated trick in Azure.

What do you think? Would you ever use Blob Storage as a database?

Securely Configuring Azure Blob Storage in .NET Web API

Harpreet Singh — Fri, 26 Sep 2025 03:33:33 +0000

When you’re building a .NET Web API that integrates with Azure Blob Storage, one of the most important things to figure out is how you’re going to secure it. Hardcoding connection strings might get you up and running quickly, but it’s definitely not something you want to do in production.

The good news is that Azure gives us a few different options, from simple connection strings to more advanced setups like SAS tokens and managed identities. In this post, we’ll walk through each option and look at some real-world examples.

1. Getting Started – Azure Storage SDK

First, install the Azure Storage Blob package:

dotnet add package Azure.Storage.Blobs

Next, register the BlobServiceClient in your Web API:

using Azure.Storage.Blobs;

builder.Services.AddSingleton(_ =>
{
    var connectionString =  builder.Configuration.GetConnectionString("AzureBlobStorage");
    return new BlobServiceClient(connectionString);
});

This gives you a ready-to-use BlobServiceClient anywhere in your app via dependency injection.

2. Option 1 – Connection Strings (Quick, But Not Secure)

In appsettings.json:

{
  "ConnectionStrings": {
    "AzureBlobStorage": "DefaultEndpointsProtocol=https;AccountName=youraccount;AccountKey=yourkey;EndpointSuffix=core.windows.net"
  }
}

This works fine for local development, but storing account keys in config is risky. If someone gets access to that file, they basically have full control of your storage account. Use it for quick demos or testing, but avoid it in production.

3. Option 2 – Shared Access Signatures (SAS Tokens)

SAS tokens are a much safer way to give out temporary, scoped access. Instead of exposing your account key, you can generate a token that’s valid only for a short period of time and only for specific actions (read, write, delete, etc.).

Example:

var blobUri = new Uri("https://youraccount.blob.core.windows.net/container/blob.txt?<SAS_TOKEN>");
var blobClient = new BlobClient(blobUri);

This way, your Web API never deals with account keys. Instead, you just hand out short-lived tokens. Super handy for scenarios where users need to upload or download files directly.

4. Option 3 – Managed Identity + Azure AD (Best for Production)

The best option in most production setups is to avoid managing secrets altogether and rely on Azure AD authentication with Managed Identities.

How it works:

Enable Managed Identity for your Web API in Azure.
Assign your Web API’s identity the Storage Blob Data Contributor role in your Storage Account.
Use DefaultAzureCredential in your app to handle authentication automatically.

using Azure.Identity;
using Azure.Storage.Blobs;

builder.Services.AddSingleton(_ =>
{
    var accountUrl = new Uri("https://youraccount.blob.core.windows.net/");
    return new BlobServiceClient(accountUrl, new DefaultAzureCredential());
});

What is `DefaultAzureCredential()`?

DefaultAzureCredential is part of the Azure Identity library. Think of it as an authentication Swiss Army knife. It tries multiple authentication methods in order until one works:

Environment variables
Managed Identity (when running in Azure)
Your logged-in account in Visual Studio or Azure CLI (when running locally)

This means you don’t have to change your code between development and production. It “just works” in both environments.

5. Example: Uploading a File

Here’s a simple example of uploading a file using the injected BlobServiceClient:

[ApiController]
[Route("api/[controller]")]
public class FilesController : ControllerBase
{
    private readonly BlobServiceClient _blobServiceClient;

    public FilesController(BlobServiceClient blobServiceClient)
    {
        _blobServiceClient = blobServiceClient;
    }

    [HttpPost("upload")]
    public async Task<IActionResult> UploadFile(IFormFile file)
    {
        var container = _blobServiceClient.GetBlobContainerClient("uploads");
        await container.CreateIfNotExistsAsync();

        var blobClient = container.GetBlobClient(file.FileName);

        using var stream = file.OpenReadStream();
        await blobClient.UploadAsync(stream, overwrite: true);

        return Ok(new { blobUrl = blobClient.Uri.ToString() });
    }
}

This controller creates the container if it doesn’t exist, uploads the file, and returns the blob’s URL.

Wrapping Up

Connection strings - good for quick testing, not safe for production.
SAS tokens - great for temporary, scoped access.
Managed identities + Azure AD - the secure, production-ready way.
DefaultAzureCredential - makes local and cloud authentication seamless.

When you’re designing APIs, always think about who should access your storage and for how long. Moving away from secrets toward managed identities and SAS tokens is the key to keeping your apps both secure and scalable.

🚀 In a future post, we’ll look at serving files securely from Blob Storage through your Web API, including download patterns and caching strategies.

Error Boundaries in React with TypeScript: Going Beyond the Basics

Harpreet Singh — Wed, 24 Sep 2025 22:59:20 +0000

We all know the classic React error boundary: wrap a component, catch rendering errors, and show a fallback UI. But if you’ve worked on real-world apps, you know the “textbook” approach often falls short. Async errors, route-specific crashes, and logging needs require a more advanced setup.

In this article, I’ll walk you through a TypeScript-first approach to error boundaries that makes your React apps more resilient, easier to debug, and more user-friendly.

1. The Strongly Typed Error Boundary

First, let’s define a solid, TypeScript-friendly error boundary that handles errors gracefully and logs them:

import React from "react";

interface ErrorBoundaryProps {
  children: React.ReactNode;
  fallback?: React.ReactNode;
}

interface ErrorBoundaryState {
  hasError: boolean;
  error?: Error;
}

export class AppErrorBoundary extends React.Component<ErrorBoundaryProps, ErrorBoundaryState> {
  state: ErrorBoundaryState = { hasError: false };

  static getDerivedStateFromError(error: Error): ErrorBoundaryState {
    return { hasError: true, error };
  }

  componentDidCatch(error: Error, info: React.ErrorInfo) {
    // Log to monitoring service
    console.error("Logged Error:", error, info);
  }

  render() {
    if (this.state.hasError) {
      return this.props.fallback ?? <h2>Something went wrong.</h2>;
    }
    return this.props.children;
  }
}

This gives you type safety for both props and state while keeping your error handling centralized.

2. Route-Level Boundaries: Isolate the Crashes

Instead of one giant boundary at the root of your app, wrap specific routes or features. This way, a single failing page doesn’t crash your whole app:

import { AppErrorBoundary } from "./AppErrorBoundary";
import Dashboard from "./Dashboard";

function DashboardRoute() {
  return (
    <AppErrorBoundary fallback={<h2>Dashboard failed to load.</h2>}>
      <Dashboard />
    </AppErrorBoundary>
  );
}

Users can still navigate your app, even if one page has an error.

3. Handling Async and Event Errors

React error boundaries don’t catch errors in async/await or event handlers. To fix this, wrap your async functions:

function safeAsync<T extends (...args: any[]) => Promise<any>>(fn: T) {
  return async (...args: Parameters<T>): Promise<ReturnType<T>> => {
    try {
      return await fn(...args);
    } catch (err) {
      console.error("Async error:", err);
      throw err; // optional: let ErrorBoundary catch it if needed
    }
  };
}

// Usage
const handleClick = safeAsync(async () => {
  throw new Error("Boom!");
});

<button onClick={handleClick}>Click Me</button>;

This ensures async crashes are logged and can be optionally caught by your boundary.

4. Resettable Boundaries: Let Users Recover

A frozen fallback UI is frustrating. With react-error-boundary, you can provide a retry button:

import { ErrorBoundary } from "react-error-boundary";

function Fallback({ error, resetErrorBoundary }: {
  error: Error;
  resetErrorBoundary: () => void;
}) {
  return (
    <div>
      <p>Something went wrong: {error.message}</p>
      <button onClick={resetErrorBoundary}>Try Again</button>
    </div>
  );
}

<ErrorBoundary
  FallbackComponent={Fallback}
  onError={(error) => console.error("Caught by boundary:", error)}
  resetKeys={[/* state/props that trigger reset */]}
>
  <Dashboard />
</ErrorBoundary>

Users can recover without having to refresh the page.

5. Layered Approach for Production-Ready Apps

Combine these strategies for a robust setup:

Global boundary - catches catastrophic failures.
Route/component boundaries - isolate crashes.
Async wrappers + logging - capture what React misses.
Resettable fallbacks - improve user experience.

This layered approach keeps your app resilient and your users happy.

Wrapping Up

React’s built-in error boundaries are just the starting point. In real apps, you need a TypeScript-first, layered strategy:

Strong typing for safety
Logging for observability
Isolation for reliability
Recovery for UX

This way, errors are no longer showstoppers, they’re just part of a manageable system.

If you enjoyed this, check out my other articles for more advanced, production-ready patterns.

Managing API Version Transitions Across Teams

Harpreet Singh — Wed, 24 Sep 2025 03:24:37 +0000

API versioning solves the breaking changes problem, but in practice, coordination between backend and frontend teams is often where the real pain happens. Deploying a new version too soon can leave frontend devs scratching their heads wondering why types don’t match or why fields disappeared.

Here are strategies (inspired by real-world team war stories) to make version transitions smoother:

1. Run Versions in Parallel

Keep v1 live as “stable” (even if marked as deprecated).
Deploy v2 alongside it.
Give frontend teams a clear migration window (e.g. 60–90 days).
Avoid hard cutovers unless the app is internal or you control all clients.

✅ This buys teams breathing room instead of rushing migrations.

2. Contracts with OpenAPI Specs

Treat your OpenAPI spec as a contract between backend and frontend.
Diff spec files between versions to see exactly what changed.
Share updated spec files as part of your release notes.

Why this matters

OpenAPI specs are a single source of truth. Backend teams define what the API should look like, while frontend teams consume it without relying on guesswork or Slack messages.

Diffing versions

You can literally diff spec files between versions:

openapi-diff old-spec.yaml new-spec.yaml

This highlights:

✅ Endpoints that stayed the same
⚠️ Fields that changed type (e.g., int → string)
❌ Endpoints that were removed (breaking change)

Sharing specs in releases

Include spec files alongside your release notes:

openapi-v1.yaml
openapi-v2.yaml

Frontend teams can generate clients or update mocks immediately, even before the backend deploys.

Living documentation

Host multiple Swagger/OpenAPI docs so consumers always know what’s live:

/swagger/v1/swagger.json
/swagger/v2/swagger.json

This makes it crystal clear which version is in use and prevents "I think this field changed?" confusion.

3. Mock Servers for Multiple Versions

Spin up mock servers from OpenAPI specs.
Frontend teams can test against v1 and v2 simultaneously.
Migration code can be written before the backend is even live.

✅ You catch breaking changes early, not during frantic late-night debugging.

4. TypeScript (or Client) Code Generation

Generate version-specific TypeScript clients from OpenAPI specs.
Compile-time errors show exactly what changed.
Keep separate packages/namespaces for v1 and v2 to avoid confusion.

✅ Prevents 3-hour debugging sessions where types don’t match the API anymore.

5. Deprecation Flags = Communication

Mark older versions as deprecated using attributes in code.
Return deprecation warnings in response headers.
Document sunset timelines in your API docs.

✅ Gives frontend teams time to plan migrations instead of dealing with surprises.

Wrapping Up

Smooth version transitions are as much about team coordination as they are about code. By running versions in parallel, leaning on OpenAPI specs, using mock servers, and generating client types, you can save both backend and frontend teams a ton of headaches.

The rule of thumb? Don’t surprise your clients. Version transitions should feel predictable, not like debugging a ghost API.

✍️ If you enjoyed this, check out my previous article on API Versioning in .NET Web API for a hands-on implementation guide.

Implementing Caching in .NET Core Web API

Harpreet Singh — Tue, 23 Sep 2025 23:35:20 +0000

Caching is one of the most effective ways to improve the performance and scalability of your APIs. By storing frequently requested data, you can reduce database load, speed up response times, and handle higher traffic without degrading performance.

In this article, we’ll explore memory caching, response caching, and distributed caching in .NET Core Web API with practical examples.

1. Response Caching

Response caching allows responses from your API to be stored and reused for a specified duration.

Setup in `Program.cs`

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllers();
builder.Services.AddResponseCaching();
var app = builder.Build();
app.UseResponseCaching();
app.MapControllers();
app.Run();

Using Response Caching in Controller

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    [HttpGet]
    [ResponseCache(Duration = 60, Location = ResponseCacheLocation.Client)]
    public IActionResult Get()
    {
        var products = new[] { "Product 1", "Product 2" };
        return Ok(products);
    }
}

✅ The API response will be cached for 60 seconds on the client.

2. In-Memory Caching

In-memory caching stores data in the server’s memory.

Setup in `Program.cs`

builder.Services.AddMemoryCache();

Using In-Memory Cache in Controller

[ApiController]
[Route("api/[controller]")]
public class OrdersController : ControllerBase
{
    private readonly IMemoryCache _cache;

    public OrdersController(IMemoryCache cache)
    {
        _cache = cache;
    }

    [HttpGet]
    public IActionResult GetOrders()
    {
        const string cacheKey = "orders_list";
        if (!_cache.TryGetValue(cacheKey, out string[] orders))
        {
            // Simulate fetching from database
            orders = new[] { "Order 1", "Order 2" };

            var cacheOptions = new MemoryCacheEntryOptions
            {
                AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(5),
                SlidingExpiration = TimeSpan.FromMinutes(2)
            };

            _cache.Set(cacheKey, orders, cacheOptions);
        }

        return Ok(orders);
    }
}

✅ Reduces repeated database calls for frequently accessed data.

3. Distributed Caching

Distributed caching stores cache outside of the application, suitable for multi-server environments.

Setup with Redis

dotnet add package Microsoft.Extensions.Caching.StackExchangeRedis

builder.Services.AddStackExchangeRedisCache(options =>
{
    options.Configuration = "localhost:6379";
    options.InstanceName = "MyApp_";
});

Using Distributed Cache in Controller

[ApiController]
[Route("api/[controller]")]
public class CustomersController : ControllerBase
{
    private readonly IDistributedCache _cache;

    public CustomersController(IDistributedCache cache)
    {
        _cache = cache;
    }

    [HttpGet]
    public async Task<IActionResult> GetCustomers()
    {
        var cacheKey = "customers_list";
        var cachedData = await _cache.GetStringAsync(cacheKey);

        if (string.IsNullOrEmpty(cachedData))
        {
            var customers = new[] { "Customer 1", "Customer 2" };
            cachedData = System.Text.Json.JsonSerializer.Serialize(customers);
            var options = new DistributedCacheEntryOptions
            {
                AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(10)
            };

            await _cache.SetStringAsync(cacheKey, cachedData, options);
        }

        var result = System.Text.Json.JsonSerializer.Deserialize<string[]>(cachedData);
        return Ok(result);
    }
}

✅ Works across multiple instances of your API in a load-balanced environment.

Wrapping Up

Caching is essential for improving API performance, scalability, and user experience. In .NET Core Web API, you have several options:

Response Caching: For simple, client-side caching of responses.
In-Memory Caching: Quick caching within a single server instance.
Distributed Caching: Scalable caching across multiple servers (e.g., Redis).

By implementing caching appropriately, you can drastically reduce database load and improve response times for your users.

API Versioning in .NET Web API

Harpreet Singh — Tue, 23 Sep 2025 23:06:43 +0000

As your API evolves, breaking changes are inevitable. Introducing API versioning ensures that your clients continue to work without disruption while you introduce new features and improvements.

This guide covers how to implement API versioning in .NET Web API with practical examples, including a clean BaseApiController approach for centralized configuration.

Why API Versioning?

Backward Compatibility: Old clients continue to work with previous versions.
Smooth Upgrades: You can introduce new endpoints without breaking existing functionality.
Clear Communication: Clients know which version they are using.
Better Lifecycle Management: Easier to deprecate old versions gradually.

Step 1: Add Required NuGet Package

dotnet add package Microsoft.AspNetCore.Mvc.Versioning

This package provides tools to version your API by query string, header, or URL segment.

Step 2: Configure Versioning in `Program.cs`

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();

// Add API versioning
builder.Services.AddApiVersioning(options =>
{
    options.AssumeDefaultVersionWhenUnspecified = true;
    options.DefaultApiVersion = new Microsoft.AspNetCore.Mvc.ApiVersion(1, 0);
    options.ReportApiVersions = true; // Returns API versions in response headers
});

var app = builder.Build();

app.MapControllers();
app.Run();

Step 3: Create a BaseApiController

A BaseApiController can hold common configuration, attributes, and helper methods for all versioned controllers.

using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/v{version:apiVersion}/[controller]")]
public abstract class BaseApiController : ControllerBase
{
    protected IActionResult ApiResponse(object data, int statusCode = 200)
    {
        return StatusCode(statusCode, new
        {
            Status = statusCode,
            Data = data,
            Version = HttpContext.GetRequestedApiVersion()?.ToString()
        });
    }
}

All your versioned controllers can now inherit from this base controller for consistent behavior.

Step 4: Versioning Controllers Using BaseApiController

[ApiVersion("1.0")]
public class ProductsController : BaseApiController
{
    [HttpGet]
    public IActionResult Get() => ApiResponse(new[] { "Product 1", "Product 2" });
}

[ApiVersion("2.0")]
public class ProductsV2Controller : BaseApiController
{
    [HttpGet]
    public IActionResult Get() => ApiResponse(new[] { "Product A", "Product B", "Product C" });
}

This keeps your code DRY and centralizes versioning logic.

Step 5: Query String and Header-Based Versioning

Query string example:

GET /api/orders?api-version=1.0
GET /api/orders?api-version=2.0

Header-based configuration in Program.cs:

builder.Services.AddApiVersioning(options =>
{
    options.AssumeDefaultVersionWhenUnspecified = true;
    options.DefaultApiVersion = new ApiVersion(1, 0);
    options.ApiVersionReader = new HeaderApiVersionReader("x-api-version");
    options.ReportApiVersions = true;
});

Clients can now set the header:

x-api-version: 2.0

Step 6: Deprecating Versions

[ApiVersion("1.0", Deprecated = true)]
public class OldController : BaseApiController
{
    [HttpGet]
    public IActionResult Get() => ApiResponse("This version is deprecated");
}

Headers will indicate deprecation.

Step 7: Swagger Integration for Versioned APIs

builder.Services.AddSwaggerGen(options =>
{
    options.SwaggerDoc("v1", new Microsoft.OpenApi.Models.OpenApiInfo { Title = "API v1", Version = "v1" });
    options.SwaggerDoc("v2", new Microsoft.OpenApi.Models.OpenApiInfo { Title = "API v2", Version = "v2" });
});

var app = builder.Build();
app.UseSwagger();
app.UseSwaggerUI(options =>
{
    options.SwaggerEndpoint("/swagger/v1/swagger.json", "API v1");
    options.SwaggerEndpoint("/swagger/v2/swagger.json", "API v2");
});

Wrapping Up

Using a BaseApiController centralizes common logic, keeps controllers DRY, and makes managing API versioning cleaner. Combined with URL, query string, or header-based versioning and Swagger integration, this approach provides a flexible and maintainable API structure in .NET.

Global Exception Handling in .NET Web API

Harpreet Singh — Tue, 23 Sep 2025 04:50:07 +0000

When building APIs, one of the most common mistakes developers make is scattering try-catch blocks across controllers. Not only does this make the code messy, but it also leads to inconsistent error responses for clients.

The solution? Global Exception Handling using middleware in .NET Web API.

Why Global Exception Handling?

Centralized error management: All exceptions go through one pipeline.
Consistent responses: Clients always receive structured error messages.
Cleaner controllers: No need for repetitive try-catch blocks.
Better logging: Easier to log all unhandled exceptions.

Step 1: Create Exception Handling Middleware

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

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

    public async Task InvokeAsync(HttpContext context)
    {
        try
        {
            await _next(context);
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Unhandled exception occurred.");
            await HandleExceptionAsync(context, ex);
        }
    }

    private static Task HandleExceptionAsync(HttpContext context, Exception exception)
    {
        context.Response.ContentType = "application/json";
        context.Response.StatusCode = (int)HttpStatusCode.InternalServerError;

        var response = new
        {
            StatusCode = context.Response.StatusCode,
            Message = "Internal Server Error. Please try again later.",
            Detail = exception.Message // Optional: remove in production
        };

        return context.Response.WriteAsJsonAsync(response);
    }
}

Step 2: Register Middleware in `Program.cs`

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

// Add global exception middleware
app.UseMiddleware<GlobalExceptionMiddleware>();

app.MapControllers();
app.Run();

Step 3: Testing the Middleware

Add a controller that throws an exception:

[ApiController]
[Route("api/[controller]")]
public class TestController : ControllerBase
{
    [HttpGet("error")]
    public IActionResult GetError()
    {
        throw new InvalidOperationException("This is a test exception.");
    }
}

Call GET /api/test/error and you should get a JSON response like:

{
  "StatusCode": 500,
  "Message": "Internal Server Error. Please try again later.",
  "Detail": "This is a test exception."
}

Step 4: Optional Enhancements

Environment-aware messages: Hide Detail in production.
Custom exception types: Handle validation exceptions differently.
Structured logging: Include correlation IDs for tracing.
Problem Details RFC 7807: Return standardized error responses.

Wrapping Up

Global exception handling keeps your Web API clean, consistent, and easier to maintain. By centralizing error management, you free controllers from repetitive try-catch blocks, make logging easier, and ensure clients always receive a predictable response.

This pattern is a must-have for any production-ready .NET Web API.

DEV Community: Harpreet Singh

GitHub Copilot's New AI Credits Explained (Without the Corporate Buzzwords)

The Old Copilot

The New Copilot

Why People Are Freaking Out

The Hidden Problem

What Actually Burns Credits Fast?

Agent Mode

Large Context Windows

Premium Models

Repeated Iteration

What Most Developers Will Probably Do

Group 1: Casual Users

Group 2: Heavy AI Users

Group 3: AI Optimizers

My Take

GitHub Copilot Just Invented Loot Boxes for Coding

The Worst Time to Quit Software Engineering Might Be Right Now

I Built a VS Code Extension to Detect Missing i18n Keys Before Production

How to find missing i18n keys without losing your mind (or your job)

vscodextensions #i18n #webdev #typescript #javascript #programming

Blob Storage as a Database: Dumb Idea or Underrated Trick?

1. The Hook

2. The Concept

3. The Benefits (Why It’s Not Completely Dumb)

4. The Pain Points (Why It Is Kinda Dumb)

5. The Hybrid Trick

6. The Verdict

7. Optional Extras

Final Thoughts

Securely Configuring Azure Blob Storage in .NET Web API

1. Getting Started – Azure Storage SDK

2. Option 1 – Connection Strings (Quick, But Not Secure)

3. Option 2 – Shared Access Signatures (SAS Tokens)

4. Option 3 – Managed Identity + Azure AD (Best for Production)

What is DefaultAzureCredential()?

5. Example: Uploading a File

Wrapping Up

Error Boundaries in React with TypeScript: Going Beyond the Basics

1. The Strongly Typed Error Boundary

2. Route-Level Boundaries: Isolate the Crashes

3. Handling Async and Event Errors

4. Resettable Boundaries: Let Users Recover

5. Layered Approach for Production-Ready Apps

Wrapping Up

Managing API Version Transitions Across Teams

1. Run Versions in Parallel

2. Contracts with OpenAPI Specs

Why this matters

Diffing versions

Sharing specs in releases

Living documentation

3. Mock Servers for Multiple Versions

4. TypeScript (or Client) Code Generation

5. Deprecation Flags = Communication

Wrapping Up

Implementing Caching in .NET Core Web API

1. Response Caching

Setup in Program.cs

Using Response Caching in Controller

2. In-Memory Caching

Setup in Program.cs

Using In-Memory Cache in Controller

3. Distributed Caching

Setup with Redis

Using Distributed Cache in Controller

Wrapping Up

API Versioning in .NET Web API

Why API Versioning?

Step 1: Add Required NuGet Package

Step 2: Configure Versioning in Program.cs

Step 3: Create a BaseApiController

Step 4: Versioning Controllers Using BaseApiController

Step 5: Query String and Header-Based Versioning

Step 6: Deprecating Versions

Step 7: Swagger Integration for Versioned APIs

Wrapping Up

Global Exception Handling in .NET Web API

Why Global Exception Handling?

Step 1: Create Exception Handling Middleware

What is `DefaultAzureCredential()`?

Setup in `Program.cs`

Setup in `Program.cs`

Step 2: Configure Versioning in `Program.cs`

Step 2: Register Middleware in `Program.cs`