DEV Community: Alimur Razi Rana

Reflection in C#: What It Is, Why It Exists

Alimur Razi Rana — Sun, 12 Jul 2026 04:51:45 +0000

Reflection is one of those features every .Net/C# developer has used directly or indirectly. This article walks through — using a dynamic email template engine as the running example — and then tours a few real-life use cases where reflection does real work.

What Is Reflection?

Reflection lets code inspect and interact with types, methods, properties, and assemblies at runtime — even ones it didn't know about at compile time. It lives in the System.Reflection namespace and has been part of .NET since .NET Framework 1.0 in 2002.

Type type = someObject.GetType();
PropertyInfo[] properties = type.GetProperties();
object instance = Activator.CreateInstance(type);

That's the mechanism. The value of reflection only becomes clear once we see the alternative.

The Problem: Life Without Reflection

Imagine someone building a system that sends different kinds of emails — order confirmations, password resets, shipping updates — each with its own data merged into a template.

Without reflection, developers need to write a separate merge method for every email type, manually pulling out each field:

public class OrderConfirmationData
{
    public string CustomerName { get; set; }
    public string OrderNumber { get; set; }
    public decimal Total { get; set; }
}

public static string BuildOrderConfirmationEmail(string template, OrderConfirmationData data)
{
    return template
        .Replace("{{CustomerName}}", data.CustomerName)
        .Replace("{{OrderNumber}}", data.OrderNumber)
        .Replace("{{Total}}", data.Total.ToString("C"));
}

public static string BuildPasswordResetEmail(string template, PasswordResetData data)
{
    return template
        .Replace("{{UserName}}", data.UserName)
        .Replace("{{ResetLink}}", data.ResetLink);
}
// ...and one more method for every new email type, forever

This has three predictable failure modes:

Duplication — the same merge pattern gets copy-pasted for every model.
It doesn't scale — add ShippingUpdateData, InvoiceData, WelcomeEmailData, and write three more methods.
Silent bugs — add a new field like EstimatedDelivery to a model and forget to add its .Replace() call. Nothing fails at compile time; the placeholder just never gets filled in.

The Fix: A Reflection-Based Template Engine

Instead of hardcoding which fields exist, the engine asks each object what properties it has and merges them generically:

public static class TemplateEngine
{
    public static string Render(string template, object data)
    {
        Type type = data.GetType();

        foreach (PropertyInfo prop in type.GetProperties())
        {
            string placeholder = "{{" + prop.Name + "}}";
            object value = prop.GetValue(data);
            template = template.Replace(placeholder, FormatValue(value));
        }

        return template;
    }

    private static string FormatValue(object value) => value switch
    {
        null => "",
        decimal d => d.ToString("C"),
        DateTime dt => dt.ToString("MMMM dd, yyyy"),
        _ => value.ToString()
    };
}

Usage is now completely generic — one method handles every email type ever created:

var order = new OrderConfirmationData
{
    CustomerName = "Sarah",
    OrderNumber = "ORD-4471",
    Total = 89.99m
};

string template = "Hi {{CustomerName}}, your order {{OrderNumber}} totaling {{Total}} has shipped!";
string email = TemplateEngine.Render(template, order);
// "Hi Sarah, your order ORD-4471 totaling $89.99 has shipped!"

var reset = new PasswordResetData { UserName = "sarah_k", ResetLink = "https://..." };
string resetEmail = TemplateEngine.Render("Hi {{UserName}}, click {{ResetLink}} to reset.", reset);

What this actually fixed:

One merge engine instead of N methods. Render() never changes as new email types are added.
Adding a field to an email becomes a one-line change: add the property to the model, add the placeholder to the template. No merge code to remember.

This is essentially how real templating libraries like RazorLight and Scriban work under the hood: bind a plain object's properties to placeholders without the library ever needing to know specific classes in advance.

Advanced Feature: Attribute-Driven Formatting

Once the basic engine works, attributes push formatting rules into the model instead of hardcoding them in the engine — keeping Render() generic while still allowing per-field customization:

[AttributeUsage(AttributeTargets.Property)]
public class DateFormatAttribute : Attribute
{
    public string Format { get; }
    public DateFormatAttribute(string format) => Format = format;
}

public class ShippingUpdateData
{
    public string CustomerName { get; set; }

    [DateFormat("dddd, MMMM d")]
    public DateTime EstimatedDelivery { get; set; }
}

Inside Render(), a quick check against the attribute decides how to format that specific field:

var dateFormat = prop.GetCustomAttribute<DateFormatAttribute>();
string formatted = dateFormat != null && value is DateTime dt
    ? dt.ToString(dateFormat.Format)
    : FormatValue(value);

This is the same pattern used by [Required] in ASP.NET Core's DataAnnotations validation, or [JsonPropertyName] in System.Text.Json — metadata lives next to the data it describes, and generic engines read it at runtime instead of needing per-type special-casing.

Other Places Reflection Does Real Work

The template engine isn't a one-off case — it's an instance of a general pattern: code that would otherwise need to know about every type in advance gets replaced by code that discovers what it needs at runtime. A few other production-grade examples:

Dependency Injection Containers

Instead of manually writing new OrderController(new OrderService(new OrderRepository(new DbConnection(...)))), a DI container reads each class's constructor via GetConstructors() and GetParameters(), then recursively resolves and builds the whole graph. This is exactly what builder.Services.AddScoped<IOrderRepository, OrderRepository>() does under the hood in ASP.NET Core.

Validation Frameworks

