DEV Community: Abdul Imran Faridh

2+ Years as a .NET Developer in Chennai — What I Learned the Hard Way

Abdul Imran Faridh — Wed, 01 Jul 2026 07:27:49 +0000

Originally published at imrantech.hashnode.dev

I Thought I Was Ready. I Wasn't.

When I got my first job as a .NET developer, I genuinely believed college had prepared me well.

I knew C#. I understood databases. I had built a few small projects. I was ready.

Two weeks into the job, I realized I knew almost nothing about real software development.

This is an honest account of 2 years building production systems — what broke, what I fixed, and what I wish someone had told me before I started.

The First Few Months Were Humbling

My first real task was writing SQL queries for an HRMS system. Attendance reports, employee data, payroll calculations — all pulling from multiple tables.

I wrote the worst SQL of my life.

Bad JOINs everywhere. Stored procedures that nobody could read. API endpoints that made three times more database calls than needed. I didn't know what an N+1 problem was. I didn't know what query optimization meant in practice.

I knew SQL from college — SELECT, INSERT, UPDATE. But writing SQL that actually performs well in production with real data? That was a completely different skill that nobody taught me.

My senior reviewed my code and rewrote half of it. That was embarrassing. But it was also the most educational week of my entire career.

The lesson? Knowing the syntax is not the same as knowing how to write good code.

College Projects vs Real Projects — Nobody Tells You This

In college, we built projects to submit assignments. There was a beginning, a deadline, and it ended there.

In a real job, the project never ends. You're working on a system that:

Real people use every single day

Has existing code you didn't write and must understand

Has bugs in production that affect actual employees getting paid

The biggest shock for me was seeing the overall flow of a real system for the first time.

In college, I built isolated features. In my job, I had to understand how the attendance module connects to payroll, how payroll connects to leave management, how leave management affects the HRMS reports — everything talks to everything else.

Nobody prepares you for that complexity. You only understand it by working through it.

The Bug That Made Me Lose Sleep

Six months in, I was given a task to integrate biometric attendance hardware with our HRMS system.

I had never done hardware integration before. The device communicated through a specific protocol. Data had to be pulled automatically and synced into our SQL Server database through Apache Tomcat.

Nothing worked for days.

The device was online. The server was running. But no attendance data was coming through. I checked the code a hundred times. Everything looked correct.

The problem turned out to be a network port forwarding issue — nothing to do with my code at all. Once the network was configured correctly, everything worked immediately.

That experience taught me something important: in production, the bug is not always in your code. Sometimes it's infrastructure. Sometimes it's network. Sometimes it's configuration. A good developer checks everything, not just their own code.

The Moment I Realized I Had to Get Serious

Around the one year mark, I looked at the code I had written in my first few months and felt genuinely embarrassed.

Bad variable names. No error handling. Inefficient LINQ queries. API endpoints that returned way more data than the frontend needed.

I knew I was producing working code — but not good code.

That's when I made a decision: I want to be technically strong. I want to write optimized code that I'm proud of.

I started reading about EF Core performance. I learned what query optimization actually means. I started thinking about every database call I was making and asking myself — is this really necessary?

That mindset shift changed everything about how I write code today.

What I Wish Someone Had Told Me Before Day 1 Four honest things I would tell my younger self:

Learn confidently — don't be scared of what you don't know In the beginning I was afraid to ask questions because I thought it made me look stupid. It didn't. Asking good questions is a sign of a good developer. Pretending to understand when you don't just wastes everyone's time including yours.

Improve your logical thinking deliberately - Syntax you can always look up. Logic is what separates a good developer from an average one. Practice breaking problems down before touching the keyboard. The best developers think before they type.

Use AI tools — but don't become dependent on them ChatGPT, GitHub Copilot, Claude — these tools are genuinely useful and using them is not cheating. But use them to learn, not to avoid learning. When AI gives you code, understand why it works. If you can't explain it, you don't own it.

Real experience beats certifications - Nobody at my company asked about my college grades. They asked what I had built, what bugs I had fixed, and how I had improved performance. Real production experience is the most valuable thing you can build early in your career.

Where I Am Now

Two years in, I've shipped three production systems:

An HRMS platform with biometric attendance integration

An Inventory Management System

An E-Commerce application with Tally ERP integration

I've fixed N+1 problems that took API response time from 1 minute to 15 seconds. I've implemented JWT authentication with refresh token rotation. I've debugged production issues that had nothing to do with code.

