Инженерная задача
Построить единый поддерживаемый фронтенд для нескольких связанных финтех-сценариев, большого объёма данных, прав доступа и меняющихся состояний продукта.
Research Platform
- Фокус
- Фронтенд / финтех
- Год
- 2024-2026
- Стек
- React · TypeScript · TanStack Query · Tailwind CSS · Puppeteer
Моя роль
Фронтенд-разработчик + продуктовый дизайнер. Отвечал за клиентскую реализацию и доводил решения по взаимодействию до рабочего кода.
Объём работ
Архитектура React · TypeScript · интеграция с API · переиспользуемые компоненты · адаптивные состояния · PDF-шаблоны · аналитика и тестирование
Результат
Запущен клиентский портал с поиском компаний, заказом исследований, управлением отчётами, ИИ-анализом и сценариями вторичного рынка.
Я разработал клиентскую часть финтех-платформы для инвестиционных исследований — от логики взаимодействия до рабочего кода на React. Фронтенд объединяет несколько связанных сценариев: поиск компаний, заказ исследований, доступ к отчётам, вторичный рынок и анализ с помощью ИИ. При этом права доступа, загрузочные состояния, адаптивное поведение и переиспользуемые компоненты должны работать единообразно во всём продукте.
Масштаб реализации
20+
маршрутов приложения
5
связанных разделов продукта
3
инструмента аналитики и обратной связи
50+
наборов автотестов
По мере развития приложение превратилось в систему из нескольких связанных продуктовых разделов, а не набор отдельных страниц. Я реализовал общую навигацию, переиспользуемые способы работы с данными и взаимодействиями, состояния на уровне маршрутов и единое поведение для поиска компаний, заказа исследований, отчётов и вторичного рынка.
От требований к структуре приложения
Исходные требования описывали бизнес-разделы и связи между ними, но не детали реализации. Я переводил их в границы приложения, навигационные сценарии, состояния интерфейса и переиспользуемые фронтенд-паттерны, которые можно было расширять по мере роста продукта.
От ранней реализации к переиспользуемой архитектуре
Ранние реализации быстро показали, где решения для отдельных страниц станут дорогими в поддержке. По мере роста продукта повторяющееся поведение переносилось в общие компоненты и более чёткие продуктовые границы, что уменьшало дублирование логики и упрощало добавление новых сценариев.
Поддерживаемая продуктовая система
В результате фронтенд организован вокруг переиспользуемых продуктовых примитивов, а не одноразовых экранов. Поиск компаний, заказ исследований, доступ к отчётам и вторичный рынок используют общие модели состояний и единый язык компонентов.
Сложные сценарии на мобильном экране
Те же состояния приложения и права доступа должны работать на узком экране без механического сжатия десктопной версии. Я менял приоритет информации, расположение действий и композицию компонентов, сохраняя общую логику сценариев.
PWA и кэширование во время работы делают портал устойчивее на мобильных устройствах и приближают веб-приложение к поведению устанавливаемого приложения.
Мобильная версия рассматривалась как отдельная среда с жёсткими ограничениями, а не уменьшенный десктоп. На узких экранах менялись приоритет информации, расположение действий и композиция компонентов, при этом права доступа, состояния исследований и логика сценариев оставались теми же.
Дизайн-система в React
Дизайн-система стала рабочей системой компонентов: токены цвета, типографики, отступов и состояний, а также переиспользуемые элементы и доменные компоненты для данных компаний, фильтров, доступа к исследованиям, действий заказа и финансового контента. Целью была не только визуальная согласованность, но и предсказуемое поведение реализации.
Интерфейс построен как система переиспользуемых React-компонентов, а не отдельная вёрстка каждой страницы. Компоненты инкапсулируют визуальные состояния, правила взаимодействия и адаптивное поведение, поэтому изменения можно распространять по продукту без дублирования логики.
Серверная генерация PDF
Отдельно я сделал клиентские шаблоны для конвейера генерации PDF. React-компоненты формируют A4-отчёты с финансовыми блоками, графиками, многостраничными таблицами и композицией для печати, а headless Chromium/Puppeteer обеспечивает стабильный серверный рендеринг документов.
Совмещение продуктового дизайна и фронтенд-разработки сокращало разрыв между макетом и реальным поведением: решения по взаимодействию можно было сразу проверять на настоящих компонентах, ограничениях API и адаптивных состояниях.