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

Slide 1

Slide 1 text

Маcштабируемая архитектура фронтенда Роман Дворнов Москва, 2018

Slide 2

Slide 2 text

Работаю в Avito Open source:  basis.js, CSSO,   component-inspector,   csstree, rempl и другие github.com/lahmatiy twitter.com/rdvornov rdvornov@gmail.com

Slide 3

Slide 3 text

Контекст

Slide 4

Slide 4 text

Avito – несколько сайтов и SPA

Slide 5

Slide 5 text

5 HTML JavaScript (генерирует HTML/DOM) Сервер Клиент Сайт SPA Обязательно vs.

Slide 6

Slide 6 text

5 HTML JavaScript (интерактивность) JavaScript (генерирует HTML/DOM) Сервер Клиент Сайт SPA Обязательно Опционально vs.

Slide 7

Slide 7 text

5 HTML JavaScript (интерактивность) JavaScript (генерирует HTML/DOM) SSR Сервер Клиент Сайт SPA Обязательно Опционально vs.

Slide 8

Slide 8 text

Разница между   сайтом и SPA в том, что... 6

Slide 9

Slide 9 text

Разница между   сайтом и SPA в том, что... 6

Slide 10

Slide 10 text

Когда все просто 7 Feature 1 Feature 2 Feature N ... Project Team

Slide 11

Slide 11 text

Когда все сложно 8 Feature 1 Feature 2 Feature N ... Project 1 Project 2 ... Project N

Slide 12

Slide 12 text

Когда все сложно 8 Feature 1 Feature 2 Feature N ... Project 1 Project 2 ... Project N Team Team Team

Slide 13

Slide 13 text

Когда все сложно 8 Feature 1 Feature 2 Feature N ... Project 1 Project 2 ... Project N Team Team Team

Slide 14

Slide 14 text

«Проект»  сайт/SPA, страница, приложение (mobile) 9

Slide 15

Slide 15 text

В чем разница • Проект-команда • Плохая предсказуемость доставки фичи, сложно приоритезировать, разное понимание • Фича-команда • Много разных интеграций, но хорошая предсказуемость и проработка фич 10

Slide 16

Slide 16 text

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

Команда 1 Команда 2 Команда 3 Команда 4 Команда 5

Slide 19

Slide 19 text

Проблемы больших продуктов • Больше «проектов» – больше точек интеграции • Увеличивается число команд с одной кодовой базой • Постоянно усложняется (новые фичи) • Растет кодовая база и техдолг (легаси) • ... 12

Slide 20

Slide 20 text

Как будем лечить • Экосистема страниц • Организация процессов разработки • Платформа 13

Slide 21

Slide 21 text

Экосистема страницы

Slide 22

Slide 22 text

Экосистема страницы задает окружение для компонент/блоков, избавляя от решения типовых задач 15

Slide 23

Slide 23 text

Типовые задачи • Лейаут страницы • Управление слоями • Загрузка и управление зависимостями • Источники данных (модели, нотификация) • Персистентное хранение данных • Транспорт • Роутинг • и т.д. 16

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

Core

Slide 26

Slide 26 text

Layout Slot 1 Slot 2 Slot N ... Core

Slide 27

Slide 27 text

Layout Slot 1 Slot 2 Slot N ... Core Block 1 Block 2 Block N

Slide 28

Slide 28 text

Layout Slot 1 Slot 2 Slot N ... Core Block 1 Block 2 Block N ... Plugin 1 Plugin 2 Plugin N

Slide 29

Slide 29 text

Layout Slot 1 Slot 2 Slot N ... Core Block 1 Block 2 Block N ... Plugin 1 Plugin 2 Plugin N Common Public API

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Абстракция от окружения

Slide 34

Slide 34 text

Блоки не используют браузерное API,   а используют API ядра и его плагинов 19

Slide 35

Slide 35 text

Block 1 Block 2 Server

Slide 36

Slide 36 text

Block 1 Block 2 Server GET /what/ever

Slide 37

Slide 37 text

Block 1 Block 2 Server GET /what/ever GET /what/ever

Slide 38

Slide 38 text

Block 1 Block 2 Server Common Public API

Slide 39

Slide 39 text