DataAnnotations and FluentValidation scan a model's properties for attributes like [Required] or [Range] and apply the corresponding rule — one generic validator instead of a hand-written method per class.

Serialization

System.Text.Json and Newtonsoft.Json walk an object's properties via reflection to produce JSON, and walk a JSON document's structure to populate an object — without ever needing hardcoded knowledge of the classes.

Test Runners

xUnit and NUnit scan the compiled assembly for methods tagged [Fact] or [Test] rather than maintaining a manual list of test methods.

ORMs

Entity Framework maps class properties to database columns by reflecting over the model classes, matching property names (or [Column] attributes) to schema columns.

Reflection is slow

Reflection is slower than direct method calls, but the difference only matters when executed thousands or millions of times. Frameworks like ASP.NET Core, Entity Framework, and System.Text.Json all use reflection where appropriate, then cache metadata so the cost is paid once rather than on every operation.

Takeaway

Reflection is powerful, but it isn't a replacement for normal object-oriented code. If types are known at compile time, direct property access is simpler, safer, and faster. Reflection shines while building reusable infrastructure that must work with types it doesn't know in advance.

From Passwords to Token-based Authentication

Alimur Razi Rana — Thu, 02 Jul 2026 06:37:42 +0000

Every authentication mechanism in use today emerged to address a specific set of constraints the previous one wasn't designed for. This article walks through that chain — not as a list of definitions, but as a sequence of problems and the constraints that shaped each solution.

1. The Problem With Sending Passwords Every Request

The earliest widely used approach, HTTP Basic Authentication, is also the simplest to understand. The client sends the username and password, base64-encoded, on every single request:

GET /api/data Authorization: Basic dXNlcjpwYXNzd29yZA==

Base64 is not encryption — it's just a reversible encoding. Anyone who intercepts this header has the raw credentials.

This approach has three structural problems.

First, the password is transmitted on every request, which means every request is a new opportunity for it to leak — through logs, proxies, or a compromised network.
Second, the server has to validate credentials against the database on every single call, since there's no concept of an established session; that's a database hit for every API request, which doesn't scale.
Third, there's no way to limit what the credentials can do or for how long. The password grants full access until it's changed, and changing it is the only way to revoke access — there's no way to invalidate just one client's access without affecting every other client using the same password.

2. Sessions Try to Fix It, But Introduce New Problems

The next evolution moved the credential check to a single moment: login. After verifying the password once, the server creates a session, stores it (in memory or a database), and gives the client a session ID, usually via a cookie. Every subsequent request just sends that ID, not the password.

The user logs in by submitting their username and password.

   Browser ───────────────▶ Server
            Login Request

The server validates the credentials.

   Server ── checks username/password ──▶ Database

If the credentials are valid, the server creates a new session, stores it in the session store, and generates a unique session ID.
```
   Server ───────────────▶ Session Store
            Create Session
```

The server returns the session ID to the browser in a Set-Cookie header.

   Server ───────────────▶ Browser
      Set-Cookie: session_id=abc123

For every subsequent request, the browser automatically includes the session cookie.

   Browser ───────────────▶ Server
   Request + session_id cookie

The server uses the session ID to retrieve the corresponding session from the session store.

   Server ───────────────▶ Session Store
          Lookup session_id
   Session Store ─────────▶ Server
          Session data

If the session exists and is still valid, the server processes the request and returns the requested resource.
```
   Server ───────────────▶ Browser
            Response
```

This solves the repeated-password-exposure problem cleanly. But it trades that problem for a different set of issues. The server now has to store and look up a session on every request, which is a form of state that has to live somewhere and be kept in sync if you're running more than one server. Cookies are also sent automatically by the browser, which is exactly what makes them vulnerable to CSRF — a malicious site can trigger a request that carries the user's cookie without their knowledge. And sessions are fundamentally a browser-native concept; they don't map cleanly onto mobile apps, CLI tools, or server-to-server calls, all of which have no natural concept of a cookie jar. For those contexts specifically, sessions weren't a broken solution — they were a solution built for a different problem.

3. Bearer Tokens Go Stateless

The fix here was to stop relying on server-side storage altogether and instead issue a self-contained token — most commonly a JWT (JSON Web Token) — that carries its own proof of validity.

The token is called a "bearer" token because possession is the only requirement — whoever holds it can use it, no further proof needed. Crucially, the server doesn't need to look anything up in a database to validate it; it just verifies the signature.

Session-based check: Request → DB/store lookup → Response (stateful) Bearer token check: Request → verify signature → Response (stateless)

This single change resolves several of the earlier problems at once. There's no session store to maintain or synchronize across servers. The token can carry scopes, limiting exactly what it's allowed to do, rather than granting blanket access. And because it's just a string in a header, it works identically whether the caller is a browser, a mobile app, a CLI tool, or another backend service — there's no cookie-jar assumption baked in.

4. The New Tension Bearer Tokens Introduce

Solving the statelessness problem exposes a different question that sessions never really had to answer cleanly: how long should a token live?
A short-lived token limits the damage if it's ever stolen — an attacker only has a small window before it expires. But it also means the user gets logged out frequently, since there's no way to silently extend access once the token has expired. A long-lived token solves the convenience problem, but now a single stolen token grants extended, possibly indefinite access, which is a much worse outcome if it leaks.

Short-lived token: safer if stolen, but logs the user out constantly Long-lived token: convenient, but dangerous if it's ever compromised

Picking one or the other means accepting one of these two problems outright. The fix wasn't to pick a side — it was to stop treating this as a single-token problem.

