Інтеграція Supabase Realtime для підписки на зміни PostgreSQL
У наших проектах при побудові чату або дошки завдань у реальному часі polling неефективний — він створює навантаження на БД і не дає миттєвого UX. Supabase Realtime вирішує це через WebSocket на основі PostgreSQL Logical Replication, слухаючи WAL-логи. Затримка передачі змін зазвичай не перевищує 10 мс, а інфраструктурні витрати знижуються до 50% порівняно з самостійним сервером. Якщо вам потрібне швидке реалтайм-рішення, замовте інтеграцію Supabase Realtime у нас.
Як працює логічна реплікація PostgreSQL?
Логічна реплікація публікує зміни на рівні рядків. На відміну від потокової реплікації, вона дозволяє підписуватися тільки на потрібні таблиці та фільтрувати дані на стороні БД. Supabase Realtime використовує саме цей механізм, а не опитування таблиці. Це дає гарантію отримання кожної зміни рівно один раз із мінімальною затримкою (зазвичай <10 мс). Докладніше про логічну реплікацію можна прочитати в документації PostgreSQL.
Як уникнути race-conditions при оновленні стану?
Відзначимо: коли кілька клієнтів одночасно пишуть в одну таблицю, база даних гарантує атомарність транзакцій, але клієнтський код може отримати події в неправильному порядку. Використовуйте оптимістичні оновлення та звіряйте версії рядків. У React-хуку нижче ми обробляємо INSERT, UPDATE і DELETE, спираючись на унікальний id рядка. Якщо порядок подій порушено, можна застосувати RSC (React Server Components) для повної синхронізації.
Встановлення та підписка на таблицю
npm install @supabase/supabase-js
import { createClient } from '@supabase/supabase-js';
const supabase = createClient(
process.env.NEXT_PUBLIC_SUPABASE_URL,
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY
);
// Підписка на всі зміни в таблиці messages
const channel = supabase
.channel('public:messages')
.on(
'postgres_changes',
{
event: '*', // INSERT, UPDATE, DELETE або *
schema: 'public',
table: 'messages',
filter: `room_id=eq.${roomId}` // фільтр за значенням
},
(payload) => {
if (payload.eventType === 'INSERT') {
setMessages(prev => [...prev, payload.new]);
}
if (payload.eventType === 'UPDATE') {
setMessages(prev =>
prev.map(m => m.id === payload.new.id ? payload.new : m)
);
}
if (payload.eventType === 'DELETE') {
setMessages(prev => prev.filter(m => m.id !== payload.old.id));
}
}
)
.subscribe((status) => {
console.log('Subscription status:', status);
});
// Відписка
return () => { supabase.removeChannel(channel); };
Фільтр room_id=eq.${roomId} перетворюється на умову WHERE room_id = 'значення' на стороні PostgreSQL. Це ефективніше, ніж фільтрувати на клієнті, і знижує кількість переданих даних до 80%.
React Hook для підписки
function useRealtimeTable<T>(
table: string,
filter?: { column: string; value: string }
) {
const [data, setData] = useState<T[]>([]);
const supabase = useSupabaseClient();
useEffect(() => {
// Початкове завантаження
let query = supabase.from(table).select('*');
if (filter) query = query.eq(filter.column, filter.value);
query.then(({ data }) => setData(data ?? []));
// Підписка на зміни
const channel = supabase.channel(`${table}:${filter?.value ?? 'all'}`)
.on('postgres_changes', {
event: '*',
schema: 'public',
table,
filter: filter ? `${filter.column}=eq.${filter.value}` : undefined
}, (payload) => {
setData(prev => {
if (payload.eventType === 'INSERT') return [...prev, payload.new as T];
if (payload.eventType === 'UPDATE')
return prev.map(item => (item as any).id === (payload.new as any).id
? payload.new as T : item);
if (payload.eventType === 'DELETE')
return prev.filter(item => (item as any).id !== (payload.old as any).id);
return prev;
});
})
.subscribe();
return () => { supabase.removeChannel(channel); };
}, [table, filter?.column, filter?.value]);
return data;
}
// Використання
const messages = useRealtimeTable<Message>('messages', {
column: 'room_id',
value: roomId
});
Хук можна розширити: додати пагінацію, підтримку сортування або optimistic updates. Він скорочує обсяг коду з 50 до 10 рядків.
Broadcast — кастомні події
Broadcast не потребує змін у БД:
// Відправити подію всім підписникам каналу
await supabase.channel('cursor-positions').send({
type: 'broadcast',
event: 'cursor-moved',
payload: { x: mouseX, y: mouseY, userId: user.id }
});
// Отримати
supabase.channel('cursor-positions')
.on('broadcast', { event: 'cursor-moved' }, ({ payload }) => {
updateCursorPosition(payload.userId, payload.x, payload.y);
})
.subscribe();
Broadcast зручний для курсорів, статусів друку, сповіщень — усього, що не пов'язане безпосередньо з даними в таблиці.
Row Level Security
Цей сервіс поважає RLS PostgreSQL — клієнт бачить тільки ті рядки, до яких він має SELECT-доступ.
-- Приклад RLS: користувач бачить тільки свої повідомлення
ALTER TABLE messages ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Users see own messages"
ON messages FOR SELECT
USING (auth.uid() = user_id);
Це критично для багатокористувацьких додатків: навіть якщо зловмисник перехопить WebSocket, він не отримає чужі дані.
Чому Supabase Realtime виграє у polling та ручних WebSocket?
| Метод | Затримка | Навантаження на БД | Складність реалізації | Підтримка RLS |
|---|---|---|---|---|
| Polling (setInterval) | від 1 с до ∞ | висока (постійні SELECT) | низька | так |
| WebSocket вручну | <10 мс | середня (тригери або NOTIFY) | висока | потрібна своя логіка |
| Supabase Realtime | <10 мс | низька (логічна реплікація) | дуже низька (3 рядки коду) | вбудована |
Supabase Realtime виграє за сукупністю факторів: він швидкий, не навантажує базу і одразу розуміє RLS.
| Параметр | SUPABASE REALTIME | WebSocket вручну |
|---|---|---|
| Середня затримка | <10 мс | <10 мс |
| Зусилля на впровадження | 1-2 дні | 5-10 днів |
| Підтримка RLS | вбудована | потребує реалізації |
| Масштабування до 10 тис. підключень | з коробки | потребує налаштування |
Як ми впроваджуємо Supabase Realtime?
При замовленні інтеграції Supabase Realtime «під ключ»:
- Налаштування логічної реплікації та каналів Realtime
- React-хук (або Vue/Preact) з початковим завантаженням і автоматичним оновленням стану
- Конфігурація RLS-політик для кожної таблиці
- Broadcast-канали для кастомних подій (курсори, сповіщення)
- Документація: опис архітектури, схема підписок, приклади запитів
- Навчання команди: як налагоджувати підписки, моніторити статус з'єднань
- Підтримка протягом 2 тижнів після здачі
Етапи:
- Аналітика: визначаємо, які таблиці потребують реалтайму, які події, фільтри. Виявляємо race-conditions.
- Проектування: створюємо схему каналів, готуємо SQL-міграції для RLS та реплікації.
- Реалізація: пишемо хук, налаштовуємо серверну частину, вбудовуємо в існуючий код.
- Тестування: перевіряємо одночасні зміни від 10+ користувачів, latency, емулюємо обриви з'єднання.
- Деплой: включаємо в CI/CD, моніторинг помилок (Sentry).
Терміни та вартість
Базова інтеграція (1-2 таблиці, базовий хук, RLS) — від 2 до 4 робочих днів. Якщо потрібно багато таблиць, складна логіка або broadcast — термін збільшується до тижня. Вартість розраховується індивідуально. Зв'яжіться з нами, щоб ми порахували під ваші завдання.
Типові помилки
-
Забули увімкнути REPLICA IDENTITY FULL — UPDATE і DELETE приходять з порожніми старими даними. Команда:
ALTER TABLE tablename REPLICA IDENTITY FULL; - Не налаштували RLS — клієнти бачать усі рядки таблиці. Перевірте політики SELECT для кожної захищеної таблиці.
-
Занадто широка підписка — без фільтра клієнт отримує всі зміни таблиці, що веде до зайвого трафіку. Завжди використовуйте
filter.
Наш досвід — 5+ років розробки реалтайм-додатків, понад 20 впроваджень Supabase Realtime у продакшні. Ми гарантуємо стабільну роботу під навантаженням до 10 тис. одночасних підключень на один інстанс. Замовте інтеграцію Supabase Realtime вже сьогодні — отримайте працюючий прототип за 2 дні.