Forem: Jairo Blanco

.NET 10 and the Next Leap in Native AOT for Cloud-Native Apps

Jairo Blanco — Wed, 15 Apr 2026 09:27:14 +0000

Introduction

The evolution of .NET over the past few years has been strongly aligned with modern infrastructure demands: containers, microservices, serverless execution, and edge computing. With .NET 10, Microsoft continues this trajectory by significantly advancing Native AOT (Ahead-of-Time compilation), transforming it from a niche optimization into a practical and strategic approach for production systems.

This article takes a deeper look at what makes Native AOT in .NET 10 particularly compelling, what problems it solves, and how it impacts architectural decisions in real-world applications.

Understanding Native AOT in Context

Traditionally, .NET applications rely on the Just-In-Time (JIT) compiler, which compiles Intermediate Language (IL) into machine code at runtime. While flexible, JIT introduces startup overhead and requires a runtime environment.

Native AOT changes this model entirely by compiling applications directly into platform-specific machine code at build time.

Why this matters:

Applications start almost instantly because there is no runtime compilation step
Memory usage is significantly reduced since the runtime is minimized
Deployment becomes simpler with self-contained executables
Security improves due to a reduced attack surface

Key Enhancements in .NET 10

1. Real-World Compatibility Improvements

Earlier iterations of Native AOT often struggled with real-world applications due to heavy reliance on reflection and dynamic behaviors.

.NET 10 addresses this by:

Expanding trimming support across the base class libraries
Introducing better static analysis tools to detect incompatibilities
Reducing reliance on runtime code generation in core frameworks

This means significantly fewer code changes are required to adopt AOT in existing systems.

2. ASP.NET Core Becomes AOT-Friendly

One of the most important milestones in .NET 10 is the maturity of ASP.NET Core under AOT constraints.

Key improvements include:

Better support for Minimal APIs, which align naturally with AOT principles
Optimized routing and request pipelines
More efficient JSON serialization with source generators

This opens the door for running high-performance APIs with extremely low startup latency.

3. Startup Performance and Scalability

Cold start performance has become a critical metric in modern distributed systems.

With Native AOT in .NET 10:

Startup times can drop by up to 80–90%
Applications can handle burst traffic more efficiently
Horizontal scaling becomes faster and more cost-effective

This is especially impactful in:

Kubernetes environments
Serverless platforms
Auto-scaling microservice architectures

4. Reduced Container Footprint

Container efficiency is a major concern in cloud-native systems.

Native AOT contributes by:

Eliminating the need for a full runtime image
Producing smaller binaries
Reducing overall container size by 30–60%

The downstream effects include:

Faster CI/CD pipelines
Reduced network transfer times
Lower storage and compute costs

5. Tooling and Developer Experience

Adopting Native AOT is significantly easier in .NET 10.

Developers benefit from:

Improved compiler warnings and diagnostics
Clear guidance on unsupported patterns
Streamlined publishing commands

Example:

dotnet publish -c Release -r linux-x64 /p:PublishAot=true

The ecosystem is also evolving to support AOT-friendly patterns, such as source generators and compile-time configuration.

Architectural Implications

Native AOT is not just a performance feature—it influences how applications are designed.

Shift Toward Compile-Time Behavior

Developers are encouraged to:

Replace reflection with source generation
Avoid runtime type discovery
Define explicit dependency graphs

Preference for Simplicity

Framework features that rely on dynamic behavior become less attractive. Instead:

Minimal APIs are favored over MVC
Lightweight libraries are preferred
Predictable execution paths are prioritized

When to Use Native AOT

Strong Candidates

Microservices with strict latency requirements
Serverless workloads
CLI tools and automation scripts
Edge and IoT deployments

Situations to Avoid

Applications relying heavily on reflection
Plugin-based or dynamically extensible systems
Large monoliths with runtime composition

Strategic Impact

Organizations adopting Native AOT in .NET 10 can expect:

Faster application startup and response times
Improved infrastructure efficiency
Lower operational costs
Better alignment with cloud-native principles

In highly competitive environments, these improvements are not just technical—they translate directly into business value.

Conclusion

.NET 10 represents a turning point where Native AOT becomes a practical and strategic choice rather than an experimental feature.

For teams building modern, distributed systems, the question is no longer whether AOT is viable—but where it provides the most leverage.

Adopting it thoughtfully can unlock significant gains in performance, scalability, and operational efficiency.

TL;DR

Native AOT in .NET 10 is mature and production-ready
It drastically improves startup time and memory usage
Ideal for cloud-native and distributed systems
Requires more compile-time discipline and less runtime dynamism

As the ecosystem continues to evolve, Native AOT is set to become a foundational pillar of high-performance .NET applications.

The illusion of Entity Framework

Jairo Blanco — Fri, 10 Apr 2026 07:26:04 +0000

Entity Framework (EF) is, by most reasonable standards, an excellent
tool. It reduces boilerplate, accelerates development, and allows
developers to operate at a higher level of abstraction. LINQ queries
feel expressive, composable, and safe. The friction of interacting with
relational databases is significantly reduced.

That is precisely the problem.

EF is so effective at hiding the database that many developers begin to
forget that one still exists.

The Illusion of "Just Objects"

At its core, EF promotes a mental model where the database is treated as
an object graph. Developers write queries in C#, compose them fluently,
and rely on EF to translate them into SQL.

var users = context.Users
    .Where(u => u.IsActive)
    .OrderBy(u => u.CreatedAt)
    .ToList();

This looks harmless---and often it is. But the abstraction creates a
dangerous illusion: that this is merely in-memory filtering and sorting.
In reality, EF is generating SQL, executing it against a database
engine, and incurring all the costs associated with that process.

When developers stop thinking in terms of execution plans, indexes, and
I/O, performance becomes an afterthought.

Deferred Execution: A Double-Edged Sword

LINQ's deferred execution is elegant but frequently misunderstood.
Queries are not executed when they are written, but when they are
enumerated.

This leads to subtle performance pitfalls:

Multiple enumerations causing repeated database calls
Complex query chains generating inefficient SQL
Accidental N+1 query patterns

The code reads cleanly, but the runtime behavior can be highly
inefficient.

The N+1 Query Problem

One of the most common anti-patterns in EF usage is the N+1 query
problem. Consider:

var orders = context.Orders.ToList();

foreach (var order in orders)
{
    var items = order.Items; // Potential lazy load
}

This can result in one query to fetch orders, followed by N additional
queries---one per order---to fetch related items.

The developer sees a simple loop. The database sees a storm of queries.

Over-Fetching and Under-Fetching

EF makes it easy to retrieve entire entities, even when only a subset of
fields is needed. This leads to over-fetching:

var users = context.Users.ToList(); // Fetches all columns

Conversely, poor use of projections or navigation properties can lead to
under-fetching, triggering additional queries later.

Both scenarios degrade performance, yet neither is obvious from the code
alone.

The Cost of Ignoring SQL

A recurring pattern among EF-heavy teams is the gradual erosion of SQL
literacy. Developers become less comfortable reading execution plans,
analyzing joins, or reasoning about indexes.

This is not a failure of EF---it is a side effect of its success.

When the abstraction works 95% of the time, the remaining 5% becomes
disproportionately difficult to diagnose. Performance issues surface
late, often under production load, and require a sudden shift back into
database-centric thinking.

EF Is Not the Problem

It is important to be precise here: EF is not inherently problematic. In
fact, it provides mechanisms to address nearly all of the issues
discussed:

Eager loading with Include
Projection with Select
Compiled queries
Raw SQL execution when necessary

The issue is not capability---it is awareness.

Reintroducing Intentionality

To use EF effectively, developers must maintain a dual mental model:

The object-oriented view (entities, navigation properties)
The relational view (tables, joins, indexes)

Every LINQ query should implicitly prompt the question: What SQL will
this generate?

Practical steps include:

Logging generated SQL during development
Reviewing query execution plans for critical paths
Benchmarking queries with realistic data volumes
Avoiding blind reliance on lazy loading

Conclusion

Entity Framework is a powerful abstraction layer, but like all
abstractions, it trades visibility for convenience. When used without
discipline, it encourages developers to forget that they are interacting
with a database system governed by very real performance constraints.

The goal is not to abandon EF, but to use it consciously.

Because no matter how elegant your LINQ is, the database still executes
SQL.

REPR vs MVC: A Pragmatic Comparison

Jairo Blanco — Fri, 10 Apr 2026 07:18:55 +0000

Introduction

When building web applications in .NET, most developers default to MVC (Model-View-Controller). It’s familiar, well-documented, and deeply integrated into ASP.NET Core.

