Pubsub dashboards guide #3091
Pubsub dashboards guide #3091
Conversation
…ocessing strategies.
…sistency and readability.
…mples for large audiences
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
paddybyers
left a comment
paddybyers
left a comment
There was a problem hiding this comment.
@m-hulbert This text contains a lot of AI giveaways, such as em dashes, and emboldened bulleted lists. Does (or should) our style guide say we aim to avoid these?
|
|
||
| Ably applies rate limits to ensure platform stability. By default, channels accept up to 50 inbound messages per second. Enterprise plans can request higher limits for specific use cases. When working with high-frequency data sources, consider batching multiple updates into single messages to stay within these limits. | ||
|
|
||
| For example, data sources generating more than 50 updates per second could be batched into periodic publishes: |
There was a problem hiding this comment.
Why are we suggesting doing this instead of server-side batching?
|
|
||
| The key benefit of server-side batching is that it reduces billable outbound message count, especially during traffic spikes. If your source publishes 10 updates per second and you have 1000 subscribers, without batching you'd have 10,000 outbound messages per second. With 500ms batching, messages are grouped into 2 batches per second, resulting in 2,000 outbound messages per second—a 5x reduction. | ||
|
|
||
| Unlike message conflation, server-side batching preserves all messages and message order. Every update is delivered, just grouped together for efficiency. This makes it suitable for scenarios where you need complete data, but can tolerate some latency in exchange for cost savings. |
There was a problem hiding this comment.
There are some nuances about changes to message ordering - order is preserved for messages of a given type, but ordering of messages vs presence messages, or live objects updates, etc, can change.
|
|
||
| #### Pairing with persist last message | ||
|
|
||
| For state-based dashboards using delta compression, the [persist last message](/docs/storage-history/storage#persist-last-message) channel rule provides a means to store and query the latest state on the channel. When enabled, Ably stores the most recent message published to a channel for 365 days. New clients can then attach with `rewind=1` to immediately receive the last published state, or query it via history. |
There was a problem hiding this comment.
Should we be clear on when we recommend this vs just persistence?
A dashboard is likely to be based on data that's consistently updated, so persist-last doesn't feel like the right solution.
@paddybyers it doesn't currently, but I have a doc that updates the contributing guide to an MDX focus so I'll include an update to the style guide with that. It's a good shout. |
Description
Checklist