Главная / Статьи / Запуск API NestJS и Prisma без ошибок связей или P1001

Запуск API NestJS и Prisma без ошибок связей или P1001

Практический чек-лист для подключения NestJS, Prisma и PostgreSQL к чистой основе API, а также решения проблем с отношениями между таблицами, ошибкой P1001 и несработавшими пул-реквестами.

1069 слов

Почти все функции бэкенда, которые команда разрабатывает позже — от аутентификации до многоклиентской архитектуры и контроля доступа по ролям — основаны на результатах первых нескольких часов настройки проекта. Если переменные окружения, подключение к базе данных, связи между схемами и процессы миграций настроены небрежно с самого начала, каждый последующий pull request унаследует этот беспорядок. В данном руководстве подробно описывается процесс создания API на NestJS с использованием Prisma и PostgreSQL, объясняются три проблемы, которые чаще всего мешают достижению первой важной вехи, а также приводится чек-лист для определения того, когда фундамент действительно готов.

Как выглядит завершенный процесс настройки

Полезно определить цель ещё до того, как начинать работу с CLI. Настройка считается завершенной, когда рецензент может склонировать ветку и подтвердить наличие всего следующего:

  • Приложения NestJS, написанного на TypeScript, которое запускается без ошибок
  • Prisma подключен к базе данных PostgreSQL
  • Конфигурация загружается из переменных окружения, а не из жестко заданных значений
  • Набор начальных моделей данных, отражающих структуру домена
  • Миграция, которая может быть корректно применена к пустой базе данных
  • Четко сфокусированный pull request, который остальная команда может просмотреть и объединить
  • Ограничения выбраны намеренно строгими: NestJS и Prisma — единственные фреймворк и ORM, PostgreSQL — база данных, а также соблюдаются существующие в команде правила по конфигурации и использованию Git.

    Набор инструментов

    • Фреймворк и язык: NestJS с TypeScript
    • Доступ к данным: prisma (CLI) и @prisma/client (генерируемый клиент запросов)
    • Конфигурация: @nestjs/config
    • База данных: локальная инстанция PostgreSQL
    • Проверка: Prisma CLI, а также браузер или клиент API для обращения к конечным точкам

    Настройка скелета проекта

    Начните с создания нового приложения с помощью Nest CLI, затем добавьте Prisma и инициализируйте его внутри проекта. В ходе инициализации создается каталог prisma/ для хранения схемы и миграций, в то время как код приложения остается в каталоге src/.

    Далее создайте файл .env, в котором будет указана переменная DATABASE_URL — строка подключения к PostgreSQL, которую использует Prisma. Загрузите конфигурацию с помощью модуля @nestjs/config, чтобы приложение брало значения из окружения, а не из литералов, разбросанных по коду. Убедитесь, что файл .env включен в список .gitignore; сохранение реальных учетных данных сразу в первом PR — это частая ошибка, которую трудно исправить.

    Прежде чем писать любые модели, убедитесь, что Prisma действительно может подключаться к базе данных. Если вы хотите более подробного рассмотрения самой части Prisma, ознакомьтесь с настройкой Prisma 7 с PostgreSQL в проекте на TypeScript и Node.js, а также проверьте актуальную документацию Prisma для получения информации, специфичной для конкретной версии.

    Моделирование первых сущностей

    Для продукта с множеством арендаторов разумной отправной точкой будет схема, включающая четыре модели:

    • Tenant — представляет организацию, использующую систему
    • User — представляет человека, входящего в систему
    • Role — используется для базового назначения ролей внутри арендатора
    • Invite — используется для привлечения новых пользователей в арендатора

    Вместе они определяют основу для последующих функций: пользователи принадлежат к арендаторам, имеют роли и поступают через приглашения. Каждая связь требует наличия поля с обеих сторон, что и является причиной первой ошибки ниже.

    После проверки схемы выполните первую миграцию, чтобы структура базы данных соответствовала схеме. Избегайте экспериментов, поскольку каждый коллега будет использовать её локально.

    Добавление конечной точки проверки работоспособности

    Со стороны API добавьте один контроллер, обрабатывающий запросы к адресу /health и возвращающий простой ответ OK. Это кажется простым, но имеет важное значение: оно позволяет вам, вашей CI-системе, а также балансировщику нагрузки или оркестратору быстро проверять, запущен ли процесс и обрабатывает ли он запросы.

    Три ошибки, часто мешающие достижению первой цели

    Prisma отклоняет связь без соответствующего поля с противоположной стороны

    Симптом: происходит сбой проверки схемы из-за отсутствия поля, соответствующего связи.

    Причина: Prisma требует, чтобы связи были объявлены в обоих моделях. Если User указывает на Tenant, но у Tenant нет поля, перечисляющего его пользователей, с точки зрения Prisma схема считается неполной.

    Решение: добавьте отсутствующие поля обратной ссылки в соответствующие модели, затем запустите команду prisma format. Этот инструмент нормализует файл и может автоматически заполнить отсутствующие поля связей, поэтому хорошей привычкой будет запускать его после каждой правки схемы.

    P1001: невозможно подключиться к серверу базы данных

    Симптом: Prisma выдает код ошибки P1001 и не может подключиться к PostgreSQL.

    Причина: обычно это одна из двух причин: либо сервер PostgreSQL не запущен, либо порт в DATABASE_URL не совпадает с портом, на котором прослушивается сервер.

    Решение: убедитесь, что процесс базы данных запущен локально, затем сравните хост и порт в строке подключения с фактической конфигурацией сервера.

    Запрос на объединение, который, кажется, удаляет всё

    Симптом: рецензент открывает запрос на объединение и видит, что все файлы в репозитории были удалены.

    Причина: коммит был сделан из неверного состояния Git, поэтому различия сравниваются с чем-то совершенно другим, чем планировалось.

    Решение: вместо попыток исправить запутанную историю изменений создайте новую ветку от правильной базовой и примените только необходимые изменения. Выполнение команды git status и просмотр различий git diff по сравнению с целевой веткой перед пушем помогает заметить подобные ошибки на ранней стадии.

    Проверка настройки

    Процедура проверки должна быть однотипной и предсказуемой:

    • Выполните команду npx prisma migrate dev и убедитесь, что миграция применяется без ошибок
    • Запустите сервер NestJS
    • Откройте адрес /health в браузере или клиенте API и проверьте наличие ответа OK

    Если миграция завершится успешно, а эндпоинт состояния отвечает, основа готова к реализации следующей функциональности.

    Основные выводы

    • Рассматривайте инструменты для старта проекта как результат работы с четкими критериями приемки, а не как временные структуры.
  • Укажите каждую связь Prisma с обеих сторон и позвольте команде prisma format поддерживать схему в порядке.
  • Когда вы видите P1001, прежде чем начинать отладку, убедитесь, что PostgreSQL работает и что порт в DATABASE_URL указан правильно.
  • Эндпоинт проверки работоспособности занимает несколько минут, но приносит пользу в процессах CI, мониторинга и проверок развертывания.
  • Небольшие, сфокусированные pull-запросы с чистой историей изменений являются неотъемлемой частью инженерной работы, а не последующим действием.
  • Связанные материалы

    • Развертывание NestJS на Bun и Prisma 7 в Cloud Run без ошибок сборки — рабочий пайплайн GitHub Actions для развертывания приложения NestJS на Bun с использованием Prisma 7 и Neon в Cloud Run, а также исправления проблем с Docker и подключением, которые часто мешают командам.
    • MovieVault Walkthrough: A Watchlist API With Express 5, Prisma 7 and JWT — Подробное описание полноценного задания с временными ограничениями, включающее бэкенд на Express, Prisma и JWT, а также примечания по проверке прав собственности, обработке каскадных эффектов и ошибок.