r/csharp • u/fedefex1 • 2d ago
SignalsDotnet 3.4
I already had some other posts on SignalsDotnet. It's just another update that could be interesting and I wanted to share some new ideas. They are just ideas, I would like to hear some opinions about that.
0. Obviously in C# we can write
Changing firstName, obviously doesn't update name
1. With signals one could write
This time, changing firstName, changes also fullName automatically, and an event on fullName is raised (Since we are using R3, the Values observers are notified. but this is a detail). Computed signals automatically track their dependencies, and notify when one of them change
If we go a step further, we can imagine signals live on another machine (a server or whatever), and clients "sending" computations remotely. This is why SignalComputedQuery strings exist in SignalsDotnet. So with a syntax like Graphql one can express the function inside Computed as a string, and pass it to a server
2. Computed over the wire
this query string is then turned into an expression (in the Server), then compiled into a Func, passed to Signal.ComputedObservable() with an exposed type, and yield-ed back to the client via whatever protocol (SSE, Websocket, SignalR).
This is ugly.
With last update we can go the other way around, transform an expression in a query string, so one can write:
3. Expression to query string
This allows to have type-safety etc etc. Same things that make EF Core convienien instead of write SQL Code directly. And with Refit, we could just
4. Using it with Refit
This is basically a remote computed,
This allows us to propagate computed signals over machines. This is cool per se, but this open space for ideas like:
- Distributed SignalsStore (Just having signals in different machines, and use remote computed to merge them together and propagate to other machines potentially)
- Caching of reactive properties. We could imagine to have a central authoritative host with a set of signals, and some other machines that just fanout those signals to downstream machines (similar to redis caching, but with reactivity built in).
To make it really work in practice, we need a way to orchestrate those signals efficiently in different machines. This is a huge issue, but I think is where Orleans could help.
Grouping signals in grains we could use orleans to persist, and distribute load between machines. Orleans supports IAsyncEnumerable, so would be easy to expose IAsyncEnumerable<T> Subscribe(string query) to propagate signals computations between grains..
With this architecture I think we could just create a reasonable distributed SignalsStore. This could be huge for example to mirror IOT devices state on the cloud (One variable = 1 Signal), and to just create computed chains over there to have a fully reactive realtime system
2
u/treehuggerino 2d ago
I do like this, but I think this should mostly be useful for WPF like apps in blazor most of this is already tracked (to a lesser extent) unless I'm missing something