Bygga ett realtids-dashboard med WeWeb och Supabase

Konfigurera Supabase Realtime

Supabase Realtime sänder databasändringar (INSERT, UPDATE, DELETE) till prenumererade klienter över en WebSocket-anslutning. Så här aktiverar du det:

1. I din Supabase-dashboard, gå till Database → Replication 2. Aktivera replikering för de tabeller du vill bevaka (t.ex. metrics, events, orders) 3. Ange RLS-policys på dessa tabeller, Supabase Realtime respekterar RLS, så användare får bara ändringar på rader de har tillåtelse att se

Detta tar 2 minuter. Det hårda arbetet är på frontend, att hantera strömmen av ändringar och uppdatera UI:t.

För svenska B2B SaaS: realtids-dashboards är en stark differentierande funktion. Kunder som iZettle-konkurrenter kan erbjuda butikschefer live-försäljningsöversikter, ett konkret affärsvärde som motiverar premium-prissättning.

Ansluta WeWeb till Supabase Realtime

WeWebs Supabase-plugin stöder realtidsprenumerationer nativt. I WeWeb:

1. Gå till Plugins → Supabase → din datakälla 2. Aktivera "Realtime" på den kollektion du vill bevaka 3. WeWeb prenumererar automatiskt på ändringar och uppdaterar bundna element när en ändring anländer

För ett metrik-dashboard bundet till en metrics-tabell: lägg till en Collection bunden till tabellen, aktivera Realtime och bind diagram-/nummerelement till kollektionen. När en ny metrisk rad infogas i Supabase uppdateras dashboarden på under 500 ms utan någon användaråtgärd.

Detta fungerar sömlöst med Supabase EU-väst-regionen, inga konfigurationsändringar behövs för att hålla data i Europa.

Bygga dashboard-layouten

Ett typiskt realtids-dashboard har tre zoner:

KPI-rad: 3-4 stora nummerkort överst. Varje bunden till ett aggregat (SUM, COUNT, AVG) från en Supabase-vy. I WeWeb, skapa en vy i Supabase som förkalkylerar aggregat och bind KPI-korten till den vyns realtidskollektion.

Diagram: Linjediagram för tidsseriedata, stapeldiagram för jämförelser, cirkeldiagram för fördelning. WeWeb har en inbyggd Chart-komponent driven av Chart.js. Bind data-prop till en Supabase-kollektion ordnad efter created_at.

Datatabell: En sorterbar, filtrerbar tabell för råa händelser. WeWebs DataGrid-komponent med sökning, sortering och paginering. Aktivera Realtime så att nya rader visas överst när de anländer.

Tidsintervallsfiltrering

Varje dashboard behöver tidsintervallskontroller. Mönster:

1. Lägg till en filterfält-komponent med förinställda knappar: Senaste 24h, Senaste 7d, Senaste 30d, Anpassat intervall 2. Skapa en sidvariabel dateRange med start- och sluttidsstämplar 3. Skicka dateRange som ett filter till varje Supabase-kollektion: .gte("created_at", dateRange.start).lte("created_at", dateRange.end) 4. När användaren väljer ett annat intervall, uppdatera dateRange, alla kollektioner hämtar om automatiskt

För anpassade datumintervall, använd WeWebs Date Picker-komponent och bind båda inmatningarna till dateRange.start och dateRange.end.

För svenska B2B-kunder: lägg till kvartalsvyer (Q1-Q4) och räkenskapsårsvy som snabbval, månadsbaserade filter räcker sällan för ekonomiavdelningens användning.

Row-Level Security för multi-tenant dashboards

För SaaS-dashboards där varje kund bara ser sin data:

Skapa en RLS-policy på metrics-tabellen: CREATE POLICY "Users see own org metrics" ON metrics FOR SELECT USING (org_id IN (SELECT org_id FROM memberships WHERE user_id = auth.uid()));

Denna policy innebär att samma dashboard-URL fungerar för alla kunder, var och en ser bara sin organisations data. Ingen filtrering behövs i WeWeb. Supabase tillämpar det på databasnivå.

