DEV Community: Karuppasamy Pandian

AutoMapper & MediatR Going License-Based: A Practical Take from a .NET Developer

Karuppasamy Pandian — Tue, 31 Mar 2026 00:48:47 +0000

If you’ve been working in the .NET ecosystem for a while, chances are you’ve used AutoMapper and MediatR in at least one project.

They’re not just libraries anymore—they’ve become habits.

So when discussions around licensing started surfacing, it caught a lot of developers off guard. Not because of the cost alone, but because of how deeply these tools are embedded in modern .NET architecture.

This isn’t just about paying for a library. It’s about rethinking some of the assumptions we’ve been making for years.

How We Got Comfortable with These Libraries

Let’s be honest—AutoMapper and MediatR made our lives easier.

With AutoMapper, we stopped writing repetitive mapping code. No more manually copying properties between models. Just define a profile and move on.

With MediatR, we started writing cleaner, decoupled code. Controllers became thin. Business logic moved into handlers. Cross-cutting concerns like logging and validation became neatly pluggable.

At some point, these tools stopped feeling like “third-party libraries” and started feeling like part of .NET itself.

That’s where the risk begins.

The Moment Licensing Enters the Conversation

When a library shifts toward a license-based model, the first reaction is usually:

“Wait… do we now have to pay for this?”

But the more important question is:

“How dependent are we on this?”

Because for many teams, the answer is: very.

It’s Not Just About Cost

Yes, there’s a financial angle. But in most enterprise setups, the actual licensing cost is not the biggest issue.

The real impact shows up elsewhere:

Procurement approvals
Legal reviews
Compliance tracking
Budget planning across multiple services

For a single project, it’s manageable. For an organization with 20+ microservices? It adds up—both in cost and operational overhead.

The Bigger Concern: Architectural Lock-In

This is where things get interesting.

With AutoMapper

If your application heavily relies on mapping profiles:

Your DTO transformations are centralized
Your services assume mappings exist
Your tests indirectly depend on those configurations

Removing AutoMapper isn’t impossible—but it’s not trivial either.

You’re looking at:

Rewriting mappings
Refactoring services
Potential regressions With MediatR

MediatR goes even deeper.

If you’ve built your system around it:

Every request flows through IMediator
Business logic lives in handlers
Pipeline behaviors handle cross-cutting concerns Now imagine removing it.

You’re not just replacing a library—you’re reshaping your application flow.

A Subtle Reality Check

This situation exposes something important:

We didn’t just adopt these tools—we designed around them.

And that’s a key distinction.

There’s nothing wrong with using libraries. But when your architecture starts depending on them, you’re no longer just “using”—you’re committing.

So What Are the Options?

Most teams will end up choosing one of these paths:

1. Continue and Pay

For many teams, this is the simplest option.

No refactoring
No disruption
Keep existing patterns

If your system is stable and heavily invested, this is a perfectly reasonable decision.

2. Gradually Move Away

Some teams will take this as an opportunity to reduce dependency.

For example:

Replace AutoMapper in performance-critical paths
Use explicit mapping where clarity matters
Limit MediatR usage to specific layers This approach isn’t about abandoning the tools—it’s about using them more intentionally.

3. Replace Completely

This is the most aggressive approach.

Manual mapping instead of AutoMapper
Direct service calls or custom mediator instead of MediatR

You gain:

Full control
Zero licensing concerns
But you also take on:
More code
More responsibility
Less abstraction

An Unexpected Side Effect: Better Engineering Conversations

Interestingly, this shift is forcing teams to ask better questions:

Do we really need AutoMapper here?
Is MediatR adding value—or just structure?
Are we optimizing for clarity, or just following patterns? These are conversations that often get skipped when everything is “free and working.”

Performance (The Thing We Often Ignore)

Let’s not forget—these tools do add overhead.

AutoMapper uses reflection (though optimized over time)
MediatR introduces an extra hop for every request In most applications, this is negligible.

But in high-throughput systems, it becomes noticeable.

Licensing discussions are pushing teams to revisit these trade-offs, which is actually a good thing.

What This Means for Clean Architecture & CQRS

A lot of people associate:

AutoMapper → Clean Architecture
MediatR → CQRS But that’s not entirely accurate.

These libraries *support * those patterns—they don’t define them.

You can implement:

Clean Architecture without AutoMapper
CQRS without MediatR It just takes a bit more effort.

And maybe that’s the real takeaway.

My Take

This shift isn’t a bad thing. It’s uncomfortable—but useful.

It reminds us that:

