DEV Community: Daniel Balcarek

.NET Reflection Benchmarks: Enum Attribute Performance (Part 1)

Daniel Balcarek — Mon, 13 Apr 2026 13:06:35 +0000

.NET reflection has a reputation for being slow, hard to read and something to avoid. But does this still apply in newer .NET versions like .NET 8+?

When I was a junior developer, I often heard that reflection should not be used, just avoid it. Over time, I encountered many scenarios where reflection was not only convenient, but also the most maintainable solution.

In this series, I’ll benchmark common reflection use cases to understand its real performance characteristics and trade-offs. The goal is simple: separate myths from measurable cost.

In this first part, we focus on a very common scenario, retrieving custom attributes from enum values and compare reflection against alternatives such as Dictionary and FrozenDictionary.

Get Custom Attribute

Sometimes we need human-readable descriptions for enum values, and one of the simplest approaches is to use attributes. Reflection provides a convenient way to retrieve these attributes at runtime.

In this benchmark, we evaluate the performance of a generic extension method that retrieves custom attributes from enum values.

Reflection Implementation

A basic extension method for retrieving a custom attribute from an enum looks like this:

public static class EnumExtensions
{
    public static T GetCustomAttribute<T>(this Enum customEnumValue) where T : Attribute
    {
        var enumType = customEnumValue.GetType();
        return enumType
            .GetField(Enum.GetName(enumType, customEnumValue)!)!
            .GetCustomAttribute<T>()!;
    }
}

Since we are creating a benchmark, we should also implement a more performant version. We can improve performance by caching results using a ConcurrentDictionary:

public static class EnumExtensions
{
    private static readonly ConcurrentDictionary<(Type EnumType, Type AttributeType, string MemberName), Attribute?> _cache = new();

    public static T? GetCustomAttributeCached<T>(this Enum customEnumValue) where T : Attribute
    {
        var enumType = customEnumValue.GetType();
        var key = (enumType, typeof(T), Enum.GetName(enumType, customEnumValue)!);
        return (T?)_cache.GetOrAdd(key, static k =>
            k.EnumType.GetField(k.MemberName)?.GetCustomAttribute(k.AttributeType));
    }
}

Note: ConcurrentDictionary is used here to ensure thread-safe access, as this extension method may be called concurrently from multiple threads.

Dictionary-Based Alternative

To compare against a faster alternative, I created a static dictionary that maps CustomEnum values to their corresponding descriptions:

public static class CustomEnumMap
{
    public static readonly Dictionary<CustomEnum, string> Map = new Dictionary<CustomEnum, string>()
    {
        ...
    };
}

Starting with .NET 8, we can use FrozenDictionary, which is optimized for read-heavy, write-once scenarios. This allows us to compare it with a standard Dictionary.

public static readonly FrozenDictionary<CustomSmallEnum, string> FrozenSmallMap = Map.ToFrozenDictionary();

Note: Another possible approach is to use a source generator, which can eliminate manual maintenance of mappings like FrozenDictionary. However, this comes at the cost of increased complexity and more difficult debugging. I am not covering it here, as it would likely produce performance similar to the FrozenDictionary approach.

Enum definition

To evaluate whether enum size has any impact on performance, I created three enums of different sizes:

CustomLargeEnum with 35 values
CustomEnum with 16 values
CustomSmallEnum with 7 values

The CustomEnumAttribute is very simple:

[AttributeUsage(AttributeTargets.Field)]
public sealed class CustomEnumAttribute : Attribute
{
    public string Description { get; }

    public CustomEnumAttribute(string description)
    {
        Description = description;
    }

}

Benchmark code

The benchmark iterates over pre-generated arrays of random enum values and calls GetCustomAttribute for each item.

[SimpleJob(RuntimeMoniker.Net10_0)]
[Orderer(BenchmarkDotNet.Order.SummaryOrderPolicy.FastestToSlowest)]
[MemoryDiagnoser]
public class GetEnumAttributeBenchmark
{
    [Params(1,100,1000,10000)]
    public int Count;

    private CustomEnum[] _values = [];
    private CustomSmallEnum[] _smallValues = [];
    private CustomLargeEnum[] _largeValues = [];


   [GlobalSetup]
    public void Setup()
    {
            var rnd = new Random(42);

            var all = Enum.GetValues<CustomEnum>();
            var smallAll = Enum.GetValues<CustomSmallEnum>();
            var largeAll = Enum.GetValues<CustomLargeEnum>();

            _values = [.. Enumerable
                .Range(0, Count)
                .Select(_ => all[rnd.Next(all.Length)])];

            _smallValues = [.. Enumerable
                .Range(0, Count)
                .Select(_ => smallAll[rnd.Next(smallAll.Length)])];

            _largeValues = [.. Enumerable
                .Range(0, Count)
                .Select(_ => largeAll[rnd.Next(largeAll.Length)])];
    }

    [Benchmark(Baseline = true)]
    public void CustomEnum()
    {
        for (var i = 0; i < _values.Length; i++)
        {
            _ = _values[i].GetCustomAttribute<CustomEnumAttribute>().Description;
        }
    }

    [Benchmark]
    public void CustomLargeEnum()
    {
        for (var i = 0; i < _largeValues.Length; i++)
        {
            _ = _largeValues[i].GetCustomAttribute<CustomEnumAttribute>().Description;
        }
    }
    ...
}

Source Solution

Results

BenchmarkDotNet v0.15.8, Windows 10 (10.0.19045.6466/22H2/2022Update)
Intel Core i5-6400 CPU 2.70GHz (Skylake), 1 CPU, 4 logical and 4 physical cores
.NET SDK 10.0.201
  [Host]    : .NET 10.0.5 (10.0.5, 10.0.526.15411), X64 RyuJIT x86-64-v3
  .NET 10.0 : .NET 10.0.5 (10.0.5, 10.0.526.15411), X64 RyuJIT x86-64-v3

Job=.NET 10.0  Runtime=.NET 10.0

Method	Count	Mean	Allocated
CustomEnumFrozenMap	1	0.5172 ns	-
CustomLargeEnumFrozenMap	1	0.5200 ns	-
CustomSmallEnumFrozenMap	1	0.5209 ns	-
CustomSmallEnumMap	1	4.5348 ns	-
CustomLargeEnumMap	1	4.5409 ns	-
CustomEnumMap	1	4.5477 ns	-
CustomLargeEnumCached	1	55.2759 ns	24 B
CustomSmallEnumCached	1	55.8674 ns	24 B
CustomEnumCached	1	63.9393 ns	24 B
CustomSmallEnum	1	886.7600 ns	280 B
CustomEnum	1	887.6823 ns	272 B
CustomLargeEnum	1	888.5621 ns	280 B
CustomEnumFrozenMap	100	99.5479 ns	-
CustomLargeEnumFrozenMap	100	99.5514 ns	-
CustomSmallEnumFrozenMap	100	99.8055 ns	-
CustomLargeEnumMap	100	336.8072 ns	-
CustomSmallEnumMap	100	337.0285 ns	-
CustomEnumMap	100	337.2214 ns	-
CustomSmallEnumCached	100	5,473.7805 ns	2401 B
CustomLargeEnumCached	100	5,571.3201 ns	2402 B
CustomEnumCached	100	6,463.1792 ns	2401 B
CustomSmallEnum	100	90,100.0065 ns	28026 B
CustomLargeEnum	100	93,418.7069 ns	28174 B
CustomEnum	100	94,719.9186 ns	27112 B
CustomEnumFrozenMap	1000	949.7209 ns	-
CustomSmallEnumFrozenMap	1000	955.7943 ns	-
CustomLargeEnumFrozenMap	1000	963.3053 ns	-
CustomLargeEnumMap	1000	3,266.3050 ns	-
CustomEnumMap	1000	3,267.1102 ns	-
CustomSmallEnumMap	1000	3,270.5155 ns	-
CustomSmallEnumCached	1000	56,106.7629 ns	24006 B
CustomLargeEnumCached	1000	57,870.7619 ns	24015 B
CustomEnumCached	1000	70,576.5613 ns	24010 B
CustomSmallEnum	1000	909,513.7370 ns	280254 B
CustomEnum	1000	921,044.2253 ns	271621 B
CustomLargeEnum	1000	925,368.7630 ns	281798 B
CustomLargeEnumFrozenMap	10000	9,240.9962 ns	-
CustomEnumFrozenMap	10000	9,243.3792 ns	-
CustomSmallEnumFrozenMap	10000	9,249.7069 ns	-
CustomSmallEnumMap	10000	32,852.3596 ns	-
CustomEnumMap	10000	32,912.0222 ns	-
CustomLargeEnumMap	10000	32,914.4958 ns	-
CustomLargeEnumCached	10000	554,776.4648 ns	240152 B
CustomSmallEnumCached	10000	559,146.3867 ns	240057 B
CustomEnumCached	10000	671,990.9701 ns	240102 B
CustomSmallEnum	10000	8,941,992.9688 ns	2802559 B
CustomEnum	10000	9,313,023.7981 ns	2716716 B
CustomLargeEnum	10000	9,354,293.2292 ns	2818074 B

Let's start with the Count = 1 scenario.

FrozenDictionary appears to be the fastest approach, with measured times in the sub-nanosecond range. However, results at this scale should be interpreted cautiously, as they are highly sensitive to JIT optimizations.

A standard Dictionary performs consistently at around ~4.5 ns per lookup, which is still extremely fast and effectively negligible in most applications.

Cached reflection shows a significant improvement over uncached reflection, reducing execution time from ~888 ns to ~55-65 ns per call. This demonstrates that caching eliminates the majority of reflection overhead.

Uncached reflection is by far the slowest approach, with roughly 15-16x higher latency compared to cached reflection and orders of magnitude slower than dictionary-based solutions.

In terms of memory allocations:

Dictionary-based approaches allocate no memory during lookup
Cached reflection allocates ~24 B per call. This is caused by boxing the enum value when using the Enum type. A zero-allocation alternative is possible using a generic constraint, but it results in a more verbose API:

public static TAttribute? GetCustomAttributeCached<TEnum, TAttribute>(this TEnum value) 
    where TEnum : struct, Enum 
    where TAttribute : Attribute

Uncached reflection allocates ~270-280 B per call

When scaling to higher Count values, the relative differences remain consistent. Execution time increases linearly for all approaches, but the absolute gap between them becomes more pronounced due to the higher per-call cost of reflection.

Finally, the size of the enum does not have a measurable impact on performance in this benchmark, which is expected given the constant-time nature of the underlying lookup mechanisms.

Summary

Dictionary-based solutions provide the best raw performance and avoid allocations during lookups, but require manual maintenance whenever enum values change. This could be avoided with source generators, which provide zero-reflection, zero-allocation, near-native performance. However, they introduce additional complexity and make debugging more difficult, which may be unnecessary for many scenarios.

Reflection is slower and introduces allocations, but when combined with caching, the performance cost becomes negligible for low-frequency operations. In many real-world scenarios, the improved maintainability outweighs the performance difference.

Reflection should therefore be avoided in hot paths but remains a practical and maintainable solution for metadata access.

Google Translate Who? The Only Translator You’ll Ever Need, Powered by Neural Networks & 90s Scams

