DEV Community: Mina Golzari Dalir

From State Machines to Configurable Workflows

Mina Golzari Dalir — Fri, 09 Oct 2026 13:55:03 +0000

There is a stage in software development where the hardest problem is no longer writing the code.

It is deciding whether the architecture you chose six months ago is still the right architecture today.

Recently, I found myself dealing with exactly this situation while designing a workflow-heavy .NET system.

The initial problem looked like a perfect use case for a state machine.

An entity had a lifecycle.

It moved from one state to another.

Some transitions were allowed, some were not.

The rules could be expressed clearly in code.

So we implemented a state-machine-oriented design.

It worked.

And that is important.

The state machine was not a bad decision.

In fact, it was the right decision for the problem we had at that time.

The problem appeared later, when the business scenarios started changing.

New scenarios appeared.

Different customers needed different processes.

Some steps became optional.

Some steps were conditional.

Some processes needed additional approval.

Existing running processes had to continue using their original rules.
At that point, the question changed from:

"What state is this entity in?"

to:

"Which business process should this entity follow?"

That distinction completely changed my view of the architecture.

This article explains that evolution.

1. The Original Problem

Let's use a fictional example.

Imagine we are building an Order Fulfillment Platform for an e-commerce company.

An order goes through a process like:

Created
   ↓
Payment Verified
   ↓
Inventory Reserved
   ↓
Packed
   ↓
Shipped
   ↓
Delivered

Initially, this looks like a textbook state machine.

We can define:

public enum OrderState
{
    Created,
    PaymentVerified,
    InventoryReserved,
    Packed,
    Shipped,
    Delivered,
    Cancelled
}

And events:

public enum OrderEvent
{
    VerifyPayment,
    ReserveInventory,
    Pack,
    Ship,
    Deliver,
    Cancel
}

Then transitions:

Created
   ├── VerifyPayment → PaymentVerified
   └── Cancel → Cancelled

PaymentVerified
   ├── ReserveInventory → InventoryReserved
   └── Cancel → Cancelled

InventoryReserved
   └── Pack → Packed

Packed
   └── Ship → Shipped

Shipped
   └── Deliver → Delivered

This is clean.

It is easy to understand.

It is easy to test.

And most importantly, it protects the business rules.

An order cannot simply jump from:

Created → Delivered

because that transition doesn't exist.

For a stable process, this is exactly what we want.

2. Why We Initially Chose a State Machine

A state machine gave us several useful properties.

Explicit states

The possible lifecycle states were clearly defined.

Explicit transitions

We could see exactly which transitions were legal.

Centralized rules

Instead of scattering conditions throughout controllers and services, transition rules were concentrated in one place.

Type safety

The compiler knew about states and events.

Testability

We could easily test:

Given Created
When VerifyPayment
Then PaymentVerified

and:

Given Created
When Deliver
Then Reject

This is much safer than having arbitrary status updates throughout the application.

At this point, choosing a state machine was a reasonable engineering decision.

3. Then the Business Changed

The first new requirement was simple:

Premium customers should have priority packing.

We added a condition.

Then another requirement appeared:

Orders above $1,000 require manual fraud review.

So the process became:

Created
   ↓
Payment Verified
   ↓
Fraud Review
   ↓
Inventory Reserved
   ↓
Packed
   ↓
Shipped

But only for some orders.

Then:

Digital products don't need shipping.

Now we had:

Physical Order:

Payment
 ↓
Inventory
 ↓
Packing
 ↓
Shipping
 ↓
Delivery

while:

Digital Order:

Payment
 ↓
Fulfillment
 ↓
Completed

Then another customer introduced:

Orders containing regulated products require compliance verification.

And another:

Enterprise customers require account-manager approval before fulfillment.

The process was no longer one fixed sequence.

It had become a collection of possible processes.

4. The State Machine Started Growing

The state machine itself could still handle these requirements.

That is important.

A state machine is not incapable of handling conditional logic.

We could add guards:

if (order.IsDigital)
{
    // Skip physical fulfillment
}

if (order.TotalAmount > 1000)
{
    // Require fraud review
}

if (order.ContainsRegulatedProducts)
{
    // Require compliance
}

if (order.CustomerType == CustomerType.Enterprise)
{
    // Require account manager approval
}

But something started bothering me.

The state machine was increasingly responsible for understanding:

customer type
product type
order value
risk level
geography
compliance requirements
approval policies
fulfillment strategy

The question was no longer simply:

"What state is the order in?"

The state machine was starting to answer:

"Which business process should this order follow?"

That is a different responsibility.

5. The Real Problem: State vs Process

This became the key architectural insight.

A state describes the current condition of something.

For example:

PaymentVerified

A workflow describes how something should progress through a business process.

For example:

Payment
 → Fraud Review
 → Inventory
 → Packing
 → Shipping

These are related, but they are not the same concept.

A state machine is excellent at answering:

"Can this entity move from state A to state B?"

A workflow engine needs to answer:

"Which steps should this business process execute, in what order, under which conditions?"

Once we recognized this distinction, the architecture became much clearer.

6. What We Actually Needed

We needed the process itself to become configurable.

Instead of hard-coding:

Payment
 → Fraud Review
 → Inventory
 → Packing
 → Shipping

we wanted to define:

Workflow
    ↓
Version
    ↓
Steps
    ↓
Conditions
    ↓
Handlers

For example:

OrderFulfillment
Version 1

1. VerifyPayment
2. ReserveInventory
3. Pack
4. Ship
5. Deliver

Another version could be:

OrderFulfillment
Version 2

1. VerifyPayment
2. FraudReview
3. ReserveInventory
4. Pack
5. Ship
6. Deliver

And a digital-product workflow could be:

DigitalOrderFulfillment
Version 1

1. VerifyPayment
2. PrepareDownload
3. CompleteOrder

The workflow itself is now data.

7. But We Didn't Want a "Everything Is JSON" System

This was an important design constraint.

A configurable workflow can easily become dangerous.

It is tempting to put everything into JSON:

{
  "condition": "order.amount > 1000 && customer.type == 'Enterprise'"
}

Then create a generic interpreter.

Eventually, you have effectively invented your own programming language.

That creates a different class of problems:

difficult debugging
weak type safety
difficult refactoring
runtime failures
complicated validation
security concerns
difficult IDE support

We wanted configurability without abandoning normal .NET engineering practices.

That led us to the handler-based model.

8. The Handler-Based Workflow

The workflow defines what should happen.

The handler defines how it happens.

For example:

Workflow Step
      ↓
Handler Key
      ↓
Handler

A workflow might contain:

VerifyPayment
ReserveInventory
FraudReview
PackOrder
ShipOrder

These map to handlers:

VerifyPayment
      ↓
VerifyPaymentHandler

ReserveInventory
      ↓
ReserveInventoryHandler

FraudReview
      ↓
FraudReviewHandler

PackOrder
      ↓
PackOrderHandler

ShipOrder
      ↓
ShipOrderHandler

A simple interface could look like:

public interface IWorkflowHandler
{
    string Key { get; }

    Task<WorkflowStepResult> ExecuteAsync(
        WorkflowContext context,
        CancellationToken cancellationToken);
}

An implementation:

public sealed class VerifyPaymentHandler
    : IWorkflowHandler
{
    public string Key => "VerifyPayment";

    public async Task<WorkflowStepResult> ExecuteAsync(
        WorkflowContext context,
        CancellationToken cancellationToken)
    {
        // Payment verification logic

        return WorkflowStepResult.Success();
    }
}

The workflow engine doesn't need to know how payment verification works.

It only knows:

Execute "VerifyPayment"

The handler contains the actual business/application logic.

9. Handler Resolution

The application can register handlers using normal .NET dependency injection:

services.AddScoped<IWorkflowHandler, VerifyPaymentHandler>();
services.AddScoped<IWorkflowHandler, ReserveInventoryHandler>();
services.AddScoped<IWorkflowHandler, FraudReviewHandler>();
services.AddScoped<IWorkflowHandler, PackOrderHandler>();
services.AddScoped<IWorkflowHandler, ShipOrderHandler>();

A resolver can then find a handler by its key:

public sealed class WorkflowHandlerResolver
{
    private readonly IEnumerable<IWorkflowHandler> _handlers;

    public WorkflowHandlerResolver(
        IEnumerable<IWorkflowHandler> handlers)
    {
        _handlers = handlers;
    }