Kritiskt: testa detta genom att logga in som användare från två olika organisationer och bekräfta att data är isolerad. En RLS-bugg i ett dashboard är en allvarlig dataläcka.

Under GDPR är dataläckor inte bara ett varumärkesproblem, de kan leda till anmälan till Integritetsskyddsmyndigheten (IMY) och böter. Testa RLS-isolation innan varje produktionsrelease.

Prestandaoptimering för stora datamängder

Dashboards med miljontals rader saktar ner snabbt om du kör aggregat på rådata.

Skapa Supabase-vyer för aggregat: Skapa en materialiserad vy, t.ex. CREATE MATERIALIZED VIEW daily_metrics AS SELECT DATE(created_at), COUNT(*), SUM(value) FROM events GROUP BY DATE(created_at). Uppdatera den materialiserade vyn varje timme via ett Supabase Edge Function cron-jobb.

Använd index: Lägg till ett index på (org_id, created_at) för varje tabell filtrerad efter organisation och tid. Det förvandlar en 5-sekunders fråga till en 50 ms-fråga.

Paginera råtabellen: Lägg aldrig in alla rader i dashboarden. Använd Supabase .range(0, 99) för datatabellen och låt användare paginera. Det håller initial laddning snabb oavsett totalt radantal. Svenska B2B-kunder med år av historiska data kommer att uppskatta snabba laddningstider även vid stora datamängder.

Fördjupning: Supabase Realtime-prenumerationer

Supabase Realtime använder PostgreSQLs funktion för logisk replikering för att fånga varje ändring på radnivå och sända den till prenumererade klienter via en WebSocket. Under huven kör Supabase en Realtime-server (öppen källkod, tillgänglig på GitHub) som lyssnar på PostgreSQLs replikeringslogg och vidarebefordrar ändringshändelser till anslutna klienter i realtid.

Det finns två typer av Realtime-kanaler i Supabase. Database Changes lyssnar på INSERT-, UPDATE- och DELETE-operationer på specifika tabeller, med valfri filtrering per kolumnvärde (till exempel bara ändringar där org_id = 'abc123'). Broadcast låter klienter skicka godtyckliga meddelanden till andra klienter som prenumererar på samma kanal, användbart för samarbetsfunktioner som indikatorer av typen "användare X redigerar just nu den här posten".

För ett dashboard använder du primärt Database Changes. Prenumerera på den specifika tabellen och händelsetypen som spelar roll: channel.on('postgres_changes', { event: 'INSERT', schema: 'public', table: 'orders' }, (payload) => { /* uppdatera UI */ }). Payload-objektet innehåller den nya radens data, så du kan lägga till den i den befintliga kollektionen utan att hämta om hela datasetet. Det gör realtid effektivt, varje uppdatering är ett kirurgiskt tillägg till det lokala tillståndet, inte en fullständig omfrågning.

Optimera realtid för flera samtidiga användare

När ett dashboard har hundratals eller tusentals samtidiga användare som alla prenumererar på samma tabell sänder Supabase Realtime-servern ändringen till varje prenumerant. Detta är effektivt av design, en databasändring utlöser en sändning som fördelas till alla klienter. Klientsidans hantering måste dock vara effektiv för att undvika hackig UI vid hög uppdateringsfrekvens.

För dashboards som tar emot dussintals uppdateringar per sekund (handelsplattformar, logistikövervakning, IoT-sensordata) är batchning av UI-uppdateringar avgörande. Istället för att rendera om vid varje händelse, samla händelser i en buffert och applicera dem i batchar var 250:e millisekund. Det håller UI:t smidigt samtidigt som det speglar data som är högst 250 ms gammal, mer än realtid nog för mänsklig uppfattning.

Filtrera prenumerationer så snävt som möjligt. Istället för att prenumerera på alla ändringar i events-tabellen, prenumerera bara på ändringar där org_id = currentUser.orgId. Det minskar antalet händelser varje klient tar emot och minskar belastningen på Realtime-servern. I WeWeb stöder Supabase-pluginet filterparametrar på realtidsprenumerationer, ange alltid org- eller användarfiltret för att begränsa prenumerationens omfattning.

Strategier för datauppdatering i dashboards

