VOOZH about

URL: https://deepwiki.com/hypervel/notifications/5-notification-channels

⇱ Notification Channels | hypervel/notifications | DeepWiki


Loading...
Menu

Notification Channels

Purpose and Scope

This document provides an overview of notification channels in the hypervel/notifications package. It explains what channels are, how they're selected during notification delivery, the built-in channels available, and the driver resolution strategy used by the ChannelManager.

For detailed information about specific channel implementations, see:

For information about constructing messages for these channels, see Message Construction.


What are Notification Channels

Notification channels are delivery mechanisms that handle the actual transmission of notifications to recipients. Each channel represents a distinct communication medium (email, real-time broadcast, Slack, database storage) and encapsulates the logic required to format and deliver messages through that medium.

Channels are implemented as classes that receive a notifiable entity and a notification object, then handle the delivery specifics. The system uses a driver-based architecture where channel names (like 'mail', 'slack', 'broadcast') are resolved to concrete channel implementations by the ChannelManager.

Sources: src/ChannelManager.php1-233


Channel Selection Process

The notification system determines which channels to use through the notification's via() method. During delivery, the NotificationSender calls this method, passing the notifiable entity, and receives an array of channel names indicating where the notification should be sent.

Channel Selection Flow


Sources: src/ChannelManager.php54-75

Determining Channels

Each notification class implements a via() method that returns an array of channel names:


The method can use conditional logic based on the notifiable entity to dynamically select channels:


Sources: High-level system diagrams (Diagram 2: Notification Dispatch Flow)


Available Channels

The hypervel/notifications package provides four built-in channels:

Channel NameClassPurpose
mailMailChannelSends email notifications via the mail factory
broadcastBroadcastChannelDispatches events to real-time broadcasting systems
databaseDatabaseChannelPersists notifications to database storage
slackSlackNotificationRouterChannelRoutes Slack messages to Web API or Webhook delivery

Built-in Channel Architecture


Sources: src/ChannelManager.php86-115

Mail Channel

The mail channel sends notifications as email messages through the hypervel/mail package. It supports HTML and Markdown rendering, attachments, multiple recipients, and customizable views. The channel is resolved via the createMailDriver() factory method which retrieves MailChannel from the dependency injection container.

See Mail Channel for detailed documentation.

Sources: src/ChannelManager.php101-107

Broadcast Channel

The broadcast channel dispatches notifications as real-time events through the hypervel/broadcasting package. It creates BroadcastNotificationCreated events that are sent to connected clients via WebSocket connections, Pusher, Ably, or Redis broadcasting. The channel is resolved via the createBroadcastDriver() factory method.

See Broadcast Channel for detailed documentation.

Sources: src/ChannelManager.php93-99

Database Channel

The database channel persists notification data to a database table for later retrieval. This is useful for creating in-app notification centers or maintaining a notification history. The channel is resolved via the createDatabaseDriver() factory method.

Sources: src/ChannelManager.php86-91

Slack Channel

The slack channel delivers notifications to Slack workspaces. It uses SlackNotificationRouterChannel as a router that determines whether to use the Slack Web API (chat.postMessage) or incoming webhooks based on the routing configuration. The channel supports Block Kit for rich message formatting. The channel is resolved via the createSlackDriver() factory method and is wrapped in an object pool proxy for performance.

See Slack Channels for detailed documentation.

Sources: src/ChannelManager.php109-115 src/ChannelManager.php44


Channel Resolution Strategy

The ChannelManager resolves channel names to driver instances using a three-tier resolution strategy with fallback logic:

Resolution Strategy Diagram


Sources: src/ChannelManager.php78-156

Resolution Precedence

  1. Custom Creators - If a custom creator closure has been registered via extend(), it is invoked to create the driver instance. src/ChannelManager.php126-135

  2. Factory Methods - If a factory method named createXxxDriver() exists on the ChannelManager (where Xxx is the studly-cased driver name), it is called. For example, 'mail' resolves to createMailDriver(). src/ChannelManager.php137-155

  3. Container Resolution - If the driver name is a fully-qualified class name that exists, the class is resolved directly from the dependency injection container. src/ChannelManager.php140-142

  4. Error - If none of the above strategies succeed, an InvalidArgumentException is thrown. src/ChannelManager.php144

Object Pooling

Drivers listed in the $poolables array (currently only 'slack') are wrapped in a NotificationPoolProxy to enable connection pooling and improve performance. The proxy manages the lifecycle of pooled instances according to configuration specified in $poolConfig.


When a poolable driver is resolved, it is wrapped before being returned:


Sources: src/ChannelManager.php41-49 src/ChannelManager.php124-156

Context-Based Default Channel

The ChannelManager supports context-based configuration of the default channel. The default channel can be set per-request or per-coroutine using the Hyperf Context system:


The context key __notifications.defaultChannel stores the current default, which takes precedence over the class-level $defaultChannel property.

Sources: src/ChannelManager.php27-29 src/ChannelManager.php194-214


Registering Custom Channels

Custom notification channels can be registered using the extend() method on the ChannelManager. This allows the system to support additional delivery mechanisms beyond the built-in channels.

Basic Registration


Poolable Custom Channels

If a custom channel maintains persistent connections or expensive resources, it can be registered as poolable:


The third parameter of extend() marks the driver as poolable, and setPoolConfig() provides pool configuration.

Sources: src/ChannelManager.php158-182

Container-Based Registration

Alternatively, custom channels can be registered by their fully-qualified class name, which will be resolved from the container:


This approach is useful when the channel has constructor dependencies that should be auto-wired by the container.

Sources: src/ChannelManager.php140-142