    public IWorkflowHandler Resolve(string key)
    {
        return _handlers.FirstOrDefault(x => x.Key == key)
            ?? throw new InvalidOperationException(
                $"Handler '{key}' was not found.");
    }
}

This gives us a useful boundary.

The workflow is configurable.

The executable business capabilities remain strongly typed.

10. Workflow Configuration

A workflow definition might conceptually look like:

WorkflowDefinition
-------------------------
Key
Name
Version
Status

And its steps:

WorkflowStep
-------------------------
WorkflowVersionId
Key
Order
Configuration

Transitions:

WorkflowTransition
-------------------------
FromStep
ToStep
Condition

For example:

OrderFulfillment v3

VerifyPayment
      ↓
FraudReview
      ↓
ReserveInventory
      ↓
PackOrder
      ↓
ShipOrder
      ↓
DeliverOrder

The important part is that the workflow engine doesn't need to be changed when we rearrange these existing capabilities.

11. Versioning Changes Everything

This was one of the strongest reasons to move toward a versioned workflow.

Imagine that version 1 is currently being used by thousands of orders.

Then the business introduces mandatory fraud screening.

We don't want to modify the meaning of an existing order's process.

Instead:

OrderFulfillment v1

remains unchanged.

We publish:

OrderFulfillment v2

with:

VerifyPayment
    ↓
FraudReview
    ↓
ReserveInventory
    ↓
PackOrder
    ↓
ShipOrder

New orders use v2.

Existing orders continue using v1.

This gives us historical reproducibility.

We can answer:

"Which process governed this order?"

with:

Order #12345
Workflow: OrderFulfillment
Version: 1

rather than trying to reconstruct the rules from the current application code.

12. The Most Important Rule: A Workflow Instance Has a Version

I would strongly recommend that a running workflow instance stores its workflow version.

Conceptually:

WorkflowInstance
-------------------------
Id
WorkflowDefinitionId
WorkflowVersionId
BusinessEntityId
CurrentStep
Status
StartedAt
CompletedAt

This means:

Order #1001 → Fulfillment v1
Order #1002 → Fulfillment v1
Order #1003 → Fulfillment v2
Order #1004 → Fulfillment v2

The active workflow can evolve without rewriting history.

This becomes especially important for systems involving:

regulations
financial processes
approvals
contracts
compliance
long-running operations

13. What Happens When the Business Changes Again?

Suppose we currently have:

v2:

Payment
 ↓
Fraud Review
 ↓
Inventory
 ↓
Packing
 ↓
Shipping

Now the business says:

Orders above $5,000 require manager approval.

We can create:

v3:

Payment
 ↓
Fraud Review
 ↓
Inventory
 ↓
Manager Approval
 ↓
Packing
 ↓
Shipping

The workflow engine remains unchanged.

If ManagerApprovalHandler already exists, this can potentially be configuration-only.

That is the key advantage.

14. Three Levels of Change

This led me to a useful way of thinking about the architecture.

Level 1 — Change the process

Existing handlers are sufficient.

A → B → C

becomes:

A → C → B

No application code needs to change.

Only the workflow definition changes.

Level 2 — Change handler configuration

The capability already exists, but its behavior needs parameters.

For example:

FraudReviewHandler

could receive configuration:

{
    "riskThreshold": 700,
    "manualReviewRequired": true
}

Different workflow versions can configure the same handler differently.

Level 3 — Introduce a new capability

The business introduces something that doesn't exist.

For example:

GovernmentComplianceCheck

There is no existing handler.

We implement:

GovernmentComplianceCheckHandler

After that, the handler becomes another reusable building block for future workflows.

This is the boundary I find most useful.

Configuration should compose capabilities. Code should create new capabilities.

15. Conditional Branching

The workflow can also represent conditional paths.

For example:

                 Payment
                    ↓
               Fraud Check
                    ↓
              Risk Level?
              /          \
           Low            High
            ↓               ↓
       Inventory        Manual Review
            │               │
            └───────┬───────┘
                    ↓
                  Packing

The workflow definition can reference a rule:

HighRiskOrder

rather than embedding arbitrary code into configuration.

The rule itself can remain strongly typed:

public interface IWorkflowRule
{
    string Key { get; }

    Task<bool> EvaluateAsync(
        WorkflowContext context,
        CancellationToken cancellationToken);
}

This keeps the dynamic part controlled.

16. Parallel Steps

Another situation where the workflow abstraction becomes attractive is parallel execution.

Suppose after payment verification we need:

              Payment
                ↓
        ┌───────┼────────┐
        ↓       ↓        ↓
      Fraud   Inventory  Compliance
        │       │        │
        └───────┼────────┘
                ↓
              Packing

These checks are conceptually independent.

A workflow engine can represent:

Parallel
   ├── Fraud
   ├── Inventory
   └── Compliance
        ↓
       Join
        ↓
      Packing

A state machine can also model this.

But as the number of parallel activities increases, a state machine often starts requiring composite states, flags, guards, and synchronization logic.

At that point, we're gradually building a workflow engine inside the state machine.

17. Human Tasks and Long-Running Processes

Another difference appears when the process needs human interaction.

For example:

Fraud Review
      ↓
Manual Approval
      ↓
Wait for Manager
      ↓
Continue

The manager may approve it:

in 30 seconds

or:

in 3 days

A workflow instance can persist:

Status = Waiting
CurrentStep = ManagerApproval
AssignedTo = Manager
DueAt = ...

and resume later.

Again, a state machine can support this, but now we need to build persistence, resumption, scheduling, timeout handling, and related infrastructure around it.

The workflow abstraction naturally starts to fit the problem better.

18. So Is a Configurable Workflow Always Better?

No.

This is probably the most important conclusion of this whole exercise.

A configurable workflow introduces significant complexity.

You now need to think about:

workflow definitions
versions
instance persistence
step execution
retries
idempotency
concurrency
conditions
failure handling
timeouts
audit history
authorization
migrations
debugging
configuration validation

A simple state machine does not need all of this.

If the process is:

Created
↓
Approved
↓
Completed

building a workflow engine would be overengineering.

A state machine is probably the better solution.

19. State Machine vs Configurable Workflow

The comparison I now use is not:

"Which one is more powerful?"

It is:

"Which type of change does the system need to optimize for?"

20. The Architectural Lesson

The biggest lesson for me was not:

"State machines are bad."

They aren't.

The lesson was:

We had initially modeled the problem as state transitions, but the problem eventually became process orchestration.

That is a very different problem.

A state machine asks:

What state am I in?
What transitions are legal?

A configurable workflow asks:

Which process applies?
Which version applies?
Which step comes next?
Which conditions apply?
Which handler executes it?
Can this step run in parallel?
Should we wait?
Can we retry?
How do we resume?

Once the business starts asking those questions, a workflow abstraction becomes much more appropriate.

21. The Architecture I Would Choose

The resulting architecture looks roughly like this:

                 ┌───────────────────────┐
                 │ Workflow Definition   │
                 │       Version         │
                 └───────────┬───────────┘
                             │
                             ↓
                 ┌───────────────────────┐
                 │    Workflow Engine    │
                 └───────────┬───────────┘
                             │
              ┌──────────────┼──────────────┐
              ↓              ↓              ↓
           Steps        Conditions       Rules
              │              │              │
              ↓              ↓              ↓
       Handler Keys      Rule Keys       Rule Handlers
              │
              ↓
       Handler Resolver
              │
      ┌───────┼────────┐
      ↓       ↓        ↓
   Payment  Fraud   Inventory
   Handler  Handler  Handler
      │       │        │
      └───────┼────────┘
              ↓
        Domain/Application
            Services

The responsibilities are separated:

Workflow

Defines:

What, when, order, branching, version.

Handler

Defines:

How a specific capability is executed.

Domain/Application services

Define:

Actual business behavior and invariants.

Database

Stores:

Definitions, versions, instances, history, and execution state.

22. The Most Important Design Principle

If I had to summarize the entire architectural decision in one sentence:

Configuration should compose existing capabilities; code should create new capabilities.

That gives us a useful balance.

We don't need to deploy the application every time the business rearranges an existing process.

But we also don't pretend that every possible future behavior can magically be represented by configuration.

When a genuinely new capability appears, we write code.

Then that capability becomes available to future workflow versions.

23. Final Takeaway

I would still happily use a state machine in a new .NET project.

If I know the lifecycle is stable, I would probably prefer it.

It is simple, explicit, strongly typed, testable, and easy to reason about.

But if I discover that:

the sequence of steps changes frequently,
different customers need different processes,
business rules evolve independently of deployments,
old processes must remain reproducible,
steps can be conditional or parallel,
human approval is involved,
processes can run for days or weeks,

then I would stop trying to make the state machine handle everything.

At that point, I would consider a versioned configurable workflow composed of strongly typed handlers.

Not because it is more sophisticated.

Because it models the problem more accurately.

And that is perhaps the most important lesson in system design:

The best architecture is not the one with the most features. It is the one whose abstractions match the kind of change the system is expected to absorb.

Benchmarking EF Core LINQ, Dapper Raw SQL, and Stored Procedures in .NET: A Real-World Performance Comparison (2026)

Mina Golzari Dalir — Sat, 31 Jan 2026 07:12:58 +0000

Benchmarking EF Core LINQ, Dapper Raw SQL, and Stored Procedures in .NET: A Real-World Performance Comparison (2026)

Mina Golzari Dalir ・ Jan 5

#benchmark #linq #dapper #storedprocedure

Benchmarking EF Core LINQ, Dapper Raw SQL, and Stored Procedures in .NET: A Real-World Performance Comparison (2026)

Mina Golzari Dalir — Mon, 05 Jan 2026 12:40:37 +0000

In .NET development, selecting the right data access strategy is crucial for balancing performance, maintainability, and developer productivity. Entity Framework Core (EF Core) with LINQ provides a powerful full ORM experience, Dapper offers lightweight micro-ORM speed with raw SQL control, and Stored Procedures deliver database-level optimization and security.
This post explores a practical benchmark comparing these approaches on a real-world query: calculating team performance summaries (total tasks, completed tasks, and completion rate) with optional date range and team filters. The test uses a database with over 50,000 tasks, executed via BenchmarkDotNet in .NET (likely .NET 8+).

Understanding BenchmarkDotNet Results: A Quick Guide
BenchmarkDotNet produces detailed statistical reports to ensure reliable comparisons. Here's how to interpret the key columns in the results table:

Mean: The average (arithmetic mean) execution time across all iterations. Lower is better.
Error: Half of the 99.9% confidence interval—indicates the uncertainty in the Mean value.
StdDev (Standard Deviation): Measures variability in measurements. Low StdDev means consistent results.
Ratio: The performance ratio relative to the baseline (here, EF Core LINQ marked as baseline).
- 1.00 = same as baseline
- <1.00 = faster (e.g., 0.50 = 2x faster)
- 1.00 = slower (e.g., 1.34 = 34% slower)
RatioSD: Standard deviation of the ratio—shows how stable the relative performance is.
Allocated: Managed memory allocated per operation (in KB or bytes). Lower means less GC pressure.
Alloc Ratio: Memory allocation ratio relative to the baseline.

These metrics come from multiple warm-up and actual iterations, eliminating noise and providing statistically sound data.

The Technologies
EF Core with LINQ
EF Core translates LINQ queries to SQL, handling change tracking, migrations, and complex mappings.
Example from the benchmark:

var result = await (from task in tasksQuery
                    join team in _context.Teams on task.TeamId equals team.Id
                    group task by new { team.Id, team.Name } into g
                    select new TeamPerformanceSummaryResponseDto
                    {
                        TeamId = g.Key.Id,
                        TeamName = g.Key.Name,
                        TotalTasks = g.Count(),
                        CompletedTasks = g.Count(t => t.Status == "Completed" || t.CompletedAt != null),
                        CompletionRate = g.Count() > 0 ? (decimal)g.Count(t => t.Status == "Completed" || t.CompletedAt != null) * 100 / g.Count() : 0
                    }).ToListAsync();

Dapper with Raw SQL
Dapper maps raw SQL results to objects with minimal overhead and full SQL control.
Example:

var sql = @"
    SELECT t.Id AS TeamId, t.Name AS TeamName,
           COUNT(task.Id) AS TotalTasks,
           SUM(CASE WHEN task.Status = 'Completed' OR task.CompletedAt IS NOT NULL THEN 1 ELSE 0 END) AS CompletedTasks,
           CASE WHEN COUNT(task.Id) > 0 
                THEN CAST(SUM(CASE WHEN task.Status = 'Completed' OR task.CompletedAt IS NOT NULL THEN 1 ELSE 0 END) * 100.0 / COUNT(task.Id) AS DECIMAL(18,2))
                ELSE 0 END AS CompletionRate
    FROM Teams t
    INNER JOIN Tasks task ON t.Id = task.TeamId
    WHERE 1 = 1 [optional filters]
    GROUP BY t.Id, t.Name
    ORDER BY t.Id";
var result = await connection.QueryAsync<TeamPerformanceSummaryResponseDto>(sql, parameters);

Stored Procedures
Pre-compiled SQL in the database, called via Dapper here for fairness.
Example Procedure:

CREATE PROCEDURE sp_GetTeamPerformanceSummary
    @StartDate DATETIME2 = NULL,
    @EndDate DATETIME2 = NULL,
    @TeamId INT = NULL
AS
BEGIN
    SELECT t.Id AS TeamId, t.Name AS TeamName, ... [same aggregation logic]
    FROM Teams t INNER JOIN Tasks task ON t.Id = task.TeamId
    WHERE (@StartDate IS NULL OR task.CreatedAt >= @StartDate) ...
    GROUP BY t.Id, t.Name
    ORDER BY t.Id;
END

Calling with Dapper:

var result = await connection.QueryAsync<TeamPerformanceSummaryResponseDto>(
    "sp_GetTeamPerformanceSummary", parameters, commandType: CommandType.StoredProcedure);

Real Benchmark Results (50,000+ Tasks)
The benchmark ran on modern hardware (Intel Core i7-7500U equivalent) with warm-up and multiple iterations.
Results Table:

Key Insights:

EF Core LINQ is the fastest here (baseline), likely due to optimized query translation and connection management in this aggregation scenario.
Dapper Raw SQL is ~34% slower but allocates less than half the memory.
Stored Procedure is the slowest (~62% over EF) but uses the least memory (~22% of EF).
High error/stddev in Dapper/SP suggests variability—possibly from connection handling or plan caching.
Recent 2024-2025 benchmarks show EF Core closing the gap significantly, often outperforming or matching Dapper in complex queries when tuned (e.g., no tracking).

These results contrast with many older benchmarks where Dapper dominated simple reads, but for aggregations/joins with large data, EF Core's optimizations shine.

Overall Insights:

EF Core often leads or ties in speed for complex aggregations, thanks to modern optimizations in .NET 8+.
Dapper and Stored Procedures consistently use less memory.
Variability (higher Error/StdDev in some runs) points to factors like connection pooling and query plan caching.

Pros and Cons

EF Core LINQ
Pros:

High productivity with type-safe LINQ.
Excellent for complex domains and rapid development.
Strong migrations and change tracking.

Cons:

Higher memory usage.
Potential for suboptimal SQL if not careful.

Dapper Raw SQL
Pros:

Low memory footprint.
Full SQL control for tuning.
Great for read-heavy or high-throughput apps.

Cons:

More boilerplate (manual SQL, parameters).
No built-in migrations or tracking.

Stored Procedures
Pros:

Minimal client-side allocation.
Pre-compiled plans and security benefits.
Ideal for regulated or legacy environments.

Cons:

Logic in database → harder versioning/maintenance.
Less flexible for dynamic queries.
When to Choose Each (2026 Perspective)
EF Core LINQ → Default for most apps. Productivity wins, and performance is now excellent (especially .NET 8+). Use for CRUD, complex models.
Dapper → Performance hotspots, APIs with massive reads, or when you need precise SQL control. Hybrid approach common.
Stored Procedures → Security-critical ops, heavy DB logic, or when DBAs own optimizations. Call via Dapper for best results.

Recent discussions (2025) confirm: EF Core is the go-to unless extreme performance demands raw SQL.

Conclusion
No universal winner—EF Core offers the best balance for most modern .NET apps in 2026, with surprising speed in aggregations. Dapper excels in memory efficiency, and Stored Procedures in allocation/security.
Always benchmark your specific workload!

The full code (including interface, DTOs, and benchmark setup) is shared above for easy replication.
The complete benchmark project is available on GitHub:
https://github.com/Productive-Build-Cycle/Reporting/tree/perf/benchmark-query
I invite you to star the repo, fork it, run the benchmarks on your setup, add more scenarios (e.g., bulk inserts, different data sizes), or share your results! Open issues for discussions or pull requests for improvements contributions are very welcome!
_
What’s your experience? Share in the comments!
What do your benchmarks show? Comment here or on GitHub!_

