Discovering Cache Channels!

Introduction

In this blog we are going to explore pusher channels new feature: Cache Channels!

Cache Channels

A Cache Channel:

• Store Realtime Data Values
• Remembers the last triggered event and sends it as the first event to new subscribers
• Provides a convenient way of working with changing data.

With the new addition of cache channels, you can now use Pusher Channels as a Realtime key-value store!

Currently Pusher channels are used for 2 things:

• Event streams: representing instantaneous events, e.g., a channel mouse-clicks.
• Variables: represents a varying value, e.g., channels like btc-usd, car-12 or gamestate-1.

The Problem with Existing Pusher Channels

Many Pusher users are running applications with very high frequency updates, e.g., Live Location Tracking, Gaming.

In these cases, Developers only care about the latest value of a datapoint which is served so frequently that any cached event would be out of date almost as soon as it was written.

Channels model event streams very well but channels could be difficult for representing variables.

Changes to the value would be broadcast over the channels as they occur, but without implementing some complicated config & code in your backend to fetch initial state, clients subscribing to channels with variable frequency updates and stuff like that. A sports app displaying live match scores would have to wait for a long amount of time to understand the current value.

A new user joining a sports app to follow up on a football match would not want to wait for a new goal to know what the current score was.

So previously, this initial state would have to be served up in the page itself, or the latest value would need to be requested by the client.

This results in three difficulties:

• Unwanted server requests
• Higher time-to-first-event
• Application complexity

How do cache channels solve this problem?

With cache channels, you can avoid the “fetch initial state” workaround and reduce some of the overhead in accommodating variable frequency updates on “normal” Pusher channels.

This simplifies things notably and users working with variable values should be able to write less code with cache channels.

Difference from the existing Pusher Channels:

• Fewer server requests
• No more missed updates due to network reconnect
• Lower initial latency

Conclusion

Cache channels has made life easier for people who were using variables with the existing pusher channels!

Lastly, Don't forget to leave a LIKE and key in your feedback in the comments