-
Notifications
You must be signed in to change notification settings - Fork 46
USPs for Pub/Sub #3043
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
USPs for Pub/Sub #3043
Changes from all commits
672707d
22075f4
f926abe
1d2b726
ac45425
3d5033d
6f16dd7
613c662
46b1022
2641416
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -151,6 +151,10 @@ A connection ID is a unique identifier given to a connection, allowing for ident | |
|
|
||
| An active connection ID is guaranteed to be unique in the Ably system whilst it is active, i.e. no other connection will share that connection ID. However, Ably reserves the right to generate a new connection ID later that may be the same as a previously discarded connection ID (once the connection is closed). Therefore customers are advised to not use the connection ID as a perpetual unique identifier as it is possible that a connection ID may be used many times. | ||
|
|
||
| <Aside data-type='see-evidence'> | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this the right place for this section? It's in between some H3s. These talk about monitoring connections to an app. If it does belong here it should really be at the bottom of the h2 (So below Connection metachannels) rather than disrupting the natural flow of reading? Or at the end of the Create a connection section? |
||
| Ably automatically recovers connections and prevents message loss or duplication when clients reconnect within two minutes. [See evidence here 🕵️](/docs/platform/architecture/idempotency#connection-recovery-and-exactly-once-delivery) | ||
| </Aside> | ||
|
|
||
| ### Connection metachannels <a id="metachannels"/> | ||
|
|
||
| [Metachannels](/docs/metadata-stats/metadata/subscribe) are a namespace of channels beginning with the [meta] qualifier, distinguishing them from regular channels. For connections there is a specific `[meta]connection.lifecycle` channel that publishes messages about the lifecycle of realtime connections. The connection lifecycle consists of a number of [connection states](/docs/connect/states#available-connection-states) that can be observed and interacted with using methods available on the connection object. | ||
|
|
@@ -222,6 +226,10 @@ By default, the Ably Pub/Sub JavaScript SDK adds a listener for the `beforeunloa | |
|
|
||
| If a connection to Ably is not explicitly closed when there is a page unload event, then the connection state is preserved by Ably for 2 minutes. Preserving connection state for 2 minutes when there is an unexpectedly dropped connection provides the opportunity for the client to reconnect and resume the connection without losing any messages. | ||
|
|
||
| <Aside data-type='see-evidence'> | ||
| Ably's SDKs automatically resolve edge network failures within 30 seconds, keeping your users connected even during infrastructure issues. [See evidence here 🕵️](/docs/platform/architecture/edge-network) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think my point is the same as what I posted above, about disrupting the h3's reading flow. |
||
| </Aside> | ||
|
|
||
| ### Reliability considerations | ||
| The `beforeunload` event can be unreliable and is not guaranteed to fire under certain circumstances: | ||
| * The event may fire but the page is subsequently not disposed of (navigation can be cancelled). | ||
|
|
||
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -149,6 +149,10 @@ channel.subscribe("channel.closed", new Channel.MessageListener() { | |||||
| ``` | ||||||
| </Code> | ||||||
|
|
||||||
| <Aside data-type='see-evidence'> | ||||||
| Auto Scaling Groups in each region scale independently according to demand, automatically maintaining sufficient capacity to handle traffic peaks. [See evidence here 🕵️](/docs/platform/architecture/infrastructure-operations#multi-region-deployment) | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
| </Aside> | ||||||
|
|
||||||
| ## Log events <a id="log"/> | ||||||
|
|
||||||
| The `[meta]log` and [`[meta]log:push`](/docs/push#Error) metachannels publish events that aren't otherwise available to clients. | ||||||
|
|
||||||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -8,6 +8,10 @@ redirect_from: | |
|
|
||
| Occupancy provides high level metrics about the clients attached to a channel. This includes the number of [connections](/docs/connect) currently attached to a channel, and the number of connections attached that are permitted to publish and subscribe to the channel. | ||
|
|
||
| <Aside data-type='see-evidence'> | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this too high in the page? You've just read the intro paragraph of 2 sentences over what Occupancy is, and then straight into see evidence about scaling. |
||
| Whether there are many lightly-loaded channels or fewer heavily-loaded ones, scaling and placement strategies ensure capacity is added as required and load is effectively distributed. [See evidence here 🕵️](/docs/platform/architecture/platform-scalability#how-ably-achieves-scalability) | ||
| </Aside> | ||
|
|
||
| ## Occupancy metric categories <a id="occupancy-metrics"/> | ||
|
|
||
| The following are the metric categories that occupancy reports: | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -23,6 +23,10 @@ Publishing directly sends push notifications to specific devices or browsers ide | |
|
|
||
| Publishing via channels uses a [Pub/Sub](/docs/channels/messages) model. Messages are sent to channels to which multiple devices or browsers can subscribe. When a message is published to a channel, all devices or browsers subscribed to that channel receive the notification. This approach is particularly powerful for simultaneously publishing messages to multiple users. | ||
|
|
||
| <Aside data-type='see-evidence'> | ||
| Ably's infrastructure serves billions of devices each month, handling enterprise-scale traffic reliably and quickly. [See evidence here 🕵️](/docs/platform/architecture/platform-scalability) | ||
| </Aside> | ||
|
|
||
| <Aside data-type="note"> | ||
| Push subscriptions do not count toward your connection limit since devices don't need to maintain an active connection to receive push notifications. However, publishing push notifications via channels does activate those channels, so your concurrent peak channel count will equal the number of channels you publish to simultaneously. | ||
| </Aside> | ||
|
|
@@ -37,7 +41,7 @@ The following diagram demonstrates the push notification process: | |
|
|
||
| ### Configure | ||
|
|
||
| Configuring push notifications sets your [device's](/docs/push/configure/device) or [browser's](/docs/push/configure/web) push notification service to operate with the Ably [platform](https://ably.com/docs/). This process includes inputting the necessary credentials into your Ably [dashboard](https://ably.com/accounts). | ||
| Configuring push notifications sets your [device's](/docs/push/configure/device) or [browser's](/docs/push/configure/web) push notification service to operate with the Ably [platform](/docs/). This process includes inputting the necessary credentials into your Ably [dashboard](https://ably.com/accounts). | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could the last link not just be /accounts? |
||
|
|
||
| ### Activate | ||
|
|
||
|
|
@@ -97,7 +101,7 @@ Each push target device or browser is associated with a unique `deviceId` and au | |
|
|
||
| * By employing a standard [Ably key](/docs/auth/basic) or [Token](/docs/auth/token), with a `deviceIdentityToken`, a credential generated during registration to assert the device's or browser's identity, included in the request header. | ||
|
|
||
| The service credential management is handled by the [Ably SDK](https://ably.com/docs/sdks), removing the need for the client application to manage device credentials unless accessing the [push admin API](/docs/api/realtime-sdk/push-admin) directly via HTTP. | ||
| The service credential management is handled by the [Ably SDK](/docs/sdks), removing the need for the client application to manage device credentials unless accessing the [push admin API](/docs/api/realtime-sdk/push-admin) directly via HTTP. | ||
|
|
||
| #### Error handling <a id="Error"/> | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry, I'm not really keen on the
See evidence here <emoji>part. I feel like we can integrate the link better. The emoji especially kind of screams AI. But also, you've already got the header "SEE EVIDENCE" as a header, do we need it as a link too?