However, modern API design has shifted toward feature-oriented architectures, where REPR (Request-Endpoint-Response) is gaining traction—especially with libraries like FastEndpoints.

This article provides a deeper, production-oriented comparison, including architectural implications, scalability, testing, and alignment with patterns like CQRS.

What is MVC?

MVC separates concerns into three components:

Model → Domain/data + business logic
View → UI rendering (Razor, HTML, etc.)
Controller → Handles HTTP requests and orchestrates responses

Example

[ApiController]
[Route("api/[controller]")]
public class UsersController : ControllerBase
{
    private readonly IUserService _service;

    public UsersController(IUserService service)
    {
        _service = service;
    }

    [HttpGet("{id}")]
    public IActionResult GetUser(int id)
    {
        var user = _service.GetUserById(id);

        if (user is null)
            return NotFound();

        return Ok(user);
    }

    [HttpPost]
    public IActionResult CreateUser(CreateUserDto dto)
    {
        var user = _service.Create(dto);
        return CreatedAtAction(nameof(GetUser), new { id = user.Id }, user);
    }
}

Observations

Multiple endpoints per controller
Shared dependencies across actions
Implicit grouping by resource (UsersController)
Controllers tend to grow over time (controller bloat)

What is REPR?

REPR stands for:

Request → Input DTO
Endpoint → Single use-case handler
Response → Output DTO

Each HTTP endpoint is implemented as a self-contained unit, typically one class per use-case.

This aligns closely with:

Vertical Slice Architecture
CQRS (Command Query Responsibility Segregation)

REPR with FastEndpoints

FastEndpoints is a .NET library that implements REPR cleanly with minimal boilerplate.

Example

public class GetUserRequest
{
    public int Id { get; set; }
}

public class GetUserResponse
{
    public int Id { get; set; }
    public string Name { get; set; }
}

public class GetUserEndpoint : Endpoint<GetUserRequest, GetUserResponse>
{
    private readonly IUserService _service;

    public GetUserEndpoint(IUserService service)
    {
        _service = service;
    }

    public override void Configure()
    {
        Get("/api/users/{id}");
        AllowAnonymous();
    }

    public override async Task HandleAsync(GetUserRequest req, CancellationToken ct)
    {
        var user = await _service.GetUserByIdAsync(req.Id);

        if (user is null)
        {
            await SendNotFoundAsync(ct);
            return;
        }

        await SendAsync(new GetUserResponse
        {
            Id = user.Id,
            Name = user.Name
        }, cancellation: ct);
    }
}

Architectural Comparison

1. Organization

Concern	MVC	REPR
Structure	Horizontal (controllers)	Vertical (features)
Grouping	By resource	By use-case
Files	Fewer, larger	More, smaller

Key Insight:

REPR follows "screaming architecture" — your folder structure reflects business capabilities.

2. Coupling & Cohesion

MVC
- High intra-controller coupling
- Shared dependencies across unrelated actions
- Risk of unintended side effects
REPR
- High cohesion per endpoint
- Minimal coupling
- Dependencies are scoped per use-case

3. Scalability (Codebase, not infra)

MVC
- Controllers grow (10–20+ actions common)
- Navigation becomes harder
- Merge conflicts increase in teams
REPR
- Linear scalability (add new files, not modify existing ones)
- Safer parallel development
- Better suited for large teams

4. Testing

MVC

Requires controller setup
Often involves mocking multiple dependencies
Harder to isolate logic

REPR

Endpoint = unit of test
Minimal mocking
Highly deterministic

// Example test idea (pseudo)
var endpoint = new GetUserEndpoint(fakeService);
await endpoint.HandleAsync(request, ct);

5. Alignment with CQRS

Pattern	MVC	REPR
Commands & Queries	Mixed in controllers	Naturally separated
Read/Write models	Often shared	Easily separated
Mental model	Resource-centric	Use-case-centric

REPR maps almost 1:1 with CQRS.

6. Performance Considerations

FastEndpoints removes some MVC overhead:

No controller discovery pipeline
Less reflection-heavy execution
Leaner middleware interaction

While differences are often negligible, REPR frameworks can offer slightly better throughput and lower allocations.

FastEndpoints: Key Features

Strongly typed request/response models
Built-in validation pipeline
Pre/post processors (middleware-like)
Fluent configuration
Minimal boilerplate
Endpoint-level dependency injection

Example: Validation

public class CreateUserValidator : Validator<CreateUserRequest>
{
    public CreateUserValidator()
    {
        RuleFor(x => x.Name).NotEmpty();
    }
}

When to Use MVC

Use MVC if:

You are building server-rendered apps (Razor Views)
Your team is heavily invested in MVC
You are maintaining legacy systems
You prefer convention over explicit structure

When to Use REPR (FastEndpoints)

Use REPR if:

You are building APIs or microservices
You want feature-based organization
You value low coupling and high cohesion
You are adopting CQRS or Vertical Slice Architecture
You want better team scalability

Trade-offs

MVC Drawbacks

Controller bloat
Harder long-term maintainability
Implicit coupling between endpoints

REPR Drawbacks

Higher file count
Initial learning curve
Less "standard" in enterprise environments (for now)

Folder Structure Comparison

MVC

Controllers/
  UsersController.cs
Services/
Models/

REPR

Features/
  Users/
    GetUser/
      Endpoint.cs
      Request.cs
      Response.cs
    CreateUser/
      Endpoint.cs
      Validator.cs

Final Thoughts

MVC is a proven and stable architectural pattern, but it shows its age in large, API-heavy systems.

REPR—especially with FastEndpoints—offers:

Better scalability
Clearer separation of concerns
Strong alignment with modern architectural patterns

If you're building a new .NET API in 2026, REPR is not just an alternative—it’s often the more maintainable default.

Vertical Slice Architecture: A Balanced Evaluation

Jairo Blanco — Tue, 07 Apr 2026 08:17:50 +0000

Introduction

Vertical Slice Architecture (VSA) is a feature-oriented architectural style that structures applications around use cases rather than technical layers. It is particularly popular in modern .NET development, often combined with tools like MediatR and minimal APIs.

This article provides an objective assessment of VSA, outlining both its strengths and its trade-offs so you can make an informed architectural decision.

What is Vertical Slice Architecture?

Vertical Slice Architecture organizes code by feature (or "slice"), where each slice contains everything required to fulfill a specific use case:

Endpoint or controller
Business logic
Validation
Data access

Example structure:

/Features
  /Orders
    CreateOrder.cs
    GetOrder.cs
    UpdateOrder.cs

Each slice is intended to be independent and self-contained.

Advantages of Vertical Slice Architecture

1. Feature-Centric Organization

Code is grouped by business capability rather than technical concern. This aligns well with how product teams think about functionality.

Benefit: Easier mapping between requirements and implementation.

2. Reduced Layer Coupling

Traditional layered architectures (Controller → Service → Repository) introduce indirection. VSA reduces or eliminates these layers.

Example using a minimal API in .NET 10:

app.MapPost("/orders", async (CreateOrderRequest request, AppDbContext db) =>
{
    var order = new Order
    {
        CustomerId = request.CustomerId,
        Total = request.Items.Sum(i => i.Price)
    };

    db.Orders.Add(order);
    await db.SaveChangesAsync();

    return Results.Created($"/orders/{order.Id}", order);
});

Benefit: Less boilerplate and fewer abstractions.

3. Improved Feature Isolation

Each slice can evolve independently, making it easier to modify or remove features.

Benefit: Lower risk when changing isolated functionality.

4. Faster Development for Small Systems

For small to medium-sized applications, VSA enables rapid development due to its simplicity.

Benefit: High velocity in early stages of a project.

Disadvantages of Vertical Slice Architecture

1. Risk of Code Duplication

Because slices are self-contained, shared logic is often duplicated instead of abstracted.

// CreateOrder slice
public static class CreateOrderValidator
{
    public static bool Validate(Order order) => order.Total > 0;
}

// UpdateOrder slice
public static class UpdateOrderValidator
{
    public static bool Validate(Order order) => order.Total > 0;
}

Impact:

Increased maintenance cost
Potential inconsistencies

2. Weak Domain Modeling

Business logic often lives in handlers or endpoints rather than domain entities.

public class Order
{
    public decimal Total { get; set; }
}

Logic may instead appear in multiple slices:

if (order.Total <= 0)
{
    return Results.BadRequest("Invalid order total");
}

Impact:

Anemic domain model
Poor encapsulation

3. Harder Cross-Cutting Concerns

