Есть ли бизнес-логика на бэкенде
Что проверяют
Насколько толстым был клиент в ваших проектах и понимаете ли вы, какие решения фронтенд принимать не должен. Интервьюер прикидывает, будет ли вам привычна их архитектура. Следом обычно спрашивают: «А что тогда делал фронт?» или «Как вы дублировали валидацию?».
Как отвечать
Опирайтесь на свой проект: какой продукт, где проходила граница, почему так решили. Каркас:
- что жило на бэкенде: права доступа, расчёт цен и скидок, переходы статусов заказа, проверки целостности. Всё, что влияет на деньги, доступ и данные, сервер проверяет сам, даже если фронт уже проверил;
- что было на фронте: состояние интерфейса, валидация форм ради UX (сервер её повторяет), оптимистичные обновления, производные данные для отображения, кеш запросов через TanStack Query или RTK Query;
- где граница размыта: BFF, серверные компоненты и Server Actions в Next.js, офлайн-режим, калькуляторы, которые считают на клиенте для скорости, но итог пересчитывает сервер.
Хорошо звучит пример конфликта: скидку сначала считали на клиенте, расчёт разъехался с сервером, и фронт стал показывать то, что вернул API. Или наоборот: бэкенд был тонким CRUD, логику пришлось держать на клиенте, и вы знаете её цену.
Приводите свои примеры и, где можете, цифры: сколько экранов, какие правила перенесли, что это дало. Если вы работали только с готовым API и не знаете, что происходило на сервере, так и скажите, но покажите понимание границы: «Скидки считал бэкенд, мы только отображали результат, а валидацию дублировали в форме через Zod».
Где спотыкаются
Отвечают «не знаю, это бэкенд» и даже не пытаются описать границу. Для фронтендера уровня middle и выше это настораживает.
Считают, что спрятать кнопку по роли уже значит защитить действие. Без проверки на сервере запрос легко отправить руками.
Хвалятся тем, что вся логика жила на клиенте, и не называют риски: подмену запроса, расхождение правил между вебом и мобильным приложением, дублирование кода.