Am I where I want to be technically? Not yet. That's the honest answer.

But I know exactly what I need to improve, I know how to learn, and I know that every bug I fix makes me better than I was yesterday.

One Last Thing

If you're just starting your .NET career or feel stuck in your first job — it's supposed to feel hard. The complexity is real. The learning curve is steep.

But every senior developer you admire was once staring at bad SQL wondering why nothing worked.

Keep going. Write the bad code first. Then make it better.

That's how everyone learns. 🚀

I write 3 practical .NET articles every week — real bugs, real fixes, real production lessons. Follow along if that sounds useful!

JWT Authentication Confused Me. Then I Built It From Scratch

Abdul Imran Faridh — Wed, 24 Jun 2026 09:21:26 +0000

Originally published at imrantech.hashnode.dev

The Honest Starting Point

When my tech lead told me to implement JWT for our HRMS portal with refresh token rotation for our HRMS portal, I nodded confidently and immediately opened Google. I had a rough idea of what JWT was. A token. You send it with every request. The server validates it. Simple enough right? Wrong. The moment I started actually building it, questions hit me one after another. Where do I store the refresh token? How short should the access token be? What happens when the refresh token expires? How do I actually revoke a token? After building it from scratch and getting it working in production, I want to walk you through the complete implementation — every file, every decision, and why I made it.

What Are We Actually Building?

Before code, let me explain the flow simply:

`User logs in

↓

Server returns TWO tokens:

→ Access Token (short-lived — expires in minutes)

→ Refresh Token (long-lived — expires in days)

↓

Client uses Access Token for every API request

↓

Access Token expires?

→ Client sends Refresh Token to get a NEW Access Token

→ No need to login again!

↓

Refresh Token expires?

→ User must login again`

Why two tokens? Because if your access token gets stolen, it expires quickly anyway. The refresh token lives in your database and can be revoked instantly if needed.

Project Structure

Here's how I structured the authentication across my project layers:

HRMS/

├── Controllers/

│ └── AuthController.cs ← API endpoints

├── HRMS.DAL/

│├── AuthService.cs ← Business logic

│ └── Interfaces/

│└── IAuthService.cs ← Contract

└── HRMS.EF/

├── Models/

│ ├── User.cs

│ └── RefreshToken.cs ← Stores refresh tokens in DB

└── DTOs/

└── AuthResponseDto.cs

Step 1 — The RefreshToken Model

First I created a database table to store refresh tokens:

// HRMS.EF/Models/RefreshToken.cs.

public class RefreshToken {

public int Id { get; set; }

public string Token { get; set; }

public DateTime Expires { get; set; }

public bool IsRevoked { get; set; }

public int UserId { get; set; } }

Three important fields here:

Expires — when does this refresh token die?
IsRevoked — did we manually invalidate it? (logout, security breach)
UserId — which user does this token belong to?

Step 2 — The Auth Response DTO

//HRMS.EF/DTOs/AuthResponseDto.cs

public class AuthResponseDto {

public string AccessToken { get; set; }

public string RefreshToken { get; set; }

}

Simple. Login returns both tokens together.

Step 3 — The AuthService

This is where the real logic lives.

//HRMS.DAL/AuthService.cs

public class AuthService : IAuthService {

private readonly AppDbContext _context;

private readonly IConfiguration _config;

public AuthService(AppDbContext context, IConfiguration config)
{
    _context = context;
    _config = config;
}

public async Task<string> Register(RegisterDto dto)
{
    var exists = await _context.Users
        .AnyAsync(x => x.Email == dto.Email);
    if (exists) return "User exists";

    var user = new User
    {
        Email = dto.Email,
        PasswordHash = BCrypt.Net.BCrypt.HashPassword(dto.Password),
        Role = "Employee"
    };

    _context.Users.Add(user);
    await _context.SaveChangesAsync();

    return "Registered";
}

public async Task<object> Login(LoginDto dto)
{
    var user = await _context.Users
        .FirstOrDefaultAsync(x => x.Email == dto.Email);

    if (user == null) return "Invalid";

    if (!BCrypt.Net.BCrypt.Verify(dto.Password, user.PasswordHash))
        return "Invalid";

    // Generate both tokens
    var accessToken = GenerateToken(user);
    var refreshToken = GenerateRefreshToken();

    // Save refresh token to database
    var entity = new RefreshToken
    {
        Token = refreshToken,
        Expires = DateTime.Now.AddDays(7),
        IsRevoked = false,
        UserId = user.Id
    };

    _context.RefreshTokens.Add(entity);
    await _context.SaveChangesAsync();

    return new
    {
        accessToken,
        refreshToken
    };
}

private string GenerateToken(User user)
{
    var claims = new[]
    {
        new Claim("UserId", user.Id.ToString()),
        new Claim(ClaimTypes.Role, user.Role)
    };

    var key = new SymmetricSecurityKey(
        Encoding.UTF8.GetBytes(_config["Jwt:Key"])
    );

    var creds = new SigningCredentials(
        key, SecurityAlgorithms.HmacSha256
    );

    var token = new JwtSecurityToken(
        claims: claims,
        expires: DateTime.Now.AddMinutes(15),
        signingCredentials: creds
    );

    return new JwtSecurityTokenHandler().WriteToken(token);
}

private string GenerateRefreshToken()
{
    return Guid.NewGuid().ToString();
}

}