Handling concerns like logging, validation, or transactions consistently can be more difficult without shared layers.

Impact:

Repetition or reliance on middleware/pipelines
Increased architectural complexity over time

4. Discoverability Challenges

Logic related to a single domain concept may be scattered across multiple slices.

Impact:

Harder onboarding for new developers
Increased cognitive load

5. Refactoring Complexity at Scale

As the system grows, duplicated logic and distributed rules make refactoring more expensive.

Impact:

Higher risk of regressions
Slower evolution of core business rules

When Vertical Slice Architecture Works Well

VSA is a good fit when:

The application is small to medium in size
Business rules are relatively simple
Rapid development is a priority
Teams prefer minimal abstraction

When to Be Cautious

Consider alternatives when:

The domain is complex or evolving
Strong domain modeling is required
There are many shared business rules
Long-term maintainability is critical

Practical Middle Ground

Many teams adopt a hybrid approach:

Use vertical slices for application flow
Extract shared domain logic into domain models
Centralize cross-cutting concerns via middleware or pipelines

Example:

public class Order
{
    public decimal Total { get; private set; }

    public void AddItem(decimal price)
    {
        if (price <= 0)
            throw new ArgumentException("Price must be positive");

        Total += price;
    }
}

This preserves domain integrity while maintaining feature-based organization.

Conclusion

Vertical Slice Architecture is neither inherently good nor bad—it is a trade-off.

It excels in simplicity, feature alignment, and rapid development, but can introduce duplication, weaker domain models, and scaling challenges if not carefully managed.

The key is to evaluate your system's complexity, team structure, and long-term goals before adopting it as a default architectural pattern.

DevOps Philosophy

Jairo Blanco — Thu, 19 Mar 2026 09:22:19 +0000

Introduction

DevOps is not a toolset or a job title---it is a philosophy. At its
core, DevOps is about breaking down silos between development and
operations to enable faster, safer, and more reliable software delivery.

This post explores the principles behind DevOps, the mindset it
requires, and the practices that make it effective.

What is DevOps?

DevOps is a cultural and technical movement that emphasizes:

Collaboration between teams
Automation of processes
Continuous delivery of value
Shared ownership of systems

It aligns development (Dev) and operations (Ops) into a unified
workflow.

The Core Principles of DevOps

1. Collaboration Over Silos

Traditional models separate responsibilities:

Developers write code
Operations deploy and maintain it

DevOps removes this divide.

Key idea: Teams share responsibility for the entire lifecycle.

This leads to: - Better communication - Faster feedback - Fewer
production surprises

2. Automation First

Manual processes are:

Error-prone
Slow
Hard to scale

DevOps promotes automation wherever possible:

Builds
Testing
Deployment
Infrastructure provisioning

Goal: Reduce human intervention in repetitive tasks.

3. Continuous Integration and Continuous Delivery (CI/CD)

Frequent, small changes are safer than large, infrequent ones.

Continuous Integration (CI): Merge code frequently and validate with automated tests
Continuous Delivery (CD): Ensure code is always in a deployable state

Benefits: - Faster releases - Lower risk - Easier debugging

4. Shift Left on Quality

Testing and quality assurance should happen early.

Instead of: - Testing at the end

Adopt: - Testing during development

This includes: - Unit tests - Integration tests - Static analysis

5. Observability and Feedback Loops

You cannot improve what you cannot measure.

DevOps relies on:

Logging
Metrics
Tracing
Monitoring

These provide feedback from production systems to developers.

Outcome: Faster detection and resolution of issues.

6. Infrastructure as Code (IaC)

Infrastructure should be:

Versioned
Reproducible
Automated

Instead of manual configuration, define infrastructure in code:

# Example (simplified)
resource "server" "app" {
  image = "ubuntu"
  size  = "small"
}

Benefits: - Consistency across environments - Easier scaling -
Auditability

7. Ownership and Accountability

In DevOps:

"You build it, you run it"

Developers are responsible for: - Writing code - Deploying it -
Monitoring it - Fixing it in production

This creates stronger incentives for quality and reliability.

DevOps Mindset

Beyond practices, DevOps requires a shift in thinking.

Think in Systems

Understand how components interact: - Services - Databases - Networks

Avoid optimizing in isolation.

Embrace Failure as Learning

Failures will happen.

DevOps encourages: - Blameless postmortems - Root cause analysis -
Continuous improvement

Prioritize Flow

Optimize for:

Faster delivery
Reduced bottlenecks
Smooth handoffs

Measure lead time and deployment frequency.

Continuous Improvement

DevOps is iterative:

Measure
Learn
Improve

Never assume the system is "done."

Common DevOps Practices

Automated testing pipelines
Continuous deployment
Blue/green or canary releases
Monitoring and alerting
Containerization (e.g., Docker)
Orchestration (e.g., Kubernetes)

Anti-Patterns to Avoid

🚫 Treating DevOps as a Role

DevOps is not a single team responsible for everything.

🚫 Tool-First Approach

Buying tools without cultural change leads to failure.

🚫 Ignoring Culture

Lack of trust and communication undermines all technical improvements.

🚫 Over-Automation Without Understanding

Automating broken processes just makes problems faster.

Measuring DevOps Success

Common metrics (DORA metrics):

Deployment frequency
Lead time for changes
Change failure rate
Mean time to recovery (MTTR)

These help evaluate performance objectively.

Example Workflow

Developer commits code
CI pipeline runs tests
Build artifact is created
Deployment pipeline pushes to staging
Automated tests validate
Deployment to production
Monitoring provides feedback

Final Thoughts

DevOps is about:

People
Processes
Technology

In that order.

Organizations that succeed with DevOps focus on:

Collaboration
Automation
Feedback
Continuous improvement

It is not a destination, but an ongoing evolution toward better software delivery.

Code Review Best Practices

Jairo Blanco — Thu, 19 Mar 2026 09:19:12 +0000

Introduction

Code reviews are a critical part of modern software engineering. When
done well, they improve code quality, reduce defects, and spread
knowledge across teams. When done poorly, they create friction, slow
delivery, and damage collaboration.

This guide focuses on how to review code effectively, with emphasis on
writing clear, objective, and actionable comments.

Goals of a Code Review

Before reviewing code, align on the purpose:

Improve correctness and reliability
Ensure maintainability and readability
Enforce team standards
Share knowledge
Reduce technical debt

A code review is not: - A place to show superiority - A stylistic
battleground - A personal critique

Principles of Effective Code Reviews

1. Be Objective, Not Subjective

Avoid vague or opinion-based comments.

❌ Bad: > "This feels weird" > "I don't like this approach"

✅ Better: > "This introduces tight coupling between X and Y, which may
make testing harder" > "This function has multiple responsibilities;
consider splitting it to improve maintainability"

Focus on: - Readability - Complexity - Performance implications -
Consistency with standards

2. Provide Context and Reasoning

A comment without reasoning forces the author to guess your intent.

❌ Bad: > "Refactor this"

✅ Better: > "Refactor this method to reduce cyclomatic complexity
(currently 15), which makes it harder to test and maintain"

Always answer: - Why is this an issue? - What is the impact?

3. Suggest Improvements, Don't Just Point Out Problems

Good reviews are constructive.

❌ Bad: > "This is wrong"

✅ Better: > "This may cause a null reference if user is missing.
Consider using a guard clause or null check here"

Even better: > "Consider using TryGetValue to avoid exceptions and
improve clarity"

4. Keep Comments Small and Specific

Avoid dumping large, unfocused feedback.

❌ Bad: > "This whole file needs improvement"

✅ Better: - "Method ProcessOrder mixes validation and persistence" -
"Variable x is unclear---consider renaming to orderTotal"

5. Separate Must-Fix vs Nice-to-Have

Not all comments are equal. Clarify priority:

Must fix: Bugs, security issues, broken logic
Should fix: Maintainability, design concerns
Nitpick: Minor style or formatting

Example:

"Nit: Consider renaming this variable for clarity"

This reduces friction and helps authors prioritize.

6. Avoid Personal Language

Keep feedback about the code, not the person.

❌ Bad: > "You wrote this incorrectly"

✅ Better: > "This implementation may fail when the input is empty"

Neutral, technical language keeps discussions professional.

7. Don't Over-Review

Focus on meaningful issues:

Logic errors
Architectural concerns
Maintainability

Avoid: - Rewriting code to match your personal style - Commenting on
trivial differences (if tooling can enforce it)

Use linters and formatters to automate style enforcement.

8. Acknowledge Good Work

Positive feedback matters.

Examples: > "Nice use of pattern matching here---improves readability"
> "Good test coverage for edge cases"

