Firebase и Supabase экономят недели разработки, но стоит забыть про правила доступа — и ваша база превращается в открытый API. LLM здесь не панацея, но если давать ей точные промты, она проектирует схему, генерирует Security Rules и RLS-политики, находит дыры в запросах и подсказывает индексы. В этой подборке — проверенные промты, которые я использую в работе, с примерами и пояснениями.
Схема данных: от требований к коллекциям и таблицам
Первый и самый важный шаг — спроектировать структуру так, чтобы потом не переделывать. LLM хорошо справляется, если дать ей контекст: какие сущности, какие запросы будут частыми, какая модель доступа (кто что читает и пишет).
Промт:
Ты — эксперт по проектированию баз данных для бэкенд-как-сервиса. Спроектируй схему для Firebase Firestore (или Supabase) под следующие требования:
- Сущности: пользователи, заказы, товары, отзывы.
- Пользователь может читать свои заказы и создавать новые.
- Товары доступны всем на чтение, но менять их может только администратор.
- Отзывы может оставить только пользователь, купивший товар.
- Частые запросы: список заказов пользователя с пагинацией, топ-10 товаров по продажам, средний рейтинг товара.
- Ожидаемая нагрузка: 10 000 пользователей, 100 000 заказов в месяц.
Предложи структуру коллекций/таблиц, поля, типы, связи. Для Firestore учти денормализацию, для Supabase — нормализацию и внешние ключи. Объясни, какие индексы понадобятся для указанных запросов.
Пример использования. Для интернет-магазина LLM предложит в Firestore коллекции users, orders, products, reviews, в каждом заказе хранить userId и массив items с id товаров и количеством. Для Supabase — таблицы с внешними ключами и отдельной таблицей order_items. Также она укажет, что для топ-10 товаров по продажам потребуется агрегация (в Firestore — счётчик в документе товара, в Supabase — materialized view или регулярный пересчёт).
Почему это работает: LLM учитывает ограничения платформы (например, в Firestore нельзя делать JOIN, поэтому нужна денормализация). Вы получаете не абстрактную схему, а готовую к реализации.
Правила безопасности: генерация и аудит
Самая большая боль BaaS — дырявые правила. LLM может написать их с нуля или проверить существующие. Главное — дать ей точную модель доступа.
Промт для Firebase Security Rules:
Напиши Firestore Security Rules для следующей модели доступа:
- Коллекция users: каждый пользователь может читать и писать только свой документ (по uid).
- Коллекция orders: пользователь может создавать заказы, где поле userId равно его uid; читать только свои заказы; обновлять только если статус "pending" и меняет только поле "address".
- Коллекция products: чтение всем, запись только пользователю с кастомным клеймом admin.
- Коллекция reviews: создание только если пользователь купил товар (проверить наличие заказа с этим productId и userId); чтение всем.
Учти, что в правилах нельзя делать запросы к другим коллекциям, но можно использовать функции и данные из auth.token. Предложи оптимизированный вариант.
Пример использования. LLM сгенерирует правила с функциями isAdmin(), isOwner(userId), hasPurchased(productId). Для проверки покупки в reviews она может предложить хранить в документе пользователя массив купленных товаров или использовать кастомные клеймы, чтобы избежать дорогих запросов. Также она укажет, что правила не фильтруют данные, а только разрешают/запрещают операции, поэтому запросы должны быть составлены так, чтобы не требовать чтения чужих документов.
Промт для аудита существующих правил:
Проверь следующие Firestore Security Rules на уязвимости. Опиши, какие данные могут быть прочитаны или изменены злоумышленником, и предложи исправления.
[вставьте правила]
Особое внимание удели: возможности обхода проверок через подделку полей, отсутствию валидации типов, использованию wildcard-путей, небезопасным условиям в allow write.
Промт для Supabase RLS:
Сгенерируй политики Row Level Security для PostgreSQL (Supabase) для таблиц users, orders, products, reviews. Модель доступа:
- users: пользователь видит только свою запись, может обновлять только поле name.
- orders: пользователь видит свои заказы, может создавать заказы с user_id = auth.uid(), обновлять только статус на "cancelled" если заказ ещё не отправлен.
- products: все читают, только админ (роль authenticated с полем is_admin = true) может изменять.
- reviews: создавать может только пользователь, купивший товар (проверить наличие записи в orders с этим product_id и user_id), читают все.
Напиши SQL-миграции для включения RLS и создания политик. Учти, что в политиках можно использовать подзапросы, но они должны быть оптимизированы. Предложи индексы для полей, используемых в политиках.
Пример использования. LLM выдаст SQL с ENABLE ROW LEVEL SECURITY и CREATE POLICY. Для проверки покупки в reviews она напишет политику с EXISTS (SELECT 1 FROM orders WHERE ...). Также она напомнит, что политики применяются к каждой строке, поэтому важно индексировать поля user_id, product_id.
Оптимизация запросов и индексов
Медленные запросы в BaaS — частая проблема, особенно когда данных становится много. LLM поможет найти узкие места и предложить индексы.
Промт для Firestore:
Проанализируй запрос Firestore и предложи оптимизацию:
```
db.collection('orders')
.where('userId', '==', uid)
.where('status', '==', 'pending')
.orderBy('createdAt', 'desc')
.limit(20)
```
Какие составные индексы нужны? Можно ли избежать индекса, изменив структуру данных? Опиши, как Firestore выполняет этот запрос и почему без индекса он может быть медленным или завершиться ошибкой.
Пример использования. LLM ответит, что нужен составной индекс на userId, status, createdAt. Также она предложит денормализовать статус в отдельную коллекцию или использовать массив для фильтрации, если статусов немного. Важно: Firestore требует индекс для запросов с несколькими equality-фильтрами и сортировкой.
Промт для Supabase:
У меня есть SQL-запрос в Supabase:
```sql
SELECT * FROM orders WHERE user_id = auth.uid() AND status = 'pending' ORDER BY created_at DESC LIMIT 20;
```
Предложи индексы для оптимизации. Проанализируй план выполнения (EXPLAIN ANALYZE). Как можно переписать запрос или изменить схему, чтобы избежать full scan? Учти, что RLS-политики также могут влиять на производительность.
Пример использования. LLM порекомендует индекс (user_id, status, created_at DESC). Также она может предложить партиционирование по status или использование частичного индекса WHERE status = 'pending', если таких заказов немного.
Аутентификация и миграции
LLM помогает настроить auth-провайдеры и миграции без боли.
Промт для аутентификации:
У меня есть приложение на Firebase Authentication. Нужно добавить кастомные клеймы для роли администратора и настроить правила безопасности, чтобы только админ мог писать в коллекцию products. Опиши пошагово: как установить клейм через Cloud Functions, как обновлять правила, как тестировать. Учти, что клеймы обновляются только после перевыпуска токена.
Пример использования. LLM напомнит, что после установки клейма пользователь должен перелогиниться или токен обновится автоматически через час. Предложит использовать Firebase Admin SDK в Cloud Function, вызываемой только администратором.
Промт для миграций Supabase:
Напиши миграцию Supabase для добавления таблицы reviews с полями: id, product_id (внешний ключ), user_id (внешний ключ), rating (1-5), comment, created_at. Добавь RLS-политики: чтение всем, создание только если пользователь купил товар (проверка через orders), обновление и удаление только автору. Предложи, как тестировать политики с помощью pgTAP.
Пример использования. LLM сгенерирует SQL-миграцию и примеры тестов на pgTAP, которые проверяют, что пользователь без покупки не может создать отзыв.
Firebase или Supabase: что выбрать
Оба инструмента решают одну задачу, но с разными trade-off.
| Критерий | Firebase | Supabase |
|---|---|---|
| Модель данных | NoSQL, документы | Реляционная, PostgreSQL |
| Правила безопасности | Декларативные Security Rules | RLS-политики на SQL |
| Запросы | Ограничены, требуют денормализации | Полноценный SQL, JOIN, подзапросы |
| Индексы | Составные индексы, автоматические | Ручное управление, гибкость |
| Аутентификация | Готовая, много провайдеров | Готовая, на основе PostgreSQL |
| Хостинг | Google Cloud | Собственный или облако |
Когда Firebase: если нужна быстрая разработка, real-time обновления, мобильный бэкенд, и вы готовы к денормализации. Когда Supabase: если нужны сложные запросы, аналитика, контроль над SQL и миграциями, или вы уже знакомы с PostgreSQL.
LLM закрывает главную боль BaaS — помогает писать безопасные правила и оптимизировать запросы, но не заменяет понимание модели доступа. Всегда проверяйте сгенерированные правила на тестовых данных.
В итоге, используйте эти промты как отправную точку, адаптируйте под свои требования и не забывайте тестировать. Для углублённого изучения бэкенда обратите внимание на Go для бэкенда (gRPC) и TypeScript Advanced: кому подходит продвинутый курс, а кому лучше не тратить время.