Налаштування Supabase для веб-додатку: аутентифікація, RLS, Realtime

Налаштування Supabase для веб-додатку

При збиранні веб-додатку часто впираєшся у необхідність швидко підняти backend з аутентифікацією, базою даних та realtime-сповіщеннями. Supabase — open-source платформа на базі PostgreSQL, яка закриває ці потреби однією екосистемою. Ми налаштували Supabase для десятків проєктів: від стартап-MVP до highload-сервісів з мільйонами запитів. У цій статті розберемо реальну конфігурацію: схема, RLS, Edge Functions та інтеграція з React/Next.js. Розкажемо, як уникнути типових помилок: дублювання політик RLS, неоптимальні запити, проблеми з гарячим перезапуском Edge Functions. І покажемо, як ми налаштовували Supabase для одного з проєктів — сервісу стрічки новин з realtime-оновленнями.

Чому Supabase краще Firebase?

Supabase дає повний контроль: ви можете розгорнути його на своїх серверах або використовувати хмарну версію. Це критично для проєктів з вимогами до data residency.

Створення проєкту

Через dashboard.supabase.com — вибрати регіон, задати пароль бази. Для self-hosted:

git clone --depth 1 https://github.com/supabase/supabase
cd supabase/docker
cp .env.example .env
# Відредагувати .env: POSTGRES_PASSWORD, JWT_SECRET, ANON_KEY, SERVICE_ROLE_KEY
docker compose up -d

Підключення клієнта та генерація типів

import { createClient } from '@supabase/supabase-js'
import type { Database } from './database.types'

export const supabase = createClient<Database>(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
)

// Для серверних операцій — service role key
export const supabaseAdmin = createClient<Database>(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
)

Виконайте npx supabase gen types typescript --project-id your-project-id > src/types/database.types.ts для автодоповнення та перевірки типів.

Схема та Row Level Security

-- Таблиця профілів (розширення auth.users)
CREATE TABLE profiles (
  id          uuid PRIMARY KEY REFERENCES auth.users ON DELETE CASCADE,
  username    text UNIQUE,
  avatar_url  text,
  bio         text,
  updated_at  timestamptz DEFAULT now()
);

-- RLS — кожен бачить тільки своє
ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;

CREATE POLICY "profiles_select_own" ON profiles
  FOR SELECT USING (auth.uid() = id);

CREATE POLICY "profiles_update_own" ON profiles
  FOR UPDATE USING (auth.uid() = id);

-- Публічні профілі — читають всі
CREATE POLICY "profiles_select_public" ON profiles
  FOR SELECT USING (true);

-- Таблиця постів з RLS
CREATE TABLE posts (
  id          uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id     uuid REFERENCES auth.users NOT NULL,
  title       text NOT NULL,
  content     text,
  is_public   boolean DEFAULT false,
  created_at  timestamptz DEFAULT now()
);

ALTER TABLE posts ENABLE ROW LEVEL SECURITY;

CREATE POLICY "posts_select_public_or_own" ON posts
  FOR SELECT USING (
    is_public = true OR auth.uid() = user_id
  );

CREATE POLICY "posts_insert_own" ON posts
  FOR INSERT WITH CHECK (auth.uid() = user_id);

CREATE POLICY "posts_update_own" ON posts
  FOR UPDATE USING (auth.uid() = user_id);

CREATE POLICY "posts_delete_own" ON posts
  FOR DELETE USING (auth.uid() = user_id);

Як налаштувати аутентифікацію та CRUD-операції

// Реєстрація
const { data, error } = await supabase.auth.signUp({
  email: '[email protected]',
  password: 'password',
  options: { data: { username: 'john_doe' } }
})

// OAuth (Google, GitHub, etc.)
await supabase.auth.signInWithOAuth({
  provider: 'google',
  options: { redirectTo: `${window.location.origin}/auth/callback` }
})

// Вставка з поверненням
const { data: post, error } = await supabase
  .from('posts')
  .insert({ title, content, user_id: user.id })
  .select()
  .single()

// Запит з фільтрами та JOIN
const { data: posts } = await supabase
  .from('posts')
  .select(`
    id, title, created_at,
    profiles ( username, avatar_url ),
    tags ( name )
  `)
  .eq('is_public', true)
  .order('created_at', { ascending: false })
  .range(0, 23)

// Повнотекстовий пошук (PostgreSQL tsquery)
const { data } = await supabase
  .from('posts')
  .select('*')
  .textSearch('content', query, { config: 'russian', type: 'websearch' })

Як налаштувати Realtime-підписки та Edge Functions

// Підписка на нові записи
const channel = supabase
  .channel('posts-feed')
  .on('postgres_changes', {
    event: 'INSERT',
    schema: 'public',
    table: 'posts',
    filter: 'is_public=eq.true'
  }, (payload) => {
    setPosts(prev => [payload.new as Post, ...prev])
  })
  .subscribe()

// Edge Function: send-notification
import { serve } from 'https://deno.land/[email protected]/http/server.ts'
import { createClient } from 'https://esm.sh/@supabase/supabase-js@2'

serve(async (req) => {
  const { userId, message } = await req.json()
  const supabase = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!
  )

  await supabase
    .from('notifications')
    .insert({ user_id: userId, message })

  return new Response(JSON.stringify({ ok: true }), {
    headers: { 'Content-Type': 'application/json' }
  })
})

Типові помилки при налаштуванні Supabase

1. Дублювання політик RLS. Часто розробники створюють кілька політик на одну таблицю, що призводить до невизначеної поведінки. Достатньо однієї політики на операцію з правильними умовами.
2. Неоптимальні індекси. Без індексів запити з фільтрацією по user_id або is_public можуть виконуватися в десятки разів повільніше. Додавайте індекси на часто використовувані стовпці.
3. Ігнорування підключень до БД. У Serverless-середовищі кожне створення нового клієнта Supabase встановлює нове з'єднання. Використовуйте пул з'єднань або клієнтський синглтон.

Як ми налаштовуємо Supabase: покроковий процес

1. Аналіз і проєктування схеми — обговорюємо вимоги, проєктуємо таблиці, індекси, зв'язки.
2. Налаштування аутентифікації — підключаємо провайдерів OAuth, створюємо політики RLS.
3. Інтеграція з фронтендом — налаштовуємо клієнтський SDK, генеруємо TypeScript-типи.
4. Деплой і моніторинг — розгортаємо в хмарі або self-hosted, налаштовуємо бекапи.

На кожному етапі документуємо прийняті рішення — це допомагає підтримувати проєкт у майбутньому.

Що входить у налаштування під ключ

• Спроєктована схема бази даних з індексами та міграціями.
• Готові RLS-політики для захисту даних.
• Інтеграція аутентифікації (email/пароль, OAuth, Magic Link).
• Клієнтський код з TypeScript-типами (React, Vue, Next.js).
• Realtime-підписки та Edge Functions під ваші сценарії.
• Документація по API та доступах.
• Навчання команди роботі з Supabase.
• Гарантія на налаштування — 30 днів безкоштовної підтримки.

Орієнтовні строки

Також можемо додати Edge Functions і realtime — ще 2–3 дні. Повний цикл займає від 5 до 10 робочих днів залежно від складності.

Ми працюємо з Supabase з його ранніх версій — накопичили досвід в оптимізації запитів, налаштуванні реплікації та деплої на власні сервери. Зверніться до нас за професійним налаштуванням Supabase — оцінимо ваш проєкт і запропонуємо оптимальне рішення. Отримайте консультацію по вашому проєкту вже сьогодні.

Чому RLS так важливий для безпеки?

Row Level Security (RLS) — це не просто галочка в налаштуваннях. Без RLS будь-який аутентифікований користувач може читати або змінювати дані інших користувачів, якщо немає обмежень на рівні API. Наприклад, у проєкті стрічки новин ми ввели політику, яка дозволяє SELECT тільки для публічних постів або власних записів. Це запобігло витоку приватних даних. «Після впровадження Supabase час розробки MVP скоротився на 40%» — Іван Петров, CTO стартапу.

Що таке Realtime-підписки і як вони працюють?

Realtime-підписки використовують механізм PostgreSQL LISTEN/NOTIFY через WebSocket-з'єднання. При вставці, оновленні або видаленні запису Supabase відправляє подію всім підписаним клієнтам. Це особливо корисно для чатів, стрічок новин і спільної роботи. Налаштування займає хвилину: увімкніть Realtime для потрібних таблиць у дашборді та використовуйте SDK.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.