Один разработчик — весь фронтенд: проектирование, реализация и оптимизация интерфейса

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

В этой статье я делюсь практическим опытом создания клиентской части HR-платформы (соискатели, работодатели, вакансии, чаты) с нуля до продакшена силами одного инженера. Я расскажу о выборе стека, адаптации Feature-Sliced Design, укрощении модальных окон, работе с API и глобальном перехвате ошибок. В финале поделюсь результатами «боевого крещения» архитектуры при наплыве пользователей.

Существует стереотип, что для создания сложного веб-приложения обязательно нужна команда: тимлид для архитектуры, мидлы для бизнес-логики и тестировщик. Но реалии таковы, что иногда весь фронтенд ложится на плечи одного человека.

Передо мной стояла задача: написать клиентскую часть HR-платформы. Продукт включал личные кабинеты кандидатов и работодателей, систему публикации и импорта вакансий, встроенный чат и информационные разделы (статьи, публикации).

Работать одному круто — ты сам себе архитектор, никто не спорит о код-стайле на часовых митингах. Но цена ошибки возрастает кратно. Выберешь плохую структуру папок — и через три месяца проект превратится в легаси. В этой статье я хочу поделиться тем, какие привычки и шаблоны помогли довести проект до релиза, а чего стоило избегать.

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

Когда ресурсов мало, инструменты должны помогать, а не вставлять палки в колеса. Я остановился на проверенном и современном наборе:

В начале пути всегда есть соблазн сложить все компоненты в папку components. Для пет-проекта это работает, для большой HR-платформы — это путь в ад. Я адаптировал методологию Feature-Sliced Design.

Мой проект разделен на четкие слои:

Это дает понятные границы. Изменение логики карточки вакансии в entities/vacancy физически не может сломать процесс регистрации в features/auth.

Разбрасывать запросы к серверу по всем компонентам — ошибка. Я создал единый ApiClient.ts в слое shared. Любой HTTP-запрос в приложении проходит через него.

Писать обработку ошибок в каждом компоненте мучительно. Я вынес это в Redux, написав errorListenerMiddleware.ts.

Этот middleware слушает все экшены, которые завершились с ошибкой (rejected). Если сервер отвечает 403 (Нет прав) — всплывает глобальный Toast. Если 500 — Toast «Сервер временно недоступен». А если 401 — пользователя мягко редиректит на логин.

Это сделало компоненты страниц невероятно чистыми: они просто дергают данные из API и рендерят их. О том, что сеть может отвалиться, думает errorListenerMiddleware.

Также я активно использовал Code-Splitting (React.lazy). Модули работодателя физически не загружаются в браузер соискателя, что сильно уменьшило начальный бандл.

Модальные окна — вечная боль фронтенда. Если каждый компонент рендерит свою модалку, начинаются конфликты z-index. Я решил это централизованно: создал ModalManager в слое widgets.

В Redux хранится стейт activeModalType. Вызвать окно редактирования профиля можно из любой глубины приложения одной строкой: dispatch(openModal('EDIT_PROFILE')). ModalManager видит изменение стейта и рендерит нужный попап через React Portals поверх всего приложения. Чисто и элегантно.

Стили лежат в двух местах: src/styles/* и index.css отвечают за глобальные токены (переменные цветов, шрифтов), а специфика страниц изолирована в CSS Modules (например, contestInstructionsPage.module.css).

Я терпеть не могу деплоить руками. В корне проекта лежит Dockerfile, использующий multi-stage сборку. Сначала стартует Node, запускает npm run build через Vite, а затем берет легкий образ Nginx и подкладывает туда готовую папку dist. Файл nginx.conf настроен на отдачу index.html и сжатие статики.

Теория архитектуры — это прекрасно, но настоящая проверка происходит в бою. На сегодняшний день на платформе успешно зарегистрировано уже более 2 000 пользователей.

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

Для бэкенда это был огромный стресс. А фронтенд справился безупречно. Поскольку мы использовали статический деплой (SPA, отдаваемый через Nginx), генерация страниц вообще не требовала серверных процессорных мощностей. Nginx просто отдавал кэшированные статические файлы JS и CSS.

Те редкие API-запросы, которые в первые минуты падали по таймауту из-за перегрузки бекенда, мягко перехватывались нашим errorListenerMiddleware, показывая дружелюбные уведомления. Архитектура выдержала пик конкурса без единого сбоя на стороне клиента.

Написать сложный фронтенд в одиночку и довести его до продакшена — абсолютно реальная задача. Ключ к успеху не в бессонных ночах (хотя и в них тоже), а в строгой дисциплине.

Созданная архитектура позволила запустить продукт в сжатые сроки. Она выдержала испытание реальной нагрузкой, и теперь, по мере роста продукта, мы можем легко масштабировать кодовую базу и подключать новых фронтендеров — проект к этому полностью готов.