Block 1 Block 2 Server Common Public API getWhatEver()

Slide 40

Slide 40 text

Block 1 Block 2 Server Common Public API getWhatEver() getWhatEver()

Slide 41

Slide 41 text

Block 1 Block 2 Server Common Public API getWhatEver() getWhatEver() request

Slide 42

Slide 42 text

Block 1 Block 2 Server Common Public API getWhatEver() getWhatEver() request Но это не точно

Slide 43

Slide 43 text

Экосистема – черный ящик 22

Slide 44

Slide 44 text

Что может быть • Запрос к серверу • Данные из кеша • Синхронизация между закладками • SSE/WebSocket/ServiceWorker/etc • ... 23

Slide 45

Slide 45 text

Что может быть • Запрос к серверу • Данные из кеша • Синхронизация между закладками • SSE/WebSocket/ServiceWorker/etc • ... 23 Progressive enhancement

Slide 46

Slide 46 text

Реализация экосистемы может ... • Меняться (подходы и технологии) • Различаться от проекта к проекту • Совершенствоваться со временем • ... • Блокам/компонентам все равно 24

Slide 47

Slide 47 text

Плюшки • Стенд для разработки блока • Моки без костылей • Реализации под «среду» • браузер • серверный рендеринг • тесты 25

Slide 48

Slide 48 text

Общее публичное API Common Public API

Slide 49

Slide 49 text

Общая кросс-проектная структура API 27

Slide 50

Slide 50 text

Зачем? • Переиспользование блоков без адаптации к API • Используем подходящую реализацию ядра, в зависимости от среды • Проще новые интеграции (меньше учить) 28

Slide 51

Slide 51 text

Модульность

Slide 52

Slide 52 text

«Нет» монолитам! • Подключение (с динамической подгрузкой) дополнительной функциональности в ядро по принципу плагинов • Интерфейсы декомпозируются на логические блоки, с динамической подгрузкой (включая зависимости) и обновлением 30

Slide 53

Slide 53 text

Подход подразумевает • Функциональность (API) экосистемы расширяется (догружается) по мере потребностей блоков • Разные версии одних и тех же зависимостей в рамках одного окружения (страницы) • Блоки взаимодействуют только с публичным API • Креш блока не тянет за собой все остальное 31

Slide 54

Slide 54 text

Точки отказа • Ядро – единственная критическая часть, ничего не будет работать • Плагин ядра – не будут работать плагины и блоки, которые от него зависят • Блок – проблемы блока никого не касаются 32

Slide 55

Slide 55 text

Итоги

Slide 56

Slide 56 text

Экосистема страницы • Абстракция от окружения • Общее публичное API • Модульность 34

Slide 57

Slide 57 text

Управление разработкой

Slide 58

Slide 58 text

Порядок и комфорт • Владение кодом • Независимость команд • Контроль зависимостей и версий • Инкрементальные рефакторинг и миграция 36

Slide 59

Slide 59 text

Владение кодом

Slide 60

Slide 60 text

Общее – значит ничье 38

Slide 61

Slide 61 text

У каждого «компонента» системы должен быть определен единственный владелец 39

Slide 62

Slide 62 text

Компонент это • Репозиторий • Директория или файл (модуль) • npm-пакет • Страница • Чанк • ... 40

Slide 63

Slide 63 text

Информация хранится   в базе знаний (реестре) 41

Slide 64

Slide 64 text

Пример 42

Slide 65

Slide 65 text

Action plan • Проблема, баг или вопрос? • Определяется релевантный компонент,   с которым это связано и его владелец • Направляется запрос владельцу • Владелец решает вопрос сам или переадресует другим, но контролирует его разрешение 43

Slide 66

Slide 66 text

Независимость команд

Slide 67

Slide 67 text

Команды минимизируют взаимодействие между собой при реализации фич, исправлении багов и релизах 45

Slide 68

Slide 68 text

Независимость команд • Модульность: блоки (функциональность) изолируются в пакеты • Могут использовать собственную версию зависимости, апгрейдится в удобное время • Поддержка более мягких интеграций • Автоматизация тестирования 46

Slide 69

Slide 69 text

