Микрофронтенд

Дима Королев, разработчик Tinkoff.ru
email: dima@korolev.dk
github: /dmitry-korolev
telegram: @dimakorolev

Интро

Фичи

Раздувание

Сложность

И это еще не всё!

Tinkoff.ru

Начало

Неожиданный рост

10 000 страниц

150 000 коммитов

200 разработчиков

10 000 компонентов

Метрики

Время

Количество ошибок

Как у нас

1.5 месяца

2x багов

Перманентный рефакторинг

Разделение на подприложения

Хорошо, но нет

Выделение отдельных модулей

Хорошо, но нет

Бизнес-логика

Что делать?

Меньше — проще

Микрофронтенд

2015

2016

Сейчас

Первые шаги

Накладные расходы

Необходимость коммуникации

Отсутствие стандартов

Во-вторых, когда все приложения делаются независимо друг от друга, пусть и договорившись о каком-то общем информационном канале, есть риск, что будет возникать много одинаковой логики, которую все будут писать по-разному, будут подключаться разные библиотеки для одних и тех же задач, и опять-таки будет раздуваться JS.

На практике в конкретных проектах всегда нужно договариваться о совместно используемых технологиях, чтобы не допускать этих проблем.

В результате можно прийти к следующему (довольно-таки абстрактному) пониманию архитектуры приложения.

Есть некие общие утилитарные библиотеки: утилиты для операциями над данными, утилиты для выполнения запросов, какие-то общие константы и так далее.
Есть сами микроприложения - независимые друг от друга приложения, способные сосуществовать на одной странице, по возможности использующие общие библиотеки.
Есть общий и единственный информационный канал, который доступен всем микроприложениям и используется всеми одинаково.
Есть процесс для определения, какие микроприложения должны показываться на странице, собирающий всё, что ими используется в единый бандл, и развертывающий его на сервере.

А что с микроприложениями?

Своё состояние

API

Отслеживание состояния

Переиспользуемость

Модульность

В качестве примера можно привести приложение платежа по провайдеру. Даже не особо разбираясь в тонкостях его работы, можно выделить несколько отдельных частей, которые вполне могут быть переиспользованы где-нибудь еще.

Логика работы с состоянием формы
Логика работы с валидацией
Логика, отвечающая за получение и использование данных о пользователе.
Непосредственно логика проведения платежа, показа окон подтверждения и так далее.

Stapp

1 модуль — 1 задача

Довольные технологи

Модули

Состояние

API

Отслеживание

formBase

validate

persist

tinkoffcreditsystems.github.io/stapp

Будущее

Как я уже сказал, о микроприложениях сейчас говорят много.

Но на мой субъективный взгляд - недостаточно много.

Ведь до сих пор не существует понимания, к чему конкретно мы идем, и как это будет выгдядеть в будущем.

Но ясно, что подобная модульная архитектура - это то, к чему идет веб-разработка.

Все современные фреймворки сейчас поддерживают компонентный подход.

В web-API добавляются такие штуки, как веб-компоненты.

И крайне важно сейчас как можно больше говорить об этом подходе, искать пути к его реализации.

Я не знаю, какой инструментарий мы будем использовать в будущем, какая именно реализация будет принята на вооружение и станет новым стандартом.

Но я точно знаю, что проблема сложности бизнес-логики на данный момент в вебе не решена. И наша с вами задача - её решить.

Веб-версия доклада: clck.ru/Dodpu
email: dima@korolev.dk
github: /dmitry-korolev
telegram: @dimakorolev