dotnet #efcore #dapper #performance #benchmark.

The Evolution of Angular

Mina Golzari Dalir — Fri, 12 Dec 2025 16:12:05 +0000

The Evolution of Angular: Key Features and Benefits from Version 12 to 21

Mina Golzari Dalir ・ Dec 12

#performance #architecture #typescript #angular

The Evolution of Angular: Key Features and Benefits from Version 12 to 21

Mina Golzari Dalir — Fri, 12 Dec 2025 16:11:17 +0000

Over the past several years, Angular has undergone one of the most significant transformations in its history, shifting from a module-heavy, change-detection–driven framework into a modern, high-performance, developer-focused platform. From version 12 through version 21, Angular has introduced major architectural advancements such as standalone components, signals, the new template control flow, an ESBuild-powered build system, and advanced SSR hydration. These changes not only simplify development and reduce boilerplate but also deliver measurable improvements in rendering speed, scalability, and user experience. Whether you are maintaining an older application or preparing to adopt the latest version, understanding this evolution is essential for making informed technical decisions and maximizing Angular’s capabilities.

Below is a professional, business-friendly, technical explanation of the main Angular features across versions 12 → 16 → 18 → 21, along with what each feature does and the measurable benefits (performance, maintainability, architectural quality).

This will help you clearly understand why each Angular generation matters and how they improve both developer experience and application performance.

1. Standalone Components
A component that works without NgModule.
You no longer need app.module.ts, product.module.ts, etc.

@Component({
  selector: 'user-card',
  standalone: true,
  template: `<h3>{{ user().name }}</h3>`
})
export class UserCard {
  user = signal({ name: 'Mina' });
}

Benefit

Eliminates unnecessary boilerplate
Reduces architectural complexity
Faster onboarding for developers
Smaller codebase, fewer files
Better tree-shaking → smaller final bundle

Introduced: Angular 14
Default: Angular 18
Fully enforced: Angular 21

2. Signals (Reactive State System)
A new built-in reactivity model that tracks data changes synchronously and efficiently, similar to SolidJS or React’s state.

const counter = signal(0);

function increment() {
  counter.update(n => n + 1);
}

Benefit

Eliminates ChangeDetection complexity
Minimal re-renders → massive performance improvement
Avoids RxJS boilerplate where not needed
Makes code more predictable and easier to debug
Works perfectly with Angular’s new template system

Preview: Angular 16
Stable: Angular 18
Recommended: Angular 21

3. New Control Flow (@if, @for, @switch)
Modern template syntax replacing *ngIf and *ngFor.

@if (loading()) {
  <p>Loading…</p>
} @else {
  @for (item of items(); track item.id) {
    <div>{{ item.title }}</div>
  }
}

Benefit

Faster runtime (because Angular compiles these more efficiently)
Much cleaner templates
Better type checking
Built for signal reactivity
Supports better tracking with track keyword

Introduced: Angular 17
Fully optimized: Angular 18–21

4. ESBuild-Based Build System
Angular replaced Webpack with ESBuild for compilation and bundling.

angular.json

{
  "builder": "@angular-devkit/build-angular:browser-esbuild"
}

Benefit

Up to 10x faster builds
Instant hot reload (almost zero refresh time in dev mode)
Smaller output bundles
Less configuration headaches

Introduced: Angular 15–16
Default: Angular 18+

5. SSR Hydration + Partial Hydration
SSR = Server-Side Rendering
Hydration = Reconnecting server-rendered HTML to client-side Angular
Partial Hydration = Only hydrate the parts that require interaction

provideClientHydration()

Benefit

Faster page load + better SEO
First Contentful Paint (FCP) drastically improved
Angular feels more like Next.js or Remix
Lower memory usage on the client
Perfect for e-commerce and blogs

Early version: Angular 16
Non-destructive hydration: Angular 18
Partial hydration + advanced SSR: Angular 21

6. Deferrable Views (@defer)
Lazy-rendering of parts of a page based on conditions.

@Component({
  selector: 'analytics-widget',
  standalone: true,
  hydration: { mode: 'client' },
  template: `<dashboard-chart />`
})
export class AnalyticsWidget {}

Benefit

Reduce initial load time
Render heavy components only when user needs them
Move expensive logic out of the critical path
Very useful for large dashboards or media-heavy pages

Stable: Angular 17+

7. Required Inputs
A Component Input must be set or Angular will show an error.

@defer (on idle) {
  <chart-dashboard></chart-dashboard>
}

Benefit

Prevents undefined bugs
Stronger API contract between components
Better maintainability

Introduced: Angular 16

8. Modern Angular Material (Material 3)
Complete redesign of Angular Material based on Google’s M3 spec.

<mat-card appearance="outlined">
  <mat-card-header>
    <mat-card-title>Product Details</mat-card-title>
  </mat-card-header>
</mat-card>

Benefit

More modern UI
Better accessibility
More customizable themes
More consistent spacing, typography, and layout

Default: Angular 18–21

9. Better TypeScript Support
Each Angular version moves TS

function logMessage<T extends string>(msg: T): T {
  return msg;
}

Benefit

Better IntelliSense
Stricter type checking
Renaming, refactoring, and autocomplete improvements
Faster compilation
Support for decorators, generics, async functions

10. Web Test Runner (instead of Karma/Jasmine)
A faster, modern test runner.

import { test, expect } from '@angular/testing';

test('price should be greater than zero', () => {
  const price = 120;
  expect(price).toBeGreaterThan(0);
});

Benefit

~15x faster test runs
Better debugging
Cleaner test environment setup
Supports modern ES modules

Introduced: Angular 17
Default: Angular 18+

11. Improved Runtime Performance
Angular removed almost all heavy, legacy ChangeDetection logic.

Benefit

Faster rendering
Less CPU usage
Better battery life on mobile devices
Higher scalability (tens of thousands of DOM nodes)

Optimized: Angular 16–21

PROJECT EXAMPLE: “Product Management Module”
Features included:

List products
Add new product
Loading state
API service integration We will show how this same feature looks in Angular 12, 16, 18, and 21.

ANGULAR 12 — Legacy Architecture

Folder Structure

/src/app/
   app.module.ts
   product/
      product.module.ts
      product-list/
          product-list.component.ts
          product-list.component.html
      product-add/
          product-add.component.ts
          product-add.component.html
      product.service.ts
      product.model.ts

Module-Based Architecture

// product.module.ts
@NgModule({
  declarations: [
    ProductListComponent,
    ProductAddComponent
  ],
  imports: [CommonModule, FormsModule],
  providers: [ProductService]
})
export class ProductModule {}

Component (Angular 12 style)

export class ProductListComponent implements OnInit {
  products: Product[] = [];

  constructor(private srv: ProductService) {}

  ngOnInit() {
    this.srv.getAll().subscribe(res => this.products = res);
  }
}

Template

<div *ngFor="let p of products">
  {{ p.name }} - {{ p.price }}
</div>

ANGULAR 16 — Transition Architecture

Folder Structure

/src/app/
   product/
      product-list.component.ts
      product-add.component.ts
      product.service.ts

Standalone Component (Optional)

@Component({
  selector: 'product-list',
  standalone: true,
  imports: [CommonModule],
  templateUrl: './product-list.component.html'
})
export class ProductListComponent {
  products = signal<Product[]>([]);

  constructor(private srv: ProductService) {
    this.srv.getAll().subscribe(r => this.products.set(r));
  }
}

Template (Still using *ngFor)

<div *ngFor="let p of products()">
  {{ p.name }} - {{ p.price }}
</div>

ANGULAR 18 — Modern Angular

Folder Structure (Modular by Feature)

/src/app/
   product/
      list/
         product-list.component.ts
      add/
         product-add.component.ts
      product.service.ts

Signal-Based Component (Modern)

@Component({
  selector: 'product-list',
  standalone: true,
  template: `
    @for (p of products(); track p.id) {
      <div>
        {{ p.name }} - {{ p.price }}
      </div>
    }
  `
})
export class ProductListComponent {
  products = signal<Product[]>([]);
  loading = signal(true);

  constructor(srv: ProductService) {
    srv.getAll().subscribe(res => {
      this.products.set(res);
      this.loading.set(false);
    });
  }
}

ANGULAR 21 — Latest Architecture (Full Signal Components + Modern Control Flow)

Folder Structure (Modern Clean)

