Download to read offline
Uploaded byRoman Dvornov
Масштабируемая архитектура фронтенда
Документ обсуждает масштабируемую архитектуру фронтенда, используя примеры из опыта работы в компании Avito. Основное внимание уделяется различиям между проектами и функциональными командами, а также принципам организации разработки и управления зависимостями. В заключение подчеркивается важность модульности, дизайна систем и применения общих подходов в разработке интерфейсов.
More Related Content
Similar to Масштабируемая архитектура фронтенда
Масштабируемая архитектура фронтенда
- 1.
- 2. Работаю в Avito Opensource: basis.js, CSSO, component-inspector, csstree, rempl и другие github.com/lahmatiy twitter.com/rdvornov rdvornov@gmail.com
- 3.
- 4. Avito – несколькосайтов и SPA
- 5.
- 6.
- 7.
- 8. Разница между сайтоми SPA в том, что... 6
- 9. Разница между сайтоми SPA в том, что... 6 🤔
- 10. Когда все просто 7 Feature1 Feature 2 Feature N... ProjectTeam
- 11. Когда все сложно 8 Feature1 Feature 2 Feature N... Project 1 Project 2 ... Project N
- 12. Когда все сложно 8 Feature1 Feature 2 Feature N... Project 1 Project 2 ... Project N Team Team Team
- 13. Когда все сложно 8 Feature1 Feature 2 Feature N... Project 1 Project 2 ... Project N Team Team Team
- 14. «Проект» сайт/SPA, страница, приложение(mobile) 9
- 15. В чем разница •Проект-команда • Плохая предсказуемость доставки фичи, сложно приоритезировать, разное понимание • Фича-команда • Много разных интеграций, но хорошая предсказуемость и проработка фич 10
- 16. В чем разница •Проект-команда • Плохая предсказуемость доставки фичи, сложно приоритезировать, разное понимание • Фича-команда • Много разных интеграций, но хорошая предсказуемость и проработка фич 10 Было Сейчас
- 18. Команда 1 Команда 2 Команда3 Команда 4 Команда 5
- 19. Проблемы больших продуктов •Больше «проектов» – больше точек интеграции • Увеличивается число команд с одной кодовой базой • Постоянно усложняется (новые фичи) • Растет кодовая база и техдолг (легаси) • ... 12
- 20. Как будем лечить •Экосистема страниц • Организация процессов разработки • Платформа 13
- 21.
- 22. Экосистема страницы задает окружениедля компонент/блоков, избавляя от решения типовых задач 15
- 23. Типовые задачи • Лейаутстраницы • Управление слоями • Загрузка и управление зависимостями • Источники данных (модели, нотификация) • Персистентное хранение данных • Транспорт • Роутинг • и т.д. 16
- 25.
- 26. Layout Slot 1 Slot2 Slot N ... Core
- 27. Layout Slot 1 Slot2 Slot N ... Core Block 1 Block 2 Block N
- 28. Layout Slot 1 Slot2 Slot N ... Core Block 1 Block 2 Block N ...Plugin 1 Plugin 2 Plugin N
- 29. Layout Slot 1 Slot2 Slot N ... Core Block 1 Block 2 Block N ...Plugin 1 Plugin 2 Plugin N Common Public API
- 30. Layout Slot 1 Slot2 Slot N ... Core Block 1 Block 2 Block N Plugin Method 1 Plugin Method 2 ... ...Plugin 1 Plugin 2 Plugin N Common Public API
- 31. Layout Slot 1 Slot2 Slot N ... Core Block 1 Block 2 Block N Plugin Method 1 Plugin Method 2 ... Browser API ...Plugin 1 Plugin 2 Plugin N Common Public API
- 32. Layout Slot 1 Slot2 Slot N ... Page Ecosystem Core Block 1 Block 2 Block N Plugin Method 1 Plugin Method 2 ... Browser API ...Plugin 1 Plugin 2 Plugin N Common Public API
- 33.
- 34. Блоки не используютбраузерное API, а используют API ядра и его плагинов 19
- 35.
- 36. Block 1 Block 2 Server GET/what/ever
- 37. Block 1 Block 2 Server GET/what/ever GET /what/ever
- 38.
- 39.
- 40.
- 41.
- 42.
- 43. Экосистема – черныйящик 22
- 44. Что может быть •Запрос к серверу • Данные из кеша • Синхронизация между закладками • SSE/WebSocket/ServiceWorker/etc • ... 23
- 45. Что может быть •Запрос к серверу • Данные из кеша • Синхронизация между закладками • SSE/WebSocket/ServiceWorker/etc • ... 23 Progressive enhancement
- 46. Реализация экосистемы может... • Меняться (подходы и технологии) • Различаться от проекта к проекту • Совершенствоваться со временем • ... • Блокам/компонентам все равно 24
- 47. Плюшки • Стенд дляразработки блока • Моки без костылей • Реализации под «среду» • браузер • серверный рендеринг • тесты 25
- 48. Общее публичное API CommonPublic API
- 49.
- 50. Зачем? • Переиспользование блоковбез адаптации к API • Используем подходящую реализацию ядра, в зависимости от среды • Проще новые интеграции (меньше учить) 28
- 51.
- 52. «Нет» монолитам! • Подключение(с динамической подгрузкой) дополнительной функциональности в ядро по принципу плагинов • Интерфейсы декомпозируются на логические блоки, с динамической подгрузкой (включая зависимости) и обновлением 30
- 53. Подход подразумевает • Функциональность(API) экосистемы расширяется (догружается) по мере потребностей блоков • Разные версии одних и тех же зависимостей в рамках одного окружения (страницы) • Блоки взаимодействуют только с публичным API • Креш блока не тянет за собой все остальное 31
- 54. Точки отказа • Ядро– единственная критическая часть, ничего не будет работать • Плагин ядра – не будут работать плагины и блоки, которые от него зависят • Блок – проблемы блока никого не касаются 32
- 55.
- 56. Экосистема страницы • Абстракцияот окружения • Общее публичное API • Модульность 34
- 57.
- 58. Порядок и комфорт •Владение кодом • Независимость команд • Контроль зависимостей и версий • Инкрементальные рефакторинг и миграция 36
- 59.
- 60. Общее – значитничье 38
- 61. У каждого «компонента»системы должен быть определен единственный владелец 39
- 62. Компонент это • Репозиторий •Директория или файл (модуль) • npm-пакет • Страница • Чанк • ... 40
- 63. Информация хранится вбазе знаний (реестре) 41
- 64.
- 65. Action plan • Проблема,баг или вопрос? • Определяется релевантный компонент, с которым это связано и его владелец • Направляется запрос владельцу • Владелец решает вопрос сам или переадресует другим, но контролирует его разрешение 43
- 66.
- 67. Команды минимизируют взаимодействие междусобой при реализации фич, исправлении багов и релизах 45
- 68. Независимость команд • Модульность:блоки (функциональность) изолируются в пакеты • Могут использовать собственную версию зависимости, апгрейдится в удобное время • Поддержка более мягких интеграций • Автоматизация тестирования 46
- 69. Типы интеграции • Жесткаяинтеграция – изменения кода компонента (требуется публикация пакета, пересборка и релиз зависимых модулей и проектов) • Конфигурационная интеграция – изменение конфигурации экземпляра компонента (требуется пересборка и релиз модуля и проекта) • Мета интеграция – конфигурация блока описывается и хранится вне кода (не требует пересборки и релиза) 47
- 70.
- 71. Чтобы избежать Dependencyhell – регулярный сбор и анализ зависимостей 49
- 72.
- 73.
- 74.
- 75.
- 76. Нельзя так простовзять и все зарефакторить
- 77. Возможность производить рефакторинг илимиграцию на новые решения и технологии поэтапно 55
- 78. Инкрементальный рефакторинг • Возможностьне делать все сразу • Рефакторинг не больше недели → релиз • Толерантность к легаси – старое должно продолжать работать без приложения усилий (консервация до лучших времен) 56
- 79. Мы сейчас всезапилим с нуля и все станет хорошо 57
- 80. Мы сейчас всезапилим с нуля и все станет хорошо 57
- 81.
- 82. Управление разработкой • Владениекодом • Независимость команд • Управление зависимостями и версиями • Инкрементальный рефакторинг 59
- 83.
- 84. Платформа – рекомендованный набор техническихрешений в компании 61
- 85.
- 86. Общие подходы кразработке интерфейсов, готовые UI компоненты и инструментарий 63
- 87. Дизайн система • UIKit (для дизайнеров) • UI компоненты (для разработчиков) • Каталог UI компонент • Общие паттерны и решения • ... 64
- 89.
- 90. Меньше зоопарк технологий– дешевле делать общие решения 67
- 91. Tech Radar 68 Build YourOwn Technology Radar Подробнее в статье:
- 92.
- 93. Инфраструктура • Сборка проектов •Управление зависимостями, публикациями и версиями • Организация тестирования (настройка, инструменты, хелперы etc) • Репортинг (ошибки, performance, etc), мониторинг, Health Check • База знаний • Скрипты по сбору данных (анализ кода, тегирование, etc) • ... 70
- 94. Модульность → репыи пакеты → затраты на поддержку 71
- 95. По моему скромномуопыту: настроить проект с нуля, имея опыт, занимает несколько часов, не считая поддержки 72
- 96. Инфраструктура – невсегда готовое • Unit-тестирование скриншотами: преодолеваем звуковой барьер – Роман Дворнов видео, расшифровка • Скриншоты как сервис – Сергей Мелюков видео 73
- 97. Идеальная настройка 74 { ... "dependencies": { "@avito/platform":"latest", ... } } package.json
- 98.
- 99. Платформа • Дизайн система •Ограниченный технологический стек • Инфраструктура 76
- 100.
- 101. Если вам показалось, что все просто и логично – отлично, так и задумано! 78
- 102. не верьте мнена слово 😉 79 Не все еще проверено в реальных условиях
- 103. не верьте мнена слово 😉 79 Не все еще проверено в реальных условиях Ожидайте update через полгода
- 104.