Daniel Balcarek — Tue, 07 Apr 2026 12:30:30 +0000

This is a submission for the DEV April Fools Challenge

I don’t have much time right now because “summer is coming” in our timezone, but I just can’t miss this challenge!

What happens when you treat an absolutely ridiculous idea with enterprise-level seriousness?

For the DEV April Fools Challenge, I built an app that nobody asked for, but implemented as if it were a mission-critical production system.

Please review it with the level of seriousness it absolutely does not deserve.

What I Built

Everyone knows Google Translate so I made a direct competitor.

It’s the best translator in the whole world! Not just text translation, but also speech-to-text and text-to-speech. It can translate into vending machine, borked regex, yoda style and many more.

Just try it below, but beware of classic 90s internet scams and don’t waste your precious tokens. Remember, premium tokens are extremely limited.

And if you want to translate something, forget pressing Enter. This translator reacts only to the Scroll Lock or Insert keys.

But translation is only the beginning of my innovation journey.

Need the current time in a random timezone measured in microseconds?
Of course you do.

Still not enough productivity? The app also includes carefully preserved cheats for classic 90s games, because documentation is temporary, cheat codes are forever.

And for maximum workplace efficiency, an evil paperclip assistant is always ready to help whether you want it or not.

I tested adding more features, but things escalated quickly.

There’s also a “Works on My Machine” button.
I don’t fully understand what it does, but it increases developer confidence by 841.347%.

But true innovation isn’t measured by features, it’s measured by recognition.
That’s why the app includes a completely serious achievement system called Definitely Not Dev Badges™. These badges are awarded for outstanding professionalism and each automatically increases your seniority!

Wanna spread the chaos? Use the buttons, they format your text for maximum professionalism.

Finally, I strongly recommend not using Ctrl+V, previous tests resulted in a catastrophe.

After all this innovation, there’s only one thing left to say.

As viewers in Central and Eastern Europe might remember from TV salesman Horst Fuchs — famous for enthusiastic 90s infomercials:

“And that’s worth it!”

Demo

Unicorm Resource Locator: absurd-text-transformer

Code

Gramli / text-transformer

🦄 Absurd Text Transformer

A chaotic, feature-packed text transformer built for maximum nonsense. Transform your boring text into Yoda-speak, Brainrot, Zalgo corruption, Corporate Synergy, Pirate lingo, and many more absurd formats — complete with Text-to-Speech, voice dictation, cursor trails, an evil floating Clippy, and 90s cheat codes.

Built for the DEV April Fools Challenge 🎉

What It Does

The Absurd Text Transformer takes normal text and ruins it — beautifully. It offers 17 transformation modes, each with a distinct personality, unique theme, and its own TTS voice settings.

Transformation Modes

Mode	Description
🤡 Silly English	Randomized caps, emoji spam, shuffled words
🌠 Yoda Style	Sentence structure reversed, Jedi-style
🏴‍☠️ Pirate	Ahoy! Full pirate vocabulary substitution
👶 Baby Talk	Uwu-fied cute baby babble
🐱 Cat	Pure meow-based communication
🐶 Dog	Woof enthusiastically repeated
🐹 Hamster	Squeak-inflected vocabulary chaos
🦆 Duck	Quack, quack, quack
🐄 Cow	Moo. Just moo.
🎰 Vending

…

View on GitHub

How I Built It

The translator is powered by a highly advanced neural network trained on archived forum posts, expired trial software popups, and suspicious email chains from 1998–2003.

Early benchmarks show it performs 300% worse than existing solutions, which confirms we are innovating in the right direction.

After months of research, optimization, and absolutely no investor funding, the final architecture emerged.

Behind all this groundbreaking technology lies a shocking truth:

It’s just Svelte running on Google Cloud Run.

Prize Category

I want to be the very best
Like no one ever was
To catch them is my real test
To train them is my cause

"Community Favorite, I choose you!"

Exit(0)

Remember: if the translation looks wrong, the problem is probably between keyboard and chair.

Happy DEV April Fools Challenge

Clean Unit Testing in .NET: Practical xUnit and Moq Tips

Daniel Balcarek — Tue, 31 Mar 2026 14:12:24 +0000

When writing unit tests in .NET, the basics are easy to learn. Frameworks like xUnit and Moq make it straightforward to create tests, mock dependencies and verify behavior. The real challenges appear later, when you start testing real production code.

Sooner or later, you run into practical questions that documentation rarely answers clearly:

What is the cleanest way to configure IOptions<T> in unit tests?
How can you test internal classes without making them public?
How do you verify ILogger calls using Moq without verbose boilerplate?
How can you test ILogger calls without Moq at all?
How do you log output in xUnit tests?
How can you keep [Theory] tests type-safe?
How can you assert objects created internally using Moq .Callback?

These are not complex architectural problems, just practical issues that appear repeatedly in real projects.

This article shows practical unit testing tips and tricks for .NET developers, helping you write cleaner, more maintainable tests with xUnit and Moq.

How to use IOptions in Unit Tests (Without Mocking)

Avoids unnecessary mocking and keeps your tests simple, type-safe, and easy to configure.

Many developers try to use new Mock<IOptions<T>>(), but that's unnecessary overhead. The Microsoft.Extensions.Options library provides a built-in helper specifically for this. You can simply use the Create extension method from the Microsoft.Extensions.Options.Options class to easily generate the required options object instead.

private readonly IOptions<DistributedLockOptions> _options;

// ...

_options = Microsoft.Extensions.Options.Options.Create(new DistributedLockOptions
{
    // configure properties
});

Make Internals Visible to Test Projects via .csproj

Enables testing internal logic without exposing implementation details publicly, keeping your code encapsulated.

You shouldn't make a class public just to test it. You can keep your logic internal and still grant your test project access by adding a simple attribute to your source project's .csproj file.

    <ItemGroup>
        <AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleToAttribute">
            <_Parameter1>Your.Test.Project.Name</_Parameter1>
        </AssemblyAttribute>
    </ItemGroup>

Example

File.Core.csproj:

    <ItemGroup>
        <AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleToAttribute">
            <_Parameter1>File.Core.UnitTests</_Parameter1>
        </AssemblyAttribute>
    </ItemGroup>

Note: Alternatively, you can place [assembly: InternalsVisibleTo("Your.Test.Project")] in an AssemblyInfo.cs file (or any source file). This approach is common in older .NET Framework projects. In SDK-style projects, configuring the attribute in the .csproj file avoids introducing an additional file and keeps assembly configuration centralized.

In this example, File.Core.UnitTests is the destination test project name. See a project example here.

Mock ILogger with Moq: Simplify Log Verification

Simplifies verifying logs in tests, reducing boilerplate and making assertions readable and maintainable.

Mocking ILogger<T> is notoriously difficult because the commonly used methods like LogInformation() or LogError() are extension methods, Moq cannot intercept those directly. You must verify calls against the underlying interface method Log<TState>(), which has a complex generic signature.

Here is a useful example of an extension class that simplifies verifying logger method calls:

using Microsoft.Extensions.Logging;
using Moq;

namespace Extensions
{
    public static class MoqLoggerExtensions
    {
        public static void VerifyLog<T>(this Mock<ILogger<T>> loggerMock, LogLevel logLevel, EventId eventId, string message, Times times)
        {
            loggerMock.Verify(
               x => x.Log(
                   It.Is<LogLevel>(y => y.Equals(logLevel)),
                   It.Is<EventId>(y => y.Equals(eventId)),
                   It.Is<It.IsAnyType>((o, _) => string.Equals(message, o.ToString(), StringComparison.InvariantCultureIgnoreCase)),
                   It.IsAny<Exception>(),
                   It.IsAny<Func<It.IsAnyType, Exception?, string>>()),
               times);
        }

        public static void VerifyLog<T>(this Mock<ILogger<T>> loggerMock, LogLevel logLevel, EventId eventId, Times times)
        {
            loggerMock.Verify(
               x => x.Log(
                   It.Is<LogLevel>(y => y.Equals(logLevel)),
                   It.Is<EventId>(y => y.Equals(eventId)),
                   It.IsAny<It.IsAnyType>(),
                   It.IsAny<Exception>(),
                   It.IsAny<Func<It.IsAnyType, Exception?, string>>()),
               times);
        }
    }
}

Example usage in a project.

Note: Prefer FakeLogger<T> for new projects targeting .NET 8+. Use the Moq approach when you're already using Moq throughout your test suite or need to target older .NET versions.

Test ILogger Without Moq Using FakeLogger

Removes the need for a mocking framework entirely when asserting log output, using a first-party in-memory logger built for testing.

Since .NET 8, the Microsoft.Extensions.Logging.Testing NuGet package ships a built-in FakeLogger<T> class designed specifically for unit tests. It collects all log records in memory, so you can assert on them directly without setting up any mocks or extension methods.

using Microsoft.Extensions.Logging.Testing;

var logger = new FakeLogger<OrderService>();
var service = new OrderService(logger);

service.ProcessOrder(orderId: 0);

Assert.Equal(1, logger.Collector.Count);
Assert.Equal(LogLevel.Warning, logger.Collector.LatestRecord.Level);
Assert.Contains("invalid order", logger.Collector.LatestRecord.Message, StringComparison.OrdinalIgnoreCase);

FakeLogger<T> exposes a Collector property (FakeLogCollector) that holds all captured records. Each FakeLogRecord gives you direct access to Level, Message, Exception, EventId, and more.

Example usage in a project.

How to Log in xUnit Tests using ITestOutputHelper

Ensures test logs are visible regardless of the test runner, improving debugging and test diagnostics.

In xUnit, Console.WriteLine won't show up in your Test Explorer or on some CI logs. You must use ITestOutputHelper to capture diagnostic data.

public class CalculatorTests
{
    private readonly ITestOutputHelper _output;

    public CalculatorTests(ITestOutputHelper output)
    {
        _output = output;
    }

    [Fact]
    public void Add_ShouldLogExecution()
    {
        _output.WriteLine("Starting addition test...");
        // Test logic goes here
    }
}

Example usage in a project.

Type-Safe [MemberData] using TheoryData

Preserves type safety in parameterized tests, preventing runtime errors and improving code readability.

Using IEnumerable<object[]> for parameterized tests is error-prone. xUnit provides TheoryData<...>, which provides compile-time safety for your test parameters.

public static TheoryData<int, string, bool> ValidScenarios => new()
{
    { 1, "Active", true },
    { 2, "Pending", false },
    { 3, "Closed", false }
};

[Theory]
[MemberData(nameof(ValidScenarios))]
public void ShouldProcessStatus(int id, string status, bool isValid)
{
    // Type-safe parameters, no object[] casting required!
}

Example usage in a project.

Use .Callback to Assert Internal Objects

Allows you to inspect and assert on objects that are constructed inside the method under test and passed directly to a dependency.

Sometimes a method creates a complex object internally and passes it to a dependency. To verify that "hidden" object, use Moq's .Callback to capture it.

var mockRepo = new Mock<IUserRepository>();
User capturedUser = null;

mockRepo.Setup(x => x.Save(It.IsAny<User>()))
        .Callback<User>(user => capturedUser = user);

var service = new UserService(mockRepo.Object);
service.Register("test@test.com", "password");