/src/app/product/
   list.component.ts
   add.component.ts
   product.service.ts

Full Signal Component

@Component({
  selector: 'product-list',
  standalone: true,
  template: `
    @if (loading()) {
      <p>Loading...</p>
    } @else {
      @for (p of products(); track p.id) {
        <div>{{ p.name }} - {{ p.price }}</div>
      }
    }
  `
})
export class ProductListComponent {
  loading = signal(true);
  products = signal<Product[]>([]);

  constructor(srv: ProductService) {
    srv.getAll().subscribe(data => {
      this.products.set(data);
      this.loading.set(false);
    });
  }
}

Docker for Developers

Mina Golzari Dalir — Wed, 26 Nov 2025 14:15:23 +0000

Mina Golzari Dalir

Nov 26 '25

Docker for Developers: From Zero to Running Your First Production-Grade Next.js App in 1 Hour

#nextjs #tutorial #devops #docker

6 min read

Docker for Developers: From Zero to Running Your First Production-Grade Next.js App in 1 Hour

Mina Golzari Dalir — Wed, 26 Nov 2025 14:03:31 +0000

Hey there! Welcome to the only Next.js + Docker guide you’ll ever need in 2025.
By the end of this single post (and ~60 minutes of your time), you will:

Ship a real Next.js 15 app in a container smaller than 90 MB
Run it exactly the same way on Mac, Windows, Linux, or even in the cloud
Make your entire team happy (no more “it works on my machine”)
Be ready to deploy to Railway, Render, Fly.io, or Kubernetes with zero changes

Let’s go – coffee ready?

What You’ll Build Today
A production-grade Next.js 15 (App Router) app that includes:

< 90 MB Docker image
Multi-stage build (no dev dependencies in production)
Non-root user + health checks
Hot reload for development
One-command workflow for the whole team
Works everywhere: local, CI, GitHub Codespaces, Gitpod

Prerequisites
Make sure you have these installed:

Node.js ≥ 18 (preferably 20 or 22) → https://nodejs.org Check with: node -v
Git → https://git-scm.com/downloads Check with: git --version
Docker Desktop (Windows/Mac) or Docker Engine (Linux) → https://www.docker.com/products/docker-desktop Check with: docker --version and docker compose version (Compose V2 is now built-in) If any of these are missing, install them first.

** Step 1: Create the Next.js App **

# 1. Create the project
npx create-next-app@latest my-nextjs-app --ts --app --eslint --tailwind --src-dir --import-alias "@/*"
# 2. Go into the folder
cd my-nextjs-app
# 3. Open it in your editor
code .    # if you use VS Code

What we just chose and why (important for Docker later):

--app→ App Router (new standard, better for Docker + Server Actions)
--src-dir → Keeps everything clean inside /src
--turbo → Uses Turbopack in dev (faster than webpack)
--import-alias "@/*" → Clean imports like @/components/Button

Test it quickly: npm run dev → http://localhost:3000
your package.json scripts should look like this

"scripts": {
  "dev": "next dev --turbo",
  "build": "next build",
  "start": "next start",
  "lint": "next lint"
}

Initialize Git + create GitHub repo + first commit
Run these commands one by one in your project folder:

# 1. Initialize git
git init

# 2. Create a nice .gitignore (Next.js already has one, but we make it perfect for Docker)

# Docker
.dockerignore
Dockerfile
docker-compose.yml

# Node
node_modules/
.env.local
EOF

# 3. First commit
git add .
git commit -m "feat: initial commit - Next.js app ready for Docker"

# 4. Create the GitHub repo (do this in your browser)
# → Go to https://github.com/new
# Name: my-nextjs-docker-app (or whatever you want)
# Keep it Public or Private — your choice
# DO NOT initialize with README (we already have one)
# Click "Create repository"

# 5. Link and push (replace YOUR_USERNAME with your GitHub username)
git remote add origin https://github.com/YOUR_USERNAME/my-nextjs-docker-app.git
git branch -M main
git push -u origin main

Step 2: The 2025 Production Dockerfile (The One Everyone Copies)
Create Dockerfile(root of project):

# Build stage -> we name this stage so we can copy from it later
FROM node:22-alpine AS builder 
# All following commands run inside /app folder
WORKDIR /app
# Copy ONLY dependency files first → Docker can cache this layer
COPY package*.json ./
#clean install (faster + reproducible, perfect for Docker)
RUN npm ci
# Now copy the rest of your code
COPY . .
# Runs next build → creates the optimized .next folder + standalone server
RUN npm run build

# Prune dev dependencies
FROM node:22-alpine AS pruner
WORKDIR /app
COPY --from=builder /app ./
RUN npm ci --omit=dev && npm cache clean --force

# Final tiny image
FROM node:22-alpine AS runtime
WORKDIR /app
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs

COPY --from=pruner --chown=nextjs:nodejs /app/node_modules ./node_modules
COPY --from=pruner --chown=nextjs:nodejs /app/package.json ./
COPY --from=pruner --chown=nextjs:nodejs /app/public ./public
COPY --from=pruner --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=pruner --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs
EXPOSE 3000

HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD wget -qO- http://localhost:3000/api/health || exit 1

CMD ["node", "server.js"]

Magic Line You Must Add (next.config.js)

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'standalone', // This makes Next.js create server.js
};

module.exports = nextConfig;

Tiny Health Check (app/api/health/route.ts)

import { NextResponse } from 'next/server';

export async function GET() {
  return NextResponse.json({ 
    status: 'ok', 
    timestamp: new Date().toISOString() 
  });
}

.dockerignore (Speeds Up Builds 5x)

node_modules
.next
.env*.local
.git
.gitignore
README.md
Dockerfile
docker-compose*.yml

Build & Run It (The Moment of Truth)

docker build -t nextjs-prod .
docker run -d -p 3000:3000 --name prod nextjs-prod

Open http://localhost:3000 → It just works.
Check image size:

docker images nextjs-prod
# → ~84 MB (vs 1 GB+ the "wrong" way)

Removing Container and Image

docker rm -f nextjs-prod 
docker rm -f nextjs-prod-app

docker rmi nextjs-prod

docker-compose.yml (new file in root)-Two services explained

services:
nextjs-dev:                     # ← Development container
    build: .                      # Use the same Dockerfile
    ports:
      - "3000:3000"               # Host port 3000 → container port 3000
    environment:
      NODE_ENV: development       # Enables hot reload
    volumes:
      - .:/app                    # Your code changes instantly appear inside container
      - /app/node_modules         # Don’t let host node_modules override container ones
      - /app/.next                # Keep build cache on host (faster restarts)
    command: npm run dev          # Override CMD from Dockerfile

  nextjs-prod:                    # ← Real production preview
    build: .
    ports:
      - "3001:3000"               # Different host port so you can run both at once
    environment:
      NODE_ENV: production
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "wget", "--no-verbose", "--tries=1", "--spider", "http://localhost:3000"]
      interval: 30s
      timeout: 10s
      retries: 3

Now run in your terminal (PowerShell or cmd):

docker compose up --build

You should see it build and start on http://localhost:3000 with hot reload.
Then open a second terminal and run:

docker compose up --build nextjs-prod
docker compose up --build nextjs-dev

if you want both at the same time in one terminal

docker compose up nextjs-dev nextjs-prod

→ http://localhost:3001 will show the real production version (super fast and tiny image ~90MB).

A common super common on Windows with WSL2 + Docker Desktop when it’s still configured to use Linux containers but somehow tries to pull a Windows image.

no matching manifest for windows/amd64 10.0.26100 in the manifest list entries

Right-click the Docker Desktop whale icon in your system tray → make sure it says “Linux containers” (not “Windows containers”).

DesktopLinuxEngine: The system cannot find the file specified.

This error means Docker Desktop’s Linux engine is not running right now (it probably stopped or crashed after the long prod build).

Look at your system tray (bottom-right near the clock)
Find the Docker whale icon
If it’s gray or has a red dot → Docker is stopped
Just double-click the whale icon → Docker Desktop will restart automatically

Rebuild and run

# Remove old broken images
docker compose down --rmi all

# Build & start dev (this time it WILL have the next binary)
docker compose up --build nextjs-dev

Stop / Start only the dev container

# Stop dev only
docker compose stop nextjs-dev

# Start dev again (instant, no rebuild)
docker compose start nextjs-dev

# Or restart dev in one command
docker compose restart nextjs-dev

Stop BOTH at once

docker compose down

When hot-reload feels weird or .next is corrupted

