DEV Community: zahid23saim

Building a Tested ASP.NET Core Minimal API in One File

zahid23saim — Thu, 03 Sep 2026 01:30:19 +0000

Minimal APIs are the fastest way I know to stand up a real HTTP service in .NET.
No controllers, no ceremony — you map routes to small lambdas and you are done.
But "fast to write" often turns into "quietly wrong": the happy path works in a
browser, and the status codes, validation, and edge cases are never actually
checked. This walks through a small task-tracker API in a single Program.cs, and
then the part people skip — integration tests that boot the whole app in memory
and hit the real endpoints.

Everything here is .NET 8, and the full project (with all tests passing) is on
GitHub: aspnet-minimal-api.

The API

The whole service fits on one screen. An in-memory ConcurrentDictionary stands
in for a database so it runs with zero setup; swapping it for EF Core later leaves
the endpoint shapes untouched.

using System.Collections.Concurrent;

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

var store = new ConcurrentDictionary<int, TodoTask>();
var nextId = 0;

app.MapGet("/tasks", () => store.Values.OrderBy(t => t.Id));

app.MapGet("/tasks/{id:int}", (int id) =>
    store.TryGetValue(id, out var task) ? Results.Ok(task) : Results.NotFound());

app.MapPost("/tasks", (CreateTask input) =>
{
    if (string.IsNullOrWhiteSpace(input.Title))
        return Results.ValidationProblem(new Dictionary<string, string[]>
        {
            ["title"] = new[] { "Title is required." }
        });

    var id = Interlocked.Increment(ref nextId);
    var task = new TodoTask(id, input.Title.Trim(), Done: false);
    store[id] = task;
    return Results.Created($"/tasks/{id}", task);
});

app.MapPut("/tasks/{id:int}/complete", (int id) =>
{
    if (!store.TryGetValue(id, out var task)) return Results.NotFound();
    store[id] = task with { Done = true };
    return Results.Ok(store[id]);
});

app.MapDelete("/tasks/{id:int}", (int id) =>
    store.TryRemove(id, out _) ? Results.NoContent() : Results.NotFound());

app.Run();

public record TodoTask(int Id, string Title, bool Done);
public record CreateTask(string? Title);
public partial class Program { }

A few decisions in here matter more than they look:

Results.Created(...) returns 201 and a Location header pointing at the new resource — the correct REST response to a create, and one a hand-rolled return task; silently gets wrong.
Validation returns 400, not an exception. Results.ValidationProblem produces a proper problem-details body, so a blank title is a clean client error rather than a 500.
record types give value semantics and the with expression, so task with { Done = true } is a one-liner that returns a new, updated task.
{id:int} route constraints mean /tasks/abc never even reaches the handler.
That last line — public partial class Program { } — exists only so the test project can reference Program. It is the one non-obvious requirement for what comes next.

The part people skip: testing it

The temptation is to test the handlers as plain functions. The problem is that
skips everything that makes it a web API — routing, model binding, status codes,
serialization. ASP.NET Core ships WebApplicationFactory<Program>, which boots the
entire app in memory and hands you an HttpClient wired to it. No mocks, no
running server, no ports.

public class TaskApiTests : IDisposable
{
    private readonly WebApplicationFactory<Program> _factory = new();
    public void Dispose() => _factory.Dispose();

    private record TaskDto(int Id, string Title, bool Done);

    [Fact]
    public async Task Create_then_fetch_roundtrips()
    {
        var client = _factory.CreateClient();

        var created = await client.PostAsJsonAsync("/tasks", new { title = "write tests" });
        Assert.Equal(HttpStatusCode.Created, created.StatusCode);
        Assert.NotNull(created.Headers.Location);

        var task = await created.Content.ReadFromJsonAsync<TaskDto>();
        var fetched = await client.GetFromJsonAsync<TaskDto>($"/tasks/{task!.Id}");
        Assert.Equal(task.Id, fetched!.Id);
    }

    [Fact]
    public async Task Blank_title_is_rejected_with_400()
    {
        var client = _factory.CreateClient();
        var res = await client.PostAsJsonAsync("/tasks", new { title = "   " });
        Assert.Equal(HttpStatusCode.BadRequest, res.StatusCode);
    }
}

These are real HTTP requests against the real pipeline. The full suite also covers
completing a task, trimming a title, a 404 on a missing id, and deleting the same
task twice (204 then 404).

The isolation trap I hit writing this