// Now assert the internal state of the captured object
Assert.NotNull(capturedUser);
Assert.Equal("test@test.com", capturedUser.Email);

Note: .Callback is useful for observing internal interactions, but relying on it heavily may signal a design smell. Prefer designs where important results are observable through return values or public behavior rather than mock interception.

How Much AI-Generated Code Are We Actually Shipping to Production? My Reality So Far

Daniel Balcarek — Tue, 24 Mar 2026 12:37:29 +0000

Every day I see posts where people claim they barely code anymore or that in a few months most production code will be vibe-coded.

Not only on dev.to, but also on Reddit, X and LinkedIn.

My experience looks very different.

In hobby projects, maybe 75% of my code is AI-generated.
At work, I am still coding a lot, I think that there is like 25% code generated by AI.

Don’t get me wrong, AI has definitely changed how I work. Whether it’s a hobby project or a sprint at the office, my workflow isn't the same as it was a year ago. However, many of the current predictions still feel heavily 'AI-hyped' compared to the boots-on-the-ground reality of software engineering.

The difference becomes especially clear when comparing legacy systems with modern codebases.

Older Codebases

We maintain several older solutions built on .NET Framework. Honestly, some parts are a mess. I’ve cursed the original authors many times.

In these systems, I rarely use AI for new features because it simply isn’t very helpful.

The problems are familiar to anyone working with legacy software:

inconsistent architecture
missing context
hidden dependencies
business rules scattered across the codebase

Even developers who have worked on these systems for 10+ years are sometimes afraid to touch certain areas. In this environment, AI struggles because understanding the system matters more than generating syntax.

Newer Codebases

In newer projects that follow good standards and clearer architecture, AI becomes much more useful.

Here is where I actually use it regularly:

generating SQL (PostgreSQL functions, tables, indexes)
creating unit test drafts for backend and frontend
generating boilerplate code from prompts we keep inside the repository
discussing performance ideas or refactoring options

However, for complex business features, I still write most of the code myself. Many tasks are too domain-specific to describe well in a prompt.

My Question to the Community

I’m interested in how AI is used in production environments, not demos or hobby projects, but daily engineering work.

Which AI coding assistant do you use most often? Do you combine multiple tools?
Roughly how much of your production code is AI-generated?
Does AI help equally in legacy and modern codebases for you?

Maybe I’m behind the trend or maybe real-world usage simply looks different from online predictions.

Node.js Dependency & Version Management with nvm, npm ci and Registries

Daniel Balcarek — Wed, 18 Mar 2026 14:44:28 +0000

Working with multiple Node.js projects often means switching between different Node versions, reinstalling dependencies and remembering various nvm and npm commands. This becomes especially painful when moving between legacy and modern codebases.

This article provides a practical overview of my most common Node.js workflow tasks: switching Node versions using nvm, cleaning and reinstalling dependencies and using the correct npm installation strategy for local development and CI/CD environments, and checking and updating dependencies regularly.

If you regularly jump between projects and forget the exact commands, this guide provides a simple, repeatable workflow you can reuse every day.

Switching to a Different Node Version
- Check the required version
- .nvmrc approach
Clean and Reinstall Dependencies
- Installation Strategy Comparison
- Reinstall with locked versions
- Full reinstall
- Corrupted npm Cache
Change registry
Checking and Updating Dependencies
- Check outdated packages
- Update dependencies
- Recommended workflow

Switching to a Different Node Version

First, determine which Node version the project requires.

Check the required version

package.json declares supported Node versions:

{
  "engines": {
    "node": ">=18"
  }
}

Use the terminal to verify which Node.js version is active locally:

node -v
# or
node --version

Once you know which version is required, list locally installed Node
versions:

nvm ls

If the required version is not installed locally:

nvm install <version>

Then switch to the desired version:

nvm use <version>

`.nvmrc` approach

Instead of manually checking the required Node version in package.json, you can define it using an .nvmrc file.

The file contains only the Node version:

18.19.0

Once the file exists, switching versions becomes simpler:

nvm use

Running nvm use inside a directory containing .nvmrc switches to the specified version. Automatic switching requires shell integration (e.g., zsh hooks or tools like avn).

`.nvmrc` vs `package.json`

package.json and .nvmrc solve related but different problems:

the engines field in package.json declares supported Node versions
.nvmrc allows nvm to automatically switch the runtime version

Using both helps keep development environments consistent across projects and teams.

Clean and Reinstall Dependencies

There are two main approaches to cleaning and reinstalling dependencies, depending on whether you want to preserve exact versions or update them:

Reinstall with locked versions – Reinstalls node_modules while keeping the exact versions specified in package-lock.json. This approach is recommended for teams and CI/CD environments, as it ensures reproducible builds.
Full reinstall – Removes node_modules and package-lock.json before reinstalling all dependencies. This is useful when performing major dependency upgrades or resolving inconsistencies in the dependency graph.

Before diving into the commands, here’s a quick table summarizing when to use each strategy:

Installation Strategy Comparison

Scenario	Command	Lockfile Behavior
Standard CI/CD Build	`npm ci`	Unchanged (strictly enforced)
Team Development	`npm ci`	Unchanged (strictly enforced)
Maintenance / Updates	`npm install`	Updates within semver; rewrites lockfile
Full Reset	`rm -rf node_modules package-lock.json && npm install`	Fully regenerated

Reinstall with locked versions

This approach is preferred for teams and CI/CD pipelines because it preserves exact dependency versions:

npm ci

Why `npm ci`?

installs exact versions from package-lock.json
produces reproducible builds
faster and deterministic installs
preferred for teams and CI environments
removes node_modules

Note npm ci fails if package.json and package-lock.json are out of sync, preventing accidental dependency drift.

Full reinstall

Full reinstall is useful when performing major dependency upgrades, switching Node versions or resolving dependency graph inconsistencies.

# Unix/Bash
rm -rf node_modules && rm package-lock.json && npm i

To completely reinstall dependencies, remove node_modules and package-lock.json, then run npm install. This regenerates package-lock.json, so review the changes carefully before committing them to Git to keep dependencies consistent across the team and CI environments.

In team settings, avoid deleting package-lock.json casually, as it updates the entire dependency graph for everyone working on the project.

`rm -rf node_modules`

Removes the node_modules directory recursively.

Why delete `node_modules`?

It may contain:

corrupted installs
incompatible binaries
dependency conflicts
leftover versions after upgrades
OS‑specific builds

Removing it forces a clean rebuild.

`rm package-lock.json`

Deletes the lock file and forces a fresh dependency resolution.

Why remove it?

recompute dependency versions
resolve a new dependency graph
potentially upgrade sub-dependencies

Note: Deleting package-lock.json triggers a "fresh" resolution of all sub-dependencies. Only do this if you intend to update your entire dependency tree.

`npm i` (`npm install`)

This command:

reads package.json
resolves dependencies
downloads packages
creates a new node_modules directory
generates a new package-lock.json

Corrupted npm Cache

In rare cases, npm installs may fail due to a corrupted local cache. Typical symptoms include integrity errors, failed package extraction, or repeated installation failures.

Verify the cache (recommended first step)

npm cache verify

This checks the cache integrity and removes invalid entries automatically.

Clean the cache

If problems persist, you can clear the npm cache:

npm cache clean --force

The --force flag is required because npm protects the cache by default. After cleaning the cache, run npm install again to rebuild dependencies.

Note Clearing the cache is rarely necessary and should only be used when troubleshooting installation issues. The npm cache is stored in ~/.npm (Linux/macOS) or %AppData%/npm-cache (Windows).
In modern npm versions (v7+), cache corruption is uncommon because npm performs strict integrity verification and automatically removes invalid cache entries.

Change registry

In some environments especially when working with private packages or company infrastructure, you may need to configure npm to use a custom registry. This is typically done once when setting up a development machine.

Log in to a registry

Authenticate against a custom registry:

npm login --registry=<registry-url> --auth-type=web

This stores authentication credentials (usually as an auth token) in your local npm configuration.

Set the default registry

Configure npm to use a specific registry by default:

npm config set registry <registry-url>

This updates your user-level npm configuration.

You can verify the current registry with:

npm config get registry

Show current npm configuration

Display the active npm configuration:

npm config list

This shows configuration values from all scopes (global, user, and project).

Note Some projects define a registry inside a project-level .npmrc, which overrides global settings.

Checking and Updating Dependencies

Even with deterministic installs (npm ci) and controlled Node.js versions (nvm), dependencies should be checked and updated regularly. npm provides simple commands for this.

Check outdated packages

npm outdated

Example output:

Package   Current   Wanted   Latest
express   4.18.1    4.18.3   5.0.0

Current — installed version
Wanted — newest version allowed by package.json (safe update)
Latest — newest published version (may contain breaking changes)

Update dependencies

npm update

This updates packages within the semver range defined in package.json, applying patches and minor updates without upgrading to breaking major versions. It also regenerates package-lock.json to reflect the new resolved versions.

Update a single package:

npm update express

Recommended workflow

npm outdated
npm update
npm ci
npm test

This keeps dependencies up to date while maintaining reproducible builds.

Echoes of Experience: Don’t Be "Too Senior" to Ask

Daniel Balcarek — Wed, 11 Mar 2026 16:51:21 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

As a junior developer, I was afraid to ask questions.
As a senior developer, I stopped questioning the obvious.

Both mistakes cost me more hours, sometimes days than I care to admit.

One lesson I had to learn the hard way is this: ask the “stupid” questions. Yes, you read that right.

For most of my career, I hesitated to ask questions that felt too obvious. I didn’t want to look inexperienced, so sometimes I pretended I understood a topic or stayed quiet during discussions.

Today, I see it differently. In most cases, it’s far better to ask. A single question can reveal hidden assumptions, prevent future production problems, or even lead to a better solution.

Over the years, three particular experiences have stayed with me, each reinforcing this lesson in its own way:

Is the Server Running?

It was a long time ago (Back when Windows XP was refusing to die in corporate offices). I was a university student when I got my first job as a junior C# developer. Most of my work involved creating new controls for WinForms applications.

One day my mentor, a senior C# developer in the company, gave me a new task. I needed to connect our application to an internal service using WCF. I received the connection details and was told that the service was already running.

The first thing I did was check the address in the browser. Normally, a WCF service shows a metadata page or some information confirming that the service is alive. But this time I didn’t see anything like that.

Still, my mentor said the service was running, so I assumed I must be doing something wrong. I didn’t want to bother him with what I thought might be a stupid question.

So I started implementing the client code. When I tried to call the service, I got an error.

Hmm… what went wrong?

I changed the configuration slightly and tried again.

Same error.

I adjusted the implementation.

Same error again.

This went on for three days. I kept experimenting with configuration, bindings, and client code, but nothing worked. Eventually, I even asked one of my university professors to look at the code with me. After reviewing it, he said the code looked fine.

Then he asked a simple question:

“Is the server actually running?”

After that, I finally emailed my mentor.

His reply was short:

“No, it actually isn’t running.”

If I had simply asked that “stupid” question at the beginning, I could have saved three days of work.

It Was Just HTTP

At that time, I was a senior developer in a mid-sized company, maintaining backend APIs and the administration system used across the company.

