Ok, I wrote almost everything in the title, but let me expand on that a bit :)

  1. Fusion is 1 year old now — it was released on July 17, 2020, and interestingly, it managed to acquire more than 1K stars on GitHub during its first year.
  2. Today I published its v1.4.3 build, which adds System.Text.Json serializer support. Earlier Fusion was supporting only Json.NET, which isn’t bad by itself, but… FusionWebServerBuilder was configuring ASP.NET Core to use Json.NET instead of System.Text.Json, and that was a deal breaker for any app that relies on System.Text.Json. The developers of such apps had…


As you might guess, the “alien engine” is Fusion — I still struggle to find a perfect one-line description for it :)

Thanks to Dmitry Filippov (̶g̶i̶r̶l̶s̶, just look at this huge pull request!), Fusion got .NET Standard 2.0 / .NET Framework 4.7+ support. Crazy, but almost every test runs on .NET Framework as well now — even the ones that use Fusion’s distributed features! To make it happen, Dmitry added .NET Standard 2.0 support to every Fusion’s assembly except Stl.Fusion.Server, which had to be re-implemented as Stl.Fusion.Server.NetFx due to quite significant API difference between ASP.NET Core and regular ASP.NET.


An interesting observation I’ve made recently is that nearly all UI architectures are quite similar.

Let’s start from Flux:

Flux UI architecture

A brief description of what happens here:

  • Views:
    - Render the UI by ~ transforming the data from Stores to actual UI controls
    - Convert user actions to Action objects and feed them to Dispatcher
  • Dispatcher routes actions to Stores
  • Stores apply Actions and notify views about the changes that happened there.

Now, let’s look at Redux:


If you believe Virtual DOM is a “lightweight copy” of a real DOM helping to speed up the updates by batching them together— continue reading. Albeit being correct, it’s a highly misleading answer. Surprisingly, it’s also the most popular one: googling for “react virtual DOM” leads you to very similar descriptions: 1, 2, and you get ~ the same results even if you stick to the top answers on StackOverflow: 1, 2, 3;

The content below equally applicable to React and Blazor.

Why it’s a misleading answer?

#1. It doesn’t highlight the key problem Virtual DOM solves — namely, the elimination of unnecessary re-renders. And…


This is Fusion too. But not a real one.

This is a short overview of features added to Fusion over the last 3 months. Some of them are already covered in the Tutorial; I’ll definitely describe the rest soon.

  1. CommandR (which challenges MediatR 😎) and Operations Framework — two parts that make multi-host state sync possible. Yes, now you can scale Fusion services to multiple hosts, and it’s nearly as easy as for any other service. Check out how it works on this animation. For the note, both components actually aren’t tied to Fusion, so you can use them for purposes other than distributed invalidation.
  2. Board Games — the…


The same day .NET 5 was released I shared a single screenshot showing how much faster .NET 5 is relatively to .NET Core 3.1. I promised to share more data later — and here it is.

1. Fusion’s Caching Test — running on Ubuntu + Intel and AMD CPUs

Code: https://github.com/servicetitan/Stl.Fusion.Samples , see “Caching Sample” section there.

Overall, these tests stress an API endpoint fetching a small object from SQL database, the only difference is how it is exposed (locally or via HTTP) and if Fusion is used there to provide transparent caching.

My initial test was performed on Window & AMD CPU, but almost every production service runs on Linux nowadays, so…


I migrated Fusion to .NET 5 today — and honestly, I was absolutely astonished by the performance boost it brings:

The output is produced by Fusion’s “Caching” sample, which uses EF Core 5 and ASP.NET Core. The speed on tests producing 20M+ operations/s (#1, #3) is mainly constrained by Fusion’s logic and Castle.DynamicProxy. And tests producing around 100K operations/s are constrained by either EF & SQL Server (#2, #5) or ASP.NET Core (#4 — it’s ~ the same as #5, but relying on Fusion’s caching features). All of this means that:

  • You may expect +20% speed boost in “normal” apps


Fusion — a small library created as an attempt to challenge the existing architecture of high-load and real-time apps — is going to be 4 months old soon. Here is what happened over these months:

  • We’ve got 300+ stars on GitHub
  • Total # of downloads of “Stl.Fusion” NuGet package approaches 14K.
  • Fusion Samples — initially a single Blazor WASM app project — got hybrid mode (WASM + Server-Side Blazor), authentication, and session tracking. …


Even though Amazon’s example isn’t unique in the context of this post, I’ll use it as a first example of efficiency of a modern web service:


Disclaimer: I am the author of Stl.Fusion — an open-source library helping to address the long-standing problem described in this post. But the problem is real, and the post is relevant even if this library won’t exist.

What’s the biggest difference between the modern and the future web apps?

To answer this question, let’s ask the opposite one first: what’s the most rudimentary UX feature used by almost any web app today?

I nominate this button:

“Refresh” button in Edge

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store