A few things worth noting:

BCrypt for passwords — never store plain passwords. BCrypt.HashPassword() on register, BCrypt.Verify() on login.

Access token expiry — I set this to 15 minutes in production. During development I actually set it to 25 seconds to test the refresh flow quickly without waiting! If your token expires almost immediately while testing — that's why. 😄

Refresh token — I'm using Guid.NewGuid().ToString() which generates a unique random string. Simple and works perfectly for this use case.

Step 4 — The AuthController

//HRMS/Controllers/AuthController.cs

[ApiController]

[Route("api/auth")]

public class AuthController : ControllerBase {

private readonly IAuthService _service;

private readonly AppDbContext _context;

private readonly IConfiguration _config;

public AuthController(
    IAuthService service,
    AppDbContext context,
    IConfiguration config)
{
    _service = service;
    _context = context;
    _config = config;
}

[HttpPost("register")]
public async Task<IActionResult> Register(RegisterDto dto)
{
    return Ok(await _service.Register(dto));
}

[HttpPost("login")]
public async Task<IActionResult> Login(LoginDto dto)
{
    return Ok(await _service.Login(dto));
}

[HttpPost("refresh")]
public async Task<IActionResult> Refresh(string refreshToken)
{
    // Find the token in database
    var token = await _context.RefreshTokens
        .FirstOrDefaultAsync(x => x.Token == refreshToken);

    // Three checks before issuing new access token
    if (token == null || token.IsRevoked || token.Expires < DateTime.Now)
        return Unauthorized("Invalid refresh token");

    var user = await _context.Users.FindAsync(token.UserId);

    var newAccessToken = GenerateToken(user);

    return Ok(new { accessToken = newAccessToken });
}

private string GenerateToken(User user)
{
    var claims = new[]
    {
        new Claim("UserId", user.Id.ToString()),
        new Claim(ClaimTypes.Role, user.Role)
    };

    var key = new SymmetricSecurityKey(
        Encoding.UTF8.GetBytes(_config["Jwt:Key"])
    );

    var creds = new SigningCredentials(
        key, SecurityAlgorithms.HmacSha256
    );

    var token = new JwtSecurityToken(
        claims: claims,
        expires: DateTime.Now.AddMinutes(15),
        signingCredentials: creds
    );

    return new JwtSecurityTokenHandler().WriteToken(token);
}

}

The Refresh endpoint does three critical checks:

if (token == null || token.IsRevoked || token.Expires < DateTime.Now) return Unauthorized("Invalid refresh token");

token == null — doesn't exist in DB (fake token?)
token.IsRevoked — we manually revoked it (user logged out)
token.Expires < DateTime.Now — it's expired

All three must pass before we issue a new access token. This is the security layer.

Step 5 — Program.cs Configuration

//JWT Bearer setup

builder.Services.AddAuthentication(options => { options.DefaultAuthenticateScheme = "Bearer";

options.DefaultChallengeScheme = "Bearer";

})

.AddJwtBearer("Bearer", options =>

{

options.TokenValidationParameters = new TokenValidationParameters

{

ValidateIssuer = false,

ValidateAudience = false,

ValidateLifetime = true,

ValidateIssuerSigningKey = true,

RoleClaimType = System.Security.Claims.ClaimTypes.Role,

ClockSkew = TimeSpan.Zero, // ← Important!

IssuerSigningKey = new SymmetricSecurityKey( Encoding.UTF8.GetBytes(builder.Configuration["Jwt:Key"]))

};

});