No library is guaranteed to stay free forever
Convenience always comes with a trade-off
Good architecture should survive tool changes If replacing a library feels impossible, that’s usually a signal—not about the library, but about the design.

Final Thought

AutoMapper and MediatR are still great tools. That hasn’t changed.

What’s changing is how we think about them.

Not as default choices—but as deliberate ones.

And that’s a healthier place to be as engineers.

LiveAuth - a nuget pkg to liberate your JWT authentication

Karuppasamy Pandian — Thu, 19 Mar 2026 21:49:34 +0000

I’m excited to announce the release of "LiveAuth" — an extension for ASP.NET Core that solves one of the most common limitations of JWT authentication: lack of real-time control over active sessions.

JWT is widely used because it is stateless and scalable. However, this design also introduces several practical challenges in real systems.
Once a JWT is issued, it cannot easily:
• be revoked immediately
• reflect role changes in real time
• support forced logout
• enforce true session control

In many production environments, this leads to difficult trade-offs between security and simplicity.

"LiveAuth" addresses this problem by introducing dynamic session validation on top of existing JWT authentication, without replacing the authentication pipeline.

Instead of modifying the authentication scheme, LiveAuth integrates with the OnTokenValidated hook of JwtBearer authentication. Every request is validated against a central session store, allowing the application to enforce real-time session state.

Key capabilities include:
• Immediate session revocation
• Version-based token invalidation
• Optional real-time role override
• Compatibility with standard ASP.NET Core JWT authentication
• No custom authentication handler required
• Works with Redis, SQL, or any session store

With this approach, applications can maintain the scalability of JWT while gaining centralized control over active sessions.

To demonstrate this concept, I also built a sample implementation that enforces a Role revocation in a Web API.

Without server-side validation:

User logs in → JWT issued
User becomes idle
JWT remains valid
Access still granted

With LiveAuth + server session validation:

User logs in
User becomes idle
Session expires
Next request → Unauthorized

This shows how LiveAuth enables real-time session enforcement while still using JWT.

This example highlights the real-world limitation of stateless JWT tokens and shows how LiveAuth can be used to enforce dynamic session policies.
Architecture:

GitHub Repository
https://github.com/ksamhere/LiveAuth

NuGet Package
https://www.nuget.org/packages/LiveAuth

The project is open source and released under the MIT license.

I built this as part of exploring practical solutions to real authentication challenges in distributed systems, and I hope it helps developers who face similar issues when working with JWT.

Feedback, suggestions, and contributions are welcome.

JWT Is Stateless — But Real Apps Aren’t

Karuppasamy Pandian — Thu, 05 Feb 2026 01:55:44 +0000

Why Modern Systems Use Hybrid Stateful Authentication (Like Facebook)

For years, JSON Web Tokens (JWT) have been promoted as the silver bullet for authentication. They’re fast, scalable, and eliminate server-side sessions.

But then you look at how real-world platforms like Facebook, Google, Netflix, or banking apps actually work:

Users stay logged in for months
Tokens can be revoked instantly
Compromised devices can be logged out
Offline access still works
Suspicious sessions are terminated immediately

Pure JWT cannot safely do all of this.

That’s why modern systems use a Hybrid Stateful Authentication Model.

Let’s break it down.

1. Stateless JWT: What It Really Means

A standard JWT contains:

User ID
Roles / claims
Expiration time
Digital signature

Once issued, the server does not store it.

Validation flow:

Client → sends JWT  
Server → verifies signature + expiration  
→ grants access

Benefits

No session storage
Horizontally scalable
Very low latency

But here’s the problem:
The server cannot revoke a JWT once issued. If stolen, it remains valid until it expires.

That’s a huge security gap.

2. Why Stateless JWT Alone Fails in Real Apps

Stateless tokens are blind.
They don’t know whether a session still exists.

3. Enter: Hybrid Stateful Authentication

This model combines:

JWT for fast authorization
Server session for control

It’s how Facebook, Google, and most identity providers work.

4. Hybrid JWT Flow (How Facebook-Style Auth Works)

Step 1 — Login

Server creates:

A JWT (short lived, signed)
A Session Record in DB / Redis:

SessionId
UserId
DeviceId
Status = Active
LastSeen

The JWT contains:

sub = userId
sid = sessionId
exp = 15 minutes

Step 2 — API Request

Client → sends JWT
Server →
  1. Verify signature
  2. Check expiration
  3. Lookup sessionId (sid) in session store
  4. Ensure session is Active
→ Grant access

Now the server controls the token.

Step 3 — Logout or Revoke

Server updates:

Session.Status = Revoked

Any request using that JWT is now rejected — even if it’s not expired.

