Что TypeScript действительно проверяет
TypeScript проверяет совместимость типов до выполнения программы и помогает находить ошибки при изменении кода. Для fullstack-проекта это полезно на границах интерфейса, API и доступа к базе: переименование поля может обнаружиться при сборке.
Но типы не валидируют сетевой ответ во время выполнения. Запись «это User» через as не превращает произвольный JSON в корректного пользователя. Данные из формы, URL, файла, API или базы старой версии нужно проверять отдельно.
Общий контракт между фронтендом и сервером
Выделите типы запроса и ответа, которые можно публиковать клиенту. Не передавайте в браузер серверную модель с внутренними полями только потому, что она уже существует.
Для заявки удобно различать успешный результат и ожидаемый отказ по отдельному полю статуса. Тогда интерфейс обязан обработать оба состояния. Перед показом успеха он проверяет фактический ответ сервера, а не только завершение сетевого запроса.
Общие типы могут храниться в отдельном модуле или пакете монорепозитория. Их смысл — согласовать контракт, а не создать зависимость браузера от серверных секретов и инфраструктуры.
Валидация во время выполнения
Проверка входа определяет обязательные поля, формат, длину, допустимые значения и поведение при неизвестном ключе. Для этого можно использовать обычные функции проверки или библиотеку схем, например Zod. Схема должна проверяться на сервере, даже если похожая проверка уже есть в форме.
После валидации отдельно проверяются права и бизнес-правила. Корректный тип суммы не означает разрешение списать деньги. Не нужно возвращать пользователю подробности внутреннего исключения или секретные значения.
React и Server Actions
Типы props описывают данные компонента. Discriminated union помогает представить состояния загрузки, успеха и ошибки без противоречивых комбинаций флагов.
В Server Action вход всё равно приходит через внешнюю границу. Нужны валидация и проверка полномочий; аннотация аргумента не заменяет ни одну из них. Ожидаемые ошибки возвращаются понятным типизированным результатом. Неожиданные исключения обрабатываются так, чтобы диагностические сведения остались на сервере.
База данных и изменение схемы
Генерируемый клиент Prisma связывает запросы с описанием схемы базы. После изменения схемы нужно обновить клиент и отдельно применить проверенную миграцию к нужной среде. Успешная генерация типов не доказывает, что рабочая база уже обновлена.
Проверьте совместимость старой и новой версии приложения в момент выпуска. Для переименования или удаления поля может потребоваться последовательное изменение читателей, данных и писателей.
Что проверить перед выпуском
- strict включён, а неоправданный any не скрывает ошибки;
- внешний ввод проверяется во время выполнения;
- серверные данные явно преобразуются в публичный ответ;
- ожидаемые отказы имеют понятный контракт;
- миграции и интеграции проверены на представительном примере;
- секреты и внутренние сообщения не попадают в браузер.
TypeScript снижает часть риска, но не заменяет тесты и наблюдение за работающей системой. О выборе архитектуры — в сравнении Next.js и React. Передайте пример интеграции, если нужно оценить согласованность типов и данных в вашем проекте.