LiveStash - persisting LiveView state across WebSocket reconnections

Your Libraries & OS Mentoring Libraries
, ,
21

LiveStash is not designed to stash megabytes of state. If a LiveView process holds megabytes of assigns, there are likely larger architectural issues at play. For typical, lightweight assigns, the ETS read/update/write cycle is negligible. That said, we aren’t ignoring the performance aspect. We are aware this read/update/write cycle could become a bottleneck under specific loads, and we already have ideas on how to optimize it in future releases. For this v0.1.0 we are prioritizing validation of the concept.

This is exactly why we designed an explicit API. We give developers full control over what and when gets stashed. It is the developer’s responsibility to manage their state logically. If they choose to only stash :k3, they only get :k3 back. We prefer giving them this explicit control over forcing a “save all or nothing” approach under the hood.

If you have a concrete implementation in mind that addresses these concerns without sacrificing explicit control, PRs are more than welcome!

1 Like
22

Half true. If a node fully crashes, the state is indeed lost. However, if a user simply reconnects to a different node, it works fine. We handle this by using :erpc to fetch the stashed state from the original node. We literally have a working multi-node example demonstrating this exact scenario in the repo.

1 Like
23

Let the developer specify the set of keys to stash ie:

@impl true
def keys_to_stash(), do: [:k1, :k2, :k3]

provide a stash_all/1 api to stash everything in the set. better yet, somehow hook into the handle_event callback and call stash_all at the end of every handle_* cycle automatically.

24

Spot on - this declarative approach is exactly what we have planned for our v0.2.0 milestone.

1 Like
25

Not handle_event but after_render so all the assigns are final, for the particular render.

26

Hi everyone,

I’m happy to share that today we released LiveStash v0.2.0!

We took your feedback to heart and we’re excited to introduce the suggested improvements. This version introduces breaking changes to our main stash API, with the goal of making it simpler, more declarative, and more fault-tolerant.

Here is what is new and changed in v0.2.0:

  • Declarative assigns API (Breaking): We removed stash_assigns/2 in favor of stash/1. Assigns that should be persisted must now be declared directly in the use macro options.

  • TTL unit update (Breaking): Changed the TTL configuration to use seconds instead of milliseconds.

  • Configuration validation: We added validation for user config to improve API correctness and fail fast on invalid inputs.

If you have any questions, ideas, or bug reports, feel free to reply here, create an issue, or start a new thread on GitHub discussions. Let us know how the new API feels!

3 Likes