FilamentPHP Alerts and Laravel Notification Channels: Rate Limiting Interoperability

Centralizing Notification Rate Limits

To prevent notification spam across both FilamentPHP visual alerts and Laravel's native notification channels, the recommended approach is to decouple the trigger logic from the delivery mechanism using Laravel's RateLimiter facade. Since Filament's Alert facade and Laravel's Notification system operate independently, they do not share a native throttling engine.

The Implementation Strategy

The most effective way to share a single limit without duplicating logic is to wrap both dispatchers in a dedicated Service class or a custom Action. This ensures that the rate-limit key is consistent regardless of whether the output is a database record, an email, or a Filament toast.

use Illuminate\Support\Facades\RateLimiter;
use Filament\Notifications\Notification as FilamentNotification;
use App\\Notifications\\SystemAlertNotification; // Your Laravel Notification

class NotificationService
{
    public function sendAlert($user, string $message)
    {
        $key = 'user_alerts_' . $user->id;

        if (RateLimiter::tooManyAttempts($key, $maxAttempts = 5)) {
            return false;
        }

        // 1. Trigger Filament Visual Alert
        FilamentNotification::make()
            ->title('Alert')
            ->body($message)
            ->sendToDatabase($user)
            ->send();

        // 2. Trigger Laravel Native Notification (Mail, Broadcast, etc.)
        $user->notify(new SystemAlertNotification($message));

        RateLimiter::hit($key, $decaySeconds = 3600);
        
        return true;
    }
}

Analysis of Interoperability

• Logic Duplication: By moving the RateLimiter::tooManyAttempts check into a service, you avoid repeating the key naming convention and threshold values across multiple controllers or Livewire components.
• Middleware: There is no native "unified" middleware that automatically intercepts both the Notification facade and the Filament\\Notifications facade because they operate on different layers of the request lifecycle (one is a service, the other often triggers via Livewire events).
• Database Divergence: Because Filament and Laravel use different notification tables/structures, this service-level approach is preferred over database-level constraints, as it intercepts the dispatch before any record is written to either table.

Verification Steps

1. Cache Inspection: Use php artisan cache:forget on your rate-limit key to reset tests.
2. Threshold Testing: Trigger the alert repeatedly; verify that after the 5th attempt, neither the Filament toast appears nor the email is dispatched.
3. Isolation Check: Ensure that different users have unique keys (e.g., user_{id}) so that one user's rate limit does not suppress notifications for the entire admin panel.

Diagnostic Detail Needed: Are your Filament alerts being triggered via Livewire events or standard HTTP requests? If triggered via asynchronous Livewire events, the rate limiter must be checked within the component's action method to avoid race conditions.