This reinforces good practices and keeps morale high.

9. Review in Context

Understand: - The feature requirements - The surrounding codebase -
Trade-offs made by the author

Avoid reviewing in isolation.

10. Keep Turnaround Time Short

Timely reviews keep teams moving.

Aim to review within a few hours (or same day)
Keep pull requests small to enable faster feedback

Structuring Review Comments

A strong comment typically follows this structure:

Observation -- What you see
Impact -- Why it matters
Suggestion -- How to improve

Example:

"This method performs both validation and persistence (observation),
which increases complexity and makes testing harder (impact). Consider
splitting it into two methods (suggestion)."

Common Anti-Patterns

🚫 The "Drive-By Review"

Superficial comments without understanding context.

🚫 The "Rewrite Reviewer"

Rewriting everything to match personal preferences.

🚫 The "Silent Approver"

Approving without meaningful feedback.

🚫 The "Overly Harsh Critic"

Creates defensive responses and slows collaboration.

Tooling Helps

Use tools to reduce noise:

Linters (e.g., StyleCop, ESLint)
Formatters (e.g., Prettier)
Static analysis tools

This lets reviews focus on logic and design, not formatting.

Example: Before vs After

Before

"This is confusing"

After

"The nested conditionals here make the flow hard to follow. Consider
using early returns to simplify the control flow"

Final Thoughts

Great code reviews are:

Clear
Objective
Actionable
Respectful

They are less about catching mistakes and more about collaboratively
improving the codebase.

If your comments consistently help others understand why and how to
improve, your reviews will add real value.

Quick Checklist

Before submitting a review:

[ ] Are my comments objective?
[ ] Did I explain why something matters?
[ ] Did I suggest improvements?
[ ] Am I focusing on important issues?
[ ] Is my tone neutral and respectful?

Refit: The Elegant REST Library for .NET That Will Change How You Write API Clients

Jairo Blanco — Thu, 05 Mar 2026 13:35:18 +0000

If you've ever written an HTTP client in .NET, you know the ritual: create an HttpClient, build the URL, set headers, serialize the request body, call SendAsync, check the status code, deserialize the response, and handle errors — for every single endpoint. It's repetitive, error-prone, and buries your intent under a mountain of boilerplate.

Refit eliminates all of that. With Refit, you define your REST API as a C# interface, and Refit generates the implementation at runtime. That's it.

What Is Refit?

Refit is a type-safe REST client library for .NET, inspired by Square's Retrofit for Android. Developed by Paul Betts and maintained by the ReactiveUI organization, it turns REST API definitions into live, callable objects — no implementation required.

"Turn your REST API into a live interface."

It supports .NET 6+, .NET Framework 4.6.1+, Xamarin, and MAUI, making it a universal solution across the .NET ecosystem.

Installation

Install via NuGet:

dotnet add package Refit

If you're using ASP.NET Core and want seamless HttpClientFactory integration:

dotnet add package Refit.HttpClientFactory

Your First Refit Client

Let's say you're consuming the JSONPlaceholder API. Here's how you'd build a client with raw HttpClient:

// The old way — verbose and fragile
var client = new HttpClient { BaseAddress = new Uri("https://jsonplaceholder.typicode.com") };
var response = await client.GetAsync("/posts/1");
response.EnsureSuccessStatusCode();
var json = await response.Content.ReadAsStringAsync();
var post = JsonSerializer.Deserialize<Post>(json);

Now here's the Refit way:

// 1. Define the interface
public interface IJsonPlaceholderApi
{
    [Get("/posts/{id}")]
    Task<Post> GetPostAsync(int id);
}

// 2. Create the client
var api = RestService.For<IJsonPlaceholderApi>("https://jsonplaceholder.typicode.com");

// 3. Call it
var post = await api.GetPostAsync(1);
Console.WriteLine(post.Title);

That's the entire implementation. Clean, readable, and self-documenting.

Core Concepts

HTTP Method Attributes

Refit supports all standard HTTP verbs:

public interface IPostsApi
{
    [Get("/posts")]
    Task<List<Post>> GetAllPostsAsync();

    [Get("/posts/{id}")]
    Task<Post> GetPostAsync(int id);

    [Post("/posts")]
    Task<Post> CreatePostAsync([Body] Post post);

    [Put("/posts/{id}")]
    Task<Post> UpdatePostAsync(int id, [Body] Post post);

    [Patch("/posts/{id}")]
    Task<Post> PatchPostAsync(int id, [Body] JsonPatchDocument<Post> patch);

    [Delete("/posts/{id}")]
    Task DeletePostAsync(int id);
}

Query Parameters

Pass query string parameters as method arguments:

public interface ISearchApi
{
    // Generates: /search?query=refit&page=2&pageSize=10
    [Get("/search")]
    Task<SearchResults> SearchAsync(string query, int page = 1, int pageSize = 10);
}

Use [AliasAs] to map parameter names to query string keys:

[Get("/users")]
Task<List<User>> GetUsersAsync([AliasAs("sort_by")] string sortBy, [AliasAs("order")] string order);

Request Headers

Add headers at the interface, method, or parameter level:

// On the interface — applies to all methods
[Headers("User-Agent: MyApp/1.0", "Accept: application/json")]
public interface IMyApi
{
    // On a specific method
    [Headers("Cache-Control: no-cache")]
    [Get("/sensitive-data")]
    Task<SensitiveData> GetSensitiveDataAsync();

    // Dynamic header via parameter
    [Get("/user/profile")]
    Task<UserProfile> GetProfileAsync([Header("Authorization")] string authorization);
}

Request Body

Serialize complex objects to JSON automatically:

public interface IBlogApi
{
    [Post("/articles")]
    Task<Article> CreateArticleAsync([Body] CreateArticleRequest request);
}

var newArticle = new CreateArticleRequest
{
    Title = "Getting Started with Refit",
    Content = "Refit makes REST easy...",
    Tags = ["dotnet", "api", "refit"]
};

var created = await api.CreateArticleAsync(newArticle);

Need to send form data instead of JSON?

[Post("/oauth/token")]
Task<TokenResponse> GetTokenAsync([Body(BodySerializationMethod.UrlEncoded)] TokenRequest request);

Working with `IApiResponse<T>`

By default, Refit throws an ApiException on non-success HTTP responses. But sometimes you want to inspect the response without throwing. Use IApiResponse<T>:

public interface IProductsApi
{
    [Get("/products/{id}")]
    Task<IApiResponse<Product>> GetProductAsync(int id);
}

var response = await api.GetProductAsync(42);

if (response.IsSuccessStatusCode)
{
    Console.WriteLine($"Product: {response.Content!.Name}");
}
else
{
    Console.WriteLine($"Error {response.StatusCode}: {response.Error?.Message}");
}

You can also use ApiResponse<T> (concrete class) to access response headers:

var response = await api.GetProductAsync(42);
var etag = response.Headers.ETag?.Tag;

Integration with `HttpClientFactory` (ASP.NET Core)

The recommended approach in ASP.NET Core is to use Refit.HttpClientFactory for proper HttpClient lifecycle management:

// Program.cs
builder.Services
    .AddRefitClient<IGitHubApi>()
    .ConfigureHttpClient(c => c.BaseAddress = new Uri("https://api.github.com"));

Then inject it anywhere via DI:

public class GitHubService
{
    private readonly IGitHubApi _github;

    public GitHubService(IGitHubApi github)
    {
        _github = github;
    }

    public async Task<IEnumerable<Repository>> GetUserReposAsync(string username)
    {
        return await _github.GetRepositoriesAsync(username);
    }
}

Authentication with `DelegatingHandler`

A clean way to add Bearer tokens is via a custom DelegatingHandler:

public class AuthHeaderHandler : DelegatingHandler
{
    private readonly ITokenService _tokenService;

    public AuthHeaderHandler(ITokenService tokenService)
    {
        _tokenService = tokenService;
    }

    protected override async Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken cancellationToken)
    {
        var token = await _tokenService.GetTokenAsync();
        request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", token);
        return await base.SendAsync(request, cancellationToken);
    }
}

builder.Services.AddTransient<AuthHeaderHandler>();

builder.Services
    .AddRefitClient<ISecureApi>()
    .ConfigureHttpClient(c => c.BaseAddress = new Uri("https://api.example.com"))
    .AddHttpMessageHandler<AuthHeaderHandler>();

Custom Serialization Settings

Refit uses System.Text.Json by default. To customize settings:

var settings = new RefitSettings
{
    ContentSerializer = new SystemTextJsonContentSerializer(
        new JsonSerializerOptions
        {
            PropertyNamingPolicy = JsonNamingPolicy.SnakeCaseLower,
            DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull,
            Converters = { new JsonStringEnumConverter() }
        })
};

var api = RestService.For<IMyApi>("https://api.example.com", settings);

Prefer Newtonsoft.Json? Install Refit.Newtonsoft.Json and swap the serializer:

var settings = new RefitSettings
{
    ContentSerializer = new NewtonsoftJsonContentSerializer(
        new JsonSerializerSettings
        {
            ContractResolver = new CamelCasePropertyNamesContractResolver(),
            NullValueHandling = NullValueHandling.Ignore
        })
};

Multipart / File Upload

Uploading files is just as simple:

public interface IFileApi
{
    [Multipart]
    [Post("/upload")]
    Task<UploadResult> UploadFileAsync(
        [AliasAs("file")] StreamPart file,
        [AliasAs("description")] string description);
}

// Usage
await using var stream = File.OpenRead("report.pdf");
var filePart = new StreamPart(stream, "report.pdf", "application/pdf");
var result = await api.UploadFileAsync(filePart, "Monthly Report");

Cancellation Token Support

All methods support CancellationToken as an optional last parameter — no special attributes needed:

public interface ISlowApi
{
    [Get("/long-running-report")]
    Task<Report> GetReportAsync(CancellationToken cancellationToken = default);
}

// Cancel after 5 seconds
using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(5));
var report = await api.GetReportAsync(cts.Token);

Real-World Example: GitHub API Client

Here's a realistic, production-style Refit client for the GitHub API:

[Headers("User-Agent: MyGitHubApp", "Accept: application/vnd.github.v3+json")]
public interface IGitHubApi
{
    [Get("/users/{username}")]
    Task<GitHubUser> GetUserAsync(string username);

    [Get("/users/{username}/repos")]
    Task<List<Repository>> GetRepositoriesAsync(
        string username,
        [AliasAs("sort")] string sort = "updated",
        [AliasAs("per_page")] int perPage = 30);

    [Get("/repos/{owner}/{repo}/issues")]
    Task<IApiResponse<List<Issue>>> GetIssuesAsync(
        string owner,
        string repo,
        [AliasAs("state")] string state = "open",
        CancellationToken cancellationToken = default);

    [Post("/repos/{owner}/{repo}/issues")]
    Task<Issue> CreateIssueAsync(
        string owner,
        string repo,
        [Body] CreateIssueRequest request,
        [Header("Authorization")] string authorization);
}

Error Handling

Catch ApiException for structured error responses:

try
{
    var user = await api.GetUserAsync("nonexistent-user-xyz");
}
catch (ApiException ex)
{
    Console.WriteLine($"HTTP {ex.StatusCode}");
    Console.WriteLine($"Reason: {ex.ReasonPhrase}");

    // Deserialize the error body
    var error = await ex.GetContentAsAsync<GitHubError>();
    Console.WriteLine($"GitHub says: {error?.Message}");
}

Testing Refit Interfaces

Since Refit generates implementations from interfaces, mocking is trivial with any mocking library:

// Using NSubstitute
var mockApi = Substitute.For<IPostsApi>();
mockApi.GetPostAsync(1).Returns(new Post { Id = 1, Title = "Test Post" });

var service = new PostService(mockApi);
var result = await service.GetPostTitleAsync(1);

Assert.Equal("Test Post", result);

No complex HTTP mocking infrastructure needed — your business logic is fully decoupled from the HTTP layer.

Refit vs. Alternatives

Feature	Refit	Raw HttpClient	RestSharp
Interface-based contracts	✅	❌	❌
Compile-time type safety	✅	Partial	Partial
DI / HttpClientFactory	✅	✅	✅
Auto serialization	✅	Manual	✅
Boilerplate required	Minimal	Heavy	Medium
Testability	Excellent	Poor	Moderate
Learning curve	Low	Medium	Low

Summary

Refit is one of those libraries that, once you use it, you can't imagine going back. By expressing your API contract as a C# interface, you gain:

Clarity — your API surface is immediately obvious from the interface definition
Type safety — no more stringly-typed URLs or manual serialization
Testability — mock the interface, test your logic
Maintainability — changes to the API are localized to the interface
Less code — dramatically less boilerplate per endpoint

Whether you're integrating with third-party APIs or consuming your own microservices, Refit is the most expressive and productive way to write HTTP clients in .NET.

Happy coding — and may your 404s be few and your 200s be plentiful.

CQRS in .NET: Deep Analysis, Benefits, and Trade-Offs

Jairo Blanco — Wed, 25 Feb 2026 11:13:25 +0000

Introduction

Command Query Responsibility Segregation (CQRS) is an architectural
pattern that separates read operations (queries) from write operations
(commands). In modern .NET applications---especially those built with
ASP.NET Core and Entity Framework Core---CQRS is commonly used to
improve scalability, maintainability, and performance.

This article provides a structured analysis of CQRS in .NET, including
its conceptual model, implementation patterns, benefits, drawbacks, and
when to apply it.

What is CQRS?

CQRS divides application operations into two distinct models:

Command Model: Responsible for changing state (Create, Update, Delete).
Query Model: Responsible for reading state (no side effects).

This separation enables different optimization strategies for reads and
writes.

Unlike traditional CRUD architectures, CQRS enforces a strict separation
between mutation and retrieval logic.

CQRS in the Context of .NET

In .NET (particularly ASP.NET Core), CQRS is typically implemented
using:

MediatR for request/handler dispatching
Entity Framework Core for persistence
Separate DTOs for read and write models
Optional event sourcing for advanced scenarios

Basic Folder Structure Example

Application/
 ├── Commands/
 │    ├── CreateOrderCommand.cs
 │    └── CreateOrderHandler.cs
 ├── Queries/
 │    ├── GetOrderByIdQuery.cs
 │    └── GetOrderByIdHandler.cs
Domain/
Infrastructure/
API/

Core Components in .NET CQRS

1. Commands

Commands represent intent to change state.

Example:

public record CreateOrderCommand(string CustomerName) : IRequest<Guid>;

Handler:

public class CreateOrderHandler : IRequestHandler<CreateOrderCommand, Guid>
{
    private readonly AppDbContext _context;

    public CreateOrderHandler(AppDbContext context)
    {
        _context = context;
    }

    public async Task<Guid> Handle(CreateOrderCommand request, CancellationToken cancellationToken)
    {
        var order = new Order { CustomerName = request.CustomerName };
        _context.Orders.Add(order);
        await _context.SaveChangesAsync(cancellationToken);
        return order.Id;
    }
}

2. Queries

Queries return data without modifying state.

public record GetOrderByIdQuery(Guid Id) : IRequest<OrderDto>;

Handler:

public class GetOrderByIdHandler : IRequestHandler<GetOrderByIdQuery, OrderDto>
{
    private readonly AppDbContext _context;

    public GetOrderByIdHandler(AppDbContext context)
    {
        _context = context;
    }

    public async Task<OrderDto> Handle(GetOrderByIdQuery request, CancellationToken cancellationToken)
    {
        return await _context.Orders
            .Where(o => o.Id == request.Id)
            .Select(o => new OrderDto { Id = o.Id, CustomerName = o.CustomerName })
            .FirstOrDefaultAsync(cancellationToken);
    }
}

Architectural Variants

1. Simple CQRS (Single Database)

Same database
Different logical models
Most common in business applications

2. Full CQRS (Separate Databases)

Separate read/write databases
Asynchronous synchronization
Often combined with Event Sourcing
Used in high-scale systems

Benefits of CQRS in .NET

1. Clear Separation of Concerns

Command logic and query logic evolve independently.

2. Optimized Read Models

Read models can use: - Projection tables - Denormalized views - Dapper
for fast reads - Caching strategies

3. Scalability

You can: - Scale read replicas independently - Apply different
performance tuning strategies

4. Maintainability

Smaller handlers are easier to test and reason about.

5. Extensibility

Cross-cutting concerns (logging, validation, transactions) can be added
via MediatR pipeline behaviors.

Trade-Offs and Costs

CQRS introduces complexity. It is not free.

1. Increased Architectural Complexity

More files, more abstractions, more patterns.

2. Learning Curve

Developers must understand: - Domain-driven design concepts - Mediator
pattern - Event-driven patterns (in advanced scenarios)

3. Eventual Consistency (in advanced CQRS)

If separate read/write models are used: - Data may not be immediately
consistent - Requires careful UX considerations

4. Overengineering Risk

For small CRUD apps, CQRS may add unnecessary overhead.

