Применял ли ты архитектурные шаблоны в коде
Что проверяют
Не список названий, а понимание причины. Интервьюер хочет услышать, какую проблему решал выбор шаблона, чем за него заплатили и что в Node делается проще, чем в языках, откуда эти шаблоны пришли.
Как отвечать
Начните с проекта и боли. Типичная история: роуты Express разрослись, в обработчиках перемешались валидация, запросы к базе и бизнес-правила, а тесты требовали поднимать HTTP-сервер. Разделили на слои: обработчик принимает запрос и валидирует, сервис держит правила, репозиторий знает про базу. После этого правила стали проверяться без сервера и без базы.
Полезно показать и обратную сторону: лишние слои в сервисе из трёх ручек только замедляют работу, а репозиторий ради одного запроса не окупается.
Отдельно скажите, что в JavaScript многое выражается языком, а не классом:
- стратегия это функция, переданная параметром;
- наблюдатель уже есть в виде
EventEmitter; - синглтон получается сам, потому что модуль кэшируется при первом импорте;
- внедрение зависимостей часто сводится к передаче готовых объектов в фабрику модуля.
Где спотыкаются
Перечисляют аббревиатуры и не могут назвать минусы. Про MVC в сервисе без интерфейса честно сказать, что представления там фактически нет и остаётся сериализация ответа, поэтому от шаблона берут только разделение обработчика и логики.
Строят слоистую архитектуру там, где она не нужна. Пять папок и три интерфейса вокруг одного запроса к базе усложняют чтение и ничего не изолируют.
Считают синглтон из кэша модулей безопасным хранилищем состояния. При нескольких воркерах или инстансах у каждого процесса окажется своя копия, и счётчик, кэш или очередь в памяти начнут расходиться.