Realtime en deal room et ailleurs

Les polling-loops sur une tablette warehouse vident la batterie et ralentissent le réseau. La plateforme utilise Supabase Realtime — changements Postgres poussés via WebSocket aux clients abonnés — pour garder les vues synchronisées sans polling.

Où c’est câblé

La deal room : messages, offers, status transitions poussent live. L’inventory list : une vente faite par un collègue se reflète dans votre vue avant qu’il ne relâche la souris. La notifications bell : le count se met à jour en temps réel. La auction live page (/auction/[id]/live) : les bid updates poussent vers tous les watchers. La receiving session : la QuickGrid intake reflète en temps réel les scans d’autres opérateurs sur la même session.

Comment cela fonctionne sous le capot

La réplication logique Postgres expose des change events pour certaines tables. Supabase Realtime les relaie en appliquant les règles RLS (un tenant ne reçoit que les change events pour les lignes qu’il est autorisé à lire). Le navigateur s’abonne via WebSocket ; sur un change event, le composant React concerné re-fetch la ligne affectée et rerender.

Fallback quand WebSocket échoue

Certains réseaux bloquent WebSocket. Le fallback de la plateforme est le short-poll — les mêmes composants requêtent à intervalle lent (toutes les 30 secondes) quand realtime est indisponible. L’utilisateur voit des mises à jour légèrement retardées plutôt que pas de mises à jour. Le fallback est automatique ; les utilisateurs n’ont pas à le savoir.

Ce qui n’est pas realtime

Les reports et analytics ne sont pas realtime — ils sont agrégés nightly ou on-demand. La pipeline view montre un statut live mais l’agrégation SLA se rafraîchit hourly. Le principe : realtime là où l’utilisateur décide dans l’instant, batch-refreshed là où la donnée sert à l’analyse.