Quand la facture d'un service tiers commence à peser sur l'architecture
Dans beaucoup de projets Laravel, les fonctionnalités temps réel reposent sur Pusher ou un service équivalent. Ce choix est souvent pragmatique au départ : quelques lignes de configuration et les WebSockets fonctionnent. Mais à mesure que le trafic augmente, la dépendance révèle deux problèmes concrets : le coût croît proportionnellement au volume de messages, et les données transitent par des serveurs externes avant d'atteindre les utilisateurs finaux.
Laravel Reverb répond directement à ces deux problèmes. C'est un serveur WebSocket officiel, écrit en PHP, qui s'intègre nativement dans l'écosystème Laravel sans nécessiter de service tiers ni de stack Node.js supplémentaire.
Ce que Reverb change concrètement
Le principal frein à l'hébergement de WebSockets en PHP a longtemps été le modèle d'exécution du langage. PHP fonctionne classiquement en mode requête-réponse : un processus démarre, traite une requête, puis se termine. Maintenir des milliers de connexions persistantes dans ce modèle est peu adapté.
Reverb contourne cette limite en s'appuyant sur ReactPHP, une bibliothèque de programmation asynchrone et événementielle pour PHP. Le serveur reste en mémoire et gère les connexions de façon non bloquante, ce qui lui permet de tenir une charge importante sans multiplier les processus.
Côté intégration, Reverb expose la même API que Pusher. Cela signifie que les applications Laravel existantes qui utilisent Laravel Echo et le broadcasting peuvent migrer en modifiant uniquement la configuration, sans réécrire la logique métier.
Installation et configuration
L'installation se fait via Composer et l'installateur Laravel :
php artisan install:broadcasting
Cette commande installe Reverb, configure les variables d'environnement nécessaires et met à jour config/broadcasting.php pour pointer vers le driver Reverb.
Les variables d'environnement clés sont les suivantes :
BROADCAST_CONNECTION=reverb
REVERB_APP_ID=mon-app-id
REVERB_APP_KEY=ma-cle
REVERB_APP_SECRET=mon-secret
REVERB_HOST=localhost
REVERB_PORT=8080
REVERB_SCHEME=http
Pour démarrer le serveur en développement :
php artisan reverb:start
En production, Reverb s'exécute derrière un reverse proxy comme Nginx ou Caddy, qui gère la terminaison TLS et redirige le trafic WebSocket vers le port local du serveur.
Un exemple de configuration Nginx pour la production :
server {
listen 443 ssl;
server_name app.exemple.com;
location /app {
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
}
}
Broadcasting et channels : la logique applicative
Reverb n'impose aucune modification à la façon dont on structure le broadcasting dans Laravel. Les events broadcastés, les channels publics et privés, et les presence channels fonctionnent exactement comme avec Pusher.
Pour diffuser un événement :
broadcast(new CommandeValidee($commande))->toOthers();
Pour définir un channel privé avec une règle d'autorisation :
// routes/channels.php
Broadcast::channel('commandes.{id}', function ($user, $id) {
return $user->id === Commande::find($id)?->user_id;
});
Côté client, Laravel Echo se configure en pointant vers l'hôte Reverb plutôt que vers Pusher :
import Echo from 'laravel-echo';
import Pusher from 'pusher-js';
window.Pusher = Pusher;
window.Echo = new Echo({
broadcaster: 'reverb',
key: import.meta.env.VITE_REVERB_APP_KEY,
wsHost: import.meta.env.VITE_REVERB_HOST,
wsPort: import.meta.env.VITE_REVERB_PORT,
wssPort: import.meta.env.VITE_REVERB_PORT,
forceTLS: false,
enabledTransports: ['ws', 'wss'],
});
La compatibilité avec le protocole Pusher permet d'utiliser pusher-js comme transport côté client, sans en avoir le service.
Mise en production et supervision
Reverb est conçu pour tourner en continu sous un gestionnaire de processus. Supervisor est l'outil habituel dans cet environnement :
[program:reverb]
command=php /var/www/html/artisan reverb:start --host=0.0.0.0 --port=8080
autostart=true
autorestart=true
user=www-data
redirect_stderr=true
stdout_logfile=/var/log/supervisor/reverb.log
Pour les environnements Docker ou Kubernetes, le serveur Reverb peut tourner dans un conteneur dédié, séparé du processus PHP-FPM qui gère les requêtes HTTP classiques. Cette séparation facilite le dimensionnement indépendant des deux composants.
Reverb supporte également la mise à l'échelle horizontale via un backend Redis partagé, ce qui permet à plusieurs instances du serveur de coordonner les messages entre elles.
Ce que ça change pour vous
Si votre application affiche des données en temps réel (notifications, suivi de commandes, chat, tableau de bord), elle dépend peut-être d'un service externe facturé au volume de messages. Passer à une solution hébergée sur votre propre infrastructure supprime ce coût récurrent, qui peut représenter plusieurs centaines d'euros par mois selon l'usage.
Autre point concret : les données de vos utilisateurs ne transitent plus par des serveurs tiers. Elles restent dans votre environnement, ce qui simplifie la conformité au RGPD et réduit la surface d'exposition.
Ce changement ne nécessite pas de réécrire votre application. Il s'agit principalement d'une modification de configuration, ce que votre équipe technique peut évaluer et chiffrer rapidement.
Cet article s'appuie sur un article publié sur dev.to par Prajapati Paresh.
