@fluidframework/datastore-definitions

@fluidframework/datastore-definitions

Interface IFluidDataStoreRuntime specifies the data store developer API.

Using Fluid Framework libraries

When taking a dependency on a Fluid Framework library's public APIs, we recommend using a ^ (caret) version range, such as ^1.3.4. While Fluid Framework libraries may use different ranges with interdependencies between other Fluid Framework libraries, library consumers should always prefer ^.

If using any of Fluid Framework's unstable APIs (for example, its beta APIs), we recommend using a more constrained version range, such as ~.

Capabilities exposed on IFluidDataStoreRuntime

TODO: The full set of functionality is under review

• DDS creation and management APIs
• Container info and states (connection state, documentId, quorum, audience, etc.)
• Loader
• Op/Signal submission
• Snapshotting
• DeltaManager
• Blob Management API.

Signals

Signals provide a transient data channel for data (any serializable payload) that doesn't need to be persisted in the op stream. Use signals where possible to avoid storing unnecessary ops, e.g. to transmit presence status during a collaborative session.

Signals are not persisted, ordered, or guaranteed. If a client is behind, the op state can be behind the signal state. For this reason people usually stick the currentSeq on the signal, so other clients can wait to process if they are behind.

You can send a signal via the container or data store runtime. The container will emit the signal event on all signals, but a data store will emit the signal event only on signals emitted on that data store runtime.

Trademark

This project may contain Microsoft trademarks or logos for Microsoft projects, products, or services.

Use of these trademarks or logos must follow Microsoft's Trademark & Brand Guidelines.

Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship.