Broadcasting Drivers

Purpose and Scope

This document provides an overview of the broadcasting driver system, explaining the available driver implementations, their characteristics, and guidance on when to use each one. Broadcasting drivers are concrete implementations of the Broadcaster contract that handle the actual delivery of broadcast messages to various destinations.

For detailed implementation specifics of each driver, see:

• Ably implementation details: Ably Broadcaster
• Pusher implementation details: Pusher Broadcaster
• Redis implementation details: Redis Broadcaster
• Log and Null implementation details: Utility Broadcasters

For the factory pattern and driver resolution mechanism, see BroadcastManager.

Sources: src/BroadcastManager.php1-465 public/broadcasting.php1-100

Driver Architecture

The broadcasting system uses a factory pattern to create and manage driver instances. The BroadcastManager class serves as the central factory, resolving driver instances based on configuration and optionally wrapping them in connection pools for performance optimization.

Sources: src/BroadcastManager.php39-464 public/broadcasting.php7-99

Driver Resolution Flow

The BroadcastManager resolves drivers through a multi-step process:

Sources: src/BroadcastManager.php224-279 src/BroadcastManager.php60-62

Driver Categories

External Service Drivers

External service drivers connect to cloud-based WebSocket services that handle client connections and message distribution. These drivers are optimized for production use with connection pooling support.

Pusher and Reverb