//Swagger with Bearer support

builder.Services.AddSwaggerGen(options =>

{

options.AddSecurityDefinition("Bearer", new OpenApiSecurityScheme

{

Name = "Authorization",

Type = SecuritySchemeType.Http,

Scheme = "bearer",

BearerFormat = "JWT",

In = ParameterLocation.Header,

Description = "Enter your JWT token only (without 'Bearer' prefix)."

});

options.AddSecurityRequirement(new OpenApiSecurityRequirement

{

{

new OpenApiSecurityScheme

{

Reference = new OpenApiReference

{

Type = ReferenceType.SecurityScheme,

Id = "Bearer"

}

},

new string[] {}

}

});

});

//Middleware order matters!

app.UseAuthentication();

app.UseAuthorization();

The most important line here:

ClockSkew = TimeSpan.Zero

By default ASP.NET Core adds a 5-minute buffer to token expiry. So a token set to expire at 3:00 PM actually expires at 3:05 PM. That drives me crazy when testing. Setting ClockSkew = TimeSpan.Zero makes tokens expire exactly when you set them — no surprises.

Step 6 — appsettings.json

{

"Jwt":

{

"Key": "YourSuperSecretKeyHereMustBe32CharsMin!"

},

"ConnectionStrings":

{

"Default": "Server=...;Database=HRMS;..."

}

}

Important: Never commit your real JWT key to GitHub! Add appsettings.json to .gitignore or use environment variables in production.

The Before vs After Story

When I first implemented login, it looked like this:

// OLD — Simple JWT, no refresh token

public async Task<string> Login(LoginDto dto)

{

var user = await _context.Users .FirstOrDefaultAsync(x => x.Email dto.Email);

if (user null) return "Invalid";

if (!BCrypt.Net.BCrypt.Verify(dto.Password, user.PasswordHash))

return "Invalid";

return GenerateToken(user); // Just returns access token

}

The problem: When the access token expired, users got logged out and had to log in again. For an HRMS portal where HR managers are working all day — that's really annoying.

The refresh token approach fixes this silently in the background. The Angular frontend detects a 401 response, automatically calls /api/auth/refresh, gets a new access token, and retries the original request — all without the user ever knowing their token expired.

Complete Flow Summary:

POST /api/auth/login

→ Returns: { accessToken, refreshToken }

Every API request:

→ Header: Authorization: Bearer {accessToken}

Access token expires (401 response):

→ POST /api/auth/refresh?refreshToken={refreshToken}

→ Returns: { accessToken } (new one)

User logs out:

→ Set IsRevoked = true on refresh token in DB

→ Both tokens now dead

Key Takeaways:

Always use two tokens — short access token for security, long refresh token for user experience.

Store refresh tokens in DB — this is what allows you to revoke them instantly. If you store them only on the client side, you can never invalidate them.

Set ClockSkew to Zero — unless you enjoy debugging token expiry issues at weird times.

BCrypt for passwords — never plain text, never MD5, never SHA1. BCrypt only.

Check three things on refresh — token exists, not revoked, not expired. Skip any one of these and you have a security hole.

Conclusion

JWT with refresh tokens sounds complicated until you break it down step by step. The actual code isn't that large — it's just understanding why each piece exists.

The access token is your fast key. The refresh token is your backup key stored in a safe. Short-lived tokens keep you secure. Long-lived refresh tokens keep your users happy.

If this helped you, subscribe for 3 practical .NET articles every week — all from real production code just like this! 🚀

I Made Our Attendance API 75% Faster By Fixing One Stupid Mistake

Abdul Imran Faridh — Tue, 23 Jun 2026 13:21:29 +0000

Originally published at imrantech.hashnode.dev

It Started With Complaints

I work on an HRMS platform and our HR team kept telling me the attendance page was too slow. I ignored it the first couple of times — I thought maybe it was their internet connection or a slow PC. Then my manager asked me about it.

Okay fine. Time to actually look at this.

The attendance API was taking over 1 minute to return data for 6500 employees. One full minute. You could make a coffee and come back and it still wouldn't be done.

I Looked at the Wrong Place First

My first instinct was to look at the main SQL query. I had JOINs, GROUP BY, filters — surely something there was wrong.
But honestly? The query looked fine. I checked it three times.