My first version shared one WebApplicationFactory across the whole test class
with IClassFixture. That reuses a single app instance — and since the store is
in-memory, one test's writes leaked into the next. The "empty store returns an
empty list" test failed because earlier tests had already added rows.

The fix is the shape above: create a fresh factory per test (in the constructor,
disposed in Dispose) so each test gets its own store. For a stateful in-memory
service this is the correct isolation, and it is worth knowing before a flaky
suite sends you debugging the API when the API was never the problem.

Takeaway

Minimal APIs make the endpoints tiny, which is exactly why the discipline has to
move into the tests. WebApplicationFactory lets you verify the whole HTTP surface
— status codes, headers, validation, edge cases — in a few dozen lines and no
infrastructure. The complete, passing project is
here if you want to run it.

What I Learned Evaluating LLMs Across Four Languages

zahid23saim — Thu, 03 Sep 2026 00:39:04 +0000

Most writing about large language models assumes English. The benchmarks are in English, the failure examples are in English, and the quiet implication is that whatever is true in English is true everywhere else, just a little worse. After spending a long stretch evaluating model output across English, Hindi, Tamil, and Marathi, I can say that assumption is wrong in ways that actually matter — and the differences taught me more about how these models work than any English-only evaluation did.

This is an opinion piece, not a benchmark. But the opinions come from sitting with thousands of real outputs in four languages, so here is what stuck.

The quality gap is not uniform, and it is not where you would guess

The naive mental model is a single dial: English is best, and every other language is some fixed amount worse. Reality is lumpier than that. A model can be genuinely strong at conversational Hindi and fall apart on Tamil technical vocabulary. It can produce fluent Marathi that is subtly wrong about facts, while producing slightly awkward English that is factually correct. The gap depends on the interaction of language and task, not on the language alone — and you only see that if you evaluate the same task across all four rather than testing each language on whatever happens to be convenient.

Fluency hides errors, and it hides them worse in some languages

The most dangerous output is the one that reads beautifully and is wrong. In English, reviewers have enough exposure to model quirks that a confident-but-wrong answer often still trips an alarm. In a language where fluent model output is rarer and more impressive, that same confident tone is far more likely to be taken at face value. I caught myself doing it: a well-formed Tamil paragraph feels authoritative in a way a clunky one does not, and that feeling has nothing to do with whether the content is correct. Evaluating across languages made me distrust fluency as a signal entirely, which improved my English evaluation too.

Script and tokenization problems are real and easy to miss

Some of the most concrete failures had nothing to do with meaning. A model would drop or mangle a diacritic, mix two scripts in one word, or transliterate when it should have translated. These are the kind of errors a monolingual English reviewer never encounters and never thinks to check for, and an automated exact-match check often waves them through because the answer is "close enough" at the character level while being clearly wrong to a native reader. If you are building evaluation tooling for multilingual output, normalization and script handling deserve as much care as the semantic checks — maybe more.

Code-switching is where models are most human and most fragile

Real speakers of these languages mix in English words constantly — technical terms, brand names, whole clauses. Sometimes the models handle this gracefully, which is genuinely impressive. Other times a single English word in a Hindi sentence throws off the grammar of everything around it, or the model over-corrects and translates a term that should have been left in English. This is exactly the kind of edge case that never shows up in a clean, single-language benchmark, and it is where the difference between "sounds fluent" and "is actually correct" is widest.

Why this matters beyond the four languages I worked in

The practical lesson is not about Hindi or Tamil or Marathi specifically. It is that evaluating a model in one language tells you how it performs in that language, and almost nothing reliable about the rest. If your product will be used in more than one language — and most will be — then single-language evaluation is not a smaller version of the real thing; it is measuring something different from what you actually ship. Building the habit of testing the same task across several languages, and of not trusting fluency as a proxy for correctness, changed how I read every model output, English included.

The models are getting better at all of this quickly. But "better on average" can still hide a specific language or a specific kind of task where the model quietly fails, and averages are exactly what single-language evaluation is built to produce. The only way I found to see the gaps was to look for them in more than one language on purpose.

Speeding Up a Slow PL/SQL Routine with BULK COLLECT and FORALL

zahid23saim — Thu, 03 Sep 2026 00:35:44 +0000

The single most common performance problem I have run into in Oracle PL/SQL is not a missing index or a bad join. It is a loop that processes one row at a time. The code reads fine, it passes review, and then it runs for forty minutes on a table that has grown past what anyone tested against. This tutorial walks through why that happens and how BULK COLLECT and FORALL fix it, usually by an order of magnitude, without changing what the routine actually does.