When to Use CQRS

CQRS is appropriate when:

The domain has complex business rules
Read/write workloads differ significantly
The system requires high scalability
The team is comfortable with architectural patterns

Avoid CQRS when:

The application is simple CRUD
The team lacks experience with distributed systems
Development speed is more important than architectural purity

CQRS and Clean Architecture

CQRS integrates well with Clean Architecture:

Commands and Queries live in the Application layer
Domain remains isolated
Infrastructure handles persistence and external systems

This alignment improves testability and separation of concerns.

Testing Strategy in .NET

Unit Testing

Test handlers directly
Mock DbContext or use InMemory provider

Integration Testing

Test pipeline behaviors
Validate end-to-end command/query flow

Performance Considerations

Use lightweight ORMs (e.g., Dapper) for query side
Avoid over-fetching in query handlers
Consider caching for high-read endpoints
Apply indexing strategies in read models

Conclusion

CQRS in .NET is a powerful architectural pattern that enhances
separation of concerns, scalability, and maintainability. However, it
introduces additional complexity and should be applied deliberately.

For enterprise-grade systems with complex domains and scaling
requirements, CQRS provides significant long-term benefits. For small
applications, traditional layered architecture may be sufficient.

Architectural discipline---not trend adoption---should guide your
decision.

SQL Server vs PostgreSQL: A Practical Comparison for Modern Developers

Jairo Blanco — Tue, 10 Feb 2026 13:38:35 +0000

Choosing a database is a strategic decision. It affects performance, cost, scalability, hiring, tooling, and even your deployment architecture. Two of the most common choices in production systems today are Microsoft SQL Server and PostgreSQL.

Both are mature, powerful relational database management systems (RDBMS). Both support ACID transactions, indexing, stored procedures, and advanced querying. But they differ significantly in philosophy, ecosystem, and real-world usage.

This article compares SQL Server and PostgreSQL across the dimensions that matter most to engineering teams.

Quick Overview

Feature	SQL Server	PostgreSQL
License	Proprietary (Express free)	Open source (PostgreSQL License)
Vendor	Microsoft	Community-driven
Platforms	Windows, Linux	Windows, Linux, macOS
Language	T-SQL	SQL + PL/pgSQL
JSON Support	Good	Excellent
Extensions	Limited	Rich ecosystem
Cloud Integration	Azure-first	Cloud-agnostic
Cost	Can be expensive	Free

Philosophy and Ecosystem

SQL Server

SQL Server is a commercial, vendor-controlled product developed by Microsoft. It integrates tightly with the Microsoft ecosystem:

Azure
Active Directory
Power BI
.NET
SSIS / SSRS / SSAS

If your organization already lives in Microsoft land, SQL Server fits naturally.

Microsoft provides polished tooling such as SQL Server Management Studio (SSMS) and Azure Data Studio, along with enterprise-grade support.

PostgreSQL

PostgreSQL is open source and community-driven. Its design emphasizes standards compliance, extensibility, and correctness.

Postgres is often described as “the world’s most advanced open source database” because of:

A powerful extension system
Custom data types
Advanced indexing methods
Strong support for modern workloads

Postgres integrates well with virtually every programming language and cloud provider.

Cost

This is often decisive.

SQL Server

Express edition is free (but heavily limited).
Standard and Enterprise editions are licensed per core.
Costs can reach tens of thousands of dollars annually at scale.

You are paying for:

Official support
Enterprise tooling
Tight Azure integration

PostgreSQL

Completely free.
No licensing fees.
You only pay for hosting and support if you choose managed services.

For startups and cost-sensitive teams, Postgres is usually the clear winner.

Performance

Both databases are fast when properly tuned.

SQL Server Strengths

Excellent performance on Windows workloads
Sophisticated query optimizer
Columnstore indexes for analytics
Strong OLAP capabilities

SQL Server shines in enterprise reporting and data warehousing scenarios.

PostgreSQL Strengths

Extremely efficient for OLTP workloads
Superior concurrency model (MVCC)
Rich indexing options (GIN, GiST, BRIN)
Better handling of complex queries

Postgres often outperforms SQL Server in high-concurrency web applications.

JSON and Modern Data

Modern applications frequently mix relational and document-style data.

SQL Server

Supports JSON via functions like OPENJSON
JSON is stored as plain text
Limited indexing options

PostgreSQL

Native json and jsonb types
Indexable JSON fields
Advanced querying operators

Postgres effectively acts as a hybrid relational/document database.

This is a major advantage for modern APIs and microservices.

Extensibility

This is where PostgreSQL truly differentiates itself.

Postgres supports extensions such as:

PostGIS (geospatial)
TimescaleDB (time series)
pgvector (AI embeddings)
Citus (distributed Postgres)

SQL Server offers far fewer extension capabilities and is much more closed.

If you need specialized data workloads, Postgres is dramatically more flexible.

Developer Experience

SQL Server

Pros:

Excellent GUI tools
Strong integration with Visual Studio
Familiar for enterprise developers

Cons:

T-SQL is non-standard
Less friendly for containerized workflows
Heavier footprint

PostgreSQL

Pros:

Standard SQL
Lightweight
Docker-friendly
Massive open-source tooling ecosystem

Cons:

Requires more manual tuning
GUI tools are less polished (though improving)

Most modern DevOps pipelines favor Postgres.

Cloud and Deployment

SQL Server

Optimized for Azure:

Azure SQL Database
Azure Managed Instance
Azure Synapse

While SQL Server runs on Linux, Azure remains its natural home.

PostgreSQL

Runs everywhere:

AWS RDS / Aurora
Google Cloud SQL
Azure Database for PostgreSQL
Self-hosted Kubernetes

Postgres is cloud-agnostic by design.

Security and Reliability

Both systems provide:

Encryption at rest and in transit
Role-based access control
Replication
Backup tooling

Postgres is known for its conservative approach to data integrity. SQL Server offers excellent enterprise compliance features.

Neither choice is weak here.

When to Choose SQL Server

SQL Server makes sense if:

You are deeply invested in Microsoft technologies
You need SSRS/SSIS/SSAS
You run large enterprise BI workloads
You require official vendor support
Budget is less of a concern

When to Choose PostgreSQL

PostgreSQL is ideal if:

You want zero licensing costs
You build cloud-native applications
You need JSON or hybrid workloads
You value extensibility
You prefer open-source ecosystems
You care about portability and vendor independence

Final Thoughts

SQL Server and PostgreSQL are both excellent databases — but they serve different philosophies.

SQL Server is a polished enterprise platform tightly coupled to Microsoft’s ecosystem.

PostgreSQL is a flexible, open, developer-friendly database that excels in modern application architectures.

For most startups and cloud-native teams in 2026, PostgreSQL is usually the better default choice. For established enterprises already standardized on Microsoft, SQL Server remains a strong contender.

The right answer depends less on raw performance — and more on your organization’s ecosystem, budget, and long-term strategy.

Result Pattern vs Exception Flow in .NET

Jairo Blanco — Thu, 05 Feb 2026 08:28:24 +0000

Error handling is one of those design choices that quietly shapes an
entire codebase.

In .NET, we usually reach for exceptions by default. It's what the
framework teaches, what most samples show, and what feels "natural" at
first.

But as systems grow, many teams start to feel friction: - Too many
try/catch blocks - Unclear method contracts - Hard-to-follow control
flow - Performance issues under load - Business logic hidden behind
thrown exceptions

This is where the Result pattern enters the picture.

Both approaches are valid. The key is understanding what problem each
one is meant to solve.

The Familiar Way: Exception Flow

This is classic .NET:

public User GetUser(Guid id)
{
    var user = _repo.Find(id);

    if (user == null)
        throw new UserNotFoundException(id);

    return user;
}

Caller:

try
{
    var user = service.GetUser(id);
}
catch (UserNotFoundException)
{
    // handle it
}

There's nothing "wrong" with this. Exceptions are deeply built into the
runtime and the language.

But there's an assumption baked into this style:

Something unusual or truly unexpected happened.

The Alternative: The Result Pattern

The Result pattern treats failures as normal outcomes, not
interruptions.

public Result<User> GetUser(Guid id)
{
    var user = _repo.Find(id);

    if (user == null)
        return Result.Fail<User>("User not found");

    return Result.Ok(user);
}

Caller:

var result = service.GetUser(id);

if (result.IsFailure)
{
    // handle it
    return;
}

var user = result.Value;

Now the method is honest about what can happen. No surprises.

The Real Difference

This is the mental model that clears up most confusion:

Exceptions Results

For things that shouldn't For things that **happen as part of
normally happen the domain**