5. Refresh Token Flow Resolves the Tension

Instead of one token trying to be both safe and convenient, the solution introduces two tokens, each optimized for a different job. The access token is short-lived and is the one actually sent with every API call. The refresh token is long-lived, but it's used for exactly one purpose: silently obtaining a new access token when the old one expires. It's never sent to the API directly.

`1. The user logs in by submitting their credentials.

       Client ───────────────▶ Auth Server
                 Login Request`

The authentication server verifies the credentials.

  Auth Server ── validates username/password ──▶ User Database

If authentication succeeds, the server issues two tokens:

A short-lived access token (e.g., 15 minutes)
A long-lived refresh token (e.g., 30 days)

   Auth Server ───────────────▶ Client
               access_token
               refresh_token

The client calls protected APIs using the access token.

   Client ───────────────▶ API
   Authorization: Bearer access_token

The API validates the access token. If it's valid, the request
is processed and the response is returned.

   API ── verifies token signature/claims ──▶
   API ───────────────▶ Client
             Response

After the access token expires, API requests are rejected
with an authentication error (typically 401 Unauthorized).

   Client ───────────────▶ API
   Expired access_token
   ◀─────────────── 401 Unauthorized

The client sends the refresh token to the authentication server
to obtain a new access token.

   Client ───────────────▶ Auth Server
            refresh_token

The authentication server validates the refresh token and,
if it's still valid, issues a new access token
(and optionally a new refresh token).
```
   Auth Server ───────────────▶ Client
               new access_token
```