One day I received what seemed like a simple task: connect to a new external service and build an administration interface for it. We used Azure as our identity provider, so I first implemented the code to obtain an access token and then added the client code to call the service.

When everything was ready, I started debugging.

Authentication error.

Hmm… what did I do wrong?

I stopped the debugger, reviewed the code, and tried again.

Same authentication error.

I checked logs, tracing, configuration, and infrastructure settings. Everything looked correct. After a few hours of debugging, I asked another senior developer for help. He reviewed the code but didn’t see any problem either. Together we spent another hour searching for the root cause, still nothing.

The next day, another senior joined us. Three experienced developers were now standing in front of my screen, brainstorming possible causes.

While we were discussing authentication flows and token validation, one of our junior developers walked by, glanced at the screen, and casually asked:

“Why are you using HTTP instead of HTTPS?”

That question hit instantly.

Three senior developers analyzing authentication and security were stopped by a junior who simply noticed the protocol in the URL, revealing how our experience had made us blind to the simplest explanation.

Changing http to https fixed the problem immediately.

If we had asked that simple question earlier and checked the configuration properly, we could have saved hours of work.

Performance

This happened recently while I was working as a Senior Engineer in a corporate environment, developing a large business application with several critical components.

One of those components was designed with a strong safety-first approach. It was reliable and almost bulletproof, but also very slow. We were already preparing major architectural changes for the next major release, but we also needed a significant performance improvement for an upcoming minor version.

I started by proposing safe optimizations that wouldn’t risk breaking existing logic: adding database indexes, introducing bulk operations, and improving several inefficient parts of the process. After implementation, the performance improved by about one third, but our goal was at least three times faster.

We discussed the problem repeatedly with other senior engineers, brainstorming new optimizations. Every idea helped a little, but none came close to the required performance target.

While we were discussing this in our open office, one of our business analysts a non-technical colleague joined the conversation and asked a simple question:

“Do you really need to modify the existing process?”

That question changed everything.

Instead of optimizing the old logic further, I realized we could create a completely separate processing flow: new code designed purely for bulk execution, running independently. If anything failed, we could simply roll back the transaction and fall back to the original safe process.

The result was fast, safe, and significantly simpler than what we had been trying to achieve.

A non-technical colleague, just by listening to our discussion, helped us find the breakthrough we had been missing.

The Lesson Behind the Stories

Looking back, these situations happened at very different stages of my career, as a junior developer, as a senior engineer and while working with experienced teams on complex systems. Yet the lesson was always the same.

In the first story, I was afraid to ask a question because I didn’t want to look inexperienced. In the second, several senior developers overlooked a simple detail because we assumed the complex parts must be wrong. In the third, we were so focused on improving the existing solution that it took a non-technical perspective to help us rethink the problem entirely.

Experience teaches us how to solve difficult problems, but it can also make us blind to simple questions.

Explaining a problem out loud, asking something that feels obvious, or inviting someone outside the technical context into the discussion often reveals what hours of debugging cannot.

Sometimes the most valuable question in the room is the one that sounds the simplest.

So today, I ask sooner. I discuss more. I never underestimate the power of the obvious, because usually, the “stupid” question is the only thing standing between you and the solution.

What’s the Worst Advice AI Has Given You? Here’s Mine.

Daniel Balcarek — Wed, 04 Mar 2026 15:02:08 +0000

I recently saw a meme about terrible legacy code on platform X and it gave me an idea for a discussion topic.

A year ago, the classic developer question was:

“What’s the worst code you’ve ever seen?”

But our day-to-day work has changed. Maybe the real question now is:

“What is the worst suggestion AI has ever given you?”

I’ll start.

I’ve happily survived plenty of questionable code: from “fast hotfixes” that didn’t even touch the root cause, to refactorings that added more complexity than my 15-years-younger self on OOP steroids.

But this happened about a year ago and it still sticks in my mind:

API key in a public Docker image

I was working on a GitHub Action that builds a Docker image from my .NET REST API, pushes it to Docker Hub as a public image and then deploys it to Azure. Pretty straightforward, right?

There was one small catch: the API uses a private API key to communicate with a third-party service.

So I asked ChatGPT for advice.

Its suggestion:

“You can store this API key as an environment variable in your Docker image.”

Wait… what?

Put a private API key inside a public Docker image?

To be clear, environment variables themselves are fine.
The problem was baking the secret into the image during build time, which would expose it to anyone pulling or inspecting the public image.

I explained this to ChatGPT.

It responded with the classic:

“You are right!”

…and suggested storing it securely in Azure.

End of the story?

Of course not.

Just a few messages later, in the same context window, ChatGPT again suggested putting the private API key into the public Docker image as an environment variable.

That was the moment I realized:

AI isn’t production-ready yet, at least for security advice. 😄

The interesting shift

We used to review junior developers’ code carefully.

Now we also need to review code written by something that sounds like a senior engineer but occasionally behaves like an intern on their first day.

Discussion

What’s the most ridiculous suggestion AI or ChatGPT has ever given you?
Do you review AI-generated code differently than human-written code?

I’d love to hear real examples from the community.

.NET: CopyToAsync vs WriteAsync: The Benchmark You Didn’t Know You Needed

Daniel Balcarek — Mon, 02 Mar 2026 12:31:27 +0000

I had a task where one small part involved writing a byte array to a MemoryStream.

Since this was a trivial task, I let Copilot generate the code. But Copilot used CopyToAsync instead of WriteAsync.

That raised a question, so I asked why.

It kept trying to convince me that CopyToAsync was a better fit for this scenario (a 1 MB file), and I quote:

CopyToAsync might offer better performance due to its internal optimizations for copying data between streams. The performance difference between these two approaches can be minimal for small to moderately sized data.

According to Copilot:

Small to medium data: 12 KB – 32 KB
Large data: 5 MB – 10 MB

But here’s the important detail:

I wasn’t copying between two independent streams.
I already had a byte array in memory.

In that case, wrapping it in a MemoryStream just to call CopyToAsync adds an extra abstraction layer. So I was skeptical.

Copilot was confident.
I was suspicious.

As a responsible developer, I couldn’t sleep until I proved my point.

So I wrote a benchmark.

The Benchmark

BenchmarkDotNet v0.15.8, Windows 10 (10.0.19045.6466/22H2/2022Update)
Intel Core i5-6400 CPU 2.70GHz (Skylake), 1 CPU, 4 logical and 4 physical cores
.NET SDK 10.0.102
  [Host]    : .NET 10.0.2 (10.0.2, 10.0.225.61305), X64 RyuJIT x86-64-v3
  .NET 10.0 : .NET 10.0.2 (10.0.2, 10.0.225.61305), X64 RyuJIT x86-64-v3

Job=.NET 10.0  Runtime=.NET 10.0

I tested four methods:

MemoryStream.CopyToAsync
MemoryStream.CopyTo
MemoryStream.WriteAsync
MemoryStream.Write

Across file sizes:

12 KB
32 KB
5 MB
10 MB
25 MB
50 MB

The Code

The benchmark uses BenchmarkDotNet and tests copying from a byte array into a MemoryStream.

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Jobs;

namespace GeneralBenchmark.CopyToAndWrite
{
    [SimpleJob(RuntimeMoniker.Net90)]
    [Orderer(BenchmarkDotNet.Order.SummaryOrderPolicy.Declared)]
    [MemoryDiagnoser]
    public class CopyToAndWriteBenchmark
    {
        public IEnumerable<CopyToAndWriteBenchmarkData> Data()
        {
            yield return new CopyToAndWriteBenchmarkData(1024 * 12);
            yield return new CopyToAndWriteBenchmarkData(1024 * 32);
            yield return new CopyToAndWriteBenchmarkData(1024 * 1024 * 5);
            yield return new CopyToAndWriteBenchmarkData(1024 * 1024 * 10);
            yield return new CopyToAndWriteBenchmarkData(1024 * 1024 * 25);
            yield return new CopyToAndWriteBenchmarkData(1024 * 1024 * 50);
        }


        [Benchmark]
        [ArgumentsSource(nameof(Data))]
        public async Task MemoryStream_CopyTo_Async(CopyToAndWriteBenchmarkData data)
        {
            using var outerStream = new MemoryStream();
            using var innerStream = new MemoryStream(data.ByteData);
            await innerStream.CopyToAsync(outerStream);
        }

        [Benchmark]
        [ArgumentsSource(nameof(Data))]
        public async Task ByteArray_Write_Async(CopyToAndWriteBenchmarkData data)
        {
            using var outerStream = new MemoryStream();
            await outerStream.WriteAsync(data.ByteData);
        }

        [Benchmark]
        [ArgumentsSource(nameof(Data))]
        public void MemoryStream_CopyTo(CopyToAndWriteBenchmarkData data)
        {
            using var outerStream = new MemoryStream();
            using var innerStream = new MemoryStream(data.ByteData);
            innerStream.CopyTo(outerStream);

        }

        [Benchmark]
        [ArgumentsSource(nameof(Data))]
        public void ByteArray_Write(CopyToAndWriteBenchmarkData data)
        {
            using var outerStream = new MemoryStream();
            outerStream.Write(data.ByteData);
        }
    }
}

Link To Code

The Results

Method	data	Mean	Allocated
MemoryStream_CopyTo_Async	12 KB	951.9 ns	12.15 KB
ByteArray_Write_Async	12 KB	916.6 ns	12.09 KB
MemoryStream_CopyTo	12 KB	905.7 ns	12.15 KB
ByteArray_Write	12 KB	891.1 ns	12.09 KB
MemoryStream_CopyTo_Async	32 KB	2,535.8 ns	32.15 KB
ByteArray_Write_Async	32 KB	2,511.8 ns	32.09 KB
MemoryStream_CopyTo	32 KB	2,456.8 ns	32.15 KB
ByteArray_Write	32 KB	2,461.5 ns	32.09 KB
MemoryStream_CopyTo_Async	5120 KB	1,820,022.6 ns	5120.27 KB
ByteArray_Write_Async	5120 KB	1,826,398.4 ns	5120.21 KB
MemoryStream_CopyTo	5120 KB	1,819,132.4 ns	5120.27 KB
ByteArray_Write	5120 KB	1,807,830.4 ns	5120.21 KB
MemoryStream_CopyTo_Async	10240 KB	3,588,365.1 ns	10240.27 KB
ByteArray_Write_Async	10240 KB	3,545,750.1 ns	10240.21 KB
MemoryStream_CopyTo	10240 KB	3,528,154.4 ns	10240.27 KB
ByteArray_Write	10240 KB	3,530,808.4 ns	10240.21 KB
MemoryStream_CopyTo_Async	25600 KB	8,796,565.6 ns	25600.26 KB
ByteArray_Write_Async	25600 KB	8,808,362.9 ns	25600.2 KB
MemoryStream_CopyTo	25600 KB	8,815,669.9 ns	25600.26 KB
ByteArray_Write	25600 KB	8,787,913.1 ns	25600.2 KB
MemoryStream_CopyTo_Async	51200 KB	8,704,199.7 ns	51200.26 KB
ByteArray_Write_Async	51200 KB	8,718,245.6 ns	51200.2 KB
MemoryStream_CopyTo	51200 KB	8,738,011.5 ns	51200.26 KB
ByteArray_Write	51200 KB	8,721,815.7 ns	51200.2 KB