Break the flow Keep the flow linear

Implicit contract Explicit contract

Expensive when thrown Cheap to return

Hard to compose Easy to compose

A Rule of Thumb That Helps

Use exceptions for system failures.\
Use results for business outcomes.

Once you start thinking this way, most design decisions become obvious.

When Exceptions Make Perfect Sense

Use exceptions when the caller cannot realistically recover:

Database connection dropped
File system unavailable
Network timeout
Serialization failure
A library throws
A programmer broke an invariant

Example:

public async Task<string> ReadConfigAsync()
{
    return await File.ReadAllTextAsync("config.json");
}

You shouldn't wrap this in a Result. If this fails, something is wrong
with the environment, not the business logic.

When Results Are the Better Choice

Use Results when the caller is expected to handle the situation:

Validation failures
Entity not found
Business rule violations
Authorization problems
Duplicate records
Insufficient balance

These are not exceptional. They are part of how the system works.

public Result Withdraw(Money amount)
{
    if (Balance < amount)
        return Result.Fail("Insufficient funds");

    Balance -= amount;
    return Result.Ok();
}

Throwing here would be misleading. Nothing "broke".

Why Exceptions Get Painful in Business Logic

As a codebase grows, exception-driven business flow starts to hurt:

The method signature lies --- it doesn't show what can happen
You end up wrapping everything in try/catch
Performance suffers when exceptions are used frequently
Composing operations becomes awkward
Async and LINQ flows become harder to reason about

Compare this:

var user = GetUser(id);
var account = GetAccount(user);
var result = Process(account);

You don't know where it might blow up.

With Results:

return GetUser(id)
    .Bind(GetAccount)
    .Bind(Process);

The flow is obvious and safe.

A Simple Result Implementation

You don't need a big library. A small type is enough:

public class Result
{
    public bool IsSuccess { get; }
    public bool IsFailure => !IsSuccess;
    public string Error { get; }

    protected Result(bool isSuccess, string error)
    {
        IsSuccess = isSuccess;
        Error = error;
    }

    public static Result Ok() => new(true, string.Empty);
    public static Result Fail(string error) => new(false, error);
}

public class Result<T> : Result
{
    public T Value { get; }

    protected Result(T value, bool isSuccess, string error)
        : base(isSuccess, error)
    {
        Value = value;
    }

    public static Result<T> Ok(T value) => new(value, true, string.Empty);
    public static new Result<T> Fail(string error) => new(default!, false, error);
}

And a helper for composition:

public static Result<K> Bind<T, K>(this Result<T> result, Func<T, Result<K>> func)
{
    if (result.IsFailure)
        return Result<K>.Fail(result.Error);

    return func(result.Value);
}

How Mature .NET Systems Use Both

It's not either/or.

A healthy architecture looks like this:

Controllers → Results
Application Layer → Results
Domain Layer → Results
Infrastructure → Exceptions

Exceptions stay at the edges. Results live where business decisions
happen.

Example in an ASP.NET Core Controller

[HttpGet("{id}")]
public IActionResult Get(Guid id)
{
    var result = _service.GetUser(id);

    if (result.IsFailure)
        return NotFound(result.Error);

    return Ok(result.Value);
}

No try/catch. Clear intent.

A Note on Performance

Exceptions are expensive when thrown. In high-traffic APIs, using them
for normal control flow can become a real bottleneck.

Results avoid this entirely.

The Practical Guideline

If the caller is expected to handle the outcome → return a
Result.

If the caller cannot reasonably recover → throw an Exception.

That's it.

Closing Thought

This isn't about being clever or following a trend. It's about making
your code:

Easier to read
Easier to reason about
More explicit
More composable
More predictable under load

Once you start separating system failures from business outcomes,
your APIs become much clearer --- both for you and for everyone else who
reads your code.

Edge Day: Turning AI from Theory into Everyday Practice

Jairo Blanco — Mon, 19 Jan 2026 09:20:04 +0000

Edge Day: Turning AI from Theory into Everyday Practice

Edge Day was dedicated to one clear goal: accelerating practical AI adoption across engineering, design, and product. This was not a day of abstract talks or speculative futures. Instead, it focused on real workflows, concrete examples, and battle-tested practices that teams can apply immediately in their day-to-day work.

We openly acknowledged the realities of working with AI today. The tools can be unpredictable, prone to hallucinations, and sometimes frustratingly inconsistent. That is precisely why the sessions centered on actionable techniques, guardrails, and patterns that help teams achieve more reliable, repeatable outcomes.

Why We Ran Edge Day

AI is already reshaping how we design, build, and ship products. Edge Day was designed to:

Expand horizons on how teams across R&D are using AI to improve productivity and workflow quality
Provide hands-on, practical examples that participants could try on their own machines
Showcase how AI usage is transforming collaboration between design, product, and engineering
Share hard-earned lessons on what works, what fails, and how to avoid common pitfalls

The emphasis throughout the day was on doing: live demos, real code, real prompts, and real trade-offs.

Highlights from the Day

Designing and Prototyping with AI

The day opened with practical examples of how AI-assisted tools can accelerate design prototyping. The focus was on shortening feedback loops, rapidly exploring ideas, and turning early concepts into tangible artifacts without sacrificing design intent.

AI Tooling for Large Codebases

Several sessions addressed a core challenge: making AI genuinely useful in complex, real-world codebases. Topics included configuring tools for monoliths, managing context effectively, and avoiding the trap of blindly accepting generated code.

Prompting for Production, Not Demos

A recurring theme was the importance of strong prompting and clear specifications. One session contrasted “copy-paste” AI usage with structured prompting approaches that dramatically reduce debugging time and improve code quality.

Agentic and Autonomous Workflows

From open-source agentic coding to building autonomous AI agents, multiple talks explored what agents actually are, where they make sense, and where they do not. The emphasis was on realistic architectures, constraints, and maintainability rather than hype.

AI in Data Science Workflows

AI-assisted driver–navigator workflows demonstrated how data science problems can be broken down more effectively, with AI acting as a collaborator rather than a black box.

Long-Term Collaboration with AI

One session tackled a common frustration: AI systems that “forget everything.” Practical approaches to structured issue tracking and long-term context management showed how agents can support sustained collaboration over time.

End-to-End Product Workflows

Later sessions connected the dots from design to code, illustrating how AI-powered tools can support an end-to-end product workflow—from wireframes to working applications—while keeping humans firmly in control of decisions and quality.

Building Agents with Agents

The day concluded with lessons learned from using coding agents to build other agents, highlighting both the potential and the operational challenges of this approach.

Key Takeaways

AI delivers the most value when paired with clear intent, strong constraints, and human judgment
Better prompts and specifications often matter more than better models
Hands-on experimentation is essential to understanding where AI fits into real workflows
Reliability, observability, and control are critical for production use
AI is a multiplier for good practices, not a replacement for them

Looking Ahead

Edge Day reinforced that successful AI adoption is not about chasing trends. It is about thoughtfully integrating tools into existing workflows, learning from real usage, and continuously refining how humans and machines collaborate.

The conversations, experiments, and lessons from the day will continue to shape how we build, design, and ship products—practically, responsibly, and with impact.

A Comprehensive Guide to Application Logging

Jairo Blanco — Tue, 13 Jan 2026 08:35:35 +0000

Intro

Logging is one of those fundamental practices that separates maintainable software from debugging nightmares. Yet despite its importance, logging is often treated as an afterthought—something developers sprinkle throughout their code without much consideration. This guide explores the different logging levels, best practices, and common pitfalls to help you build better observability into your applications.

Understanding Log Levels

Most logging frameworks provide a hierarchy of log levels, each serving a distinct purpose. Understanding when to use each level is crucial for creating useful logs.

TRACE

The most granular level of logging, TRACE captures extremely detailed information about program execution. This level is typically used for diagnostic purposes during development and is rarely enabled in production environments.

Use TRACE when you need to follow the exact path of execution through your code, including entry and exit points of methods, loop iterations, or detailed state transitions. For example, you might log every iteration of a data processing loop or every step in a complex algorithm.

DEBUG

DEBUG level provides detailed information useful for debugging during development and troubleshooting in production. Unlike TRACE, DEBUG logs should focus on meaningful events and state changes rather than exhaustive execution details.

Use DEBUG for variable values, conditional branch decisions, intermediate calculation results, and other information that helps you understand why your application behaved a certain way. For instance, logging the parameters passed to a function or the result of a database query would be appropriate at this level.

INFO

INFO is the standard logging level for recording normal application behavior. These logs document significant events in your application's lifecycle and business logic execution.