I was confused. The SQL was clean. The database had indexes. So why was it so slow?

I almost opened a Stack Overflow tab. But then I added a simple Stopwatch log

`var sw = System.Diagnostics.Stopwatch.StartNew();

foreach (var item in data) {

item.EmpCategoryName = AppConfig.GetAppConfigDescription(item.EmpCategoryID);

}

sw.Stop(); LogError.WriteErrorLog("foreach time: " + sw.ElapsedMilliseconds + "ms");`

The log showed 45+ seconds just for the foreach loop.

Wait. What.

The Real Culprit

Here's the original code I had written:

This looked innocent. It was not.

foreach (var item in data) {

item.EmpCategoryName = AppConfig.GetAppConfigDescription(item.EmpCategoryID);

}

See the problem?

GetAppConfigDescription() was hitting the database on every single loop iteration.

If grouped data returned 150 rows — that's 150 separate database calls. Just to get category names. I was genuinely embarrassed when I realized this.

This is the N+1 problem. And it was hiding in a tiny helper method that looked completely harmless.

Here's what my full original code looked like:

public IList GetEmpAttenDanceDetails(GetNewAttenListDto obj)

{ try

{

using (var ctx = new hrms2Context())

{ var locationIds = obj.LocIds; var departmentIds = obj.DepartIds;

        var selectMonths = AppconfigtableList
            .Where(a => a.Source == "AttendanceDisplayMonth")
            .Select(o => o.Value)
            .FirstOrDefault();

        var today = DateTime.Now.Date;
        var fromMonth = today.AddMonths(-(Convert.ToInt32(selectMonths) - 1));
        var startDate = new DateTime(fromMonth.Year, fromMonth.Month, 1);
        var endDate = today;

        var data = ctx.tEmpAttendance
            .Join(ctx.tEmployees,
                a => a.EmpIoyeeID,
                b => b.ID,
                (a, b) => new { a, b })
            .Join(ctx.tLocations,
                ab => ab.b.EmpLocationID,
                d => d.ID,
                (ab, d) => new { ab, d })
            .Where(w =>
                w.d.IsActive &&
                w.ab.b.IsActive &&
                locationIds.Contains((int)w.ab.b.EmpLocationID) &&
                departmentIds.Contains((int)w.ab.b.DepartmentID) &&
                w.ab.a.AttendDate >= startDate &&
                w.ab.a.AttendDate < endDate.AddDays(1))
            .GroupBy(g => new
            {
                Year = g.ab.a.AttendDate.Year,
                Month = g.ab.a.AttendDate.Month,
                Category = g.ab.b.EmpCategoryID,
                Location = g.ab.b.EmpLocationID,
                LocationName = g.d.LocationName
            })
            .Select(s => new GetAllAttendanceDetailsDTO
            {
                AttendanceYear = s.Key.Year.ToString(),
                AttendanceMonth = new DateTime(s.Key.Year, s.Key.Month, 1)
                                    .ToString("MMMM"),
                AttendanceMonthInt = s.Key.Month,
                EmpCategoryID = s.Key.Category,
                LocationID = s.Key.Location,
                LocationName = s.Key.LocationName
            })
            .OrderByDescending(o => o.AttendanceYear)
            .ThenByDescending(o => o.AttendanceMonthInt)
            .ToList();

        // THE PROBLEM WAS HERE ALL ALONG
        foreach (var item in data)
        {
            item.EmpCategoryName = 
                AppConfig.GetAppConfigDescription(item.EmpCategoryID);
        }

        return data;
    }
}
catch (Exception ex)
{
    LogError.WriteErrorLog(
        "AttendanceNewService- GetEmpAttenDanceDetails : " + ex.Message);
    throw ex;
}

}

The main query? Perfect. The foreach at the bottom? Disaster.

The Fix Was Actually Simple

Once I understood the problem, the fix was straightforward.

Instead of calling the database on every loop iteration, I pre-fetch all category names once into a dictionary. Then inside the loop I just do a simple dictionary lookup — no database involved at all.

// Pre-fetch all category names in ONE call

var categoryIds = data .Select(d => d.EmpCategoryID) .Distinct() .ToList();

var categoryDict = AppconfigtableList .Where(a => categoryIds.Contains(a.ID)) .ToDictionary(a => a.ID, a => a.Description);