docker compose down -v
docker compose up nextjs-dev          # fresh .next cache

When you changed Dockerfile or node_modules

docker compose down --rmi all
docker compose up --build nextjs-dev

When your PC is crying for disk space

docker system prune -a               # frees gigabytes in 10 seconds

Start BOTH at once

docker compose up
# or in background (like a real server)
docker compose up -d

Rebuild + start only one

docker compose up --build nextjs-dev

List running containers

docker compose ps

stops + removes containers + removes YOUR volumes

docker compose down -v

Delete ALL volumes created by this docker-compose file (100% safe)

docker compose down --volumes

Volumes from other projects

docker volume ls

** See logs (super useful!)**

docker logs nextjs-dev -f          # -f = follow live

Tag an existing image with multiple tags

docker tag nextjs-docker-app-nextjs-prod username/nextjs-docker-app:latest
docker tag nextjs-docker-app-nextjs-prod username/nextjs-docker-app:v1

See all your local images + their tags

docker images

Folder Structure

my-nextjs-app/
├── .dockerignore
├── .gitignore
├── Dockerfile
├── docker-compose.yml
├── next.config.js
├── package.json
├── app/
│   └── api/health/route.ts
└── public/

Now that you have a perfect Docker setup, here are the real-world ways to share the exact same image with your team (or with CI/CD, hosting, etc.):

Step 3: Push to Docker Hub

# 1. Log in to Docker Hub (create account at `hub.docker.com` if you don't have one)
docker login

# 2. Tag your prod image with your username
docker tag nextjs-docker-app-nextjs-prod username/nextjs-docker-app:latest

# 3. Push it
docker push username/nextjs-docker-app:latest

# Then your entire team (or any server in the world) can start your exact production app in 5 seconds with:

docker run -d -p 3000:3000 username/nextjs-docker-app:latest

# Only download the image (no container starts)
docker pull username/nextjs-docker-app:latest

You just graduated from “Docker curious” to “Docker professional” in under an hour.

I’ve personally used this exact setup on every new Next.js projects.
If this guide saves even one hour of your life, drop a comment below and tell me how it went — I read every single one.

Technical SEO for Developers: A Comprehensive Guide to Building Search-Friendly Applications

Mina Golzari Dalir — Sun, 16 Nov 2025 13:40:54 +0000

Mina Golzari Dalir

Nov 16 '25

Technical SEO for Developers: A Comprehensive Guide to Building Search-Friendly Applications

#technicalseo #seo #nextjs #webdev

4 min read

Technical SEO for Developers: A Comprehensive Guide to Building Search-Friendly Applications

Mina Golzari Dalir — Sun, 16 Nov 2025 13:39:38 +0000

As developers, we often focus on writing clean code and optimizing performance, but one critical aspect that's frequently overlooked is technical SEO. In this article, using a real-world plastic injection factory example, we'll explore how you can implement SEO at the code level.

Why Technical SEO Matters
Technical SEO forms the foundation of any successful SEO strategy. Even if you create the best content in the world, without proper technical structure, search engines cannot properly index and understand it.

The Business Impact

60% of organic clicks go to the first three results
53% of website traffic comes from organic search
Proper technical SEO can increase conversion rates by 30%

Real-World Code Analysis: Plastic Injection Factory Example
Let's break down the provided metadata code and extract valuable SEO lessons:

export const metadata: Metadata = {
  // Strategic title tag
  title: "Products & Services | Plastic Injection Factory",
  description: "Comprehensive plastic injection services • Precision mold making • Plastic parts manufacturing for automotive, medical, electronics, and consumer goods industries • Guaranteed quality",

  // Targeted keywords (though less important for Google, still valuable)
  keywords: "plastic injection products, mold services, automotive plastic parts, medical plastic components, electronic parts manufacturing, industrial mold making, Hamedan plastic injection",

  // Authority and ownership signals
  authors: [{ name: "Plastic Injection Factory" }],
  creator: "Plastic Injection Factory",
  publisher: "Plastic Injection Factory",

  // Crawler instructions
  robots: "index, follow, max-image-preview:large",

  // URL management
  metadataBase: new URL('https://hamedan-plastic-injection.ir'),
  alternates: {
    canonical: 'https://hamedan-plastic-injection.ir/products',
  },

  // Social media optimization
  openGraph: {
    title: "Products & Services | Plastic Injection Factory",
    description: "Comprehensive plastic injection services • Precision mold making • Custom plastic parts for various industries",
    images: [
      {
        url: '/og-products.jpg',
        width: 1200,
        height: 630,
        alt: 'Products and Services - Plastic Injection Factory',
      },
    ],
    locale: 'fa_IR', // Crucial for local SEO
    type: 'website',
  },

  // Twitter-specific optimization
  twitter: {
    card: 'summary_large_image',
    title: "Products & Services | Plastic Injection Factory",
    description: "Comprehensive plastic injection services • Precision mold making • Custom plastic parts",
    images: ['/og-products.jpg'],
  },
};

Common Developer SEO Mistakes to Avoid

Ignoring URL Structure

// ❌ Poor SEO practice
/products?id=123&category=plastic

// ✅ SEO-friendly approach
/products/plastic-injection-molds

// ✅ Even better with hierarchy
/services/plastic-injection/automotive-parts

2. Forgetting Canonical Tags

// Always set canonical URLs to prevent duplicate content
alternates: {
  canonical: 'https://example.com/correct-url',
},

3. Neglecting Image Optimization

images: [
  {
    url: '/og-image.jpg',
    width: 1200,    // Specify dimensions
    height: 630,    // Specify dimensions
    alt: 'Meaningful image description', // Descriptive alt text
  },
],

4. Overlooking International SEO

// For multilingual sites
alternates: {
  languages: {
    'en': 'https://example.com/en/products',
    'fa': 'https://example.com/fa/products',
    'de': 'https://example.com/de/products',
  }
}

SEO-Friendly Coding Best Practices

1. Semantic HTML Implementation

// ❌ Poor semantics
<div onClick={handleClick}>Products</div>

// ✅ SEO-friendly
<button onClick={handleClick} aria-label="Browse our products">
  Products
</button>

// ✅ Even better with proper heading structure
<section>
  <h2>Our Manufacturing Services</h2>
  <button onClick={handleClick}>Explore Products</button>
</section>

2. Structured Data Implementation

// JSON-LD for rich snippets
const productSchema = {
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Plastic Injection Mold",
  "description": "High-precision plastic injection mold for automotive industry",
  "brand": {
    "@type": "Brand",
    "name": "Plastic Injection"
  },
  "offers": {
    "@type": "Offer",
    "availability": "https://schema.org/InStock",
    "priceCurrency": "USD",
    "price": "2500"
  }
};

3. Performance Optimization for SEO

// Next.js example with ISR for better SEO
export const dynamic = 'auto';
export const dynamicParams = true;
export const revalidate = 3600; // Incremental Static Regeneration

// Image optimization
import Image from 'next/image';

<Image
  src="/manufacturing-process.jpg"
  alt="Plastic injection manufacturing process"
  width={800}
  height={600}
  priority={true} // For above-the-fold images
/>

International SEO Considerations

Local SEO Implementation

openGraph: {
  locale: 'en_US', // Important for geographic targeting
  siteName: 'Plastic Injection Factory',
  // ...
},

// For multi-regional targeting
metadataBase: new URL('https://hamedan-plastic-injection.ir'),
alternates: {
  canonical: 'https://hamedan-plastic-injection.ir/en/products',
  languages: {
    'en': 'https://hamedan-plastic-injection.ir/en/products',
    'fa': 'https://hamedan-plastic-injection.ir/fa/products',
  }
}

Essential SEO Tools for Developers
1. Validation Tools

Google Rich Results Test - Structured data validation
Schema Markup Validator - Schema.org testing
Lighthouse SEO Audit - Comprehensive SEO auditing
Google Search Console - Performance monitoring

2. Development & Monitoring

Screaming Frog SEO Spider - Technical SEO auditing
Ahrefs Site Audit - Comprehensive SEO analysis
PageSpeed Insights - Performance monitoring

Key Metrics to Track

