Интеграция Supabase Realtime: подписка на изменения PostgreSQL

Интеграция 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?

Supabase Realtime выигрывает по совокупности факторов: он быстрый, не нагружает базу и сразу понимает RLS.

Как мы внедряем Supabase Realtime?

При заказе интеграции Supabase Realtime «под ключ»:

• Настройка логической репликации и каналов Realtime
• React-хук (или Vue/Preact) с первоначальной загрузкой и автоматическим обновлением состояния
• Конфигурация RLS-политик для каждой таблицы
• Broadcast-каналы для кастомных событий (курсоры, уведомления)
• Документация: описание архитектуры, схема подписок, примеры запросов
• Обучение команды: как отлаживать подписки, мониторить статус соединений
• Поддержка в течение 2 недель после сдачи

Этапы:

1. Аналитика: определяем, какие таблицы нуждаются в реалтайме, какие события, фильтры. Выявляем race-conditions.
2. Проектирование: создаём схему каналов, готовим SQL-миграции для RLS и репликации.
3. Реализация: пишем хук, настраиваем серверную часть, встраиваем в существующий код.
4. Тестирование: проверяем одновременные изменения от 10+ пользователей, latency, эмулируем обрывы соединения.
5. Деплой: включаем в 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 дня.