Inte all dashboard-data drar nytta av realtidsprenumerationer. Vissa data ändras sällan (kontoinställningar, användarprofil), vissa ändras på ett känt schema (dagliga summor, veckorapporter), och vissa ändras kontinuerligt (live-händelser, aktiva sessioner). Att matcha uppdateringsstrategin till datatypen ger ett dashboard med bättre prestanda.

För kontinuerligt föränderlig data (orderantal, aktiva användare, live-intäkter) är Supabase Realtime-prenumerationer rätt val. Data uppdateras på under 500 ms från databasinfogningen till dashboard-uppdateringen. För data som ändras enligt ett schema (gårdagens summor, förra veckans sammanfattning) räcker en manuell uppdatering eller en tidsstyrd omhämtning var 60:e sekund, ingen realtidsprenumeration behövs.

I WeWeb implementerar du den tidsstyrda omhämtningen med en setInterval i en JavaScript-åtgärd vid sidladdning, som anropar ww.collections.refresh('your-collection-name') med det konfigurerade intervallet. För ett hybrid-dashboard med både live- och schemalagd data hanterar realtid de levande flödena medan tidsstyrda uppdateringar håller sammanfattningskorten korrekta. Den här kombinationen är effektivare än att prenumerera allt på realtid, den minskar volymen WebSocket-händelser och undviker onödiga omrenderingar av stabil data.

Hantera realtidsfel på ett elegant sätt

WebSocket-anslutningar tappas. Mobilanvändare byter nätverk. Företagsbrandväggar blockerar WebSocket-uppgraderingar. Ett dashboard i produktion med realtid måste hantera avbrutna anslutningar på ett elegant sätt istället för att tyst visa inaktuell data.

Supabases Realtime JavaScript-klient har inbyggd logik för återanslutning. När WebSocket-anslutningen kopplas ner försöker klienten automatiskt återansluta med exponentiell backoff. Under tiden anslutningen är nere tas dock inte ändringar gjorda i databasen emot av klienten. När återanslutningen lyckas bör du hämta om de berörda kollektionerna för att komma ikapp med missade ändringar, en så kallad gap fetch.

I WeWeb implementerar du gap fetch genom att prenumerera på Supabase-kanalens onError- och onClose-händelser med en anpassad JavaScript-åtgärd. När någon av händelserna utlöses, sätt en sidvariabel connectionStatus till 'reconnecting' och visa en synlig statusindikator på dashboarden. När kanalen återansluter (onJoin-händelsen), uppdatera alla realtidskollektioner och återställ connectionStatus till 'connected'. Det här mönstret säkerställer att användare alltid vet om datan de ser är live och aktuell.

Fallstudie: Finansiellt dashboard

En av de mest krävande realtids-dashboard-implementationerna vi har byggt på App Studio är ett dashboard för finansiell drift åt en fintech-startup som processar betalningar över flera europeiska marknader. Dashboarden spårar live-transaktionsvolym, godkännandegrad per betalmetod, bedrägeriflaggor och avvecklingsstatus, uppdaterat i realtid när transaktioner processas.

Arkitekturen använder Supabase som det centrala datalagret. En Edge Function tar emot webhook-payloads från betalningsprocessorn och infogar processade transaktionsposter i transactions-tabellen. Realtidsprenumerationen i WeWeb utlöses vid varje infogning, och dashboarden uppdaterar live-räknarna, lägger till den nya transaktionen i datatabellen och räknar om godkännandegrad-diagrammet, allt inom 600 ms från att betalningen processats.

Viktiga implementationsdetaljer som fick detta att fungera i skala: materialiserade vyer för timvisa aggregat (för att undvika kostsamma COUNT/SUM på hela transactions-tabellen), ett sammansatt index på (org_id, created_at, status) för det vanliga frågemönstret, och batchning av UI-uppdateringar för att hantera skurar på 20-30 transaktioner per sekund under högtrafik. Dashboarden hanterar 50 000+ dagliga transaktioner utan prestandaförsämring, och körs på Supabases Pro-plan. Det här är samma arkitektur vi tillämpar på varje dataintensivt WeWeb-dashboard vi bygger.