👾 Fusion: The missing layer for real-time apps

<br/>

Overview

ActualLab.Fusion acts as method-call middleware, transparently enriching every call to Fusion-enhanced services with caching, dependency tracking, invalidation, RPC, and more — with almost no changes to application code.

You can think of Fusion as make or msbuild, but operating on functions and their outputs instead of source files and build artifacts. Like MSBuild, Fusion uses lazy computation:

• When something changes, dependent results are immediately marked as inconsistent – and this signal propagates all the way to remote clients
• Recomputation only happens when you actually request the result

Fusion solves a set of infamously hard problems with a 🦄 single abstraction:

| Problem | Fusion's Answer | So you don't need... | |---------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------| | ⚡ Caching | In-memory memoization by call arguments | Redis, memcached, ... | | 🔄 Cache invalidation | Automatic dependency tracking + cascading invalidation | Manual tracking – an infamously hard problem | | 🪄 Real-time updates | Fusion client automatically propagates server-side cache invalidation back to the client making it aware of state changes on the server side | SignalR, WebSockets, custom pub/sub, ... | | ✈️ Offline operation | Client-side persistent cache support (IndexedDB, SQLite) is integrated right into the Fusion RPC client, so you get offline mode for free! | Service workers, sync logic, conflict resolution, ... | | 🤬 Network chattiness | Persistent cache enables speculative execution on the client side, allowing ActualLab.Rpc to batch hundreds of RPC calls into a single transmission frame | Request batching, debouncing, manual optimization, ... | | 📡 Network traffic | ActualLab.Rpc is 2-5x faster than gRPC and SignalR even in its "raw" mode; Fusion integration, if enabled, turns it into an efficiency beast by adding "cache match" responses | Protocol tuning, custom serialization, ... | | 🧩 Client-side state management | Same abstractions everywhere: Computed<T>, MutableState<T>, and compute methods | MobX, Flux/Redux, Recoil, ... | | 💰 Single codebase | Single codebase for Blazor Server, WebAssembly, and MAUI (iOS, Android, Windows, macOS, and more) | Platform-specific code, multiple implementations, ... |

The best part: you get all of this without turning your code into a mess. You can think of Fusion as a call middleware or a decorator. That's why Fusion-based code looks as if there is no Fusion at all! So you can focus on building your app and ship faster — and save yourself from dealing with a 2–3× larger codebase and a plethora of "why is it stale?" bugs, which are among the hardest to debug.

Documentation

[Documentation] is the best place to start from.

If you prefer video, check out:

| ActualLab.Fusion Video<br/><img src="./docs/img/Fusion-Video.jpg" title="ActualLab.Fusion, the distributed state sync monster" width="300"/> | ActualLab.Rpc Video<br/><img src="./docs/img/ActualLab-Rpc-Video.jpg" title="ActualLab.Rpc – the fastest RPC protocol on .NET" width="300"/> | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |

Samples

1. Clone [Fusion Samples] repository: git clone git@github.com:ActualLab/Fusion.Samples.git
2. Follow the instructions from README.md to build and run everything.

Below is Fusion+Blazor Sample delivering real-time updates to 3 browser windows:

The sample supports both Blazor Server and Blazor WebAssembly hosting modes. And even if you use different modes in different windows, Fusion still keeps in sync literally every bit of a shared state there, including the sign-in state:

Is Fusion fast?

Yes, it's incredibly fast. Here is an RPC call duration distribution for one of the most frequent calls on [Voxt.ai]:

IChats.GetTile reads a small "chat tile" – typically 5 entries pinned to a specific ID range, so it can be efficiently cached. And even for these calls the typical response time is barely measurable: every X-axis mark is 10x larger than the previous one, so the highest peak you see is at 0.03ms!

The next bump at ~4-5ms is when the service actually goes to the DB – i.e., it's the time you'd expect to see without Fusion. The load would be much higher though, because the calls you see on this chart are only the calls that "made it" to the server – in other words, they weren't eliminated by the client and its Fusion services.

Benchmark Highlights

Our benchmarks show Fusion delivering over 300 million calls per second on a consumer CPU (AMD Ryzen 9 9950X3D) with its transparent caching:

| Scenario | Without Fusion | With Fusion | Speedup | |------------------------------------------------|-----------------------|-----------------|-------------| | Local DAL, almost no writes (peak performance) | 38.61K calls/s | 313.75M calls/s | >8,000x | | Local repo-like service, non-stop writes | 135.44K calls/s | 266.58M calls/s | ~1,968x | | Remote repo-like service, non-stop writes | 100.72K calls/s (REST) | 226.73M calls/s | ~2,251x |

These aren't typos – Fusion makes your services thousands of times faster by eliminating redundant computation, RPC, and database access.

Note that these benchmarks test Fusion method calls with no dependency chains. Real-life Fusion-based API services typically call other compute services, forming deep dependency graphs. Each layer multiplies the savings (i.e. when something is recomputed, it's typically recomputed just partially), so real-world speedups are often even higher than what you see here.

ActualLab.Rpc: The Fastest RPC Protocol on .NET

ActualLab.Rpc is an extendable RPC protocol powering Fusion's distributed features. It isn't "coupled" to Fusion, so you can use it independently. It outperforms all major alternatives on plain RPC tests, especially on call tests and small-item streaming tests:

| Framework | Calls/s | Streaming | |-----------|---------|-----------| | ActualLab.Rpc | 9.33M | 101.17M items/s | | SignalR | 5.30M | 17.17M items/s | | gRPC | 1.11M | 39.59M items/s |

So it's significantly faster than gRPC and SignalR, both for calls and for streaming.

What makes Fusion fast:

• The concept itself is all about eliminating any unnecessar