Масштабируемая архитектура фронтенда
•
0 likes•174 views
Когда проект делает один разработчик — все просто. Когда над ним работает небольшая команда, можно синхронизироваться и договориться. А вот когда проектов (сайтов и приложений) становится много, и над ними трудится множество команд с перекрестной функциональностью и смежными зонами ответственности, все становится сложным и запутанным. Я расскажу о своем виденье архитектуры фронтенда, какой она должна быть, чтобы обеспечить её масштабируемость. На основе своего опыта и проблем, с которыми сталкиваются большие проекты. Видео: https://www.youtube.com/watch?list=PLknJ4Vr6efQFtZmsXmGG64Rz_PHrcXCBL&v=z9y6PNC2FL0
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Масштабируемая архитектура фронтенда
Similar to Масштабируемая архитектура фронтенда (20)
More from Roman Dvornov
More from Roman Dvornov (20)
Масштабируемая архитектура фронтенда
- 2. Работаю в Avito Open source: basis.js, CSSO, component-inspector, csstree, rempl и другие github.com/lahmatiy twitter.com/rdvornov rdvornov@gmail.com
- 3. Контекст
- 4. Avito – несколько сайтов и SPA
- 8. Разница между сайтом и SPA в том, что... 6
- 9. Разница между сайтом и SPA в том, что... 6 🤔
- 10. Когда все просто 7 Feature 1 Feature 2 Feature N... ProjectTeam
- 11. Когда все сложно 8 Feature 1 Feature 2 Feature N... Project 1 Project 2 ... Project N
- 12. Когда все сложно 8 Feature 1 Feature 2 Feature N... Project 1 Project 2 ... Project N Team Team Team
- 13. Когда все сложно 8 Feature 1 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
- 22. Экосистема страницы задает окружение для компонент/блоков, избавляя от решения типовых задач 15
- 23. Типовые задачи • Лейаут страницы • Управление слоями • Загрузка и управление зависимостями • Источники данных (модели, нотификация) • Персистентное хранение данных • Транспорт • Роутинг • и т.д. 16
- 25. Core
- 26. Layout Slot 1 Slot 2 Slot N ... Core
- 27. Layout Slot 1 Slot 2 Slot N ... Core Block 1 Block 2 Block N
- 28. Layout Slot 1 Slot 2 Slot N ... Core Block 1 Block 2 Block N ...Plugin 1 Plugin 2 Plugin N
- 29. Layout Slot 1 Slot 2 Slot N ... Core Block 1 Block 2 Block N ...Plugin 1 Plugin 2 Plugin N Common Public API
- 30. Layout Slot 1 Slot 2 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 Slot 2 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 Slot 2 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
- 34. Блоки не используют браузерное API, а используют API ядра и его плагинов 19
- 36. Block 1 Block 2 Server GET /what/ever
- 37. Block 1 Block 2 Server GET /what/ever GET /what/ever
- 43. Экосистема – черный ящик 22
- 44. Что может быть • Запрос к серверу • Данные из кеша • Синхронизация между закладками • SSE/WebSocket/ServiceWorker/etc • ... 23
- 45. Что может быть • Запрос к серверу • Данные из кеша • Синхронизация между закладками • SSE/WebSocket/ServiceWorker/etc • ... 23 Progressive enhancement
- 46. Реализация экосистемы может ... • Меняться (подходы и технологии) • Различаться от проекта к проекту • Совершенствоваться со временем • ... • Блокам/компонентам все равно 24
- 47. Плюшки • Стенд для разработки блока • Моки без костылей • Реализации под «среду» • браузер • серверный рендеринг • тесты 25
- 48. Общее публичное API Common Public API
- 50. Зачем? • Переиспользование блоков без адаптации к API • Используем подходящую реализацию ядра, в зависимости от среды • Проще новые интеграции (меньше учить) 28
- 51. Модульность
- 52. «Нет» монолитам! • Подключение (с динамической подгрузкой) дополнительной функциональности в ядро по принципу плагинов • Интерфейсы декомпозируются на логические блоки, с динамической подгрузкой (включая зависимости) и обновлением 30
- 53. Подход подразумевает • Функциональность (API) экосистемы расширяется (догружается) по мере потребностей блоков • Разные версии одних и тех же зависимостей в рамках одного окружения (страницы) • Блоки взаимодействуют только с публичным API • Креш блока не тянет за собой все остальное 31
- 54. Точки отказа • Ядро – единственная критическая часть, ничего не будет работать • Плагин ядра – не будут работать плагины и блоки, которые от него зависят • Блок – проблемы блока никого не касаются 32
- 55. Итоги
- 56. Экосистема страницы • Абстракция от окружения • Общее публичное API • Модульность 34
- 58. Порядок и комфорт • Владение кодом • Независимость команд • Контроль зависимостей и версий • Инкрементальные рефакторинг и миграция 36
- 59. Владение кодом
- 60. Общее – значит ничье 38
- 61. У каждого «компонента» системы должен быть определен единственный владелец 39
- 62. Компонент это • Репозиторий • Директория или файл (модуль) • npm-пакет • Страница • Чанк • ... 40
- 63. Информация хранится в базе знаний (реестре) 41
- 64. Пример 42
- 65. Action plan • Проблема, баг или вопрос? • Определяется релевантный компонент, с которым это связано и его владелец • Направляется запрос владельцу • Владелец решает вопрос сам или переадресует другим, но контролирует его разрешение 43
- 67. Команды минимизируют взаимодействие между собой при реализации фич, исправлении багов и релизах 45
- 68. Независимость команд • Модульность: блоки (функциональность) изолируются в пакеты • Могут использовать собственную версию зависимости, апгрейдится в удобное время • Поддержка более мягких интеграций • Автоматизация тестирования 46
- 69. Типы интеграции • Жесткая интеграция – изменения кода компонента (требуется публикация пакета, пересборка и релиз зависимых модулей и проектов) • Конфигурационная интеграция – изменение конфигурации экземпляра компонента (требуется пересборка и релиз модуля и проекта) • Мета интеграция – конфигурация блока описывается и хранится вне кода (не требует пересборки и релиза) 47
- 71. Чтобы избежать Dependency hell – регулярный сбор и анализ зависимостей 49
- 72. Статический анализ package.json и кода 50
- 76. Нельзя так просто взять и все зарефакторить
- 77. Возможность производить рефакторинг или миграцию на новые решения и технологии поэтапно 55
- 78. Инкрементальный рефакторинг • Возможность не делать все сразу • Рефакторинг не больше недели → релиз • Толерантность к легаси – старое должно продолжать работать без приложения усилий (консервация до лучших времен) 56
- 79. Мы сейчас все запилим с нуля и все станет хорошо 57
- 80. Мы сейчас все запилим с нуля и все станет хорошо 57
- 81. Итоги
- 82. Управление разработкой • Владение кодом • Независимость команд • Управление зависимостями и версиями • Инкрементальный рефакторинг 59
- 83. Платформа
- 84. Платформа – рекомендованный набор технических решений в компании 61
- 85. Дизайн система
- 86. Общие подходы к разработке интерфейсов, готовые UI компоненты и инструментарий 63
- 87. Дизайн система • UI Kit (для дизайнеров) • UI компоненты (для разработчиков) • Каталог UI компонент • Общие паттерны и решения • ... 64
- 90. Меньше зоопарк технологий – дешевле делать общие решения 67
- 91. Tech Radar 68 Build Your Own 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 через полгода