// SEO metrics monitoring structure
const seoMetrics = {
  coreWebVitals: {
    lcp: '2.5s',    // Largest Contentful Paint (target: <2.5s)
    fid: '100ms',   // First Input Delay (target: <100ms)
    cls: '0.1',     // Cumulative Layout Shift (target: <0.1)
  },
  crawlability: {
    indexedPages: 150,
    crawlErrors: 0,
    robotsTxt: 'valid',
    sitemapStatus: 'healthy',
  },
  performance: {
    pageSpeed: 85,
    timeToInteractive: '3.2s',
    firstContentfulPaint: '1.8s',
  },
  businessMetrics: {
    organicTraffic: '45%',
    conversionRate: '3.2%',
    bounceRate: '42%',
  }
};

Actionable Checklist for Development Teams

Pre-Launch SEO Checklist

Semantic HTML structure implemented
All images have descriptive alt text
XML sitemap generated and submitted
robots.txt properly configured
Canonical tags set for all pages
Structured data implemented
Page speed optimized (LCP < 2.5s)
Mobile-responsive design tested
SSL certificate installed
404 pages customized

Ongoing SEO Maintenance

Regular performance monitoring
Broken link checks
Schema markup validation
Core Web Vitals tracking
Search Console error monitoring

Advanced Technical SEO Techniques

1. Dynamic Rendering for JavaScript-Heavy Apps

// For SPAs that need SEO support
// Use server-side rendering or dynamic rendering
export async function getServerSideProps(context) {
  // Fetch data for SEO
  const productData = await fetchProductData(context.params.id);

  return {
    props: {
      product: productData,
      seo: {
        title: productData.seoTitle,
        description: productData.seoDescription,
        canonical: `https://example.com/products/${productData.slug}`
      }
    }
  };
}

2. API Route for Dynamic Sitemaps

// pages/api/sitemap.xml.js
export default function handler(req, res) {
  const sitemap = generateSitemap();
  res.setHeader('Content-Type', 'text/xml');
  res.write(sitemap);
  res.end();
}

Pro Tips for Development Teams

SEO-First Development - Integrate SEO requirements from sprint planning
Collaborate with Content Teams - Align on keywords and URL structures
Performance as Priority - Fast sites rank better and convert better
Mobile-First Mindset - Over 60% of searches happen on mobile
Structured Data Foundation - Implement schema.org from the beginning
International from Day One - Plan for global expansion from the start

Conclusion
Technical SEO is a long-term investment that should be at the core of your development process. By implementing these practices, you'll not only achieve better search rankings but also provide a superior user experience.

The Ultimate Guide to Becoming a Full-Stack Developer

Mina Golzari Dalir — Sat, 15 Nov 2025 11:32:49 +0000

Full-stack development is a dynamic career that combines backend logic, data persistence, frontend design, and user experience. By mastering ASP.NET Core for robust APIs, Entity Framework Core (EF Core) for seamless data access, ReactJS for dynamic interfaces, SQL for database optimization, and Figma for prototyping, you can build end-to-end solutions that power modern applications. This guide covers the responsibilities, project structure, roadmap, professional tips, and challenges of becoming a full-stack developer, equipping you to excel in this high-demand field.

What Does a Full-Stack Developer Do?
A full-stack developer delivers complete applications by working across the tech stack. Here’s a breakdown of responsibilities:

Backend (ASP.NET Core): Build scalable RESTful APIs to handle business logic, authentication, and data processing. For example, creating endpoints for a task management system to manage tasks.
Data Access (EF Core): Use EF Core to interact with databases, mapping objects to relational data and optimizing queries for performance.
Database (SQL): Design schemas and write efficient SQL queries for data retrieval and analytics, ensuring scalability with indexing and partitioning.
** Frontend (ReactJS)**: Develop responsive, interactive UIs using ReactJS and tools like Next.js, leveraging state management and React 18 features for performance.
UI/UX (Figma): Prototype interfaces and collaborate with stakeholders to align designs with user needs.

Impact on Projects: Full-stack developers drive measurable outcomes. In a task management app, you might reduce API latency by 20% with ASP.NET Core, cut query times by 30% with EF Core optimizations, improve UI load times by 15% with React, and boost user satisfaction by 10% through Figma-driven design iterations.

Structuring a Full-Stack Project
A well-organized project ensures scalability, maintainability, and team collaboration. Below is a recommended structure for a task management app, emphasizing EF Core for data access.

1. Backend Structure (ASP.NET Core + EF Core)
Adopt **clean architecture **to separate concerns:

TaskManagementApp/
├── src/
│   ├── Core/                  # Entities, Interfaces
│   ├── Infrastructure/        # EF Core DbContext, Repositories
│   ├── Application/           # Business logic, Services, DTOs
│   ├── Api/                   # Controllers, Middleware
├── tests/                     # Unit and integration tests
├── TaskManagement.Frontend/   # ReactJS/Next.js frontend

Core Layer (Entities)
Define the Task entity for the task management system.

// Core/Entities/Task.cs
namespace TaskManagement.Core.Entities
{
    public class Task
    {
        public int Id { get; set; }
        public string Title { get; set; } = string.Empty;
        public string? Description { get; set; }
        public bool IsCompleted { get; set; }
        public DateTime CreatedAt { get; set; } = DateTime.UtcNow;
    }
}

Infrastructure Layer (EF Core)
Configure EF Core for SQL Server and define the DbContext.

// Infrastructure/Data/TaskDbContext.cs
using Microsoft.EntityFrameworkCore;
using TaskManagement.Core.Entities;

namespace TaskManagement.Infrastructure.Data
{
    public class TaskDbContext : DbContext
    {
        public TaskDbContext(DbContextOptions<TaskDbContext> options) : base(options) { }
        public DbSet<Task> Tasks { get; set; }

        protected override void OnModelCreating(ModelBuilder modelBuilder)
        {
            modelBuilder.Entity<Task>()
                .Property(t => t.Title)
                .IsRequired()
                .HasMaxLength(100);
        }
    }
}

Create a repository for data access to keep the code clean.

// Infrastructure/Repositories/TaskRepository.cs
using TaskManagement.Core.Entities;
using TaskManagement.Infrastructure.Data;
using TaskManagement.Application.Interfaces;

namespace TaskManagement.Infrastructure.Repositories
{
    public class TaskRepository : ITaskRepository
    {
        private readonly TaskDbContext _context;

        public TaskRepository(TaskDbContext context)
        {
            _context = context;
        }

        public async Task<List<Task>> GetAllAsync()
        {
            return await _context.Tasks.ToListAsync();
        }

        public async Task<Task?> GetByIdAsync(int id)
        {
            return await _context.Tasks.FindAsync(id);
        }

        public async Task AddAsync(Task task)
        {
            await _context.Tasks.AddAsync(task);
            await _context.SaveChangesAsync();
        }
    }
}

Application Layer (Services, DTOs)
Define a service to handle business logic and a DTO for API responses.

// Application/Interfaces/ITaskService.cs
using TaskManagement.Core.Entities;

namespace TaskManagement.Application.Interfaces
{
    public interface ITaskService
    {
        Task<List<Task>> GetAllTasksAsync();
        Task<Task?> GetTaskByIdAsync(int id);
        Task CreateTaskAsync(Task task);
    }
}

// Application/DTOs/TaskDto.cs
namespace TaskManagement.Application.DTOs
{
    public class TaskDto
    {
        public int Id { get; set; }
        public string Title { get; set; } = string.Empty;
        public string? Description { get; set; }
        public bool IsCompleted { get; set; }
    }
}

// Application/Services/TaskService.cs
using TaskManagement.Core.Entities;
using TaskManagement.Application.Interfaces;
using TaskManagement.Application.DTOs;

namespace TaskManagement.Application.Services
{
    public class TaskService : ITaskService
    {
        private readonly ITaskRepository _repository;

        public TaskService(ITaskRepository repository)
        {
            _repository = repository;
        }

        public async Task<List<Task>> GetAllTasksAsync()
        {
            return await _repository.GetAllAsync();
        }

        public async Task<Task?> GetTaskByIdAsync(int id)
        {
            return await _repository.GetByIdAsync(id);
        }

        public async Task CreateTaskAsync(Task task)
        {
            if (string.IsNullOrEmpty(task.Title))
                throw new ArgumentException("Title is required.");
            await _repository.AddAsync(task);
        }
    }
}

API Layer (Controller)
Expose REST endpoints using ASP.NET Core.

// Api/Controllers/TasksController.cs
using Microsoft.AspNetCore.Mvc;
using TaskManagement.Application.Interfaces;
using TaskManagement.Application.DTOs;
using TaskManagement.Core.Entities;

