«Масштабируемая архитектура фронтенда» — Роман Дворнов, Avito

Transcript

1. Маcштабируемая архитектура фронтенда Роман Дворнов Москва, 2018
2. Работаю в Avito Open source:
 basis.js, CSSO, 
 component-inspector, 
 csstree, rempl и другие github.com/lahmatiy twitter.com/rdvornov rdvornov@gmail.com
3. Контекст
4. Avito – несколько сайтов и SPA
5. 5 HTML JavaScript (генерирует HTML/DOM) Сервер Клиент Сайт SPA Обязательно vs.
6. 5 HTML JavaScript (интерактивность) JavaScript (генерирует HTML/DOM) Сервер Клиент Сайт SPA Обязательно Опционально vs.
7. 5 HTML JavaScript (интерактивность) JavaScript (генерирует HTML/DOM) SSR Сервер Клиент Сайт SPA Обязательно Опционально vs.
8. Разница между 
 сайтом и SPA в том, что... 6
9. Разница между 
 сайтом и SPA в том, что... 6
10. Когда все просто 7 Feature 1 Feature 2 Feature N ... Project Team
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
21. Экосистема страницы
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
33. Абстракция от окружения
34. Блоки не используют браузерное API, 
 а используют API ядра и его плагинов 19
35. Block 1 Block 2 Server
36. Block 1 Block 2 Server GET /what/ever
37. Block 1 Block 2 Server GET /what/ever GET /what/ever
38. Block 1 Block 2 Server Common Public API
39. Block 1 Block 2 Server Common Public API getWhatEver()
40. Block 1 Block 2 Server Common Public API getWhatEver() getWhatEver()
41. Block 1 Block 2 Server Common Public API getWhatEver() getWhatEver() request
42. Block 1 Block 2 Server Common Public API getWhatEver() getWhatEver() request Но это не точно
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
49. Общая кросс-проектная структура API 27
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. Пример 42
65. Action plan • Проблема, баг или вопрос? • Определяется релевантный компонент, 
 с которым это связано и его владелец • Направляется запрос владельцу • Владелец решает вопрос сам или переадресует другим, но контролирует его разрешение 43
66. Независимость команд
67. Команды минимизируют взаимодействие между собой при реализации фич, исправлении багов и релизах 45
68. Независимость команд • Модульность: блоки (функциональность) изолируются в пакеты • Могут использовать собственную версию зависимости, апгрейдится в удобное время • Поддержка более мягких интеграций • Автоматизация тестирования 46
69. Типы интеграции • Жесткая интеграция – изменения кода компонента (требуется публикация пакета, пересборка и релиз зависимых модулей и проектов) • Конфигурационная интеграция – изменение конфигурации экземпляра компонента (требуется пересборка и релиз модуля и проекта) • Мета интеграция – конфигурация блока описывается и хранится вне кода (не требует пересборки и релиза) 47
70. Управление зависимостями и версиями
71. Чтобы избежать Dependency hell – регулярный сбор и анализ зависимостей 49
72. Статический анализ
 package.json и кода 50
73. Версии (первый подход) 51
74. Использование UI компонент 52
75. Инкрементальный рефакторинг
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
89. Ограниченный технологический стек
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 через полгода
104. Роман Дворнов @rdvornov rdvornov@gmail.com Спасибо!