The difference? Statistically negligible for both mean execution time and allocations.
Write avoids creating the extra MemoryStream wrapper, but the practical impact remains minimal even at 50 MB.

This doesn’t mean CopyTo is bad. It’s the correct API to use when copying between two arbitrary streams.

But it is not “magically faster.”

In fact, when your source is already a byte array, Write is:

Simpler
More direct
Semantically correct

The Real Lesson

Yeah, I put all this effort into investigating a single line of abstraction suggested by Copilot and even wrote a post about it. But this wasn’t about proving Copilot wrong, it was about something more important:

AI suggestions are hypotheses, not conclusions. Measure when it matters. Trust evidence over assumptions.

If you already have the buffer, use the buffer API.

The right choice depends on the scenario, not on AI suggestions about “internal optimizations.”

And yes… now I can sleep.

Clean Architecture in .NET: Real-World Pros, Cons and Trade-offs

Daniel Balcarek — Tue, 24 Feb 2026 13:15:34 +0000

I have experience with Clean Architecture across multiple projects, both when creating new applications and when maintaining existing ones. Based on this experience, I decided to write about the pros and cons of using Clean Architecture, focusing on real-world examples rather than repeating the same theoretical descriptions found in many articles on this topic.

Pros
- UI, Framework, and Database Independence
- Highly Testable
- Maintainability and Extensibility
- Clear Boundaries
- Scalability
Cons
- Understanding and Complexity
- Heavy Structure
- Performance
- Initial Setup Time
- Data Model Duplication
Conclusion

Pros

The advantages of Clean Architecture go beyond theoretical principles. In practice, it improves maintainability, testability, and scalability, especially in applications with complex business logic. The following sections highlight real-world examples of how these benefits are realized in day-to-day development.

UI/Framework/Database Independence

Business logic is kept at the core, enabling external frameworks and databases to be changed with minimal disruption.

Many articles mention this advantage, but I think the common explanation is misleading. How often do you actually change the database, framework, or UI? Sure, the Core is independent of these layers, so in theory you could change them, but the real advantage is more specific:

Thanks to the Infrastructure layer and abstractions, you can easily replace an external library or switch to a different external service without touching the Core, because the implementation is hidden behind an abstraction and resides in the Infrastructure layer.

Independence in Practice

We had a requirement to read Excel files, so we chose a library and implemented the feature.

Later, the requirements changed and we needed to support password protected Excel files, which our original library could not handle.

Because we followed Clean Architecture, the Excel library was used only in the Infrastructure layer. We were able to replace the library by updating that layer only, while the business logic in the Core layer remained unchanged.

Highly Testable

Business logic in Clean Architecture is isolated from external concerns, making unit testing easy and straightforward.

This benefit is straightforward and one of the strongest advantages of Clean Architecture. Thanks to separation of concerns and extensive use of abstractions you can easily mock and test every layer independently especially the Core layer.

Highly Testable In practice

This unit test demonstrates how Clean Architecture makes the system easy to test in isolation.

The request handler lives in the Core layer, because in a REST API the core application logic is implemented in request handlers and business services.

The handler depends only on abstractions:

IRequestValidator<T>
IWeatherService

Because these are interfaces, we can mock all dependencies in the test and fully control their behavior.

Although implementation of IWeatherService belongs to the Infrastructure layer and calls an external weather API, the handler does not depend on any HTTP client or third-party library directly. Thanks to this abstraction, the handler can be tested without making real HTTP calls.

As a result:

The test is fast
The test is deterministic
All success and failure scenarios can be covered easily

public class GetCurrentWeatherHandlerTests
{
    private readonly Mock<IRequestValidator<GetCurrentWeatherQuery>> _getCurrentWeatherQueryValidatorMock;
    private readonly Mock<IRequestValidator<CurrentWeatherDto>> _currentWeatherValidatorMock;
    private readonly Mock<IWeatherService> _weatherServiceMock;

    private readonly IStatusRequestHandler<CurrentWeatherDto, GetCurrentWeatherQuery> _uut;

    public GetCurrentWeatherHandlerTests()
    {
        _getCurrentWeatherQueryValidatorMock = new();
        _currentWeatherValidatorMock = new();
        _weatherServiceMock = new();

        _uut = new GetCurrentWeatherHandler(
            _getCurrentWeatherQueryValidatorMock.Object, 
            _currentWeatherValidatorMock.Object, 
            _weatherServiceMock.Object, 
            _loggerMock.Object);
    }

    [Fact]
    public async Task Success()
    {
        //Arrange
        var getCurrentWeatherQuery = new GetCurrentWeatherQuery(1, 1);
        var currentWeather = new CurrentWeatherDto();

        _getCurrentWeatherQueryValidatorMock.Setup(x => x.Validate(It.IsAny<GetCurrentWeatherQuery>())).Returns(new RequestValidationResult { IsValid = true });

        //Act
        var result = await _uut.HandleAsync(getCurrentWeatherQuery, CancellationToken.None);

        //Assert
        Assert.Equal(HandlerStatusCode.Success, result.StatusCode);
        _getCurrentWeatherQueryValidatorMock.Verify(x => x.Validate(It.Is<GetCurrentWeatherQuery>(y => y.Equals(getCurrentWeatherQuery))), Times.Once);
    }
}

Maintainability and Extensibility

Clean Architecture provides a clear structure that keeps changes isolated and predictable, improving maintainability and extensibility.

When Clean Architecture is followed together with SOLID principles each part of the system has one clear responsibility so when you are fixing a bug or implementing a new feature you are working in isolated part of the solution so you usually don’t break others.

Maintainability in practice

We had a bug related to user login.

Because responsibilities were clearly defined, we knew the issue belonged to the API layer, where the login endpoint and request handling logic live.

We were able to quickly locate the relevant code, fix the bug, and deploy the change without affecting other parts of the system.

Extensibility in practice

We needed to add a new endpoint for fetching data from the database.

Following Clean Architecture:

I added a new endpoint in the API layer
Created a new handler in the Core layer to handle the use case
Implemented a new query in the Infrastructure layer to access the database through a repository

No existing logic had to be modified, and the structure made it obvious where each piece of code belonged.

Clear Boundaries

Establishes well-defined boundaries between components, which helps teams divide work effectively.

Each part of the system has a clear responsibility and components communicate through well defined abstractions. As a result, critical changes in the Infrastructure layer do not necessarily impact the Core layer for example.

Clear Boundaries in practice

We were integrated with an external service that was part of a very old legacy system.

Over time, the team owning that service rewrote it using a new technology stack and the entire communication contract changed. As a result, we had to adapt our system to work with the new contract.

All of the changes were done in the Infrastructure layer, where integration and communication with the external service are handled.

The Core layer, which contains business rules and data processing logic, was not modified at all.

Scalability

Clean Architecture promotes scalability by keeping functionality modular, making it easier to adapt or extract parts of the system when necessary.

Clean Architecture’s modular structure and use of abstractions make it easier to extract parts of the system and scale them independently from the rest of the application.

Scalability in Practice

We were using a legacy library to generate large DOC, PDF, and Excel files, but it consumed a significant amount of memory and did not release resources properly. In some cases, we even had to call GC.Collect explicitly to avoid memory pressure.

To address this, we decided to move file generation into a separate microservice that encapsulates this library and handles document generation independently.

Thanks to Clean Architecture and its modular design, we were able to reuse the existing file generation code and move it into the new microservice without changing the Core layer.

Cons

While Clean Architecture offers many benefits, it is not without drawbacks. In reality, the added structure, abstractions and layer separations can introduce complexity, additional boilerplate and upfront development overhead. The next sections explore these challenges with concrete examples from real projects.

Understanding and Complexity

Understanding the architecture can be challenging, especially for developers or teams unfamiliar with it.

Deciding how to split responsibilities and assign code to the correct layer often requires experience and careful reasoning, not just following dependencies or namespaces.

Understanding in practice

Let’s look at the example below. All referenced dependencies implementations IDataCommandRepository and IAuditLogger come from the Infrastructure layer. Because of this, many developers might assume that DataService should also belong to the Infrastructure layer.

However, this class actually contains business logic:

It decides how data would be updated (setting State)
It applies business rules (ignoring empty input)
It coordinates persistence and auditing as part of a business operation

For these reasons, DataService belongs in the Core layer, even though it depends on abstractions that are implemented in Infrastructure layer.

This example highlights one of the main challenges of Clean Architecture: layer placement is determined by responsibility and intent. Understanding this distinction often takes time and experience.

internal sealed class DataService : IDataService
{
    private readonly IDataCommandRepository _dataCommandRepository;
    private readonly IAuditLogger _auditLogger;

    public async Task<Result> FinishDataSafeAsync(IReadOnlyCollection<int> dataIds, CancellationToken cancellationToken)
    {
        if(dataIds is null || !dataIds.Any())
        {
            return Result.Ok();
        }

        var updateCommands = dataIds.Select(x => new UpdateDataCommand{
            Id = x,
            State = DataState.Finish,
        });

        var updateResult = await _dataCommandRepository.UpdateDataSafeAsync(updateCommands, cancellationToken);

        if(updateResult.IsFailed)
        {
            return Result.Fail("Update data failed.").WithErrors(updateResult.Errors);
        }

        _auditLogger.Log(updateCommands);

        return Result.Ok();
    }
}

Heavy Structure

Clean Architecture enforces a strict layered structure and extensive use of abstractions.

While this improves long-term maintainability, it also introduces significant boilerplate and ceremony, which can feel excessive for small or simple applications, especially basic CRUD based applications.

Heavy Structure in Practice

In Clean Architecture, even a simple CRUD operation often requires changes across multiple layers:

Creating an endpoint in the API layer
Implementing a handler or use case in the Core layer
Adding a repository method in the Infrastructure layer

Now imagine that the controller, Minimal API file or repository class does not exist yet, you first have to create all of them before implementing the actual functionality.

On top of that, if you enforce code coverage standards, you also need to write unit tests for these components.

As a result, a very simple CRUD operation can require a large amount of code and setup, which may feel unnecessarily heavy for straightforward use cases.

Performance

The layered structure and extensive use of abstractions may cause minor performance overhead compared to simpler, more direct architectures.

The additional layers of abstraction in Clean Architecture can introduce slight performance overhead due to increased indirection and mapping between layers. While this is rarely an issue for most business applications, performance critical systems may require careful optimization.

Performance in Practice

Let’s look at a performance critical CRUD endpoint in a .NET application.

For every request, a deep call stack is executed involving multiple allocations:

The RequestHandler resolves IValidator and IRepository.
The Repository resolves IConnectionProvider and IMapper.
Data is mapped from DataEntity (Infrastructure) to Data (Core).

Each step is small, but collectively they introduce extra allocations, method calls, and indirection compared to a more direct approach. In high-throughput scenarios, this additional overhead can become noticeable under load.

internal sealed class RequestHandler : IRequestHandler
{
    private readonly IValidator _validator;
    private readonly IRepository _repository;

    public RequestHandler(IValidator validator, IRepository repository)
    {
        _validator = validator;
        _repository = repository;
    }