namespace TaskManagement.Api.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class TasksController : ControllerBase
    {
        private readonly ITaskService _taskService;

        public TasksController(ITaskService taskService)
        {
            _taskService = taskService;
        }

        [HttpGet]
        public async Task<ActionResult<IEnumerable<Task>>> GetTasks()
        {
            return Ok(await _taskService.GetAllTasksAsync());
        }

        [HttpGet("{id}")]
        public async Task<ActionResult<Task>> GetTask(int id)
        {
            var task = await _taskService.GetTaskByIdAsync(id);
            if (task == null) return NotFound();
            return Ok(task);
        }

        [HttpPost]
        public async Task<ActionResult> CreateTask(TaskDto taskDto)
        {
            var task = new Task { Title = taskDto.Title, Description = taskDto.Description, IsCompleted = taskDto.IsCompleted };
            await _taskService.CreateTaskAsync(task);
            return CreatedAtAction(nameof(GetTask), new { id = task.Id }, task);
        }
    }
}

Program.cs (Dependency Injection and EF Core Setup)

// Api/Program.cs
using Microsoft.EntityFrameworkCore;
using TaskManagement.Infrastructure.Data;
using TaskManagement.Infrastructure.Repositories;
using TaskManagement.Application.Interfaces;
using TaskManagement.Application.Services;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddDbContext<TaskDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));
builder.Services.AddScoped<ITaskRepository, TaskRepository>();
builder.Services.AddScoped<ITaskService, TaskService>();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();

app.Run();

Add to appsettings.json:

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=localhost;Database=TaskDb;Trusted_Connection=True;TrustServerCertificate=True;"
  }
}

Run migrations:

dotnet ef migrations add InitialCreate
dotnet ef database update

2. Database (SQL Server)
Design a simple schema with indexing for performance:

CREATE TABLE Tasks (
    Id INT PRIMARY KEY IDENTITY(1,1),
    Title NVARCHAR(100) NOT NULL,
    Description NVARCHAR(MAX),
    IsCompleted BIT NOT NULL DEFAULT 0,
    CreatedAt DATETIME2 NOT NULL
);
CREATE INDEX idx_tasks_id ON Tasks(Id);

3. Frontend Structure (ReactJS/Next.js)


TaskManagement.Frontend/
├── components/    # Reusable components (e.g., TaskCard)
├── pages/         # Next.js pages (e.g., /dashboard)
├── hooks/         # Custom hooks
├── styles/        # Tailwind CSS
├── lib/           # API calls

Sample Component:

// components/TaskCard.jsx
import { useState } from 'react';

const TaskCard = ({ task, onUpdate }) => {
  const [isCompleted, setIsCompleted] = useState(task.isCompleted);

  const handleToggle = async () => {
    await fetch(`/api/tasks/${task.id}`, {
      method: 'PUT',
      body: JSON.stringify({ ...task, isCompleted: !isCompleted }),
      headers: { 'Content-Type': 'application/json' },
    });
    setIsCompleted(!isCompleted);
    onUpdate();
  };

  return (
    <div className="p-4 border rounded shadow">
      <h3>{task.title}</h3>
      <p>{task.description}</p>
      <input type="checkbox" checked={isCompleted} onChange={handleToggle} />
    </div>
  );
};

export default TaskCard;

4. Figma Workflow

Wireframes: Create low-fidelity layouts for task lists and dashboards.
** Prototypes**: Build high-fidelity, interactive designs for stakeholder feedback.
Design System: Define reusable components (e.g., buttons, cards) for UI consistency.

This structure ensures modularity. For example, adding a “Task Categories” feature requires minimal changes due to the decoupled layers.

Roadmap to Becoming a Full-Stack Developer
Follow this 12–18 month roadmap to master the stack:
Months 1–3: Foundations

Learn C# and ASP.NET Core: Study MVC, REST APIs, and dependency injection (Microsoft Learn).
Master EF Core: Learn migrations, LINQ queries, and repository patterns (EF Core docs).
** Understand SQL**: Practice schema design, joins, and indexing (SQLShack tutorials).
Learn ReactJS: Focus on components, hooks, and state management (React.dev).
Explore Figma: Create basic wireframes and learn design principles (Figma Community tutorials).
Project: Build a simple CRUD app (e.g., to-do list) with ASP.NET Core, EF Core, and React.

Months 4–8: Intermediate Skills

ASP.NET Core: Build microservices-ready APIs with clean architecture.
EF Core: Optimize queries with indexing and eager/lazy loading.
SQL: Write complex queries (e.g., window functions) and design data warehouses.
ReactJS: Learn Next.js for SSR and Zustand for state management.
Figma: Create interactive prototypes and collaborate with teams.
Project: Develop a task management app with real-time updates (e.g., SignalR) and deploy to Azure.

Months 9–12: Advanced Skills

ASP.NET Core + EF Core: Implement authentication (JWT) and containerize with Docker.
SQL: Optimize for big data with partitioning and sharding.
ReactJS: Use React 18’s Concurrent Rendering and Server Components.
Figma: Build a design system for scalable UI development.
Project: Create a production-ready app with CI/CD pipelines and share on GitHub.

Months 13–18: Specialization and Leadership

Contribute to open-source: Add features to ASP.NET Core or React projects.
** Write tutorials**: Publish on Medium to establish thought leadership.
Lead projects: Mentor juniors and drive end-to-end delivery.
Portfolio: Showcase 3–5 projects with measurable impact (e.g., “Reduced API latency by 20%”).

Professional Tips

Write Clean Code: Follow SOLID principles and use tools like SonarQube for code quality.
Optimize Performance: Use EF Core’s query profiling and React’s useMemo to boost efficiency.
Leverage Cloud Tools: Deploy to Azure or AWS for scalability. Use Azure DevOps for CI/CD.
Document Everything: Maintain clear API docs (Swagger) and Figma handoff notes.
Engage with Communities: Share projects on X, Reddit (r/dotnet, r/reactjs), and Dev.to to gain visibility.
Test Rigorously: Write unit tests for ASP.NET Core services and React components using xUnit and Jest.

Challenges and Solutions
Challenge: Managing EF Core performance with large datasets.
Solution: Use indexing, eager loading, and query splitting. Profile queries with EF Core’s logging

Challenge: Coordinating backend and frontend state in React.
Solution: Use Zustand or Redux Toolkit for predictable state management.

Challenge: Aligning Figma designs with coded UIs.
Solution: Use Figma’s Dev Mode and CSS frameworks like Tailwind for consistency.

Challenge: Balancing multiple roles in tight deadlines.
Solution: Prioritize tasks with Agile methodologies and automate repetitive tasks (e.g., CI/CD).

Challenge: Keeping up with tech updates (e.g., ASP.NET Core 8.0, React 18).
Solution: Follow blogs (e.g., Microsoft Learn, React.dev) and experiment with new features in side projects.

Essential and Helpful Soft Skills
Essential Soft Skills:

Communication: Explain technical concepts to non-technical stakeholders, e.g., presenting Figma prototypes in sprint reviews.
Problem-Solving: Debug EF Core query issues or React rendering bugs efficiently.
Adaptability: Switch between backend, frontend, and design tasks seamlessly.

Helpful Soft Skills:
Empathy: Understand user needs to design intuitive UIs in Figma.
Time Management: Balance coding, designing, and testing under tight deadlines.
Leadership: Guide teams through code reviews and mentor juniors.

These skills enhance teamwork. For example, clear communication ensures alignment on project goals, while empathy improves UI usability, leading to better user feedback.

Conclusion

Becoming a full-stack developer with ASP.NET Core, EF Core, ReactJS, SQL, and Figma is a journey of technical mastery and collaboration. By following the roadmap, structuring projects effectively, and honing soft skills, you can build impactful applications — like a task management app that boosts team productivity. Start small, iterate often, and share your work on platforms like Medium or X to inspire others. The future of full-stack development is yours to shape — get coding!

[Boost]

Mina Golzari Dalir — Thu, 13 Nov 2025 10:05:36 +0000

Build a Modern Contact Us Page with Next.js + Tailwind CSS (Component-Based + SEO-Ready)

Mina Golzari Dalir ・ Nov 8

#tailwindcss #component #seo #webdev

A well-structured contact page is a must-have for any website. In this tutorial we’ll:

Mina Golzari Dalir — Sat, 08 Nov 2025 13:29:30 +0000

Build a Modern Contact Us Page with Next.js + Tailwind CSS (Component-Based + SEO-Ready)

Mina Golzari Dalir ・ Nov 8

#tailwindcss #component #seo #webdev