Thanks for posting this. Quick feedback: a few more examples, and more real-world-like, would be very appreciated.

Agreed - not sure what/where it is supposed to be. What is a “context”?

If I were you I’d use that as theproject description on GitHub

Hi @l3nz,

I see what you mean about it resembling an Elixir Agent, but there are a few key differences and advantages that Chord brings, especially with deltas and their management:

• Flexibility in architecture: While Agents are a stateful abstraction, Chord works in both stateful (via GenServer) and stateless modes (direct calls to backends like Redis or ETS). This flexibility makes it easier to adapt Chord to a variety of use cases.
• Efficient state updates with deltas: Instead of syncing the entire state on every update, Chord tracks the changes (deltas). This minimizes bandwidth usage and makes real-time synchronization more efficient, especially for larger datasets or high-frequency updates.
• Delta retention and expiry: Chord allows you to configure how long deltas are retained and when expired deltas should be cleaned up. This gives you fine-grained control over memory and storage, which is something Agents don’t provide by default.
• Decoupled backend support: Chord allows you to plug in different backends, such as ETS for in-memory storage or Redis for distributed setups. This makes it highly scalable, which can be challenging to achieve with simple Agents.

Let me know if there are specific points you’d like to see covered more in-depth in the docs!

Hi @dimitarvp, thank you so much for your thoughtful feedback, I truly appreciate it!

Initially, I chose not to include old_value for the :removed action by default, instead offering the option to implement a custom delta formatter to adapt deltas to specific needs. However, after reflecting on your suggestion, I completely agree with you. Adding old_value to the :removed action provides greater flexibility and aligns better with the behavior of other actions like :modified. I’ll be incorporating this change in the next update.

Regarding your question, a “backend” in Chord simply refers to the underlying data storage mechanism, such as ETS or Redis.

As for “context” versus “state,” I understand your perspective, and you raise a great point. The term “context” was chosen to highlight the library’s flexibility and adaptability, aligning with its design goals. While “state” might feel more universally intuitive, “context” reflects the broader intent behind Chord’s functionality. I really appreciate your input, it’s always valuable to revisit and reflect on these choices.

Thanks again for your insights! Let me know if there’s anything else you’d like to discuss or suggest, I’d be happy to hear it!