// Dictionary lookup — zero database calls

foreach (var item in data) { item.EmpCategoryName = categoryDict .GetValueOrDefault(item.EmpCategoryID ?? 0); }

That's it. Two small changes. No fancy libraries. No major refactoring.

Here's the full fixed version:

public IList GetEmpAttenDanceDetails(GetNewAttenListDto obj)

{

try

{

using (var ctx = new hrms2Context())

{

var locationIds = obj.LocIds; var departmentIds = obj.DepartIds;

        var selectMonths = AppconfigtableList
            .Where(a => a.Source == "AttendanceDisplayMonth")
            .Select(o => o.Value)
            .FirstOrDefault();

        var today = DateTime.Now.Date;
        var fromMonth = today.AddMonths(-(Convert.ToInt32(selectMonths) - 1));
        var startDate = new DateTime(fromMonth.Year, fromMonth.Month, 1);
        var endDate = today;

        var data = ctx.tEmpAttendance
            .Join(ctx.tEmployees,
                a => a.EmpIoyeeID,
                b => b.ID,
                (a, b) => new { a, b })
            .Join(ctx.tLocations,
                ab => ab.b.EmpLocationID,
                d => d.ID,
                (ab, d) => new { ab, d })
            .Where(w =>
                w.d.IsActive &&
                w.ab.b.IsActive &&
                locationIds.Contains((int)w.ab.b.EmpLocationID) &&
                departmentIds.Contains((int)w.ab.b.DepartmentID) &&
                w.ab.a.AttendDate >= startDate &&
                w.ab.a.AttendDate < endDate.AddDays(1))
            .GroupBy(g => new
            {
                Year = g.ab.a.AttendDate.Year,
                Month = g.ab.a.AttendDate.Month,
                Category = g.ab.b.EmpCategoryID,
                Location = g.ab.b.EmpLocationID,
                LocationName = g.d.LocationName
            })
            .Select(s => new GetAllAttendanceDetailsDTO
            {
                AttendanceYear = s.Key.Year.ToString(),
                AttendanceMonth = new DateTime(s.Key.Year, s.Key.Month, 1)
                                    .ToString("MMMM"),
                AttendanceMonthInt = s.Key.Month,
                EmpCategoryID = s.Key.Category,
                LocationID = s.Key.Location,
                LocationName = s.Key.LocationName
            })
            .OrderByDescending(o => o.AttendanceYear)
            .ThenByDescending(o => o.AttendanceMonthInt)
            .ToList();

        // Pre-fetch once
        var categoryIds = data
            .Select(d => d.EmpCategoryID)
            .Distinct()
            .ToList();

        var categoryDict = AppconfigtableList
            .Where(a => categoryIds.Contains(a.ID))
            .ToDictionary(a => a.ID, a => a.Description);

        // In-memory lookup
        foreach (var item in data)
        {
            item.EmpCategoryName = categoryDict
                .GetValueOrDefault(item.EmpCategoryID ?? 0);
        }

        return data;
    }
}
catch (Exception ex)
{
    LogError.WriteErrorLog(
        "AttendanceNewService- GetEmpAttenDanceDetails : " + ex.Message);
    throw ex;
}

}

Before vs After

	Before	After
Employees	6500	6500
Response Time	~1 minute	~15 seconds
DB calls in loop	150+	0
Improvement	—	75% faster

The HR team didn't even say thank you. They just stopped complaining. That felt like a win. 😄

What I Learned From This A few things I'll never forget after this:

The main query is not always the problem. I wasted time staring at perfectly fine SQL while the real issue was a tiny method call at the bottom.

Never trust what looks innocent. That one-liner GetAppConfigDescription() looked completely harmless. It wasn't.

Stopwatch logs are your best friend. Adding timing around different sections of code immediately told me where the problem was. I should have done that first.

Pre-fetch, then lookup. Any time you need external data inside a loop — fetch it all before the loop, store in a dictionary, and use .GetValueOrDefault() inside.

Wrapping Up

The N+1 problem doesn't always look like a classic SELECT inside a loop. Sometimes it hides inside a helper method that calls the database quietly in the background.

If your API is slow and you can't figure out why — add Stopwatch logs around each section. The numbers will tell you exactly where to look.

Hope this saves someone a few hours of frustration! If it did, consider subscribing — I write 3 practical .NET articles every week based on real things I've actually fixed in production.