Use INFO for application startup and shutdown, configuration values being loaded, successful completion of major operations, user actions, and state transitions that matter to your business logic. INFO logs should tell the story of what your application is doing under normal circumstances.

WARN

WARN indicates something unexpected happened, but the application can continue functioning. These are potential problems that don't prevent the current operation from completing but might cause issues later.

Use WARN for deprecated API usage, fallback to default values when configuration is missing, recoverable errors like temporary network issues with retry logic, performance degradation, or approaching resource limits. A warning suggests that while things are working now, someone should probably investigate.

ERROR

ERROR indicates a serious problem that prevented a specific operation from completing. The application can usually continue running, but something definitely went wrong.

Use ERROR for exceptions that prevent business logic from completing, failed database transactions, failed external API calls without a fallback, invalid user input that can't be processed, or missing required resources. ERROR logs should always provide enough context to understand what went wrong and why.

Common Mistakes

Logging Too Much or Too Little

One of the most common mistakes is finding the wrong balance. Too much logging creates noise that obscures important information and can impact performance. Too little logging leaves you blind when problems occur.

Avoid logging inside tight loops at INFO level or above, logging the same information repeatedly, or creating massive log files that are expensive to store and process. Equally problematic is having no logs around critical business logic, catching exceptions without logging them, or failing to log enough context to diagnose issues.

Poor Log Messages

Vague messages like "Error occurred" or "Processing complete" provide almost no value. Your logs should tell a clear story to someone who wasn't present when the code was written.

Include relevant context such as identifiers, parameters, and state information. Use structured logging with key-value pairs rather than string concatenation. Avoid including sensitive information like passwords, tokens, credit card numbers, or personally identifiable information unless you have proper redaction in place.

Inconsistent Formatting

When every developer on your team uses different logging styles, searching and parsing logs becomes a nightmare. Establish conventions for your team and stick to them.

Inconsistencies appear in timestamp formats, how exceptions are logged, naming conventions for log fields, and the structure of log messages. Using a structured logging framework can help enforce consistency automatically.

Logging at the Wrong Level

Misusing log levels makes it difficult to filter logs effectively. If everything is logged at ERROR, you can't distinguish real problems from routine events. If business-critical events are logged at DEBUG, they'll be invisible in production.

A common mistake is logging every caught exception as ERROR when many exceptions represent expected business logic outcomes. Similarly, logging successful operations at WARN or DEBUG undermines the purpose of INFO level logging.

Performance Impact

Logging isn't free. String concatenation, formatting, and I/O operations all consume resources. Logging inside performance-critical code paths without consideration can significantly impact application performance.

Be especially careful about logging in tight loops, constructing expensive log messages unconditionally even when that log level is disabled, and synchronous logging in high-throughput code paths. Use asynchronous logging and guard clauses to check if a log level is enabled before constructing expensive messages.

Best Practices

Use Structured Logging

Modern applications should embrace structured logging formats like JSON. Structured logs are machine-readable, making them much easier to search, filter, and analyze at scale.

Instead of logging "User John logged in from 192.168.1.1", structure it as key-value pairs with fields for user, action, and IP address. This allows you to easily query all login events or all actions by a specific user.

Include Correlation IDs

In distributed systems, tracking a single request across multiple services is essential. Include correlation or trace IDs in your logs to connect related events across service boundaries.

When a request enters your system, generate or extract a correlation ID and include it in every log statement related to that request. This allows you to reconstruct the complete journey of a request through your infrastructure.

Log Contextual Information

Every log statement should include enough context for someone to understand what was happening without reading the code. This includes relevant identifiers, operation being performed, input parameters, and environmental context.

However, balance this with privacy and security concerns. Use redaction libraries to automatically scrub sensitive data, and ensure your logging practices comply with regulations like GDPR.

Set Appropriate Default Levels

Configure production environments to log at INFO by default, with the ability to dynamically increase verbosity to DEBUG when troubleshooting. Development environments can default to DEBUG. TRACE should almost never be enabled in production due to its volume and performance impact.

Implement the ability to change log levels without restarting your application. This allows you to increase verbosity when investigating issues without downtime.

Make Logs Actionable

Every ERROR log should suggest a clear path forward. If a database connection fails, log not just the error but also which database, what operation was attempted, and relevant configuration details.

Similarly, WARN logs should indicate what the potential impact is and what action might be needed. A warning about approaching disk space limits is only useful if it includes how much space remains and where.

Use Logging Frameworks

Don't write logs directly to stdout or files. Use established logging frameworks like Log4j, Logback, Serilog, or Python's logging module. These frameworks provide features like log rotation, filtering, asynchronous logging, and multiple output destinations.

Logging frameworks also allow you to configure logging behavior without changing code, making it easier to adjust logging in different environments.

Sample High-Volume Logs

For very high-traffic operations, consider sampling your logs. You don't need to log every single request at INFO level if you're handling millions per minute. Logging 1% of successful requests with full DEBUG logging for errors provides good observability without overwhelming your log storage.

Implement intelligent sampling that always logs errors and warnings while sampling routine successful operations based on configured rates.

Integration with Observability

Modern logging doesn't exist in isolation. Integrate your logs with metrics and tracing to build comprehensive observability.

When an error occurs, your logs should reference relevant metric names and trace IDs. When investigating a performance issue, you should be able to jump from a slow trace to the corresponding detailed logs. This integration transforms logs from isolated events into part of a cohesive narrative about your application's behavior.

Use log aggregation tools like the ELK stack (Elasticsearch, Logstash, Kibana), Splunk, or cloud-native solutions like CloudWatch or Stackdriver. These tools make it possible to search across millions of log entries, create alerts based on log patterns, and visualize trends over time.

Conclusion

Effective logging is a skill that develops over time. It requires understanding your application's behavior, anticipating what information will be valuable during troubleshooting, and balancing detail with readability and performance.

Start by establishing clear conventions for your team, use structured logging from the beginning, and regularly review your logs to ensure they're providing the value you need. Good logging transforms debugging from guesswork into detective work, where the clues you need are already waiting in your log files.

Remember that logs are written once but read many times, usually under stressful circumstances when something is broken. Invest the time to make them clear, consistent, and useful. Your future self, your teammates, and your on-call rotation will thank you.

Forem: Jairo Blanco

.NET 10 and the Next Leap in Native AOT for Cloud-Native Apps

Introduction

Understanding Native AOT in Context

Why this matters:

Key Enhancements in .NET 10

1. Real-World Compatibility Improvements

2. ASP.NET Core Becomes AOT-Friendly

3. Startup Performance and Scalability

4. Reduced Container Footprint

5. Tooling and Developer Experience

Architectural Implications

Shift Toward Compile-Time Behavior

Preference for Simplicity

When to Use Native AOT

Strong Candidates

Situations to Avoid

Strategic Impact

Conclusion

TL;DR

The illusion of Entity Framework

The Illusion of "Just Objects"

Deferred Execution: A Double-Edged Sword

The N+1 Query Problem

Over-Fetching and Under-Fetching

The Cost of Ignoring SQL

EF Is Not the Problem

Reintroducing Intentionality

Conclusion

REPR vs MVC: A Pragmatic Comparison

Introduction

What is MVC?

Example

Observations

What is REPR?

REPR with FastEndpoints

Example

Architectural Comparison

1. Organization

2. Coupling & Cohesion

3. Scalability (Codebase, not infra)

4. Testing

MVC

REPR

5. Alignment with CQRS

6. Performance Considerations

FastEndpoints: Key Features

Example: Validation

When to Use MVC

When to Use REPR (FastEndpoints)

Trade-offs

MVC Drawbacks

REPR Drawbacks

Folder Structure Comparison

MVC

REPR

Final Thoughts

Further Reading

Vertical Slice Architecture: A Balanced Evaluation

Introduction

What is Vertical Slice Architecture?

Advantages of Vertical Slice Architecture

1. Feature-Centric Organization

2. Reduced Layer Coupling

3. Improved Feature Isolation

4. Faster Development for Small Systems

Disadvantages of Vertical Slice Architecture

1. Risk of Code Duplication

2. Weak Domain Modeling

3. Harder Cross-Cutting Concerns

4. Discoverability Challenges

5. Refactoring Complexity at Scale

When Vertical Slice Architecture Works Well

When to Be Cautious

Practical Middle Ground

Conclusion

DevOps Philosophy

Introduction

What is DevOps?

The Core Principles of DevOps

Working with `IApiResponse<T>`

Integration with `HttpClientFactory` (ASP.NET Core)

Authentication with `DelegatingHandler`