Типы интеграции • Жесткая интеграция – изменения кода компонента (требуется публикация пакета, пересборка и релиз зависимых модулей и проектов) • Конфигурационная интеграция – изменение конфигурации экземпляра компонента (требуется пересборка и релиз модуля и проекта) • Мета интеграция – конфигурация блока описывается и хранится вне кода (не требует пересборки и релиза) 47

Slide 70

Slide 70 text

Управление зависимостями и версиями

Slide 71

Slide 71 text

Чтобы избежать Dependency hell – регулярный сбор и анализ зависимостей 49

Slide 72

Slide 72 text

Статический анализ  package.json и кода 50

Slide 73

Slide 73 text

Версии (первый подход) 51

Slide 74

Slide 74 text

Использование UI компонент 52

Slide 75

Slide 75 text

Инкрементальный рефакторинг

Slide 76

Slide 76 text

Нельзя так просто взять и все зарефакторить

Slide 77

Slide 77 text

Возможность производить рефакторинг или миграцию на новые решения и технологии поэтапно 55

Slide 78

Slide 78 text

Инкрементальный рефакторинг • Возможность не делать все сразу • Рефакторинг не больше недели → релиз • Толерантность к легаси – старое должно продолжать работать без приложения усилий (консервация до лучших времен) 56

Slide 79

Slide 79 text

Мы сейчас все запилим с нуля и все станет хорошо 57

Slide 80

Slide 80 text

Мы сейчас все запилим с нуля и все станет хорошо 57

Slide 81

Slide 81 text

Итоги

Slide 82

Slide 82 text

Управление разработкой • Владение кодом • Независимость команд • Управление зависимостями и версиями • Инкрементальный рефакторинг 59

Slide 83

Slide 83 text

Платформа

Slide 84

Slide 84 text

Платформа – рекомендованный набор технических решений в компании 61

Slide 85

Slide 85 text

Дизайн система

Slide 86

Slide 86 text

Общие подходы к разработке интерфейсов,   готовые UI компоненты и инструментарий 63

Slide 87

Slide 87 text

Дизайн система • UI Kit (для дизайнеров) • UI компоненты (для разработчиков) • Каталог UI компонент • Общие паттерны и решения • ... 64

Slide 88

Slide 88 text

No content

Slide 89

Slide 89 text

Ограниченный технологический стек

Slide 90

Slide 90 text

Меньше зоопарк технологий – дешевле делать общие решения 67

Slide 91

Slide 91 text

Tech Radar 68 Build Your Own Technology Radar Подробнее в статье:

Slide 92

Slide 92 text

Инфраструктура

Slide 93

Slide 93 text

Инфраструктура • Сборка проектов • Управление зависимостями, публикациями и версиями • Организация тестирования (настройка, инструменты, хелперы etc) • Репортинг (ошибки, performance, etc), мониторинг, Health Check • База знаний • Скрипты по сбору данных (анализ кода, тегирование, etc) • ... 70

Slide 94

Slide 94 text

Модульность → репы и пакеты → затраты на поддержку 71

Slide 95

Slide 95 text

По моему скромному опыту: настроить проект с нуля, имея опыт,   занимает несколько часов, не считая поддержки 72

Slide 96

Slide 96 text

Инфраструктура – не всегда готовое • Unit-тестирование скриншотами: преодолеваем звуковой барьер – Роман Дворнов  видео, расшифровка • Скриншоты как сервис – Сергей Мелюков  видео 73

Slide 97

Slide 97 text

Идеальная настройка 74 { ... "dependencies": { "@avito/platform": "latest", ... } } package.json

Slide 98

Slide 98 text

Итоги

Slide 99

Slide 99 text

Платформа • Дизайн система • Ограниченный технологический стек • Инфраструктура 76

Slide 100

Slide 100 text

Заключение

Slide 101

Slide 101 text

Если вам показалось,   что все просто и логично – отлично, так и задумано! 78

Slide 102

Slide 102 text

не верьте мне на слово 79 Не все еще проверено в реальных условиях

Slide 103

Slide 103 text

не верьте мне на слово 79 Не все еще проверено в реальных условиях Ожидайте update через полгода

Slide 104

Slide 104 text

Роман Дворнов @rdvornov rdvornov@gmail.com Спасибо!