5. Why This Is Still Fast

Session lookups are done in:

Redis
Memory cache
Distributed cache

Latency is typically < 2ms.

This is negligible compared to database calls and network overhead.

Security > micro-optimizations.

6. Offline & Long-Term Login

Apps use:

Short-lived access token (JWT)
Long-lived refresh token (stateful)

When access expires:

Client → sends refresh token
Server → validates session
→ issues new JWT

This is how Facebook keeps you logged in for months.

7. Stateless vs Hybrid Stateful

8. Final Thought

JWT is an authorization format, not a complete authentication strategy.

Real-world systems must answer:

“Is this session still valid?”

Only a hybrid stateful model can do that safely.

That’s why Facebook, Google, and most enterprise systems do not rely on stateless JWT alone.

If you’re designing authentication for a serious application,
stateless is not enough.

Security requires state.

FluentValidation in ASP.NET Core: Why One Validator per Request Is the Real Best Practice

Karuppasamy Pandian — Wed, 04 Feb 2026 01:02:09 +0000

In modern .NET Web APIs, validation is not just about checking nulls or ranges. It is part of your API contract and one of the most critical layers that protects your system from bad data.

FluentValidation has become the industry standard for handling validation in a clean, testable, and maintainable way.

In this article, let's see below:

What FluentValidation is
How to implement it in ASP.NET Core
Why a “generic validator” is a bad idea
Why one request = one validator is the correct pattern

What is FluentValidation?
FluentValidation is a popular .NET library that allows you to define validation rules using a fluent, strongly typed syntax instead of attributes or controller logic.

Instead of this:

[Required]
[EmailAddress]
public string Email { get; set; }

You define rules in a separate validator class:

RuleFor(x => x.Email)
    .NotEmpty()
    .EmailAddress();

This keeps your API models clean and moves validation into a dedicated validation layer.

Why Validation Should NOT Be in Controllers
Putting validation in controllers leads to:

Duplicated logic
Hard-to-test code
Fat controllers
Business rules leaking into API layer

FluentValidation integrates directly into the ASP.NET Core pipeline, so validation runs automatically before your controller executes.

If validation fails, the framework returns a 400 Bad Request — no extra code required in the controller.

How to Implement FluentValidation in ASP.NET Core

Install Packages

dotnet add package FluentValidation
dotnet add package FluentValidation.AspNetCore

Create a Request DTO

public class CreateUserRequest
{
    public string FirstName { get; set; }
    public string Email { get; set; }
    public int Age { get; set; }
}

This is a Request DTO — not your database entity.

Create the Validator

public class CreateUserRequestValidator 
    : AbstractValidator<CreateUserRequest>
{
    public CreateUserRequestValidator()
    {
        RuleFor(x => x.FirstName)
            .NotEmpty()
            .MinimumLength(3);

        RuleFor(x => x.Email)
            .NotEmpty()
            .EmailAddress();

        RuleFor(x => x.Age)
            .InclusiveBetween(18, 60);
    }
}

builder.Services.AddControllers()
    .AddFluentValidationAutoValidation();

builder.Services.AddValidatorsFromAssemblyContaining<CreateUserRequestValidator>();

That’s it. Every request is now validated automatically.

Why NOT Use a Generic Validator?
Many developers ask: “Can I create one generic validator for all requests?”

Short answer: No.

Here’s why:

Every request has different business rules
Generic validators become God classes
Rules turn into if/else chaos
You lose type safety
You break single responsibility

Validation is not generic — it is use-case specific.

The Industry Standard Pattern

CreateUserRequest      → CreateUserRequestValidator
UpdateUserRequest      → UpdateUserRequestValidator
CreateOrderRequest     → CreateOrderRequestValidator

Each API contract gets its own validator.

This gives you:

Clear rules per use case
Easy unit testing
Zero duplication
Clean controllers
Scalable architecture

Sharing Rules Without Duplication
You can still reuse logic safely.

Rule Extensions

public static class ValidationExtensions
{
    public static IRuleBuilderOptions<T, string> ValidEmail<T>(
        this IRuleBuilder<T, string> rule)
    {
        return rule.NotEmpty().EmailAddress();
    }
}

Usage:

RuleFor(x => x.Email).ValidEmail();

This keeps validators clean and reusable without breaking architecture.

Final Thought
FluentValidation is not just a validation tool — it is a design decision.

By using:

Request DTOs
One validator per request
Automatic pipeline validation

You build APIs that are:

Safer
Cleaner
Easier to test
Easier to maintain That is what real-world, production-grade .NET systems look like.