The problem: the context switch

When a PL/SQL block runs a SQL statement, control passes from the PL/SQL engine to the SQL engine and back. That handoff is called a context switch, and on its own it is cheap. The trouble is doing it inside a loop, once per row. A cursor FOR loop that inserts each fetched row looks harmless:

BEGIN
  FOR rec IN (SELECT id, amount FROM staging_payments) LOOP
    INSERT INTO payments (id, amount, loaded_at)
    VALUES (rec.id, rec.amount, SYSDATE);
  END LOOP;
  COMMIT;
END;

For a few hundred rows this is fine. For a few million, you are paying for millions of context switches, and that overhead — not the actual insert work — becomes the bottleneck.

Step 1: fetch in batches with BULK COLLECT

Instead of fetching one row per round trip, BULK COLLECT pulls many rows into a collection in a single switch. The key detail people miss is the LIMIT clause: without it, you load the entire result set into memory at once, which can blow up PGA on a large table. Batching in chunks keeps memory bounded.

DECLARE
  CURSOR c IS SELECT id, amount FROM staging_payments;

  TYPE t_ids IS TABLE OF staging_payments.id%TYPE;
  TYPE t_amts IS TABLE OF staging_payments.amount%TYPE;

  v_ids  t_ids;
  v_amts t_amts;
BEGIN
  OPEN c;
  LOOP
    FETCH c BULK COLLECT INTO v_ids, v_amts LIMIT 5000;
    EXIT WHEN v_ids.COUNT = 0;
    -- v_ids / v_amts now hold up to 5000 rows fetched in one context switch
  END LOOP;
  CLOSE c;
END;

Note the %TYPE anchors on the collection element types — if the column definition changes, the code follows it instead of breaking. And place the EXIT WHEN v_ids.COUNT = 0 right after the fetch so the last, partial batch is still processed before you leave the loop.

Step 2: write in batches with FORALL

FORALL is the write-side counterpart. It sends an entire collection to the SQL engine in one statement instead of looping in PL/SQL. Putting the two together:

DECLARE
  CURSOR c IS SELECT id, amount FROM staging_payments;

  TYPE t_ids IS TABLE OF staging_payments.id%TYPE;
  TYPE t_amts IS TABLE OF staging_payments.amount%TYPE;

  v_ids  t_ids;
  v_amts t_amts;
BEGIN
  OPEN c;
  LOOP
    FETCH c BULK COLLECT INTO v_ids, v_amts LIMIT 5000;
    EXIT WHEN v_ids.COUNT = 0;

    FORALL i IN 1 .. v_ids.COUNT
      INSERT INTO payments (id, amount, loaded_at)
      VALUES (v_ids(i), v_amts(i), SYSDATE);

    COMMIT;  -- commit per batch, not per row
  END LOOP;
  CLOSE c;
END;

The routine does exactly the same thing as the original — read staging rows, insert them into payments — but instead of millions of context switches it now makes a handful per batch. On real workloads this is routinely the difference between minutes and seconds.

Step 3: don't let one bad row kill the batch

A FORALL insert stops on the first error by default, which means one malformed row can abort a 5000-row batch. SAVE EXCEPTIONS lets the batch finish and collects the failures so you can log them instead of losing the whole run:

    BEGIN
      FORALL i IN 1 .. v_ids.COUNT SAVE EXCEPTIONS
        INSERT INTO payments (id, amount, loaded_at)
        VALUES (v_ids(i), v_amts(i), SYSDATE);
    EXCEPTION
      WHEN OTHERS THEN
        FOR e IN 1 .. SQL%BULK_EXCEPTIONS.COUNT LOOP
          DBMS_OUTPUT.PUT_LINE(
            'row ' || SQL%BULK_EXCEPTIONS(e).ERROR_INDEX ||
            ' failed: ' || SQLERRM(-SQL%BULK_EXCEPTIONS(e).ERROR_CODE));
        END LOOP;
    END;

Now a handful of bad rows get reported by index and reason, and the millions of good rows still load.

When not to reach for this

The honest caveat: if the whole thing can be expressed as a single set-based statement — INSERT INTO payments SELECT ... FROM staging_payments — do that instead. Pure SQL avoids the PL/SQL engine entirely and is almost always fastest. BULK COLLECT and FORALL earn their keep when you genuinely need procedural logic in the middle — per-row transformation, calling a function, conditional routing — that can't be pushed down into one SQL statement. In that case, batching is what turns an overnight job back into a coffee-break one.