The PusherBroadcaster handles both Pusher service and Reverb (Laravel's self-hosted alternative). The Reverb driver configuration uses the Pusher protocol internally.

Key characteristics:

• Uses the Pusher PHP SDK for communication
• Supports connection pooling via BroadcastPoolProxy
• Handles channel authentication with HMAC signatures
• Supports presence channels with user information
• Configurable via PUSHER_* or REVERB_* environment variables

Sources: src/BroadcastManager.php292-334 public/broadcasting.php35-73

Ably

The AblyBroadcaster integrates with Ably's realtime messaging platform.

Key characteristics:

• Uses Ably REST SDK for communication
• Supports connection pooling via BroadcastPoolProxy
• JWT-based authentication for channels
• Configurable via ABLY_KEY environment variable
• Simplified configuration compared to Pusher

Sources: src/BroadcastManager.php339-350 public/broadcasting.php75-84

Internal Drivers

Redis

The RedisBroadcaster uses Redis pub/sub for broadcasting within your infrastructure.

Key characteristics:

• No external service dependency
• Requires Redis server and client application to subscribe
• Uses Lua scripts for efficient multi-channel broadcasting
• No connection pooling (uses existing Redis connection pool)
• Suitable for self-hosted WebSocket servers (like Soketi)

Sources: src/BroadcastManager.php355-363 public/broadcasting.php86-89

Utility Drivers

Log

The LogBroadcaster writes broadcast events to the application log for debugging.

Key characteristics:

• Logs all broadcast operations
• No actual message delivery
• Useful for development and debugging
• No configuration required

Sources: src/BroadcastManager.php368-371 public/broadcasting.php91-93

Null

The NullBroadcaster discards all broadcast events.

Key characteristics:

• No-op implementation
• Used to disable broadcasting entirely
• Default driver if not configured
• No configuration required

Sources: src/BroadcastManager.php376-379 public/broadcasting.php95-97

Driver Comparison

Driver	Type	External Service	Connection Pool	Use Case	Configuration Complexity
Ably	External	Yes (Ably)	Yes	Production with Ably service	Low (key only)
Pusher	External	Yes (Pusher)	Yes	Production with Pusher service	Medium (key, secret, app_id, cluster)
Reverb	External	Yes (Self-hosted)	Yes	Production with self-hosted Reverb	Medium (same as Pusher)
Redis	Internal	No	No	Self-hosted WebSocket server	Low (connection name)
Log	Utility	No	No	Development/debugging	None
Null	Utility	No	No	Testing/disabled broadcasts	None

Sources: src/BroadcastManager.php292-379 public/broadcasting.php34-98

Driver Selection Guide

When to Use External Service Drivers

Use Pusher when:

• You need a managed WebSocket infrastructure
• Scaling WebSocket connections is a concern
• You want built-in presence channel support
• You're already using Pusher services

Use Reverb when:

• You want the Pusher protocol without the cost
• You can self-host your WebSocket infrastructure
• You need control over the WebSocket server
• Laravel ecosystem compatibility is important

Use Ably when:

• You need advanced realtime features beyond WebSockets
• You require guaranteed message delivery
• You're building complex realtime applications
• You prefer Ably's pricing model

When to Use Internal/Utility Drivers

Use Redis when:

• You're running your own WebSocket server (e.g., Soketi)
• You want full control over infrastructure
• You need to avoid external service costs
• Your application already uses Redis

Use Log when:

• Debugging broadcast behavior
• Verifying event payloads
• Testing broadcast logic without external services
• Development environments

Use Null when:

• Running tests that don't require broadcasts
• Temporarily disabling broadcasting
• Environments where broadcasting isn't needed

Sources: src/BroadcastManager.php39-464

Configuration Structure

Each driver is configured in config/autoload/broadcasting.php under the connections array. The configuration structure varies by driver type.

Sources: public/broadcasting.php1-100

Configuration Parameters by Driver

Pusher/Reverb Configuration

• key: API key for authentication
• secret: API secret for signing requests
• app_id: Application identifier
• options: Array containing cluster, host, port, scheme, useTLS
• client_options: Guzzle HTTP client configuration
• pool: Connection pool settings (min_objects, max_objects, wait_timeout, max_lifetime)

Ably Configuration

• key: Ably API key (includes app_id and secret)
• pool: Connection pool settings

Redis Configuration

• connection: Name of Redis connection from database.php config
• Reuses existing Redis connection pool configuration

Log and Null Configuration

• driver: Only the driver name is required
• No additional parameters needed

Sources: public/broadcasting.php34-98 src/BroadcastManager.php292-379

Connection Pooling

Drivers that communicate with external services support connection pooling to optimize resource usage and improve performance. The BroadcastManager automatically wraps poolable drivers in a BroadcastPoolProxy.

Poolable Drivers

The BroadcastManager defines poolable drivers in the $poolables property:

• ably: Ably connections are pooled
• pusher: Pusher connections are pooled (including Reverb)

Redis, Log, and Null drivers do not use connection pooling.

Sources: src/BroadcastManager.php60-62 src/BroadcastManager.php244-259

Driver Factory Methods

The BroadcastManager implements factory methods for each driver type. These methods are invoked during driver resolution.

Factory Method	Returns	External Dependencies	Notes
createReverbDriver()	PusherBroadcaster	Pusher SDK	Delegates to createPusherDriver()
createPusherDriver()	PusherBroadcaster	Pusher SDK, Guzzle	Creates Pusher instance with pusher()
createAblyDriver()	AblyBroadcaster	Ably REST SDK	Creates Ably instance with ably()
createRedisDriver()	RedisBroadcaster	Redis connection	Uses RedisFactory from container
createLogDriver()	LogBroadcaster	PSR-3 Logger	Uses logger from container
createNullDriver()	NullBroadcaster	None	No external dependencies

Sources: src/BroadcastManager.php292-379

Custom Driver Registration

The BroadcastManager supports custom driver implementations through the extend() method:

Custom creators are checked before built-in factory methods during driver resolution.

Sources: src/BroadcastManager.php422-427 src/BroadcastManager.php268-270 src/BroadcastManager.php284-287

Driver Interface Contract

All broadcasters must implement the Broadcaster contract, which defines three core methods:

The contract ensures all drivers can:

• Authenticate channel access requests
• Generate valid authentication responses
• Broadcast events to multiple channels

Each driver implements these methods according to its specific protocol and requirements.

Sources: src/Contracts/Broadcaster.php1-26 src/BroadcastManager.php14-18