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

Transcript

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

   View Slide

2. Работаю в Avito
   Open source:

   basis.js, CSSO, 

   component-inspector, 

   csstree, rempl и другие
   github.com/lahmatiy
   twitter.com/rdvornov
   rdvornov@gmail.com
   

   View Slide

3. Контекст
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

8. Разница между 

   сайтом и SPA в том, что...
   6
   

   View Slide

9. Разница между 

   сайтом и SPA в том, что...
   6
   
   

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

14. «Проект»

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

    View Slide

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

    View Slide

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

    View Slide

17. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

24. View Slide

25. Core
    

    View Slide

26. Layout
    Slot 1 Slot 2 Slot N
    ...
    Core
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

34. Блоки не используют браузерное API, 

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

    View Slide

35. Block 1
    Block 2
    Server
    

    View Slide

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

    View Slide

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

    View Slide

38. Block 1
    Block 2
    Server
    Common
    Public
    API
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

51. Модульность
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

55. Итоги
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

63. Информация хранится 

    в базе знаний (реестре)
    41
    

    View Slide

64. Пример
    42
    

    View Slide

65. Action plan
    • Проблема, баг или вопрос?
    • Определяется релевантный компонент, 

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

72. Статический анализ

    package.json и кода
    50
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

81. Итоги
    

    View Slide

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

    View Slide

83. Платформа
    

    View Slide

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

    View Slide

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

    View Slide

86. Общие подходы к разработке интерфейсов, 

    готовые UI компоненты и инструментарий
    63
    

    View Slide

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

    View Slide

88. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

95. По моему скромному опыту:
    настроить проект с нуля, имея опыт, 

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

    View Slide

96. Инфраструктура – не всегда готовое
    • Unit-тестирование скриншотами: преодолеваем
    звуковой барьер – Роман Дворнов

    видео, расшифровка
    • Скриншоты как сервис – Сергей Мелюков

    видео
    73
    

    View Slide

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

    View Slide

98. Итоги
    

    View Slide

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

    View Slide

100. Заключение
     

     View Slide

101. Если вам показалось, 

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide