Data API
Data API — это ваша база, доступная по HTTP. Фронтенд ходит в неё напрямую: сервер писать не нужно, деплоить нечего, платить за простаивающий контейнер не за что.
Адрес — https://data.layero.ru/<база>, где <база> — слаг базы из панели.
Запрос выглядит так:
curl "https://data.layero.ru/moya-baza/rest/v1/entries?select=*&limit=5" \
-H "apikey: pk_live_…"
Контракт — Supabase
Пути, заголовки, форма ответа и коды ошибок повторяют PostgREST и GoTrue.
Это значит, что работает @supabase/supabase-js — тот же клиент, те же
примеры, та же документация по фильтрам:
import { createClient } from "@supabase/supabase-js";
const db = createClient("https://data.layero.ru/moya-baza", "pk_live_…");
const { data, error } = await db.from("entries").select("*").limit(5);
Совместимость сделана ради переезда: проект, написанный под Supabase, запускается без правки политик доступа. Рантайм при этом свой, и то, чего у нас нет, отвечает отказом с именем возможности, а не молчаливой заглушкой — см. Чего нет.
Ключи и роли
У базы два ключа, и разница между ними — это разница ролей в самой базе.
| Ключ | Роль в базе | Где живёт |
|---|---|---|
pk_live_… — публичный | anon | в бандле фронтенда, виден всем посетителям |
sk_live_… — секретный | service | только на вашем сервере |
Ключ передаётся заголовком apikey (как у Supabase) или
authorization: Bearer …. Вошедший пользователь приложения кладёт в
authorization свой токен, а ключ остаётся в apikey — тогда запрос идёт под
ролью authenticated.
🚨 Ключ не даёт прав. Он выбирает роль, а что этой роли доступно, решают гранты и политики RLS в самой базе. Свежая база не отдаёт по API ни одной таблицы: доступ выдаётся по одной таблице явно, вместе с политикой.
Получить ключи на машину:
layero data env # посмотреть
layero data env --write # положить в .env.local
Чем ходить
Ничем — запрос это обычный fetch. Если хочется клиента: свой тонкий
@layero/data (вызов функций) или @supabase/supabase-js (таблицы, фильтры,
вход) — контракт совместим с обоими. Подробности — Чего нет.
Какие схемы видны
| Схема | Таблицы | Функции |
|---|---|---|
api | да | да, и только здесь |
public | да | нет |
app | да | нет |
Таблицы шлюз ищет в трёх схемах, функции для /rpc/ — только в api.
Правило несимметричное, и заголовком Accept-Profile его не изменить: схема
api и есть публичная витрина, то, что человек положил туда, он положил
осознанно. Подробности — Функции и RPC.
Что дальше
- Таблицы и REST — чтение, запись, фильтры, доступ
- Функции и RPC — публичная функция как единственный вход
- Вход пользователей — регистрация, сессии, вход из панели
- Приём с чужого домена — форма на сайте клиента
- Исходящие вызовы — уведомления в Telegram и вебхуки
- Грабли переезда — то, на чём спотыкаются чаще всего
- Чего нет — что не поддержано и что делать вместо