// the find
servicetitan/Stl.Fusion
Build real-time apps (Blazor included) with less than 1% of extra code responsible for real-time updates. Host 10-1000x faster APIs relying on transparent and nearly 100% consistent caching. We call it DREAM, or Distributed REActive Memoization, and it's here to turn real-time on!
A .NET library that turns regular method calls into automatically-cached, automatically-invalidated 'compute services' by intercepting calls on virtual methods marked [ComputeMethod], then extends that same dependency graph over WebSocket RPC so Blazor Server and WebAssembly clients share consistent state without hand-written SignalR/invalidation code. Aimed at teams building Blazor (or general .NET microservice) apps that need real-time UI updates and want to avoid wiring Redis + a pub/sub layer + manual cache busting.
The dependency tracking is the real deal, not marketing: a ComputeMethod call that invokes another ComputeMethod registers as a dependency automatically, so invalidating a low-level read transitively invalidates everything built on top of it, verified in the shipped test suite (PerformanceTest.cs). It ships its own call interceptor and RPC protocol (Stl.Rpc) built specifically to avoid the overhead of generic DI-proxy approaches - no argument boxing, one allocation per call, pluggable MemoryPack/MessagePack serialization instead of being locked into JSON. The Blazor Server/WebAssembly parity is genuinely useful: the same ComputedStateComponent code runs unmodified against a local compute service or a remote compute service client, which is a real pain point for anyone maintaining both hosting modes. It's validated against a production app (Actual Chat) rather than just toy samples, so the claims aren't purely synthetic.
The headline performance table (9.5M calls/s) is comparing a cache hit against a cold DB read under an EF Core benchmark tuned to maximize the non-Fusion baseline's readers - it's not a fair representation of real-world throughput gains and nobody should plan capacity off it. Correctness depends entirely on you remembering to call Computed.Invalidate() on every code path that mutates state the compute graph depends on; miss one write path and you get silent stale reads with no compiler or runtime check to catch it. Adopting it means restructuring your service layer around virtual methods and a tagging interface (IComputeService), which is a much more invasive commitment than a caching library - ripping it back out later is not a quick revert. At under 2k stars and maintained by effectively one company (ServiceTitan) plus one very active contributor, the bus factor and long-term support story is thinner than the architectural bet being asked of you; most of the actual learning material (Quick Start, Tutorial, Cheat Sheet) lives in a separate Samples repo rather than being self-contained.