With the new Channel Metadata API, you can keep abreast of changes in metadata associated with your channels; or request this information whenever you need it. Read on to understand how this overcomes the classic n-squared problem you’d face with presence when you have all your clients subscribe to receive updates about other clients joining and leaving your app.
TL;DR
The quick version is that we’ve just launched the Channel Metadata API. This API gives you insights into the metadata associated with the data channels in an Ably app. This includes:
- The state changes in a channel’s lifecycle.
- Occupancy changes, (such as the number of publishers, subscribers or presence members).
- Enumeration (or ‘listing’) of all the active channels in a specific app.
Check out a quick 2 min video explaining what you can use this API for
As well as providing general stats about the channels in an app, this API solves some much bigger issues, which we delve into below.
The long version
The Channel Metadata API can be useful in a range of realtime use cases. Let’s look at three key challenges that it solves:
Problem 1: Presence and the n-squared challenge
If you’ve been working with realtime technologies for a while, you probably know about a feature called Presence. Presence tells you which of your clients are currently connected (or ‘online’). This is a commonly used feature in realtime applications such as online multiplayer gaming and live collaboration.
Traditionally, clients could find out know which other clients are connected/online/present by querying for presence data using a REST request, or subscribing to the presence events. The latter is, of course, the realtime way of doing it, where an update is pushed to all the presence subscribers whenever a client comes online, goes offline or updates their presence data.
While this sounds fine on the surface, if you look more closely, it actually gives rise to an ‘n-squared problem’. Imagine 1,000 clients enter a channel, and each of these clients is a subscriber to the channel’s presence updates. What will happen is that every one of these 1,000 clients joining triggers a message to be sent to every other client on the channel, resulting in 1,000 x 1,000 (1,000,000) messages being sent at once. This isn’t a practical or sustainable way of doing things.
Solution 1
A natural solution to this problem is for your backend app server alone to subscribe to presence updates. The other clients publish their presence updates but don’t subscribe to updates from others. This way, you can have a single point collecting this information, from where you can then decide how to act upon it. However, you still require your server to do this work for every participant involved.
Now imagine a scenario where you’re interested in the total number of participants present in the app, but not so much in keeping track of individual members. This is where the Channel Metadata API comes in handy, limiting the work to be done to a single unit, irrespective of the number of participants. An example of such a scenario is a HQ trivia app.
Problem 2: Implementation effort
This challenge overlaps with the previous problem. More often than not, developers need to be aware of the metadata surrounding their app. This gives them the opportunity to trigger certain actions in response to how their app is being used. However, gathering the necessary metadata traditionally means repeating the work for every present participant, because there has been no way to centrally collect or distribute this information about the app as a whole.
Solution 2
The new Channel Metadata API enables you to subscribe to metadata, meaning that you’ll now receive updates when the metadata of an application changes. As we mentioned previously, this update could be related to the state-change in a channel’s lifecycle, changes in its occupancy or just a list of all active channels in an app. However, the key difference is that you only need to subscribe to these events once, irrespective of the number of participants. This minimizes implementation effort.
Problem 3: Only publishing when someone is actually listening
A core attribute of the pub/sub model is that publishers are decoupled from subscribers. However, this results in a publisher not knowing how many subscribers, if any, will receive a published message. In some cases, a publisher may want to stop publishing when there are no consumers and consequently save costs.
Solution 3
Subscribing to channel lifecycle events using the Metadata API tells publishers if anyone is subscribing to their data, meaning they can ensure they’re only pushing data out when someone (or something) is listening.
In summary…
The new Channel Metadata API gives you the overall stats related to your channels. You can consume this data:
- Via with a pull mechanism, using Ably’s REST API to request this data when you need it. This can be done via the Channel Status API, — which is a subset of the Channel Metadata API.
- Via a push mechanism, subscribing to the data and having Ably push updates to you whenever the stats change.
The second option is the realtime way, and is more useful in most scenarios.
You can get started with this right away by jumping into the documentation, or one of our tutorials explaining subscription to Channel Lifecycle Events and Channel Occupancy Events using the Realtime library; and enumerating active channels in an app using the REST library.
