Почти неделю назад, однажды в пятницу утром, я дал внутренний отчет группе разработчиков компании.
Речь шла о довольно занимательном командном опыте ремастеринга проекта посредством использования наборов, в наше время уже не новых практик и подходов, но ранее неизвестных мне.
Применив ряд рецептов, я сравнил показатели производительности двух версий легаси и ремастер-системы и был, мягко говоря, приятно удивлён.
Такие подходы, как отделение слоя пользовательского интерфейса от монолита, SPA и технологии прогрессивного рендеринга, заставили меня взглянуть на веб-разработку совершенно по-другому.
Недолго думая, я решил вынести доклад на улицу и рассказать о нашем опыте тем, кто раньше работал только с монолитной архитектурой WEB-проектов.
Мое самое первое знакомство с вышеописанными практиками произошло через разработку проектов ПЭТ, о которых я рассказывал в предыдущих статьях, например» История одного видеоредактора ” 
Потом я стал присматриваться к этим подходам и технологиям более внимательно.
И после того, как мы всей командой столкнулись с перечнем проблем в рамках рабочего проекта, я начал понимать, что изученный мной набор рецептов должен был решить большинство неприятных нюансов.
Прежде чем начать свой рассказ, мне следует лишь коснуться идеи самого проекта.
Продукт представлял собой сервис для подписания и проверки электронных документов.
Сервис предназначен для формирования и проверки электронной подписи под документом.
Первоначальная бизнес-идея была довольно простой — цифровизация документооборота внутри компании, но запросы на масштабирование не заставили себя долго ждать.
На момент завершения разработки MVP-версии продукта это была обычная монолитная архитектура, построенная на следующих технологиях: 
Позже поступил запрос на разработку API для всего уже существующего в системе функционала.
Никаких сложностей при разработке это не вызвало, так как изначально все функции были упакованы как сервисы и оставалось только разработать интерфейс для API и использовать существующую бизнес-логику.
Разработка API была необходима для того, чтобы дать нашим партнерам возможность строить свои приложения на основе нашего функционала.
Когда все бизнес-функции системы были покрыты API-интерфейсом, возникло вполне логичное понимание того, что WEB, как и любые другие платформы, может использовать API и быть похожим на нативное приложение, существующее отдельно от монолита.
Далее в команду был привлечен UI/UX специалист для работы над WEB-интерфейсом.
И в этот момент возникло понимание, что элементы интерфейса стали выходить за границы шаблонных представлений.
Появлялось все больше различных нетривиальных графических компонентов, которые нужно было создавать с абсолютного нуля и иметь возможность повторно использовать их в различных частях приложения, причем именно по заявленному дизайнером макету.
Все эти графические компоненты должны были работать очень быстро, чтобы улучшить взаимодействие с пользователем.
Больше компонентов — больше данных.
Следующая проблема, которая, конечно, не была актуальной на тот момент, но очень скоро могла ею стать, — это производительность.
Все эти проблемы дали нам понять, что стоит отойти от прежнего типового, в нашем случае, подхода и посмотреть на построение проекта под другим углом.
Мы не изобретали велосипед, так как решение уже существовало и уже очень давно используется огромным количеством компаний по всему миру.
Более того, у меня уже был опыт работы в собственных проектах ПЭТ, в которых я использовал подобные подходы.
Не было необходимости вводить эксперименты в проект. В рамках нового подхода было решено использовать три концепции:
- Возьмите ВЕБ из камня;
- Конвертировать WEB в SPA;
- Применяйте прогрессивные технологии рендеринга.
В результате за лицевую часть отвечали двое разработчиков из нашей команды, а один работал «под капотом».
Для реализации всех ранее описанных подходов в WEB части необходимо было выбрать инструмент. При выборе я руководствовался тремя правилами:
- Проверенная технология
- Долгосрочная поддержка
- Отличное сообщество
Первым шагом на пути ремастера стал перенос всех представлений монолита из шаблонизатора Twig в компоненты React. 
В плане улучшения системы мы выбрали эволюционный и итеративный подход. В самом начале мы как команда определили примерно двухнедельный план выпуска списка функций, которые должны войти в действие.
В этот план релиза мы включили как бизнес-задачи, так и задачи, связанные с переходом на новые решения.
Например, в одном из планов релиза стояла задача перенести функцию создания процессов на React. Создание процесса — функция, организующая процесс согласования документов.
Создание процесса имеет простую форму со следующими полями:
- Имя процесса
- Примечание
- Файл (документ)
- Подписчик списка с возможностью поиска
- Кнопка создания процесса
Несмотря на то, что большая часть функций уже была реализована в API, некоторые API еще необходимо было создать.
Во-первых, нам нужно было понять, какие методы API нам нужны для реализации функции создания процесса, которую нам нужно было использовать на этой странице.
Вот тут-то и становится очевидным, что нам нужно.
- Получение списка подписантов
- Поиск среди подписантов
- Создание процесса
Как только всем в команде стало ясно, что нужно делать, мы приступили к производственному процессу, и это происходило параллельно.
Поскольку интерфейс ответа был определен, участники клиентской части имитировали объекты и разрабатывали компоненты, а участники внутренней части разрабатывали API. Мы, как фронтенд-разработчики, просто избавились от всего презентационного кода из twig-файлов и сделали в этом файле единый контейнер, куда рендерился весь реактивный код. Когда API было готово, участники фронтенда взяли API и.
используя реальные данные.
вместо макетов объектов проверялись на работоспособность компоненты интерфейса Когда вся команда выполнила свою работу, была записана куча задач и передана в отдел тестирования.
Таким образом, итерацию можно назвать завершенной.
Затем мы взяли следующую страницу и повторили цикл.
Таким образом, шаг за шагом мы перенесли все представления веток в React. В рамках того же этапа перехода слоя представления на React мы использовали технологию прогрессивного рендеринга — ленивую загрузку — для повышения производительности и улучшения взаимодействия с пользователем.
Здесь следует привести пример, основанный на той же функции создания процесса.
Мы задали себе вопрос: «Какие данные на этой странице мы получаем от APIЭ» В нашем случае это получение списка потенциальных подписантов, а также данных о пользователях при поиске.
Следующий вопрос, который мы себе задали, был: «Действительно ли нужно загружать эти данные при запуске страницыЭ» В нашем случае ответ был отрицательным, поскольку эти данные могут быть загружены только в момент взаимодействия пользователя с компонентом.
Мы немного изменили это правило.
Поскольку запрос асинхронный, то загружать данные в форму лучше после сборки компонента выпадающего списка, а не во время взаимодействия с этим списком.
Цель — исключить ожидание получения данных в момент нажатия.
На момент загрузки данных мы ограничили их количество 10 записями и при прокрутке загружалась следующая порция.
И прежде чем мы начали использовать подход отложенной загрузки, мы задали себе два вопроса:
- Какие данные на этой странице мы получаем от API?
- Действительно ли эти данные нужно загружать при запуске страницы?
Подход загрузки данных при сборке компонентов интерфейса позволил нам опробовать метод прогрессивной отрисовки страниц, когда информация загружается в компоненты пошагово.
Вместо того, чтобы смотреть на загрузчик браузера и ожидать всю страницу.
Когда мы шаг за шагом подошли к финальному этапу миграции всего интерфейса на React и применения прогрессивных технологий рендеринга, пришло время отделить интерфейс от монолита.
Мы взяли весь реактивный код из монолитных представлений и перенесли его в новую среду, настроили проксирование к API на уровне веб-сервера, чтобы избежать проблем с CORS, и внедрили CI для сборки внешнего интерфейса.
Подводя итог, сравнивая результаты отображения одной и той же страницы в легаси-версии и ремастере, у первой на формирование страницы без учета кэша ушло 1,22 секунды, а у второй сама страница отрисовывалась за 40 миллисекунд, а для загрузки данных с подписантами потребовалось 512 миллисекунд и эти самые полсекунды происходили в асинхронной форме, невидимой для пользователя.
И помимо всех описанных выше преимуществ, весь асинхронный контент загружался в формате прогрессивного рендеринга и не требовал ожидания всей страницы, как в устаревшей версии, что должно улучшить пользовательский опыт для клиентов.
В результате, разделив зону ответственности внутри команды и применив эволюционный и итеративный подход, мы смогли без потерь для кого-либо реализовать наш план и улучшить качество обслуживания клиентов.
Слова благодарности Хочу выразить благодарность своей команде, отделу тестирования, менеджерам проектов и компании Wooppay в целом за возможность получить столь масштабный опыт, а также платформе Хабра за возможность поделиться практикой.
.
Видеоотчет Теги: #CSS #JavaScript #HTML #frontend #php #web #symfony #react.js #react
-
Отказ От Архитектуры Powerpc
19 Oct, 24
