Forem: Harpreet Singh

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.

Adding Rate Limiting to Your .NET Web API

Harpreet Singh — Tue, 23 Sep 2025 03:58:36 +0000

Adding Rate Limiting to Your .NET Web API (with Settings from `appsettings.json`)

APIs are awesome, but they can also be fragile. If a client starts firing off requests too quickly, your API could slow down or worse, go down entirely. That’s where rate limiting comes in: it helps you control traffic and keep things stable.

For this walkthrough, we’ll use the popular AspNetCoreRateLimit library, which makes it easy to set up IP-based rate limiting in a .NET Web API. The best part? We’ll configure everything in appsettings.json so we can change rules without touching the code.

Step 1: Add NuGet Packages

First, install the package:

dotnet add package AspNetCoreRateLimit

Step 2: Configure `appsettings.json`

Here’s an example configuration with different rules based on HTTP verbs:

"IpRateLimiting": {
   "EnableEndpointRateLimiting": true,
   "StackBlockedRequests": false,
   "RealIpHeader": "X-FORWARDED-FOR", // Use this header when your app is behind a proxy/load balancer to capture the actual client IP
   "ClientIdHeader": "X-ClientId",
   "HttpStatusCode": 429,
   "GeneralRules": [
     {
       "Endpoint": "GET:/*",
       "Period": "1s",
       "Limit": 10
     },
     {
       "Endpoint": "GET:/*",
       "Period": "1m",
       "Limit": 100
     },
     {
       "Endpoint": "POST:/*",
       "Period": "1s",
       "Limit": 5
     },
     {
       "Endpoint": "POST:/*",
       "Period": "1m",
       "Limit": 25
     },
     {
       "Endpoint": "PUT:/*",
       "Period": "1s",
       "Limit": 5
     },
     {
       "Endpoint": "PUT:/*",
       "Period": "1m",
       "Limit": 30
     },
     {
       "Endpoint": "DELETE:/*",
       "Period": "1m",
       "Limit": 5
     }
   ]
 },
 "IpRateLimitPolicies": {
   "IpRules": []
 }

This configuration enforces multiple layers of throttling:

GET → 10 requests per second, 100 per minute
POST → 5 per second, 25 per minute
PUT → 5 per second, 30 per minute
DELETE → 5 per minute

Step 3: Register Services in `Program.cs`

Now let’s wire things up:

using AspNetCoreRateLimit;

var builder = WebApplication.CreateBuilder(args);

// Load configuration from appsettings.json
builder.Services.AddOptions();
builder.Services.AddMemoryCache();

// Load IpRateLimiting config
builder.Services.Configure<IpRateLimitOptions>(
    builder.Configuration.GetSection("IpRateLimiting"));

builder.Services.Configure<IpRateLimitPolicies>(
    builder.Configuration.GetSection("IpRateLimitPolicies"));

// Inject the rate limiting services
builder.Services.AddInMemoryRateLimiting();
builder.Services.AddSingleton<IRateLimitConfiguration, RateLimitConfiguration>();

builder.Services.AddControllers();

var app = builder.Build();

// Enable IP rate limiting
app.UseIpRateLimiting();

app.MapControllers();

app.Run();

Step 4: Add a Test Controller

[ApiController]
[Route("api/[controller]")]
public class HelloController : ControllerBase
{
    [HttpGet]
    public IActionResult Get()
    {
        return Ok(new { Message = "Hello, world!" });
    }

    [HttpPost]
    public IActionResult Post()
    {
        return Ok(new { Message = "You posted something!" });
    }
}

Now, if you hit GET /api/hello more than 10 times per second or 100 times per minute, you’ll start getting HTTP 429 Too Many Requests. The same applies for POST, PUT, and DELETE with their own limits.

Wrapping Up

With just a few lines of setup, you’ve added IP-based rate limiting to your .NET Web API. Everything is controlled by configuration in appsettings.json, so tweaking rules is as simple as editing JSON.

This approach is great for protecting your API from abuse, buggy clients, or even DDoS-style traffic spikes. And since it’s based on IP addresses, you can easily extend it with policies to give specific clients different limits.

Protect your API early your infrastructure (and your users) will thank you. 🚀

I Built My First NPM Library: no-console-production

Harpreet Singh — Tue, 19 Aug 2025 03:32:15 +0000

As a developer, I was tired of shipping apps full of console.logs. Debugging locally is fine, but in production it looks messy, unprofessional, and sometimes even risky. So I built my first open-source package to fix it.

💡 Meet no-console-production
🔗 NPM Package: https://www.npmjs.com/package/no-console-production

A lightweight library (~2KB) that automatically hides console logs in production while keeping errors visible for monitoring.

✨ Features

🛡️ Smart defaults — detects environment, hides logs/warnings, preserves errors.

⚛️ React-ready — hooks + providers for easy integration.

🎯 Developer-friendly — TypeScript support, granular control, fast, tiny bundle.

🔧 Flexible — suppress all methods or just specific ones.

📦 NPM: no-console-production

🚀 Why it matters

Cleaner, more professional apps

Better performance (no useless console ops)

Reduced risk of leaking sensitive data

🙏 First OSS Contribution

This is my first open-source project and it taught me a lot about npm publishing, TypeScript libraries, and performance optimization. I’d love your feedback:

⭐ Star the repo

🐛 Report issues

💡 Suggest features

Your support will help me grow as a developer and improve this tool for everyone!

Forem: Harpreet Singh

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

Step 2: Register Middleware in Program.cs

Step 3: Testing the Middleware

Step 4: Optional Enhancements

Wrapping Up

Adding Rate Limiting to Your .NET Web API

Adding Rate Limiting to Your .NET Web API (with Settings from appsettings.json)

Step 1: Add NuGet Packages

Step 2: Configure appsettings.json

Step 3: Register Services in Program.cs

Step 4: Add a Test Controller

Wrapping Up

I Built My First NPM Library: no-console-production

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`

Adding Rate Limiting to Your .NET Web API (with Settings from `appsettings.json`)

Step 2: Configure `appsettings.json`

Step 3: Register Services in `Program.cs`