Комментарии 4
Скучаю по временам, когда фронт рендерился на бэкенде, а CSS был каскадным, а не как сегодняшний tailwind, который фактически синтаксический сахар к тегу style="...". Иногда возникает ощущение, что мы свернули не туда. Или это возраст? )
В статье предлагается целостный UI сайта разбить на раздельные кусочки и репозитории (что несет за собой усложнение ci, сборки, слежение за зависимостями, ухудшение реиспользования кода и т.п.), а потом еще и отображать разные куски одновременно на одной странице через iframe, который тоже добавит ада по визуалу, по работе с этим, дебагу и т.п. Что-то фронтендеры точно не туда едут и усложняют фронт ради усложнения.
P.S> что у вас за проект, что он делает, где надо такое?
Привет! Ответ от автора)
Да, микрофронты это осознанное усложнение архитектуры для решения проблем масштабирования. Когда над продуктом работают десятки команд и 100+ разработчиков толкаются в одном репозитории, очень больно.
Зачем дробим фронт? По той же причине, что и когда-то многие проекты/компании/команды начали дробить бэк: чтобы модули большой экосистемы могли масштабироваться и развиваться независимо. Это не для всех проектов, но для крупных — необходимость. Нам такой подход был необходим.
P.S. Если ваш проект растет и команды начинают мешать друг другу, вы поймете, зачем это нужно 😉 Мы крупный ретейл.
Информация
- Сайт
- usetech.ru
- Дата регистрации
- Дата основания
- Численность
- 1 001–5 000 человек
- Местоположение
- Россия
- Представитель
- Usetech
Пилим монолит на… микрофронты (Часть 1)