Comments 13
Медитировал над рисунком, но совершенно ничего не понял. К сожалению, текст никак не связан с рисунком, причем в оригинальной статье тоже текст не связан с рисунком. Может быть кто-то понимает о чем там идет речь?
ПСБанк недавно проводил хакатон на тему микрофронтендов. Так мы там демонстрировали подход $mol на эту тему. И не смотря на то, что $mol не был рекомендуемой технологией, нам удалось попасть в тройку финалистов. Просто потому, что мы смогли за пару дней сделать больше и качественнее в свободное от безделья время. Гляньте, наш питч - это кардинально иной подход, вобравший лучшее из обоих миров:
Что мне нравится в микрофронтенде, что любой аргумент который используется как достоинство, можно использовать как и недостаток)
Работал и видел несколько очень крупных проектов, от 1 до 3млн строк, прекрасно масштабировались и работали. И я честно не представляю какого масштаба был бы хаос в этих проектах будь они микрофронтовыми.
Особенно классно, когда ты где то за городом или в метро, тебе очень срочно нужна информация, а вместо этого грузится angular и вроде бы ты даже его грузил, но черт, он другой версии….
А править баги связанные с ядром микрофронтов это просто адовый труд.
Я вижу только пару причин использовать микрофронтенд:
переезд на другую технологию, когда требуется итеративный переход.
Экономия на ресурсах других отделов, это касается именно поставки отдельных модулей/приложений. Если мы поставляем физически одно приложение из ста, то и тестировать можно одно из ста, но с этим прекрасно справляется и микросервисный монолит.
Технологию настолько наводящую хаос в проекте не встречал со времён редакса)
Холивар опен)
Микрофрентенды - это подход адекватный лишь в некоторых ситуациях, он точно не для всех. Поэтому, все зависит от конкретной ситуации, решение тут точно не стоит принимать на волне хайпа. Частным случаем применимости можно считать виджеты сторонних сервисов: на мой взгляд, это хороший пример того, когда это работает и вообще понятно зачем. Однако, виджетостроение - это особое искусство, где планка требований к разработчикам заметно выше.
А что не так с редаксом? Вроде ж его так активно продвигали и использовали, причем создавалось ощущение, что он именно про наведение порядка (а не про магию [хаоса])
Холивар опен)
Вроде на хабре в основном +- согласятся с вами. Насчет микросервисов хайпа было много, но в реальные проекты очень немного перешло.
Возможно у меня контекст такой, но каждый второй проект в сфере финтеха или экосистем с которым я сталкиваюсь, сейчас либо переходит на микрофронт, либо инвестирует в изучение этих переходов.
Когда проект завален деньгами и берут всех разработчиков подряд, достигая заявленных целей по количеству персонала — тогда да, микрофронт — отличное занятие для большей части этих программистов. Тоже в финтехе наблюдал и немного участвовал в подобном, когда вместо продуктовой разработки много людей занимаются развитием протоколов подключения и общения разнородных баз кода на одной странице, поддержкой аналогичных по функционалу библиотек компонентов, решением коллизий и взаимовлияния кода, апдейтом в десятках репозиториев дублирующегося кода (подключения шрифтов, к примеру, либо коннекторов к руту), cli-инструментами для фетча нескольких реп и управления их локальными версиями, решением проблем версионирования/выкатки/интеграционного тестирования/откатов при деплое, подключением серверного рендеринга и строковой склейкой одной страницы из нескольких частей...
И, разумеется, все это значительно влияет на производительность приложения и его размер + скорость поставки фич. Через полгода-год это с большой вероятностью приходит в холд по бизнес-фичам со всеми вытекающими.
Так что какой холивар — и так понятно, что микрофронты для очень узкого круга проектов (этап миграции либо виджеты), нишевая технология. А при применении в качестве основной архитектуры недостатков намного больше, чем преимуществ.
Пробовали что-то из аля микрофронтенда во времена, когда и не пахло этой темой, на базе SharePoint. Воспоминания как про срочную службу в армии). Рано еще переходить, инфраструктура окружения не готова
Статья - ужасна, куча ошибок и неточностей как в примерах кода так и в описании технологий. Я понимаю конечно, что перевод, но тут, видимо, и сам исходник - треш.
Микро-фронтенд. Обзор архитектуры и рекомендуемые практики