    public async Task<Result<IEnumerable<Data>>> HandleAsync(
        Request request, 
        CancellationToken cancellationToken)
    {
        if (!_validator.IsValid(request))
        {
            return Result.Fail("Invalid request");
        }

        return await _repository.GetDataSafeAsync(request, cancellationToken);
    }
}

internal sealed class Repository : IRepository
{
    private readonly IConnectionProvider _provider;
    private readonly IMapper _mapper;

    public Repository(IConnectionProvider provider, IMapper mapper)
    {
        _provider = provider;
        _mapper = mapper;
    }

    public async Task<Result<IEnumerable<Data>>> GetDataSafeAsync(
        Request request, 
        CancellationToken cancellationToken)
    {
        try
        {
            using var connection = _provider.GetOpenedConnection();
            var data = await connection.ExecuteQueryAsync<DataEntity>(...);
            return Result.Ok(_mapper.Map<Data>(data));
        }
        catch (DbException)
        {
            return Result.Fail("Database command failed");
        }
    }
}

NOTE: In practice, this downside is arguably negligible for 99% of business applications. For most I/O bound web APIs, database latency far outweighs the cost of a few extra interface allocations.

Initial Setup Time

Clean Architecture requires a significant upfront investment in structure, abstractions, and conventions

Before delivering visible features, teams must define layers, interfaces, dependency rules and project organization, which can slow down early development, especially for greenfield projects.

Initial Setup Time in practice

We started a greenfield application with heavy business logic and the initial development phase was noticeably slow. Every new feature required creating a full structure: Minimal API endpoints, application handlers, business services, repositories and external proxy services.

Because these were new features, we had to introduce new abstractions and classes for almost every layer. Additionally, to maintain a minimal level of quality, we implemented unit tests for each component.

As a result, progress in the early stages felt slow, even though the architecture paid off later as the system grew.

Data Model Duplication

Strict separation of concerns often leads to duplicating similar data structures across layers, increasing the maintenance burden.

To keep the Core layer independent of the Database and the UI, you normally cannot use the same class for all three. This forces you to create separate classes for Database Entities, Domain Models, and API DTOs, even if they look almost identical.

Duplication in Practice

In a previous project, we had a User object. To follow Clean Architecture strictness, we had:

UserEntity (Infrastructure for fetching data from the database)
User (Core, rich domain model)
UserDto (API, exposed to clients)

Every time we added a new field like PhoneNumber, we had to:

Add it to all three classes.
Update the mapper from Infrastructure to Core.
Update the mapper from Core to API.

This "mapping tax" consumed a lot of development time for fields that were just being passed through the system without valid business logic. However, this does not apply to all cases, in many scenarios only UserEntity and UserDto are sufficient.

Conclusion

Clean Architecture is not a silver bullet, and it shouldn't be the default choice for every single project.

If you are building a small operational tool, a POC or a simple CRUD application, the overhead of Clean Architecture will likely slow you down without providing much value. In these cases, a simpler approach like Vertical Slice Architecture or a straightforward layered monolith is often a better fit.

However, for complex, long-lived enterprise systems where business rules change frequently and technology needs to evolve, Clean Architecture is an invaluable investment. The initial cost of setup and boilerplate pays dividends in the form of a system that is testable, adaptable, and resistant to rot over time.

The key is to understand the trade-offs. Don't adopt it blindly because it's popular, adopt it when your problem domain is complex enough to warrant the solution.

Angular: HTTP Caching with RxJS shareReplay

Daniel Balcarek — Mon, 16 Feb 2026 13:08:56 +0000

At some point in every Angular application repeated HTTP calls start to hurt, slower page loads, unnecessary backend load, and wasted network traffic.

The obvious solution is caching. But in Angular, caching is not just about storing data, it’s about managing observables correctly.

Done wrong, it leads to duplicate requests, stale data, or permanently cached errors. Done right, it eliminates redundant calls entirely.

A Naive Caching Approach

The simplest way to cache data in Angular, without knowing much about RxJS, is to use a field in a service class:

@Injectable({
  providedIn: 'root',
})
export class AppService {
  private vehiclesDataCache: VehiclesApiResponse | null = null;

  constructor(private http: HttpClient) {}

  public getVehiclesData(): Observable<VehiclesApiResponse> {
    if (this.vehiclesDataCache) {
      return of(this.vehiclesDataCache);
    }

    const observable = this.http.get<VehiclesApiResponse>(
      'https://starwars-databank-server.vercel.app/api/v1/vehicles',
    );
    observable.subscribe((response: VehiclesApiResponse) => {
      this.vehiclesDataCache = response;
    });
    return observable;
  }
}

Although this solution works, it is not very elegant and has several problems:

If getVehiclesData() is called multiple times before the first request completes, each call triggers a new HTTP request instead of sharing the in-flight one.
The code subscribes manually and never unsubscribes, which can lead to memory leaks.

A Better Solution: shareReplay

Angular applications rely heavily on RxJS and RxJS provides a much cleaner solution: the shareReplay operator.

shareReplay is an RxJS operator designed to cache the latest emitted value from an observable so that multiple subscribers can share it without triggering multiple backend calls.

sharereplay - Share source and replay specified number of emissions on subscription.

This makes it ideal for caching relatively static data such as enums, configuration values, or reference data. Once the frontend has fetched this data, it doesn’t need to call the backend again on every page visit.

Basic Example:
The most basic use of shareReplay looks like this:

@Injectable({
  providedIn: 'root',
})
export class AppService {

  private vehiclesDataShareReplay$: Observable<VehiclesApiResponse> | null = null;

  constructor(private http: HttpClient) {}

  public getVehicleShareReplay(): Observable<VehiclesApiResponse> {
    if (!this.vehiclesDataShareReplay$) {
      this.vehiclesDataShareReplay$ = this.http
        .get<VehiclesApiResponse>('https://starwars-databank-server.vercel.app/api/v1/vehicles')
        .pipe(shareReplay(1));
    }
    return this.vehiclesDataShareReplay$;
  }
}

This caches the last emitted value (shareReplay(1)). The subscription to the source (HttpClient) remains active until the request completes. This is the most common pattern for caching HTTP requests in Angular services.

However, while this approach looks correct, it hides a subtle issue.

The "Cached Error" Problem

A common pitfall with shareReplay is that it also caches errors. If the HTTP request fails, every future subscriber will immediately receive the same error, and no new HTTP request will ever be made.

A typical solution is to use retry and catchError before shareReplay:

@Injectable({
  providedIn: 'root',
})
export class AppService {

  private vehiclesDataShareReplay$: Observable<VehiclesApiResponse> | null = null;

  constructor(private http: HttpClient) {}

  public getVehicleShareReplay(): Observable<VehiclesApiResponse> {
    if (!this.vehiclesDataShareReplay$) {
      this.vehiclesDataShareReplay$ = this.http
        .get<VehiclesApiResponse>('https://starwars-databank-server.vercel.app/api/v1/vehicles')
        .pipe(
          retry(2),
          catchError((error) => {
            this.vehiclesDataShareReplay$ = null;
            return throwError(() => error);
          }),
          shareReplay(1),
        );
    }
    return this.vehiclesDataShareReplay$;
  }
}

In this example, retry(2) means the request is attempted up to three times in total. If all attempts fail, catchError resets the cached observable before the error is replayed.

Cache with Refresh

The biggest limitation of shareReplay(1) is that the cached data can become stale. In some scenarios, you want to refresh the data while still benefiting from caching.

A common solution is the “cache with refresh” pattern using a BehaviorSubject and switchMap:

@Injectable({
  providedIn: 'root',
})
export class AppService {

  private vehiclesDataBehavior$: Observable<VehiclesApiResponse> | null = null;
  private refreshTrigger$ = new BehaviorSubject<void>(undefined);

  constructor(private http: HttpClient) {}

  public getVehicleBehavior(): Observable<VehiclesApiResponse> {
    // 1. Check if we already created this observable
    if (!this.vehiclesDataBehavior$) {
      // 2. Create the observable (only once)
      this.vehiclesDataBehavior$ = this.refreshTrigger$.pipe(
        // 3. Listen to refresh trigger
        switchMap(() =>
          // 4. When trigger fires, make HTTP request
          this.http
            .get<VehiclesApiResponse>('https://starwars-databank-server.vercel.app/api/v1/vehicles')
            .pipe(
              // 5. If request fails, retry 2 times
              retry(2),
              // 6. If still fails after retries, catch error
              catchError((error) => {
                console.error('Error fetching vehicles:', error);
                return EMPTY;
              }),
            ),
        ),
        // 7. Cache the most recent successful HTTP response and replay it to all current and future subscribers
        shareReplay(1),
      );
    }
    // 8. Return the cached observable
    return this.vehiclesDataBehavior$;
  }

  public refreshVehiclesBehavior(): void {
    // Trigger a new fetch by calling next() on the BehaviorSubject
    this.refreshTrigger$.next(undefined);
  }
}

In this example, the BehaviorSubject triggers an HTTP request whenever next() is called. The switchMap ensures that if a refresh is triggered while a request is still in flight, the previous request is canceled and replaced with a new one.

However, let’s take a closer look at error handling in this pattern. We cannot simply reset the cached observable and rethrow the error like this:

catchError((error) => {
  this.vehiclesDataShareReplay$ = null;
  return throwError(() => error);
})

When throwError() is called inside switchMap, it completes the entire stream. Once completed, the stream is dead forever. Any future calls to next() on the BehaviorSubject will have no effect, because there is no longer an active subscription. Setting vehiclesDataBehavior$ = null does not revive the stream, the observable pipeline has already terminated.

That's why we use EMPTY instead. When an error occurs, EMPTY completes the inner observable without emitting a value. Since there's no value to emit, the outer stream stays alive and listening to the BehaviorSubject. This means:

Subscribers are NOT notified of the error – they retain the last successful cached value
The refresh mechanism stays active – users can trigger another fetch with refreshVehiclesBehavior()
Trade-off: Users see stale data instead of an error message, which may or may not be desirable depending on your use case.

If you prefer to notify subscribers of errors instead, you'd need a different approach (e.g., Subject<VehiclesApiResponse | Error> to explicitly model both success and failure states).

Choosing the Right `shareReplay` Configuration

To avoid memory leaks, it’s important to understand how different shareReplay configurations affect subscriptions and memory usage.

1. `shareReplay()` - no arguments

Buffer: Caches all emitted values (infinite buffer).
Subscription: Stays active until the source completes, even if there are no subscribers.
Use Case: Suitable only for finite streams where you need the full emission history.

2. `shareReplay(1)` - buffer size only

This is the most common usage for HTTP requests.

Buffer: Caches the last emitted value.
Subscription: Remains active until the source completes.
Use Case: Ideal for global singleton data fetched once and reused across the app.

3. `shareReplay({ bufferSize: 1, refCount: true })`

refCount: true is better for streams where you want cleanup when nobody's listening (WebSockets, timers), not necessarily for component-level data.

Buffer: Caches the last emitted value.
Subscription (Magic of refCount): Automatically unsubscribes from the source when the subscriber count drops to zero.
Use Case: Recommended for long-lived or infinite streams (e.g., WebSockets), or when you want cached data to reset when users leave a feature.

When NOT to Use `shareReplay`

While shareReplay is powerful, it's inappropriate for:

