DEV Community: Khashayar Nourian

Task, async, and await: the lifetime of asynchronous work

Khashayar Nourian — Sat, 03 Oct 2026 00:00:00 +0000

A method that fetches an HTTP response and parses it involves two related tasks: the HTTP task carries the response text, while the method's task represents the full work through parsing. Keeping those responsibilities separate makes it easier to see which result, failure, or cancellation reaches the caller.

await lets a method yield while an operation is incomplete and continue when it finishes; it does not block a thread just to wait, and it does not guarantee a pause if the task is already complete. The article follows that flow through HttpClient, error handling, cancellation, and continuation context—including why ConfigureAwait(false) is a scoped library-code choice, not a rule for every await.

The practical point: keep the task with the work so callers can observe its result and handle its outcome. For independent requests, start both before awaiting them; Task.WhenAll collects their results but does not start them.

CQRS with a separate read store: useful projections, new guarantees

Khashayar Nourian — Mon, 07 Sep 2026 00:00:00 +0000

A separate read store is not the next mandatory CQRS step. It is useful when a screen, report, or read workload needs a shape that the transactional write model should not own.

For an order-tracking screen, a projection can keep one denormalized row with an order number, customer name, status, last-updated time, and total. That can remove repeated joins and let read traffic scale separately from command handling.

The trade-off is visible behavior. A command can commit before the projection updates, so the next read can be stale. Treat the write side as authoritative, make projections rebuildable, and state what the user should expect after a successful command. If a shared database and direct projection already work, keep them.

Minimal CQRS: separate code paths, keep one application and one database

Khashayar Nourian — Thu, 03 Sep 2026 00:00:00 +0000

CQRS does not have to begin with a second database, a queue, or a separate service.

A useful first step is much smaller: keep one application and one database, but give commands and queries separate code paths. A command such as PlaceOrder loads the state it needs, checks business rules, and commits a change. A query such as GetOrderSummary can project exactly the fields a screen needs without rebuilding a domain aggregate.

The database is shared. The responsibilities are not.

This keeps transactions, immediate reads after a successful command, and a simple deployment model. It does not create independent read scaling or reporting projections for free. Those are later decisions, not a starting requirement.

CQS and commands: make the application understand intent

Khashayar Nourian — Wed, 26 Aug 2026 00:00:00 +0000

SetStatus(itemId, Deactivated) tells an application what a field should contain. DeactivateInventoryItem(itemId, reason) tells it what the user wants to do.

That difference matters when the action has rules. A deactivation may require a reason, permission, a valid state transition, and a transaction that saves the result. With a behavior-focused command, those concerns have one natural home instead of being inferred from changed fields or scattered between the UI and a generic update handler.

The UI can still help by explaining obvious failures early. It cannot be the final authority because another client, a retry, or a concurrent request can reach the same operation.

A command is also not an event. A command asks for work and may be rejected. An event describes something that already happened after the command succeeded.

When CRUD stops describing the work

Khashayar Nourian — Mon, 24 Aug 2026 00:00:00 +0000

CRUD is not the enemy. It is often the smallest correct design for a profile, a team setting, or a simple lookup table.

The trouble starts when a changed object hides a business action. An API that receives an updated inventory DTO can see that Status became Deactivated, but it still has to infer why that happened, whether a reason is required, who is allowed to do it, and what should happen next.

That is where Command-Query Separation helps. A query returns information. A command asks the system to change something. DeactivateInventoryItem(id, reason) says more than a generic update ever can.

This does not require two databases, a message broker, or microservices. It starts with making the request visible where the rules belong.

Async, concurrency, and parallelism are different

Khashayar Nourian — Mon, 17 Aug 2026 00:00:00 +0000

Async, concurrency, and parallelism answer different questions. Async is about avoiding a block while waiting for I/O. Concurrency is about letting independent operations make progress over the same period. Parallelism is about running CPU-bound calculations at the same time on different cores.

Two downloads can overlap without using two CPU cores. Two image-processing jobs can use multiple cores without any network wait. The distinction matters because the right tool depends on where the time goes.

Start with the bottleneck: use async for external waits, concurrency when independent waits can overlap, and parallelism when measurement shows CPU work is the problem. Keep small local work simple.

Why async programming exists

Khashayar Nourian — Sat, 15 Aug 2026 00:00:00 +0000

A slow HTTP request is not the same thing as a slow calculation. When an application waits for a database, file system, or remote service, most of that time is spent waiting on work outside the process.

Async lets the application yield during that wait and return to work that is ready. A UI can stay responsive, and a server can use its available capacity for other requests. The external operation still takes as long as it takes; async does not make the database or API faster.

I use async for meaningful I/O waits, not for a short calculation that already has its data in memory.

Three Ways to Clean Up Local Git Branches

Khashayar Nourian — Thu, 13 Aug 2026 00:00:00 +0000

Local branches accumulate for different reasons, so one cleanup command is not safe for every situation. A branch whose upstream is gone is different from one already merged into main, and both differ from a local branch you want to discard regardless of its merge status.

This post compares all three cases with Git Bash and PowerShell commands. The key safety distinction is -d versus -D: -d protects unmerged work, while -D bypasses that check. In particular, the gone-upstream command force-deletes matches without pausing for a preview, so inspect the list first if you need to protect local-only commits.

Choose the cleanup that matches the branch state, change the integration branch names to fit your repository, and do not force-delete work you may need.