Не придумывать отсутствующую инфраструктуру
Разбираем сценарий C: нет DB client, auth resolver и migration runner — значит нельзя тихо строить новую платформу.
После рабочего UI MVP появилась логичная задача: подключить прогресс Academy к PostgreSQL. Но правильный ответ нашелся не в коде Academy, а в аудите root app. В `package.json` не было `pg`, Prisma, Drizzle или Supabase. В `docker-compose.yml` не было Postgres service. В `Dockerfile` не было DB env. В root `src` не было shared auth helper или migration runner. Значит сценарий A невозможен, а сценарий B тоже не подтвержден.
Выбор сценария C означает: мы не подключаем PostgreSQL прямо сейчас, не ставим ORM автоматически и не создаем вторую auth-систему. Вместо этого мы фиксируем отсутствие инфраструктуры как результат аудита и готовим boundary для будущей интеграции. Это дисциплина, которая отличает инженерную работу с AI от генерации «правдоподобного» кода.
- Внезапно установить Prisma без решения.
- Создать новый fake user для production.
- Считать migration примененной, потому что файл существует.
- Придумать auth layer внутри одной feature.
- Провести аудит root app.
- Зафиксировать отсутствующие слои.
- Оставить adapter boundary.
- Сделать demo fallback явным.
- Отключить production storage по умолчанию.
ACADEMY_PROGRESS_STORAGE=cookie # development/demo only
ACADEMY_PROGRESS_STORAGE=disabled # production default until real auth + DB existОтсутствующая инфраструктура — это результат аудита, а не повод незаметно изобрести новую платформу внутри одной feature.
Три варианта будущего persistence
- 1pg
Минимальный PostgreSQL client. Хорош для текущей архитектуры, если нужен явный SQL и мало ceremony.
- 2Existing backend/API
Подходит, если платформа позже получит отдельный backend service и Next.js не должен напрямую писать в DB.
- 3ORM или query builder
Может быть полезен, но только после решения по общему data layer. Нельзя выбирать ORM изнутри одной feature.
Важная деталь: cookie fallback нельзя автоматически мигрировать в PostgreSQL без отдельного решения. Cookie progress — demo state. Production progress должен появляться только от authenticated user через утвержденный storage. Иначе можно случайно смешать локальные эксперименты с настоящими пользовательскими данными.
- DB client найден или честно отсутствует.
- Migration runner найден или честно отсутствует.
- User resolver найден или честно отсутствует.
- Production default не пишет fake-user данные.
- Fallback явно документирован.
Practice
A real WorkerHubs scenario for this lesson.
Для проекта без DB client предложи три варианта persistence и объясни, почему нельзя выбирать ORM без контекста всей платформы.