User presence and audience
The audience is the collection of users connected to a container. When your app creates a container using a service-specific client library, the app is provided with a service-specific audience object for that container as well. Your code can query the audience object for connected users and use that information to build rich and collaborative user presence features.
This document will explain how to use the audience APIs and then provide examples on how to use the audience to show user presence. For anything service-specific, the Tinylicious Fluid service is used.
Working with the audience
When creating a container, your app is also provided a container services object which holds the audience. This audience is backed by that same container. The following is an example. Note that client
is an object of a type that is provided by a service-specific client library.
const { container, services } = await client.createContainer(containerSchema);
const audience = services.audience;
The IMember
Audience members exist as IMember
objects:
export interface IMember {
id: string;
connections: IConnection[];
}
An IMember
represents a single user identity.
IMember
holds a list of IConnection
objects, which represent that audience member's active connections to the container.
Typically a user will only have one connection, but scenarios such as loading the container in multiple web contexts or on multiple computers will also result in as many connections.
An audience member will always have at least one connection. Each user and each connection will both have a unique identifier.
Connections can be short-lived and are not reused. A client that disconnects from the container and immediately reconnects will receive an entirely new connection. The audience will reflect through its member leaving and member joining events.
Service-specific audience data
The ServiceAudience
class represents the base audience implementation, and individual Fluid services are expected to extend this class for their needs. Typically this is through extending IMember
to provide richer user information and then extending ServiceAudience
to use the IMember
extension. For TinyliciousAudience
, this is the only change, and it defines a TinyliciousMember
to add a user name.
export interface TinyliciousMember extends IMember {
userName: string;
}
Because audience data is service-specific, code that interacts with audience may be less portable to other services.
APIs
getMembers
The getMembers
method returns a map of the audience's current members. The map keys are user IDs (i.e. the IMember.userId
property), and values are the IMember
objects for the corresponding user IDs. Your code can further query the individual IMember
objects for their client connections.
The map returned by getMembers
represents a snapshot in time and will not update internally as members enter and leave the audience. Instead of holding onto the return value, your code should subscribe to ServiceAudience
's events for member changes.
getMyself
The getMyself
method returns the IMember
object from the audience corresponding to the current user calling the method. It does so by matching the container's current client connection ID with one from the audience.
Connection transitions can result in short timing windows where getMyself
returns undefined
. This is because the current client connection will not have been added to the audience yet, so a matching connection ID cannot be found. Similarly, offline scenarios may produce the same behavior.
Events
membersChanged
The membersChanged
event is emitted whenever a change to the audience members' client connections is made and will always be paired with a memberAdded
or memberRemoved
event. Listeners may call the getMembers
method to get the new list of members and their connections. Listeners that need the specific changed member or connection should use the memberAdded
and memberRemoved
events instead.
memberAdded
The memberAdded
event is emitted whenever a client connection is added to the audience. The event also provides the connection client ID and the IMember
object for this change. The IMember
object may be queried for more information on the new connection using the provided connection client ID. Depending on if it already had previous connections, the IMember
object may be either new or existing.
memberRemoved
The memberRemoved
event is emitted whenever a client connection leaves the audience. The event also provides the connection client ID and the IMember
object for this change. The IMember
object reflects its state in the audience before the connection's removal, and may be queried for more information on the removed connection using the provided connection client ID.
Using audience to build presence features
Data management and inter-user communication
While the audience is the foundation for user presence features, the list of connected users does not provide a compelling experience on its own. Building compelling presence features will involve working with additional user data. These data typically fit into one or more of the categories below.
Shared persisted data
Most presence scenarios will involve data that only a single user or client knows and needs to communicate to other audience members. Some of those scenarios will require the app to save data for each user for future sessions. For example, consider a scenario where you want to display how long each user has spent in your application. An active user's time should increment while connected, pause when they disconnect, and resume once they reconnect. This means that the time each user has spent must be persisted so it can survive disconnections.
One option is to use a SharedMap
object with a SharedCounter
object as the value onto which each user will increment their time spent every minute (also see Introducing distributed data structures). All other connected users will then receive changes to that SharedMap automatically. Your app's UI can display data from the map for only users present in the audience. A returning user can find themselves in the map and resume from the latest state.
Shared transient data
Many presence scenarios involve data that are short-lived and do not need to be persisted. For example, consider a scenario where you want to display what each user has selected in the UI. Each user will need to tell other users their own information -- where they clicked -- but the past data are irrelevant.
You can address this scenario using DDSes in the same way as with the persisted data scenario. However, using DDSes results in storage of data that are neither useful long term nor in contention among multiple users or clients. Signals are designed for sending transient data and would be more appropriate in this situation. Each user can broadcast a signal containing their selection data to all connected users, and those users can store the data locally. Newly connected users can request other connected users to send their selection data using another signal. When a user disconnects, the local data are discarded.
Unshared data
In some cases, the user data could be generated locally or fetched from an external service. For example, consider a scenario where you want to display the connected users with a profile picture and a color border. If your app retrieves a user's profile picture from a user metadata service and assigns each user a color based on a hash of their user ID, then the app will have the desired data on other users without needing to communicate with them.