Automating LLM Answer Evaluation with a Small Python Scoring Script

zahid23saim — Thu, 03 Sep 2026 00:29:58 +0000

If you have ever evaluated a language model's output by hand, you know how quickly it stops scaling. Ten answers are fine. A thousand answers, re-run every time someone tweaks a prompt, is not. After spending a lot of time auditing LLM output for correctness, I have found that a small, boring Python script removes most of the pain — and, just as importantly, makes your evaluation consistent instead of depending on how tired the reviewer is.

This tutorial builds a minimal but genuinely useful scoring harness: give it a set of questions with known correct answers and the model's answers, and it returns a score plus a list of exactly which items failed and why. No frameworks, standard library only.

The idea

Most "did the model get it right?" checks fall into three buckets:

Exact match after light normalization (case, whitespace, punctuation).
Numeric match within a tolerance (the model says 3.14, the gold answer is 3.14159).
Contains — the gold answer appears somewhere in a longer response.

A good harness applies the right check per question rather than forcing everything through exact match, which is where naive scripts quietly report wrong numbers.

The gold set

Keep your evaluation data as plain JSON so anyone can edit it without touching code:

[
  {"id": "q1", "question": "What year did the first moon landing happen?", "answer": "1969", "match": "contains"},
  {"id": "q2", "question": "What is pi to two decimals?", "answer": "3.14", "match": "numeric", "tol": 0.01},
  {"id": "q3", "question": "Name the capital of France.", "answer": "Paris", "match": "contains"}
]

The match field is the important part: it tells the scorer how to compare, so each question is judged the way it should be.

The scorer

import json
import re


def normalize(text):
    """Lowercase, strip, collapse whitespace, drop trailing punctuation."""
    text = text.strip().lower()
    text = re.sub(r"\s+", " ", text)
    return text.rstrip(".!?,;:")


def first_number(text):
    """Pull the first number out of a string, or None if there isn't one."""
    m = re.search(r"-?\d+(?:\.\d+)?", text.replace(",", ""))
    return float(m.group()) if m else None


def is_correct(item, model_answer):
    kind = item.get("match", "exact")
    gold = item["answer"]

    if kind == "exact":
        return normalize(model_answer) == normalize(gold)

    if kind == "contains":
        return normalize(gold) in normalize(model_answer)

    if kind == "numeric":
        got = first_number(model_answer)
        want = first_number(gold)
        if got is None or want is None:
            return False
        return abs(got - want) <= item.get("tol", 0.0)

    raise ValueError(f"unknown match type: {kind!r}")


def score(gold_path, answers):
    """answers: dict of {id: model_answer_string}. Returns (score, failures)."""
    gold = json.load(open(gold_path, encoding="utf-8"))
    passed, failures = 0, []
    for item in gold:
        model_answer = answers.get(item["id"], "")
        if is_correct(item, model_answer):
            passed += 1
        else:
            failures.append({
                "id": item["id"],
                "question": item["question"],
                "expected": item["answer"],
                "got": model_answer or "(no answer)",
            })
    return passed / len(gold), failures

Running it

answers = {
    "q1": "The first moon landing was in 1969.",
    "q2": "Pi is about 3.14159",
    "q3": "The capital of France is Paris.",
}

acc, failures = score("gold.json", answers)
print(f"accuracy: {acc:.0%}")
for f in failures:
    print(f"FAIL {f['id']}: expected {f['expected']!r}, got {f['got']!r}")

Two things make this more useful than a one-line accuracy number. First, q1 passes even though the model wrapped 1969 in a full sentence, because contains/normalization handles the wrapping — an exact-match-only script would have marked it wrong and sent you chasing a non-bug. Second, every failure comes back with the question, the expected answer, and what the model actually said, so you can see why it failed instead of just that it failed.

Where to take it next

Once this is in place, small additions pay off quickly:

Regression tracking: dump the failures to a file per run and diff two runs, so you can see exactly which items a prompt change broke or fixed.
Weighting: add a weight field for questions that matter more.
Guarding the input: reject a gold file where two items share an id, or where a numeric item's answer has no number in it — bad eval data causes more wrong conclusions than bad models do.

None of this is fancy, and that is the point. A hundred lines of readable Python turns "I looked at some outputs and they seemed okay" into a repeatable number with a paper trail — which is the difference between an opinion about a model and an actual evaluation of it.