I did a company-internal presentation about the current state of the art for building UIs with real-time updates with both Flow and Hilla, and also a bit at the end about how we think it can be made even easier in the future through this magic thing called full-stack signals.
The presentation was also a practice run for the live-coding part of the Building multi-player applications: real-time collaboration in Vaadin presentation that I will do at Vaadin Create next week. I will then use a slightly different structure for the examples and also spend more time explaining the basics and the theory behind what I’m showing.
Thank you for the overview and for the outlook into the future. From a developer’s point of view, full-stack signals and the associated simplifications look very promising. However, I wonder whether these simplifications also come at a certain cost? Are there perhaps restrictions or limitations on the use of full-stack signals that do not apply when using the flux approach, for example?
They are different abstractions: message passing (low level) vs shared state (high level). Being on a higher abstraction level also means that you give up some flexibility and performance (increased server-side memory usage due to the underlying event log). A full-stack signal is also overkill for a simple long-running task without any progress tracking (for which I would use mono.flux() until Support Mono in addition to Flux · Issue #399 · vaadin/hilla · GitHub is implemented).
I expect that full-stack signals will cover 80% of the use cases with 20% of the effort. Flux would remain as a low-level solution for the remaining 20% of the cases that need more flexibility.
I suppose that the current architecture for NumberSignals is not yet the final architecture for more complex signals like Lists or Sets for example? I think you mentioned something like this during the Q&A part of your Devoxx talk.
The architecture seems solid on a high level but there are still significant parts that are not yet implemented. ListSignal was merged last week and is included in Vaadin 24.6.0.alpha1 and that enables a wide range of use cases even though you’re still restricted to only level of nesting out of the box.
We’re also planning to add a MapSignal (for one level of key-value pairs) and NodeSignal (for building tree structures of arbitrary depth) but they will not have a big impact on the over all architecture. I’m not sure about a SetSignal but that could also be considered if there are use cases where its not sufficient to deduplicate entries in the client when rendering.
Next up on the roadmap is to build out things needed to make ValueSignal, NumberSignal and ListSignal applicable for more use cases. This includes things like fine-grained access control (e.g. so that only privileged users can remove entires), automatic removal when a client goes offline (e.g. to remove the user’s avatar), graceful handling of network issues, and a server-side API for the signal values (with repeatable reads within the same round trip so that concurrency doesn’t cause a mess).
It’s based on an internal Flux endpoint which is in turn based on WebSockets. This means that if your application uses both full-stack signals and Flux endpoints, then all of the messages will be multiplexed over a single WebSocket connection.