User-specific data: Risk of showing cached data from one user to another
Real-time data: Stock prices, live scores, etc. need fresh data on every request
Large payloads: Caching large responses increases memory footprint
Security-sensitive data: Ensure proper cache invalidation on logout

Conclusion

Caching in Angular is not just about improving performance, but also about controlling side effects, avoiding duplicate work, and managing application state predictably.

shareReplay provides a powerful and elegant way to cache HTTP responses, but it must be used with a clear understanding of its behavior:

shareReplay(1) is ideal for global, static data that rarely changes.
Error handling is mandatory, otherwise failures can be permanently cached.
Stale data requires an explicit refresh strategy, such as a BehaviorSubject combined with switchMap.
refCount matters when dealing with long-lived or infinite streams and component lifecycles.

There is no single “correct” configuration for shareReplay. The right approach depends on how long the data should live, who consumes it, and whether it needs to be refreshed.

When used deliberately, shareReplay can eliminate redundant HTTP calls, simplify state management, and significantly improve application performance, without introducing hidden bugs or memory leaks.

A working example project is available in my 📁 GitHub repository

A Silly Idea: A Star Wars Lightsaber Duel in the Terminal with GitHub Copilot CLI

Daniel Balcarek — Mon, 09 Feb 2026 12:57:19 +0000

This is a submission for the GitHub Copilot CLI Challenge

🎬 What I Built

In a previous submission for a productivity tool, I sneaked in a small Easter egg inspired by The Matrix. That led to a slightly silly thought, what if I built an actual movie scene using GitHub Copilot CLI, rendered entirely in a terminal with Unicode characters?

That idea stuck with me. It sounded unnecessary, impractical… and kind of awesome 🙂

So I decided to create a Star Wars inspired lightsaber duel in pure CLI. My very first idea was the Lord of the Rings “Ride of the Rohirrim” scene 🐎🐎, but I quickly realized I should keep the scope smaller — after all, it’s still just a terminal and Unicode characters. 😆

📽️ Teaser

The full animation is a bit too long for this post, so I prepared a short “teaser” instead.

View the complete version (~65 seconds) on GitHub

🏃‍♂️ Run it locally

git clone https://github.com/Gramli/star-wars-animation.git
cd star-wars-animation
dotnet run

Note:

You’ll need .NET 10 SDK installed.
Use a font with good Unicode support (e.g., Cascadia Code).
The Visual Studio Console or VS Code terminal render the block characters best -> they’re true Jedi-level terminals 😄

⚠️ Running in classic cmd.exe or other limited terminals may break the animation. Consider it a training exercise for Padawans, only the worthy (and properly equipped) terminals will experience the duel in all its glory.

🎥 My Experience with GitHub Copilot CLI

I brought the idea and created several detailed prompts. Copilot handled most of the code generation and quickly produced a nice draft version. However, something was missing — it lacked soul.

At that point, Copilot stopped being just a code generator and became a Creative Director. I kept refining prompts, pushing for stronger visuals, better animation flow, and more cinematic moments.

Here’s a real example of how our “conversation” looked:

Me:
The animation works and we already have some nice effects, but we need to take it to the next level an Oscar-movie level. We need a real wow effect that makes this animation stunning. Can you suggest 3–5 ideas?
Copilot:

Here are a few ways to push the animation toward a more cinematic feel, even within CLI constraints:

1. Lightsaber motion trails to make fast swings feel fluid and powerful  
2. Gradient-based lighting to simulate glow and light falloff  
3. Impact shockwaves that briefly distort the screen on heavy clashes  
4. Molten damage on walls and floors that cool over time  
5. Cinematic letterboxing during key moments to focus attention  

I’d start with motion trails and molten damage for the biggest visual impact.
Which one would you like me to implement first?

Copilot responded with ideas like motion trails for lightsabers, gradient lighting, shockwave effects, molten damage on walls, and even cinematic letterboxing. Some of them made it into the final version, others stayed on the cutting-room floor, but the process itself was surprisingly fun.

I was genuinely impressed. Copilot helped transform a simple ASCII-style drawing into a small but entertaining show. Sure, it’s not an Oscar-winning movie, but for a playful, slightly ridiculous idea, I think it turned out pretty cool.

💥 When We Failed (And Pivoted)

Things went smoothly… until I had a very bad idea:

“What if we add a camera rotation illusion?” 😅

Yeah. That was ambitious.

This turned out to be a real challenge, even for Copilot. After many new sessions and repeatedly reworking prompts, we eventually had to pivot. A full Y-axis camera rotation just wasn’t readable with simple ASCII silhouettes, so we ended up experimenting with X-axis rotation and a top-down view instead.

At that point, the silhouettes are so minimal that the viewer has to mentally accept the perspective shift, but that’s part of the charm (and limitation) of doing cinematic nonsense in a CLI.

And honestly? That experimentation, even when it didn’t fully work was one of the most fun parts of the project.

💭 Final Thoughts

I really enjoyed this ride. Using GitHub Copilot CLI for something completely non-practical, visual, and slightly absurd turned out to be a great experience. It pushed me to think differently about prompts, iteration, and collaboration with an AI, not just as a tool, but as a creative partner.

May the Source be with you!

.NET: Exceptions vs Result Pattern - Performance Benchmark

Daniel Balcarek — Thu, 05 Feb 2026 12:59:59 +0000

In the realm of error handling and control flow, developers often choose between two primary approaches: throwing exceptions and using the Result Pattern. Throwing exceptions relies on the standard language mechanism to handle errors, whereas the Result Pattern involves returning a structured object containing both the operation's outcome and any error details.

Both approaches have distinct trade-offs, and the optimal choice often depends on the specific project context. Based on my experience with both, I was curious about the performance differences between them.

Benchmark Methodology

To provide a comprehensive comparison, the benchmark evaluates two execution scenarios: a failure path and a success path. The failure path measures the overhead of propagating errors through the call stack, highlighting the cost of throwing exceptions versus returning structured results. The success path measures the overhead during normal execution when no errors occur. Evaluating both scenarios offers a clearer perspective on the trade-offs and illustrates how each approach behaves under different runtime conditions.

For the benchmark, I created two handlers: ResultHandler and ThrowExceptionHandler. Both perform the same task but use different error handling mechanisms. Each processes generated data through multiple validation layers. To introduce asynchronous suspension without performing real I/O, Task.Yield() is used. This forces the method to asynchronously yield execution, allowing the benchmark to measure error propagation across async boundaries.

📁 Benchmark Repository - all benchmark source code is available on GitHub.

Benchmark class

To reflect control flow overhead rather than test data processing, the benchmark uses small datasets.

[SimpleJob(RuntimeMoniker.Net10_0)]
[Orderer(BenchmarkDotNet.Order.SummaryOrderPolicy.Declared)]
[MemoryDiagnoser]
public class ExceptionAndResultBenchmark
{
    private readonly ResultHandler _resultHandler;
    private readonly ThrowExceptionHandler _throwExceptionHandler;

    public IEnumerable<ExceptionAndResultBenchmarkData> Data()
    {
        yield return new ExceptionAndResultBenchmarkData(100);
        yield return new ExceptionAndResultBenchmarkData(250);
        yield return new ExceptionAndResultBenchmarkData(500);
        yield return new ExceptionAndResultBenchmarkData(750);
    }

    public IEnumerable<ExceptionAndResultBenchmarkData> ValidOnlyData()
    {
        yield return new ExceptionAndResultBenchmarkData(100, true);
        yield return new ExceptionAndResultBenchmarkData(250, true);
        yield return new ExceptionAndResultBenchmarkData(500, true);
        yield return new ExceptionAndResultBenchmarkData(750, true);
    }

    public ExceptionAndResultBenchmark()
    {
        _resultHandler = new ResultHandler(Logger.Instance);
        _throwExceptionHandler = new ThrowExceptionHandler(Logger.Instance);
    }

    [Benchmark]
    [ArgumentsSource(nameof(Data))]
    public async Task Result_Pattern(ExceptionAndResultBenchmarkData data)
    {
        var _ = await _resultHandler.Handle(data.RequestData);
    }

    [Benchmark]
    [ArgumentsSource(nameof(Data))]
    public async Task Exception_Throw(ExceptionAndResultBenchmarkData data)
    {
        var _ = await _throwExceptionHandler.Handle(data.RequestData);
    }

    [Benchmark]
    [ArgumentsSource(nameof(ValidOnlyData))]
    public async Task Result_Pattern_ValidOnly(ExceptionAndResultBenchmarkData data)
    {
        var _ = await _resultHandler.Handle(data.RequestData);
    }

    [Benchmark]
    [ArgumentsSource(nameof(ValidOnlyData))]
    public async Task Exception_Throw_ValidOnly(ExceptionAndResultBenchmarkData data)
    {
        var _ = await _throwExceptionHandler.Handle(data.RequestData);
    }
}

Result pattern handler

internal sealed class ResultHandler(Logger logger)
{
    private readonly Logger _logger = logger;

    public async ValueTask<HandleDto?> Handle(IEnumerable<RequestItem> data)
    {
        if (data is null || !data.Any())
        {
            return default;
        }

        var processResult = await ProcessData(data);

        if (processResult.IsFailed)
        {
            _logger.Log(processResult.Errors);
            return default;
        }

        return new HandleDto { Sum = processResult.Value };
    }

    private static async ValueTask<Result<double>> ProcessData(IEnumerable<RequestItem> data)
    {
        var getValidDataResult = await GetValidData(data);

        if (getValidDataResult.IsFailed)
        {
            return Result<double>.Fail(getValidDataResult.Errors);
        }

        var positiveDataResult = await GetPositiveData(getValidDataResult.Value);

        if (positiveDataResult.IsFailed)
        {
            return Result<double>.Fail(positiveDataResult.Errors);
        }

        return Result<double>.Ok(positiveDataResult.Value.Sum(x => x.Value));
    }

    private static async ValueTask<Result<IEnumerable<RequestItem>>> GetValidData(IEnumerable<RequestItem> inputData)
    {
        if (inputData.All(x => !x.IsValid))
        {
            return Result<IEnumerable<RequestItem>>.Fail("All data are invalid");
        }

        await Task.Yield();

        foreach (var item in inputData)
        {
            var isValidSecondLayerResult = IsValidSecondLayer(item);
            if (isValidSecondLayerResult.IsFailed)
            {
                return Result<IEnumerable<RequestItem>>.Fail("Second level validation is invalid.")
                    .WithErrors(isValidSecondLayerResult.Errors);
            }
        }

        return Result<IEnumerable<RequestItem>>.Ok(inputData.Where(x => x.IsValid));
    }

    private static Result<bool> IsValidSecondLayer(RequestItem item)
    {
        if (!item.IsValidSecondLayer)
        {
            return Result<bool>.Fail("Item is not valid in the second layer");
        }

        return Result<bool>.Ok(true);
    }

    private static async ValueTask<Result<IEnumerable<RequestItem>>> GetPositiveData(IEnumerable<RequestItem> inputData)
    {
        await Task.Yield();

        if (inputData.All(x => x.Value < 0))
        {
            return Result<IEnumerable<RequestItem>>.Fail("All data are smaller than 0");
        }

        return Result<IEnumerable<RequestItem>>.Ok(inputData.Where(x => x.Value > 0));
    }
}