The client retries the original request using the new
access token and continues working without requiring
the user to log in again.

   Client ───────────────▶ API
   Authorization: Bearer new_access_token
   ◀─────────────── Response`

This refresh exchange happens silently in the background, invisible to the user — there's no re-login screen, no interruption. The user only has to log in again once the refresh token itself eventually expires, which can be set to a much longer window precisely because the refresh token isn't exposed to the same attack surface as the access token; it's used rarely, against a single dedicated endpoint, rather than being sent on every API call where it would have more chances to leak.

This two-token model is part of the OAuth 2.0 specification, which formalized exactly this pattern: access tokens for calling resources, refresh tokens for renewing access, and a clear separation of purpose between the two.

6. How Access and Refresh Tokens Improve on Earlier Approaches

Looking back at the chain, the access token plus refresh token pair addresses each prior constraint in turn. The password itself is only ever sent once, at login — not on every request, which closes the exposure problem Basic Auth had. There's no server-side session store to maintain, since the access token is self-contained and stateless, removing the scaling constraint that sessions introduce for multi-server deployments. The user isn't forced to log in every few minutes, since the refresh token silently renews access in the background. And if an access token does leak, the damage is bounded by its short expiry, while the refresh token — the more sensitive, longer-lived credential — is never exposed on routine API calls in the first place, limiting its attack surface.

Each step in this chain didn't make the previous mechanism wrong — it made it insufficient for a different set of requirements: scale, statelessness, portability across client types, and convenience without sacrificing security. The access token and refresh token pair is where that chain currently settles in stateless, API-driven systems, and it's the foundation that more specialized mechanisms later build directly on top of it.

7. When Sessions Are Still the Right Choice

Bearer tokens and refresh tokens address the constraints of stateless, multi-client APIs well — but that doesn't make sessions obsolete. They remain widely used, and in several contexts they're genuinely the better fit.

Immediate revocation is a hard requirement. When a user logs out of a session-based system, the server deletes the session record, and access stops immediately. With bearer tokens, logout on the client side doesn't invalidate the token itself — it just discards it locally. The token remains technically valid until it expires, which is acceptable for most applications but not for systems where instant revocation is non-negotiable, such as banking platforms or enterprise applications managing sensitive data.
The client is exclusively a browser. Sessions and cookies were designed for exactly this context. If your application is a traditional server-rendered web app with no mobile client, no public API, and no third-party consumers, sessions carry less overhead and are simpler to implement correctly.
The use case is internal or enterprise-facing. Internal tools, admin panels, and enterprise web applications often prioritize control and auditability over scalability. Session-based auth fits this context well — each active session is visible and individually revocable from the server side, which matters when you need to respond quickly to a compromised account.

In practice, many large systems use both approaches for different layers: session-based auth for first-party browser interfaces where the server needs tight control, and token-based auth for APIs and third-party integrations where statelessness and portability matter more. The two aren't mutually exclusive — they answer different questions.

Singleton, Scoped, and Transient: What They Actually Mean for Your DbContext

Alimur Razi Rana — Wed, 24 Jun 2026 10:37:18 +0000

Anyone who has worked with dependency injection in .NET, might have registered something like this:

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString));

It works. app runs. But why does AddDbContext default to Scoped, and what would break if it didn't?

Let's find out — by breaking it on purpose.

The three lifetimes

Before touching any code, here's what each lifetime actually promises:

Transient — A new instance is created every single time it's requested. Ask for it twice in the same method, and get two different instances.

Scoped — One instance is created per scope, and reused for every request within that scope. In a web app, a scope is one HTTP request — so everything inside that request shares the same instance. The next request gets a fresh one.

Singleton — Exactly one instance, ever, for the entire lifetime of the app. Every request, every user, every caller — all sharing that one object, forever, until the app shuts down.

That's the theory. Now let's watch it actually happen.

Setting up a DbContext that tells us who it is

The trick to seeing lifetime behavior instead of just reading about it: give the DbContext a fingerprint.

public class AppDbContext : DbContext
{
    public Guid InstanceId { get; } = Guid.NewGuid();

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

Every time a new AppDbContext gets constructed, it stamps itself with a new Guid. If two services end up holding the same InstanceId, we know for certain they got handed the same object — not two copies that look alike.

Two services that both need a database connection

In any real app, most cases never have just one class touching the database. Let's add two:

public class OrderWriter
{
    private readonly AppDbContext _db;
    public OrderWriter(AppDbContext db) => _db = db;

    public void ShowInstance(string label) =>
        Console.WriteLine($"[OrderWriter]     {label} → {_db.InstanceId}");
}

public class InventoryWriter
{
    private readonly AppDbContext _db;
    public InventoryWriter(AppDbContext db) => _db = db;

    public void ShowInstance(string label) =>
        Console.WriteLine($"[InventoryWriter] {label} → {_db.InstanceId}");
}

Both just print which AppDbContext they were handed. Think of these as stand-ins for an OrderRepository and an InventoryService in a real order-processing flow — two unrelated classes that both happen to need the same database context.

We still haven't registered anything with DI yet.

Wiring it up — starting with Singleton

Here's where it gets interesting. Let's register AppDbContext as a Singleton and see what happens across two separate "requests":

var services = new ServiceCollection();

services.AddSingleton<AppDbContext>(_ =>
{
    var options = new DbContextOptionsBuilder<AppDbContext>()
        .UseInMemoryDatabase("SingletonTest").Options;
    return new AppDbContext(options);
});

services.AddTransient<OrderWriter>();
services.AddTransient<InventoryWriter>();

var provider = services.BuildServiceProvider();

I used an in-memory database here on purpose — no real SQL Server needed, so anyone can copy this straight into a console app and run it.

Quick note on OrderWriter and InventoryWriter being Transient: that's deliberate. We want them rebuilt fresh every time, so the only thing that can explain a repeated InstanceId is the DbContext's own lifetime — not some side effect of caching the writer itself.

Simulating two HTTP requests

In a real web app, a "scope" is created automatically for you on every incoming request. In a console app, we have to make that explicit:

using (var requestOne = provider.CreateScope())
{
    var order = requestOne.ServiceProvider.GetRequiredService<OrderWriter>();
    var inventory = requestOne.ServiceProvider.GetRequiredService<InventoryWriter>();
    order.ShowInstance("Request 1");
    inventory.ShowInstance("Request 1");
}

using (var requestTwo = provider.CreateScope())
{
    var order = requestTwo.ServiceProvider.GetRequiredService<OrderWriter>();
    order.ShowInstance("Request 2");
}

Each using block is standing in for one separate incoming HTTP request, completely unrelated to the other.

Run this with the Singleton registration from above, and here's what prints:

[OrderWriter]     Request 1 → 3f1a2b4c-...
[InventoryWriter] Request 1 → 3f1a2b4c-...
[OrderWriter]     Request 2 → 3f1a2b4c-...

Same InstanceId, every single time — even across two completely separate requests.

Why that's actually a problem

In a real app: two unrelated users, hitting your API at the same time, would be sharing one AppDbContext.

DbContext isn't thread-safe. If request 1 and request 2 land close enough together, you'll hit:

InvalidOperationException: A second operation was started on this 
context instance before a previous operation completed.

And even if you never hit that exact exception, there's a quieter problem: EF Core's change tracker never gets cleared. With Scoped, a new DbContext — and therefore a new empty change tracker — gets created for every request. When the request ends, that DbContext gets disposed, and the tracker (along with everything it was holding onto) gets thrown away with it. But in this case, every entity ever loaded by any request stays tracked in that one singleton context, forever, growing without bound for as long as the app runs.

Singleton is wrong here. Let's try the opposite extreme.

Swapping in Transient

Same harness — change the registration line:

services.AddTransient<AppDbContext>(_ =>
{
    var options = new DbContextOptionsBuilder<AppDbContext>()
        .UseInMemoryDatabase("TransientTest").Options;
    return new AppDbContext(options);
});

Run the same two-request simulation, and now you get:

[OrderWriter]     Request 1 → 9c2e7f10-...
[InventoryWriter] Request 1 → 7b44d821-...
[OrderWriter]     Request 2 → a91f3c05-...

Every InstanceId is different — including OrderWriter and InventoryWriter, within the same request.

Why that's also a problem —

Picture OrderService written like this:

public class OrderService
{
    private readonly AppDbContext _db;
    private readonly IInventoryService _inventory;
    private readonly IOrderRepository _repository;

    public OrderService(AppDbContext db, IInventoryService inventory, IOrderRepository repository)
    {
        _db = db;
        _inventory = inventory;
        _repository = repository;
    }

    public async Task PlaceOrderAsync(Order order, OrderItem item)
    {
        await _inventory.ReserveAsync(item.ProductId, item.Quantity);
        await _repository.SaveAsync(order);
        await _db.SaveChangesAsync();
    }
}

ReserveAsync and SaveAsync are written to only stage their changes — no internal SaveChangesAsync() calls — trusting that one final commit at the bottom will save everything. That's the correct pattern, but only if every _db in this picture is the same object.

What happens with Transient

If AppDbContext is registered Transient, OrderService's own constructor gets handed its own fresh instance — call it DbContext#3. That's separate from whatever IInventoryService was given (DbContext#1) and whatever IOrderRepository was given (DbContext#2).

So:

_inventory.ReserveAsync stages its change on DbContext#1.
_repository.SaveAsync stages its change on DbContext#2.
_db.SaveChangesAsync() commits DbContext#3 — which nothing ever touched.

The method runs to completion. No exception. No error. And nothing was saved — because the one context that actually got told to commit was never the one holding any staged changes. The changes inside DbContext#1 and DbContext#2 are simply discarded the moment those objects are disposed, since nobody ever called SaveChangesAsync() on either of them specifically.

Now the one that actually works: Scoped

Last swap:

services.AddScoped<AppDbContext>(_ =>
{
    var options = new DbContextOptionsBuilder<AppDbContext>()
        .UseInMemoryDatabase("ScopedTest").Options;
    return new AppDbContext(options);
});

Run it again:

[OrderWriter]     Request 1 → c450e9a2-...
[InventoryWriter] Request 1 → c450e9a2-...
[OrderWriter]     Request 2 → e702b614-...

Look at that pattern closely — OrderWriter and InventoryWriter share an InstanceId within Request 1, but Request 2 gets a completely different one.

That's exactly the property we need:

Within one request, every service shares one DbContext — one change tracker, one real unit of work. OrderWriter and InventoryWriter can both stage changes and commit them together.
Across requests, nothing leaks. Request 2 starts clean, with no leftover tracked entities from Request 1, and no thread-safety conflict if both requests happen to run at the same time.

Putting it side by side

Lifetime	Within one request	Across two requests	What goes wrong
Singleton	Same instance	Same instance	Thread-safety crashes, unbounded change tracker growth
Transient	Different instances	Different instances	Two services in one request can't share a transaction
Scoped	Same instance	Different instances	Nothing — this is the one that fits

Try it yourself

The full thing runs as a plain console app — no real database required, since we're using EF Core's in-memory provider for the experiment. You'll need:

dotnet add package Microsoft.EntityFrameworkCore.InMemory

Then just swap the single registration line between AddSingleton, AddTransient, and AddScoped, rerun, and watch the GUIDs tell the story. [gist link] Once you've seen all three side by side like this, the rule stops being something you memorized and starts being something you actually understand: match the lifetime to how long the state inside the object is supposed to live. A DbContext should live exactly as long as one unit of work — which, in a web app, is exactly one request. That's not a coincidence. That's the entire reason Scoped exists.

That covers Scoped pretty thoroughly. But Scoped isn't the only lifetime that earns its place — Singleton and Transient each have a scenario where they're not just "safe," they're the better choice than the other two. Let's look at one real example of each.

When Singleton is the right call

Use Singleton for stateless objects, require heavy initialization, or hold global application state. Common examples:

Caching services
Configuration providers
Logging utilities
Background workers and hosted services

When to avoid Singleton:

Thread-unsafe state — if multiple requests can hit the same instance at the same time, concurrent modifications to mutable data will cause bugs that are hard to reproduce.
Captive dependencies — never inject a shorter-lived service (Scoped or Transient) into a Singleton. Doing so forces that shorter-lived service to live far longer than it was designed to, which is exactly the bug our AppDbContext experiment above demonstrated: a Scoped DbContext trapped inside something longer-lived stops behaving like a per-request unit of work and starts leaking state across requests instead.

Picture an app-wide pricing settings provider — tax rates, currency exchange rates, feature flags — loaded once from configuration or a slow-changing table, then read over and over by every request that calculates a price.

If this were Scoped, every single request would re-read config and rebuild that exchange-rate data from scratch — paying the same cost over and over for a result that never changes between requests. Transient would be worse, potentially rebuilding it multiple times within one request if several services injected it.

When Transient is the right call

Use Transient when:

The service is stateless — the class doesn't hold or track data across multiple calls.
You're building lightweight utilities — simple validators, formatters, or data mappers are a natural fit.
The service isn't thread-safe — since you get a fresh instance every time, you sidestep the concurrency issues that come from sharing one object across multiple threads.
You need to avoid state contamination — you want one operation's execution to never leak data into another operation's execution, even within the same request.

When not to use Transient:

Heavily used dependencies — since the container builds a new object every single time, excessive use of Transient services increases allocations and adds pressure on the garbage collector, which can hurt performance at scale.
When sharing context is required — if multiple services need to work on the same unit of work at the same time (Entity Framework's DbContext being the textbook case), Transient breaks that sharing apart. That's exactly what we watched happen in the experiment above — use Scoped instead.

Now picture a report builder that accumulates lines as it works — say, one service builds the text for an invoice summary, and a separate, unrelated service builds the text for a shipping label. These aren't two pieces of one shared document; they're two completely independent outputs that just happen to use the same kind of builder. Transient guarantees each service gets its own instance, starting from a clean slate, so the invoice service's lines never show up inside the shipping service's result, and vice versa.

The pattern across all three

Lifetime	What actually justifies it	What goes wrong with the wrong choice
Singleton	Holds no per-request data; nothing mutates after construction	Scoped/Transient would rebuild expensive, identical state on every request for no benefit
Scoped	Wraps a per-request unit of work (like `DbContext`) that multiple services need to share	Singleton leaks state across users; Transient splits one logical operation into disconnected pieces
Transient	Mutates its own state mid-operation, and that state must never be shared between callers	Scoped or Singleton would let one caller's leftover state corrupt another's result

Every lifetime decision in this article comes down to the same one question, asked about the specific object in front of you: what does this object store on itself, who else might be holding the same instance at the same time, and what would happen if they were? Answer that honestly for any service in your own app, and the right registration call — AddSingleton, AddScoped, or AddTransient — stops being a guess.

React Doesn't Need Node.js — Until It Does

Alimur Razi Rana — Mon, 08 Jun 2026 16:44:03 +0000

The Truth Nobody Tells You When You Start React

Most React tutorials for beginners start the same way

"First, install Node.js..."

And every beginner obeys without question. Most of them never challenge it. It's just accepted as part of the ritual.

But here's the thing — React doesn't actually need Node.js to work.

And understanding why that's true, and where it stops being true, will completely change how developers think about the entire React ecosystem — including Vite, Next.js, and npm itself.

Let's start with a proof.

Part 1: React With Zero Node.js

Create a plain .html file on your desktop. Paste this in:

<!DOCTYPE html>
<html>
  <head>
    <title>React, no Node.js</title>
  </head>
  <body>

    <div id="root"></div>

    <!-- React from CDN -->
    <script src="https://unpkg.com/react@18/umd/react.development.js"></script>
    <script src="https://unpkg.com/react-dom@18/umd/react-dom.development.js"></script>

    <!-- Babel to handle JSX in the browser -->
    <script src="https://unpkg.com/@babel/standalone/babel.min.js"></script>

    <script type="text/babel">
      function App() {
        const [count, setCount] = React.useState(0);
        return (
          <div>
            <h1>Hello from React!</h1>
            <p>Count: {count}</p>
            <button onClick={() => setCount(count + 1)}>Click me</button>
          </div>
        );
      }

      ReactDOM.createRoot(document.getElementById('root')).render(<App />);
    </script>

  </body>
</html>

Double-click the file. Open it in your browser.

It works. State works. JSX works. React works.

No Node.js. No npm. No terminal. No installation.

Just a file and a browser.

This isn't a trick or a hack. This is how React was used in its early days. React is, at its core, just a JavaScript library — the same as jQuery or Lodash. It can be loaded with a <script> tag like anything else.

So if that's true... why does every guide tell you to install Node.js?

Part 2: Where the CDN Approach Breaks Down

The CDN approach works perfectly for small experiments. But the moment the app grows beyond a single file, it hits its real limitations.

First, a common misconception worth clearing up:

Modern browsers actually support ES module imports natively:

<script type="module">
  import Header from './Header.js'
  import Footer from './Footer.js'
</script>

So imports themselves aren't the problem. The real limitations are deeper than that.

1. JSX Needs Compilation

Browsers understand JavaScript. They do not understand JSX:

// ❌ Browser has no idea what this is
function App() {
  return <h1>Hello</h1>
}

// ✅ Browser only understands this
function App() {
  return React.createElement("h1", null, "Hello")
}

Every JSX file needs to be compiled into plain JavaScript before a browser can run it. Native ES modules don't solve this — the browser still can't parse the JSX syntax itself.
This compilation step is handled by different tools depending on setup:

Babel — the original JSX compiler, still widely used in plain React projects
Vite — the popular choice for modern plain React projects
Next.js SWC — Next.js ships with its own built-in compiler

2. npm Packages Aren't ES Module Compatible Out of the Box

Most npm packages are written in CommonJS format — Node.js's own module system:

// CommonJS — how most npm packages are written
const axios = require('axios')
module.exports = something

This is completely different from ES modules:

// ES Modules — what browsers understand
import axios from 'axios'
export default something

Browsers cannot run CommonJS. A bundler is needed to convert and reconcile these formats before they reach the browser.

3. Dependency Management Becomes a Nightmare

Want to use axios? You'd manually find its CDN link. Then manually find CDN links for all of axios's dependencies. Then their dependencies. A single real-world package can pull in dozens of sub-dependencies — tracking all of them by hand is completely unworkable.

4. Performance Suffers With Many Module Files

Even if everything was ES module compatible, loading 200 separate JavaScript files means 200 separate network requests — each with its own overhead. A bundler combines them into one or a few optimized files, which loads faster.

Part 3: What Node.js Actually Is

Before understanding why Node.js solves these problems, you need to understand what Node.js actually is — because most developers use it for years without knowing this.

Operating system cannot run JavaScript.

OS can run Python (if installed). It can run compiled C++ binaries. But JavaScript? No. Most operating systems don't include a built-in JavaScript runtime that can execute JavaScript files directly.

Only two environments (currently, there are different alternatives like Deno or Bun, but for simplicity, exclude these environments) have been able to execute JavaScript:

1. The Browser
   → Chrome, Firefox, and Safari all have a built-in JS engine
   → Chrome uses V8 (built by Google)
   → Firefox uses SpiderMonkey

2. Node.js
   → Takes Chrome's V8 engine
   → Strips out the browser parts (DOM, window, etc.)
   → Adds OS-level access (file system, network, processes)
   → Runs as a standalone program on your computer

That's literally all Node.js is. It's Chrome's JavaScript engine, liberated from the browser and given the ability to talk to your operating system.

Ryan Dahl, who created Node.js in 2009, had one core insight:

"JavaScript is already a great language. Why does it only run in browsers? What if it could run anywhere?"

So when you install Node.js, you're essentially installing a JavaScript interpreter directly onto your machine — the same engine that powers Chrome, just without the browser.

This is why npm packages need Node.js.

npm packages are JavaScript files. OS can store them just fine — it's great at storing files. But it cannot execute them. It has no JavaScript engine. Node.js provides that engine. Without it, those JavaScript files just sit there on your disk doing nothing.

Part 4: What npm Actually Solves

After Node.js, let's talk about npm — because it's far more than just a package downloader.

When you run npm install axios, npm doesn't just download axios. It:

1. Downloads axios
2. Reads axios's list of dependencies
3. Downloads those dependencies
4. Reads THEIR dependencies
5. Downloads those too
6. Resolves any version conflicts across the whole tree
7. Builds a complete, working dependency graph
8. Stores everything in node_modules

This process — called dependency resolution — is genuinely complex. Packages depend on other packages, which depend on other packages, which might conflict with each other's version requirements. npm handles all of this automatically.

Without npm, developers would need to do this by hand. For a real project with dozens of dependencies, each with their own sub-dependencies, that would be thousands of files to track manually. It would be completely unworkable.

And critically — npm itself is built on Node.js. It needs Node.js to run the resolution logic, download packages, execute install scripts, and manage the entire node_modules directory.

So the chain is clear:

You need npm
  → npm needs Node.js to run
    → Node.js provides the JS engine
      → JS engine executes npm's logic
        → npm manages your packages
          → packages can now be used in your app

Remove Node.js from this chain and the whole thing collapses.

Part 5: In Production, Node.js Disappears (For Plain React)

Here's something that surprises many developers.

When you run npm run build in a plain React + Vite project, Vite does all its work and produces a /dist folder:

/dist
  index.html
  assets/
    main.abc123.js     ← plain JavaScript, no JSX
    styles.abc123.css  ← plain CSS
    logo.abc123.png    ← optimized image

These are completely static files. Plain HTML, CSS, and JavaScript that any browser understands natively.

At this point, Node.js is completely out of the picture. You can take this /dist folder and host it on:

AWS S3
GitHub Pages
Netlify
Cloudflare Pages
A basic Apache server
Literally any file hosting service

No Node.js required. No server running. No ongoing processes. Just files being served.

Node.js was only needed during development — to run the JSX compiler, manage packages, and transform your code. Once the build is done, it has no role left.

Part 6: Next.js Changes Everything

Everything we've covered so far describes plain React — a client-side application where the browser does all the rendering work.

Next.js fundamentally changes this model.

How Plain React Renders

User visits your site
        ↓
Server sends an almost empty HTML file:

<html>
  <body>
    <div id="root"></div>  ← nothing here
    <script src="bundle.js"></script>
  </body>
</html>
        ↓
Browser downloads bundle.js (can be 1-2MB)
        ↓
JavaScript runs, React builds the UI
        ↓
User finally sees content

The server does almost nothing. The browser does all the work. This means:

Users on slow connections wait a long time before seeing anything
Search engines see an empty page — bad for SEO
The user's device carries all the rendering cost

How Next.js Renders

User visits react site
        ↓
Request hits the Next.js SERVER (Node.js running live)
        ↓
Server executes React components
        ↓
Produces complete HTML with actual content:

<html>
  <body>
    <div id="root">
      <h1>Your Product Name</h1>   ← already here
      <p>Price: $49</p>            ← already here
      <button>Buy Now</button>     ← already here
    </div>
    <script src="bundle.js"></script>
  </body>
</html>
        ↓
Browser receives full HTML instantly
        ↓
User sees content immediately ✅
        ↓
React "hydrates" — attaches event listeners
        ↓
App becomes interactive ✅

The key difference: the server does the rendering work before the browser gets involved.

The Browser Has No Idea

The browser doesn't know — and doesn't care — whether it received HTML from a Next.js server, a plain React build, a WordPress site, or hand-written HTML. It just renders what it gets.

The difference is entirely in what the server sends. Next.js sends richer, fuller HTML. Plain React sends almost nothing and lets the browser figure it out.

Node.js Stays Alive in Production

This is the critical difference from plain React.

In a plain React app, Node.js is a development-only tool that disappears after the build.

In Next.js, Node.js runs permanently in production ( Next.js can also run a project with little or no traditional Node server, depending on how the application is configured ) — processing every user request, rendering components on the server, fetching data from databases, and generating HTML in real time.

Plain React:
Node.js role → Development only → Gone after build

Next.js:
Node.js role → Development AND Production → Always running

This is why Next.js cannot be deployed to a static file server (unless exported it as fully static). It needs a live Node.js process running 24/7 to handle incoming requests.

Found this useful? Share it with the developer who just ran npm install without knowing why.

Guide to Integrating Cypress and Cucumber with Angular

Alimur Razi Rana — Sun, 03 Mar 2024 08:57:39 +0000

In software engineering, despite developers' confidence in their code, comprehensive testing is indispensable for determining its efficacy. Developers and QA engineers must navigate through diverse testing phases to ascertain the comprehensive functionality of their applications. Two widely embraced methodologies for this purpose, are End-to-End (E2E) testing and Behavior-Driven Development (BDD) testing.

While Cypress and Cucumber are favored tools for such testing, integrating them poses challenges due to their differing configurations. If developers try to work with typescript, it creates one extra configuration layer. Cypress’s configuration changed a lot from their pre-10 version. So maybe this blog can help others when they need to work later.

Numerous tutorials and blogs cover the importance and procedures of E2E testing or BDD testing. However, This article focuses specifically on integration procedures for these testing methodologies.

Now it's time to make our hands dirty. Cypress and cucumber will be integrated into an angular project which by default maintains typescript. So ensure that you have already installed Node.js, npm, and ng package in your work environment.

Create a new angular project. ng new angular-cypress-cucumber
E2E testing needs your project running, so you need to run this angular project by npm start
Install @cypress/schematic package, this will help the angular project to run with Cypress. ng add @cypress/schematic

During installation, @cypress/schematic automatically includes necessary npm packages. Additionally, it generates a Cypress configuration file, "cypress.config.ts" and adjusts the "angular.json" configuration file accordingly. Furthermore, it establishes a dedicated "cypress" sub-directory, including sample test files to help the developer get started.

We will execute test cases on a user list page. On this basic listing page, we can envision below scenarios:

Initially, the page will display no users.
Following the click of the "Get Users" button, an API call will be triggered. If the API returns a valid response, the list will appear.
In case of an error returned by the API, the page will remain unchanged.

Now it is time for BDD
npm i @badeball/cypress-cucumber-preprocessor @cypress/webpack-preprocessor -d

Replace the whole cypress.config.ts with below configuration content

import { defineConfig } from 'cypress';
const webpack = require("@cypress/webpack-preprocessor");
const preprocessor = require("@badeball/cypress-cucumber-preprocessor");

async function setupNodeEvents(on, config) {
  await preprocessor.addCucumberPreprocessorPlugin(on, config);
  on(
    "file:preprocessor",
    webpack({
      webpackOptions: {
        resolve: {
          extensions: [".ts", ".js"],
        },
        module: {
          rules: [
            {
              test: /\.feature$/,
              use: [
                {
                  loader: "@badeball/cypress-cucumber-preprocessor/webpack",
                  options: config,
                },
              ],
            },
          ],
        },
      },
    })
  );
  return config;
}

export default defineConfig({
  e2e: {
    'baseUrl': 'http://localhost:4200', // this will be the default page for e2e testing
    specPattern: ["**/e2e/**/*.feature"], // all e2e test file’s name should be in this pattern
    setupNodeEvents
  },
  component: {
    devServer: {
      framework: 'angular',
      bundler: 'webpack',
    },
    specPattern: '**/*.cy.ts'
  }
})

The configuration file facilitates the preprocessing of Cucumber-generated test cases, preparing them for execution by Cypress. Furthermore, it adjusts the spec locations, allowing Cypress to discover .feature files for test execution. These feature files encapsulate BDD test cases written in the Gherkin syntax.

In the package.json file add this new property too

"cypress-cucumber-preprocessor": {
    "stepDefinitions": "cypress/e2e/bdd-cucumber/step-defination/*.step.cy.ts"
},

Within the existing cypress/e2e directory, create a new folder named bdd-cucumber and create another folder inside bdd-cucumber named features. Navigate to the cypress\e2e\bdd-cucumber\features directory and create a new file named user-page.feature. As previously noted, Cucumber or BDD operates with the Gherkin language. The features within this folder will adhere to its syntax.

user-page.feature

Feature: User List functionality
  Background: Prepare user page
    Given I am on the user page

  Scenario: Users appear in UI when API call succeeds
    When I click the "Get Users" button
    Then A api call will be requested with valid response
    And user list will be appear on successful api request

  Scenario: Users do not appear in UI when API call fails
    When I click the "Get Users" button to check failed response
    Then A api call will be requested with failed response
    And User list will not appear on failed api request

You can also install highlight-cucumber vscode extension to colorize those features.

In the bdd-cucumber folder create another folder named step-defination . Cypress test files will be added to this folder.

user-page.step.cy.ts

import {
  Given,
  When,
  Then,
} from '@badeball/cypress-cucumber-preprocessor';

const apiUrl = 'https://jsonplaceholder.typicode.com/users';

Given('I am on the user page', () => {
  cy.visit('/');
});

When('I click the "Get Users" button', () => {
  cy.intercept('GET', apiUrl).as('getUserList');
  cy.contains('Get User').click();
});

Then('A api call will be requested with valid response', () => {
  cy.wait('@getUserList').then((interception) => {
    expect(interception.request.url).to.eq(apiUrl);
    expect(interception.response?.statusCode).to.eq(200);
  });
});

Then('user list will be appear on successful api request', () => {
  cy.get('span.user-name').its('length').should('be.greaterThan', 0);
});

When('I click the "Get Users" button to check failed response', () => {
  cy.intercept('GET', apiUrl, { forceNetworkError: true }).as('getUserList');
  cy.contains('Get User').click();
});

Then('A api call will be requested with failed response', () => {
  cy.wait('@getUserList').then((interception) => {
    expect(interception.request.url).to.eq(apiUrl);
    expect(interception.error).to.exist;
    expect(interception.error?.message).to.eq('forceNetworkError called');
  });
});

Then('User list will not appear on failed api request', () => {
  cy.get('span.user-name').should('not.exist');
});

As we have already written our test cases, the next step is to implement a user list page. For simplicity, the Angular project comprises solely html and typescript code to retrieve user data via API.

app.component.ts

import { Component } from '@angular/core';
import { HttpClient } from '@angular/common/http';

type User = {
  name: string;
}

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})

 export class AppComponent {
  title = 'angular-cypress-cucumber';
  url = "https://jsonplaceholder.typicode.com/users";
  users: User[] = [];
  constructor(private httpClient: HttpClient) {}

  getUsers() {
    this.httpClient.get<User[]>(this.url).subscribe(
      {
        next: (res) => {
          this.users = res;
        },
        error: (err: any) => {
          alert("Something went wrong!");
         },
        complete: () => { }
      }
    );
  }
}

app.component.html

<div>
  <button (click)="getUsers()">Get User</button>
  <ul>
    <li *ngFor="let user of users">
      <span class="user-name">{{user.name}}</span>
    </li>
  </ul>
</div>

Now navigate to the project's directory, and run the command npm run cypress:open. Before that, ensure that the angular project is running in http://localhost:4200 which is declared as the base URL in the cypress configuration.

Github Link