Масштабируемость — одно из основных нефункциональных требований для современных веб-приложений. Чтобы получать от них ожидаемую производительность по мере развития проекта, важно сразу обеспечить хорошую масштабируемость как самого приложения, так и процессов разработки.
Однако сегодня эта сложная задача требует учета множества составляющих факторов. Рассмотрим 10 наиболее важных из них.
1. Архитектура приложения
Архитектура приложения — наиболее важный аспект при разработке проекта. При этом традиционно предпочитают монолитную архитектуру, поскольку она упрощает процессы разработки, отладки и тестирования за счет единой базы кода всего приложения.
Такой подход прекрасно работает на ранних стадиях разработки, но приводит к серьезным трудностям по мере развития приложения. Придется поддерживать все компоненты и службы в единой кодовой базе, использовать единый конвейер для сборок и выпусков. В результате даже при небольшом изменении в одном компоненте для завершения выпуска потребуется много времени. С масштабируемостью монолитной архитектуры есть и немало других проблем. Поэтому в современных приложениях не рекомендуется ее применять.
Вместо нее для создания масштабируемых фронтенд-приложений можно использовать более сложный подход c архитектурой микрофронтендов. Она позволяет разбивать кодовую базу на более мелкие части и поддерживать их по отдельности. Разные команды разработчиков могут разрабатывать, создавать, тестировать и выпускать каждый микрофронтенд независимо. По сравнению с монолитной архитектурой этот подход работает намного быстрее, и можно легко масштабировать приложение, не влияя на его производительность и скорость разработки.
Кроме того, для создания архитектуры микрофронтендов в приложении можно использовать специализированные инструменты и инфраструктуру, например Bit. Этот инструмент используют в масштабируемых фронтенд-приложениях Dell, eBay и Tesla.
2. Инфраструктура и инструменты
При создании масштабируемых фронтенд-приложений также важно выбрать необходимые инструменты и инфраструктуры. Правильное решение позволит легко автоматизировать большую часть рутинных операций и сэкономит много времени для основных задач.
Например, обзор качества кода — это трудоемкая задача. До определенного уровня ее можно выполнять и вручную. Но в какой-то момент это станет барьером для масштабируемости приложений. Легко автоматизировать процесс проверки кода и упростить масштабирование приложения позволит такой инструмент, как SonarCloud.
С помощью специальных инструментов можно доработать и многие другие составляющие фронтенд-архитектуры.
- Линтинг (Linting). Проверка соблюдения стандартов программирования, например с помощью Prettier, позволяет за считанные секунды форматировать и поддерживать во всем проекте единый стиль кода.
- Начальная загрузка — автоматизация создания исходной структуры проекта и установки пакета.
- Управление компонентами. Компоненты выполняют особенно важную роль в архитектуре микрофронтендов. Поэтому для их создания, обслуживания и совместного использования между микрофронтендами нужен надлежащий механизм. Например, Bit позволяет разрабатывать распределенные компоненты с модульной архитектурой, автономными командами, несвязанными кодовыми базами и независимыми выпусками.
- Управление зависимостями. Автоматизация управления зависимостями — еще одна важная задача, поскольку невозможно по мере развития приложения вручную поддерживать сотни зависимостей, управлять ими между приложениями и группами. Bit отлично подходит и для этой задачи.
- Развертывания. Ручное развертывание множества микрофронтендов занимает много времени. Вместо этого можно инициировать автоматическое развертывание кода в таких инструментах CI/CD, как GitHub Actions и Azure Pipelines.
3. Моно- и мультирепозитории
Выбор между моно- и мультирепозиторием — еще одно важное решение, принимаемое при разработке фронтенд-приложения. Оба подхода придают архитектуре проекта некоторые уникальные особенности и проблемы, которые необходимо анализировать с учетом требований проекта.
Монорепозитории
Монорепозиторий имеет единую кодовую базу для всех микрофронтендов. Такой дизайн упрощает обмен кодом между микрофронтендами и совместную работу команд, имеющих общий доступ к репозиторию. Кроме того, в одном месте можно хранить все наборы тестов, сценарии автоматизации и конфигурации инфраструктуры. Однако монорепозитории усложняют процесс развертывания и часто вызывают конфликты в общем коде.
Мультирепозитории
Подход с мультирепозиториями противоположен монорепозиториям. В мультирепозиториях каждый компонент или проект будет иметь отдельный репозиторий. Такой дизайн помогает индивидуально контролировать доступ в репозиторий и избегать множества конфликтов кода между командами. Однако совместно использовать код в мультирепозиториях будет сложнее, чем в монорепозиториях.
4. Технологический стек
Выбор надежного стека технологий — еще один важный этап создания масштабируемого приложения. Всегда нужно планировать будущее развитие приложения, выбирая технологический стек, который можно эффективно масштабировать в соответствии с постоянно меняющимися потребностями клиента или фреймворка.
Вот некоторые особенности масштабируемого стека технологий.
- Непрерывные обновления.
- Программа будущих версий.
- Поддержка сообщества.
- Хорошая экосистема со сторонними библиотеками и инструментами.
- Хорошая документация.
Кроме того, рекомендуется учитывать и принятый в организации стек, поскольку он позволяет разработчикам быстро знакомиться со всеми проектами организации. Примечательно, что если использовать микрофронтенды, стандартный технологический стек способствует совместному использованию кода и сотрудничеству между разработчиками. Однако бывают ситуации, когда приходится выходить за эти рамки. Например, если проекту требуются определенные технологии, то при выборе стека, возможно, придется пойти против норм организации и сообщества.
Кроме того, нужно тщательно выбирать каждый из компонентов стека с учетом их совместимости. Фронтенд-стек обычно включает: фреймворк, язык, процессор стилей, тестирование, управление состоянием, лининг и инструменты сборки.
Например, базовый стек технологий на основе React будет включать:
- React;
- TypeScript;
- стилизованные компоненты;
- Jest;
- Redux;
- Prettier;
- Webpack.
5. Шаблоны компонентов
Компоненты являются основным строительным блоком современных фронтенд-приложений. Они расширяют возможности повторного использования кода, позволяют масштабировать приложение с минимальными усилиями. Например, создавая платформу для онлайн-продаж, можно написать один компонент для отображения сведений о продукте и использовать его в перечне всех продуктов проекта.
Тем не менее для совместимости нужно поддерживать согласованный дизайн во всех компонентах. Поэтому всегда полезно использовать генератор шаблонов компонентов, а не создавать их вручную.
Например, React, Angular и Vue.js позволяют создавать шаблоны компонентов через интерфейс командной строки.
6. Межпроектные зависимости
Сегодня совместное использование кода — одна из наиболее популярных концепций во фронтенд-приложениях. Несмотря на стремление к архитектуре микрофронтендов для улучшения масштабируемости приложений, разработчики по-прежнему используют преимущества совместно используемого кода.
Например, иногда нужно использовать компонент из другого микрофронтенда или приложения. Таким образом, возникнет зависимость между разными микрофронтендами и проектами.
7. Процесс сборки и тестирования
Тестирование гарантирует работоспособность приложения, в частности при модификации кода. Перед сборкой и выпуском приложения нужно выполнять тесты, чтобы проверить поведение нового кода и его влияние на другие части приложения.
Одна из наиболее распространенных стратегий тестирования, используемая при разработке фронтенда, включает модульные, E2E и интеграционные тесты. Для небольшого приложения эти тесты можно легко запустить и после внесения изменений собрать приложение вручную. Но по мере масштабирования приложения этот процесс необходимо автоматизировать, чтобы избежать ограничений.
Например, для каждого из микрофронтендов нужно поддерживать отдельные конвейеры сборки и тестирования. Но для сотни микрофронтендов отслеживать каждый вручную нецелесообразно. В таких ситуациях после фиксации изменения в кодовой базе для запуска тестирования и создания конвейеров можно использовать такие инструменты, как GitHub Actions и Azure Pipelines.
8. Взаимодействие с бэкендом
Взаимодействие между серверной (бэкенд) и клиентской (фронтенд) частью — еще одна важная составляющая масштабируемости приложения. Например, чрезмерная обработка данных во фронтенд может привести по мере масштабирования приложения к проблемам с производительностью и взаимодействием с пользователем. Поэтому всегда нужно стараться выполнять большую часть вычислений на сервере, а клиенту передавать лишь необходимые данные.
Кроме того, для перемещения фронтенд-логики на промежуточный уровень можно использовать такие шаблоны проектирования, как BFF (Backend for Frontend). Это позволит значительно снизить нагрузку на фронтенд, не полагаясь на серверную часть. Новый промежуточный уровень будет связываться с серверными службами, выполнять вычисления и отправлять отформатированные результаты во фронтенд. Таким образом, можно масштабировать фронтенд, не беспокоясь о производительности.
9. Стилизация
Стилизация — неотъемлемая часть разработки фронтенда. Она позволяет добавлять приложению уникальность, улучшая его внешнее представление. Однако поддержание общего согласованного стиля может оказаться сложной задачей при масштабировании.
Предположим, что нужно масштабировать приложение, включающее от 10 до 100 компонентов. В этом случае для обеспечения согласованности необходимо поддерживать те же цвета, шрифты, поля, границы и все остальные стили во вновь созданных компонентах. Этот трудоемкий процесс может сопровождаться ошибками.
В результате приобрела популярность темизация на основе компонентов, а также логика и стили разделения. Эти методы позволяют создавать компоненты с одинаковыми стилями и повторно использовать их в проектах, обновляя только бизнес-логику.
10. Сотрудничество разработчиков
Сотрудничество между разработчиками — еще одна центральная тема, которую необходимо учитывать при разработке масштабируемых приложений. Чтобы избежать повторяющейся работы и повысить производительность команды, разработчики должны правильно координировать действия. Синхронизация позволяет легко внедрять новые функции и масштабировать приложение без задержек в разработке.
Но часто несколько разработчиков должны работать над одной и той же частью или компонентом приложения. Во избежание лишних конфликтов в таких ситуациях каждый должен хорошо понимать, что делают другие. Чтобы синхронизировать кодовые базы и легко обрабатывать конфликты на уровне кода, можно использовать методы контроля версий.
Вывести совместную работу на новый уровень помогают такие инструменты, как Storybook и Bit. Они позволяют создать область, совместно используемую для экспорта, импорта и модификации компонентов. Кроме того, можно просмотреть и сравнить внесенные в компонент изменения перед их принятием.
Заключение
В этой статье рассмотрено 10 важных аспектов, которые следует учитывать при разработке масштабируемого фронтенд-приложения.
Читайте также:
- Элементы архитектуры веб-приложений
- 7 вопросов по фронтенд-разработке
- Движки JavaScript. Часть 1: парсинг
Читайте нас в Telegram, VK и Дзен
Перевод статьи Chameera Dulanga: Scaling Frontend Applications in 2023
