Feature detection and implicit subscriptions

A web application is not the same as the service it uses, even if you wrote them both. If your service has an API, you should not make assumptions about how the client application is going to use the API or the data.

A successful API will likely have more than one client written for it, and the authors of those clients will have very different ideas about how to use the data. Maybe you'll consume the API internally for other uses as well. You can't predict the future, so part of separating your API concerns from your clients should be feature detection.

For a real time application, feature detection is a great way to manage client subscriptions to data.

As I discussed a few weeks ago, for realtime apps it's better to send hints, not data. When a client deliberately subscribes to a data channel for updates on changes, that is an explicit subscription. By contrast, an implicit subscription occurs when a client advertises the features and data types it is capable of dealing with, and the server automatically subscribes it to the relevant data channels.

Implicit subscriptions give the client more flexibility in getting data and give the service more flexibility in managing the channels over which it pushes data. Implicit subscriptions can also be affected by relationships with and the availability of other users.

For example, in a collaboration application, I may be in a group. My client might support displaying the geographical location of users, so my client publishes a feature URI (say, http://jabber.org/protocol/geoloc) to the service.
Since my client is a member of a group, the service might subscribe me to the geolocation of other users in the group, such as /adam/geolocation and /bill/geolocation.

Using implicit subscriptions here saves the client from the hassle of managing all of these subscriptions when various events occur (when I first log in, when other users log in and out, when users are added and removed from the group, etc.).

This keeps the concerns of the service separate from the concerns of the client. The service knows and cares which data feeds it is sending to the client, but the client doesn't care. The client only cares that the service sends the data types it supports and wants. The client doesn't need to know how these data feeds are organized at all, and so it shouldn't be up to the client to manage its subscriptions to them.

In addition to subscriptions, feature publishing can affect the results I get back when I make an API call. When a client explicitly retrieve data about /users/bill, the service could send items related to Bill that my client has declared support/interest in. In the spirit of hypermedia APIs, the service could also suggest URIs of related information with the results of a query.

Managing subscriptions for realtime web applications can be tedious. Using implicit subscriptions - by creatively combining feature detection, API calls, user presence and relationships, and recent queries - can give web apps and their authors a lot of flexibility without the tedium.

--
Would you like our help with your architecture? Please contact us, we'd be glad to help!

• Next: Postgres’s publish-subscribe features made better with JSON
• Previous: Choosing the right database for the job