While using the Result Pattern introduces a lot of repetition—you must check IsFailed after nearly every method call, this trade-off leads to highly predictable code and explicit control flow.

Result implementation

As the Result<T> object is a crucial component of the Result pattern, its implementation is included below.

internal readonly struct Result<T>
{
    public T? Value { get; }
    public bool IsFailed { get; }
    public IEnumerable<string> Errors { get; }

    private Result(T value)
    {
        Value = value;
        IsFailed = false;
        Errors = [];
    }

    private Result(IEnumerable<string> errors)
    {
        Value = default;
        IsFailed = true;
        Errors = errors;
    }

    private Result(string error)
    {
        Value = default;
        IsFailed = true;
        Errors = [error];
    }

    public Result<T> WithErrors(IEnumerable<string> errors)
    {
        return new Result<T>(Errors.Concat(errors));
    }

    public static Result<T> Ok(T value) => new(value);
    public static Result<T> Fail(IEnumerable<string> errors) => new(errors);
    public static Result<T> Fail(string error) => new(error);

    public override string ToString()
    {
        return string.Join(string.Empty, Errors);
    }
}

Throw exception handler

internal sealed class ThrowExceptionHandler(Logger logger)
{
    private readonly Logger _logger = logger;

    public async ValueTask<HandleDto?> Handle(IEnumerable<RequestItem> data)
    {
        if (data is null || !data.Any())
        {
            return default;
        }

        try
        {
            var processResult = await ProcessData(data);
            return new HandleDto { Sum = processResult };
        }
        catch (Exception ex)
        {
            _logger.Log(ex);
            return default;
        }
    }

    private static async ValueTask<double> ProcessData(IEnumerable<RequestItem> data)
    {
        var getValidDataResult = await GetValidData(data);

        var positiveDataResult = await GetPositiveData(getValidDataResult);

        return positiveDataResult.Sum(x => x.Value);
    }

    private static async ValueTask<IEnumerable<RequestItem>> GetValidData(IEnumerable<RequestItem> inputData)
    {
        if (inputData.All(x => !x.IsValid))
        {
            throw new ArgumentException("All data are invalid", nameof(inputData));
        }

        await Task.Yield();

        foreach (var item in inputData)
        {
            IsValidSecondLayer(item);
        }

        return inputData.Where(x => x.IsValid);
    }

    private static void IsValidSecondLayer(RequestItem item)
    {
        if (!item.IsValidSecondLayer)
        {
            throw new ArgumentException("Item is not valid in the second layer", nameof(item));
        }
    }

    private static async ValueTask<IEnumerable<RequestItem>> GetPositiveData(IEnumerable<RequestItem> inputData)
    {
        await Task.Yield();

        if (inputData.All(x => x.Value < 0))
        {
            throw new ArgumentException("All data are smaller than 0", nameof(inputData));
        }

        return inputData.Where(x => x.Value > 0);
    }
}

The exception-based implementation is simpler and cleaner at first glance. However, I have observed many times that throwing exceptions can lead to a cycle of catch-and-rethrow, which quickly transforms to spaghetti code.

Benchmark results

BenchmarkDotNet v0.15.8, Windows 10 (10.0.19045.6466/22H2/2022Update)
Intel Core i5-6400 CPU 2.70GHz (Skylake), 1 CPU, 4 logical and 4 physical cores
.NET SDK 10.0.102
  [Host]    : .NET 9.0.9 (9.0.9, 9.0.925.41916), X64 RyuJIT x86-64-v3
  .NET 10.0 : .NET 10.0.2 (10.0.2, 10.0.225.61305), X64 RyuJIT x86-64-v3

Job=.NET 10.0  Runtime=.NET 10.0

Method	data	Mean	Error	StdDev	Gen0	Allocated
Result_Pattern	100 items	1.384 us	0.0227 us	0.0212 us	0.2251	704 B
Exception_Throw	100 items	57.909 us	0.6635 us	0.6206 us	5.8594	18658 B
Result_Pattern_ValidOnly	100 items	3.792 us	0.0690 us	0.0645 us	0.3281	1022 B
Exception_Throw_ValidOnly	100 items	3.318 us	0.0511 us	0.0546 us	0.2747	903 B
Result_Pattern	250 items	1.347 us	0.0141 us	0.0131 us	0.2251	704 B
Exception_Throw	250 items	58.265 us	0.4117 us	0.3851 us	5.8594	18661 B
Result_Pattern_ValidOnly	250 items	6.500 us	0.2048 us	0.5875 us	0.2441	1017 B
Exception_Throw_ValidOnly	250 items	6.659 us	0.1314 us	0.2336 us	0.2823	892 B
Result_Pattern	500 items	1.371 us	0.0137 us	0.0129 us	0.2251	704 B
Exception_Throw	500 items	57.530 us	0.8766 us	0.8200 us	5.8594	18629 B
Result_Pattern_ValidOnly	500 items	7.139 us	0.1873 us	0.5524 us	0.3204	1013 B
Exception_Throw_ValidOnly	500 items	6.468 us	0.1283 us	0.1798 us	0.2823	885 B
Result_Pattern	750 items	1.317 us	0.0124 us	0.0103 us	0.2251	704 B
Exception_Throw	750 items	58.142 us	0.5948 us	0.5564 us	5.8594	18665 B
Result_Pattern_ValidOnly	750 items	8.023 us	0.1575 us	0.2675 us	0.3204	1011 B
Exception_Throw_ValidOnly	750 items	10.361 us	0.2963 us	0.8738 us	0.2441	883 B

Performance Analysis

The Failure Path (Error Handling Overhead)

The benchmark shows a clear performance gap when errors occur: the Result Pattern is approximately 44 times faster (~1.3 μs vs. ~58 μs). While a few microseconds might seem small, these costs add up quickly in applications that process thousands of requests per second.

Why is the Exception approach slower? (~58 μs)
When you throw an exception, the .NET runtime has to do some heavy lifting:

Stack Walking: The runtime must traverse the entire call stack to identify the appropriate catch block. This requires aggregating metadata for every active method in the current execution thread, which is a CPU-bound process.
Internal Bookkeeping: Even if the StackTrace is never explicitly accessed, the runtime must still capture and store the raw frame data during the throw. This ensures the diagnostic information is available if needed, but it creates immediate overhead.
Memory Allocation: Exceptions are heavyweight heap objects. These results show an allocation of ~18.6 KB per error. Excessive throwing increases memory pressure and triggers more frequent Garbage Collection (GC) cycles, which can lead to application stutters.

Why is the Result Pattern faster? (~1.3 μs)
It treats an error like a regular piece of data:

No call-stack traversal is required: It doesn't care about the history of method calls; it just returns a simple object.
Lightweight: It consumes significantly less memory (~704 B). Because Result<T> is a small value type, it typically avoids the large heap allocations associated with exception objects, though it may still be copied or stored within async state machines depending on usage.

The Success Path (Normal Execution)

When everything goes right (the ValidOnly benchmarks), the performance gap disappears. In fact, the exception approach is slightly faster in some cases.

This is because .NET uses "zero-cost" exceptions. If an error is never thrown, the try/catch block doesn't slow down your code at all. On the other hand, the Result Pattern has a tiny "success tax" as you always pay a few nanoseconds because the code must wrap the successful answer inside a Result object.

The memory usage on the success path is also nearly identical (around 1 KB), showing that during normal operation, the choice of error handling doesn't really impact your app's performance.

Conclusion

The benchmark results clearly demonstrate that the Result Pattern is substantially faster and consumes significantly less memory than exception-based error handling in the failure path. In most scenarios, the Result Pattern is the superior choice for managing expected failures. While it requires more repetitive "failure checks", it provides predictable behavior and undeniable performance benefits. Exact performance characteristics will vary based on how the Result<T> object is implemented.

While the exception-based approach often results in cleaner-looking code, it demands strict discipline. Developers must catch only specific exceptions and handle general failures at a central level. Without this rigor, exception-based control flow can quickly devolve into a confusing web of dependencies, forcing developers to dig through lower-level logic just to understand what might go wrong.

In summary, when failures occur frequently and are a normal part of the business logic, the Result Pattern is the clear winner. However, exceptions remain the correct tool for truly exceptional, unexpected conditions, especially when the diagnostic value of a full stack trace outweighs the performance cost. The ideal architecture likely uses both, choosing the right tool based on failure frequency, performance needs, and domain clarity.

DEV Community: Daniel Balcarek

.NET Reflection Benchmarks: Enum Attribute Performance (Part 1)

Get Custom Attribute

Reflection Implementation

Dictionary-Based Alternative

Enum definition

Benchmark code

Source Solution

Results

Summary

Google Translate Who? The Only Translator You’ll Ever Need, Powered by Neural Networks & 90s Scams

What I Built

Demo

Code

Gramli / text-transformer

🦄 Absurd Text Transformer

What It Does

Transformation Modes

How I Built It

Prize Category

Exit(0)

Clean Unit Testing in .NET: Practical xUnit and Moq Tips

How to use IOptions in Unit Tests (Without Mocking)

Make Internals Visible to Test Projects via .csproj

Example

File.Core.csproj:

Mock ILogger with Moq: Simplify Log Verification

Test ILogger Without Moq Using FakeLogger

How to Log in xUnit Tests using ITestOutputHelper

Type-Safe [MemberData] using TheoryData

Use .Callback to Assert Internal Objects

How Much AI-Generated Code Are We Actually Shipping to Production? My Reality So Far

Older Codebases

Newer Codebases

My Question to the Community

Node.js Dependency & Version Management with nvm, npm ci and Registries

Contents

Switching to a Different Node Version

Check the required version

.nvmrc approach

.nvmrc vs package.json

Clean and Reinstall Dependencies

Installation Strategy Comparison

Reinstall with locked versions

Why npm ci?

Full reinstall

rm -rf node_modules

Why delete node_modules?

rm package-lock.json

npm i (npm install)

Corrupted npm Cache

Verify the cache (recommended first step)

Clean the cache

Change registry

Log in to a registry

Set the default registry

Show current npm configuration

Checking and Updating Dependencies

Check outdated packages

Update dependencies

Recommended workflow

Echoes of Experience: Don’t Be "Too Senior" to Ask

Is the Server Running?

It Was Just HTTP

Performance

The Lesson Behind the Stories

What’s the Worst Advice AI Has Given You? Here’s Mine.

API key in a public Docker image

The interesting shift

Discussion

.NET: CopyToAsync vs WriteAsync: The Benchmark You Didn’t Know You Needed

The Benchmark

The Code

The Results

The Real Lesson

Clean Architecture in .NET: Real-World Pros, Cons and Trade-offs

Table of Contents

Pros

UI/Framework/Database Independence

Independence in Practice

`.nvmrc` approach

`.nvmrc` vs `package.json`

Why `npm ci`?

`rm -rf node_modules`

Why delete `node_modules`?

`rm package-lock.json`

`npm i` (`npm install`)

Choosing the Right `shareReplay` Configuration

1. `shareReplay()` - no arguments

2. `shareReplay(1)` - buffer size only

3. `shareReplay({ bufferSize: 1, refCount: true })`

When NOT to Use `shareReplay`