Пробовал ли делать сервисы на Express.js
Что проверяют
Есть ли у вас серверная часть в арсенале. Фронтендеру она нужна для слоя между клиентом и чужим API, и интервьюер смотрит, понимаете ли вы, чем серверный код отличается от клиентского.
Как отвечать
Назовите честный уровень: поднимал учебный сервис, писал слой для проксирования и склейки ответов, поддерживал сервис в проде.
- Основа. Маршруты и промежуточные обработчики, выстроенные в цепочку. Порядок подключения решает всё: разбор тела, логирование и авторизация идут до маршрутов, обработчик ошибок последним.
- Ошибки. Обработчик ошибок узнаётся по четырём аргументам:
(err, req, res, next). С тремя он станет обычным обработчиком и молча не сработает. - Асинхронность. В четвёртой версии отклонённый промис из обработчика никуда не всплывает, запрос висит до таймаута. Либо оборачивайте обработчик, либо явно зовите
next(err). - Прод. Ограничение размера тела, проверка входа отдельно от бизнес-логики, таймауты на исходящие запросы, корректное завершение процесса, никакого состояния в памяти, если инстансов больше одного.
Уместно сказать и где вы такой слой заводить не стали бы: у современных фронтенд-фреймворков есть свои серверные обработчики, и отдельный процесс ради пары маршрутов добавляет только возни с развёртыванием.
Где спотыкаются
Пишут асинхронный обработчик с походом в сеть и не ловят отказ. Клиент получает не ошибку, а зависший запрос, и на графиках это выглядит как деградация сети.
Вторая ошибка: отвечают дважды. После отправки ответа выполнение функции продолжается, если из неё не выйти, и следом прилетает ошибка про уже отправленные заголовки.
Третья: кладут тело запроса в базу как есть. Серверный слой это граница доверия, проверка схемы на входе там обязательна, даже когда клиент свой и данные шлёт правильные.