pro-1.29.0

Author: rmosolgo

CHANGELOG-pro.md

@@ -6,6 +6,11 @@
 
 ### New Features
 
+# 1.29.0 (27 Aug 2024)
+
+- Subscriptions: use a single Pusher or Ably channel to deliver broadcast payloads to subscribers
+- Dashboard: fix crash when a topic had no active subscriptions
+
 # 1.28.1 (22 Aug 2024)
 
 - Subscriptions: Track `last_triggered_at`; add more metadata to the dashboard.

guides/pro/checksums/graphql-pro-1.29.0.txt

@@ -0,0 +1 @@
+8b7c83c448d7cadf1223c75f495b1342809f703374433a54cd184d5d4c2e934bf5f1ab3cebea1c901de42780e7a73a6f1fdea575400b32376efd2ef1befd0d63

guides/subscriptions/ably_implementation.md

@@ -128,6 +128,12 @@ For better performance reading and writing to Redis, you can pass a `connection_
     ably: Ably::Rest.new(key: ABLY_API_KEY)
 ```
 
+### Broadcasts
+
+If you set up {% internal_link "Broadcasts", "/subscriptions/broadcasts" %}, then you can update many clients over a single Ably channel.
+
+Broadcast channels have stable, predictable IDs. To prevent unauthorized clients from "listening in," use [token authorization](#authorization) for transport. Broadcasts channels use the namespace `gqlbdcst:`, so you can provide capabilities to receive them using `"gqlbdcst:*" => [ ... ]` in your authorization code. (If you're using [encryption](#encryption), the prefix will be `ablyencr-gqlbdcst:` instead.)
+
 ## Execution configuration
 
 During execution, GraphQL will assign a `subscription_id` to the `context` hash. The client will use that ID to listen for updates, so you must return the `subscription_id` in the response headers.

guides/subscriptions/pusher_implementation.md

@@ -116,6 +116,19 @@ For better performance reading and writing to Redis, you can pass a `connection_
     connection_pool: ConnectionPool.new(size: 5, timeout: 5) { Redis.new },
 ```
 
+### Broadcasts
+
+If you set up {% internal_link "Broadcasts", "/subscriptions/broadcasts" %}, then you can update many clients over a single Pusher channel.
+
+Broadcast channels have stable, predictable IDs. To prevent unauthorized clients from "listening in," use an [authorized Pusher channel](#authorization) for transport. In your authorization code, you can check for a broadcast using `.broadcast_subscription_id?`:
+
+```ruby
+# In your Pusher authorization endpoint:
+channel_name = params[:channel_name]
+MySchema.subscriptions.broadcast_subscription_id?(channel_name)
+# => true | false
+```
+
 ## Execution configuration
 
 During execution, GraphQL will assign a `subscription_id` to the `context` hash. The client will use that ID to listen for updates, so you must return the `subscription_id` in the response headers.