Comments 22
А в итоге зачем на проекте требовались микрофронтенды?
Я всей ситуации не обладаю и не участвовал в проектирований всей системы, мне донесли как данность. Да и если бы хотел, всего рассказать не могу, сами понимаете. Но, постараюсь ответить, исходя из того, что получается в итоге.
Микрофроненды нашли хорошее применение в организации ролевого доступ к АРМ. Как я говорил в статье, у каждого приложения есть манифест и сервер о них знает. В зависимости от привелегий пользака, север формирует пул манифестов и отправляет его клиенту. Не обладая нужными правами, пользак при всем своем желании не попадет туда, куда не следует, просто потому, что ему этот микрофронт не доступен с домашней страницы. Конечно, он может попытаться по прямой ссылке пойти, но и там его ждет облом, но это уже немного другое
Целевая аудитория - системные администраторы, и у них есть разные уровни доступа. По требованиям ТЗ предполагается, что могут быть как локальные админы (администраторы структурной единицы в предприятия), так и супер админы (админ всего предприятия/нескольких предприятий, хоть всей РФ). Одни должны настраивать пул доменов, NTP, DNS и т.д., другим же достаточно предоставить доступ к управлению машинами, пользователям, принтерам.
При этом, объем системы большой и изменение в функционале точечно затрагивают модули, снижая время на CI/CD и вывод в релиз отдельных элементов системы или выноса функционала в отдельный домен.
К сожалению, были моменты корректировки ТЗ и на одной из крупных подсистем было очень много стихийных изменений, и мы бы уперлись в конфликты в репозитории и ожидании развертывания без микрофронтов, dev-стенд вообще по несколько раз в час обновлялся.
Так же, сильно ускорилась работа, были сформированы несколько команд/одиночных разработчиков, работающих абсолютно независимо друг от друга, без ожиданий очередей сборки с минимальными конфликтами в git
Более конкретно рассказать не могу, чтобы не получить по голове за разглашение :)
Надеюсь, ответил на Ваш вопрос, если нет, то уточните, где я свернул не туда
Микрофроненды нашли хорошее применение в организации ролевого доступ к АРМ. Как я говорил в статье, у каждого приложения есть манифест и сервер о них знает.
Ну здесь можно и клеймами в JWT решить. Если к беку доступа нет, то и фронтовый никакого доступа не раскроет, а бек в любом случае придется защищать.
Так же, сильно ускорилась работа, были сформированы несколько команд/одиночных разработчиков, работающих абсолютно независимо друг от друга, без ожиданий очередей сборки с минимальными конфликтами в git
Вот тут сборка - да, а все остальное через feature modules можно решить.
Ну здесь можно и клеймами в JWT решить
Вы совершенно правы, но, как говорится, кто платит - тот и музыку заказывает :)
Заказчик в будущем своими силами хочет расширять функционал системы и не хочет копаться в фронтовых делах. Ведь на самом деле дествительно легко поднять любое приложение на любом стеке и "вклинить" его в существующую систему, чем копаться в архитектуре и т.д., тем более, в какой-то момент это станет легаси и бизнес не захочет слышать просьбы на выделение средств на рефактор :) Но, это уже совсем другая история
остальное через feature modules можно решить
Если я не ошибаюсь, feature modules предполагает нахождение на одном сервере, а module federation позволяет тянуть части системы из любого места. Поправьте, если не прав.
приложение на любом стеке и "вклинить" его в существующую систему
Мухаха, оно конечно "вклинивается", но без single spa роуты делать больно:)
Если я не ошибаюсь, feature modules предполагает нахождение на одном сервере, а module federation позволяет тянуть части системы из любого места
Я никогда не пробовал, но, кажется, что можно разные чанки раскидать по серверам, но зачем... Если вы не про деплой в прод, а про репозиторий, то в одном репо, да.
Смотрели ли на NX, и если да, то почему выбрали webpack module federation?
начал смотреть на NX, но слишком поздно, под конец проекта. На другом проекте обкатывают коллеги лерну и она им больше не нравится, чем нравится. Думаю, NX будет следующим. Но это история не про module federation
Сам module federation выбрал по нескольким причинам:
1) Шаринг зависимостей. Не нужно писать костыли для определения инстансов бибилиотек.
2) Подкупили утверждения автора технологии по поводу экономии сетевого трафика и это на самом деле оказалось правдой
3) По сути, конфигурация простая, но выглядит заковыристо. Пару строк в конфиг вебпака, бутстрап для энтиропоинта - и микрофронтенды готовы к работе
4) Я слишком буквально воспринял фразу "подключить любое приложение в любой момент". Никто другой не мог на тот момент предложить, что можно встроить без костылей и лишних библиотек/фреймоврков механизм работы с приложениями. Да, было что-то уже в вебпаке плагинчик (не помню как называется), который позволял делать схожее, но причина ниже. Я ориентировался на то, что завтра/полгода/год с бухты-барахты заказчик притащит команду ангулярщиков, а мы все пишем на реакте (реакт был в требованиях тз). И нам как-то придется всем месте жить, а бизнес слышит про микрофронты и думает, что все просто.
5) У меня была абсолютная свобода действий. Я люблю работать с новыми библиотеками, и тут подвернулся такой шанс. Хотя, возможно, сейчас бы я не стал так рисковать как год назад. А тогда я увидел новую хайповую фичу и решил попробовать.
Да и возможно выбор module federation был yolo-решением и, слава богу, оно сыграло и опрадалось. Но, опять же, впредь я вряд-ли рисковать буду таким образом
Мы в итоге пришли к NX. Изначально на основном проекте была своя система сборки модулей, на основе вебпака. Потом сделали свои плагины на основе DllPlugin от вебпака, чтобы части приложения можно было подключать через манифесты, в то время module federation еще пока не было. Это позволило перейти в монорепозиторий на лерне, и в дальнейшем на сборку ангуляром с кастомными скриптами под вебпак. Сейчас собираемся перейти на NX, так как в других проектах он себя хорошо показывает. Я правда не знаю, на сколько хорошо NX интегрируется с проектами на реакте, но с ангуляром снимает очень много головной боли.
Я ориентировался на то, что завтра/полгода/год с бухты-барахты заказчик притащит команду ангулярщиков, а мы все пишем на реакте
В этом плане обычно возникает больше проблем с когерентностью, чем со сборкой, чтобы зацепить различный роутинг, туже авторизацию и т. д., но я так понял вы и сами с этим частично столкнулись. Лично для себя, я пришел к выводу, что такие вещи надо закладывать заранее, но по возможности стараться делать приложение на одном стеке. Сейчас в нашем приложении это не так, и по итогу куча самописного кода под какие-то корневые механизмы.
В целом было достаточно интересно почитать про ваш опыт. Спасибо.
Лерна вроде депрекейтед
Сейчас собираемся перейти на NX, так как в других проектах он себя хорошо показывает
Я видел, что NX не поддерживает отдельные релизы подсистем, это дейтсвительно так и насколько больнно делать свои workaround'ы для этого?
У нас каждый фронт релизится отдельно, интересно попробовать спроецировать этот опыт на будущее и подготовиться :)
я так понял вы и сами с этим частично столкнулись
Да, но не сказал бы, что сильно было критично. Самая большая проблема с шарингом состояния и передачей из дочери в ядро. Например, пагинация у нас в шапке ядра, еще и хитровыдуманная, поэтому пришел к выводу, что нужно делать DI и выводить методы в стейт ядра, чтобы дочки их дергали. Отсюда и думаю, что в следующий раз попробовать общаться через воркеры, оценить затраты и плюсы/минусы
Спасибо за ваш отзыв!
@movlпромахнулся веткой, извините
Тут смотря что понимать по раздельными релизами. Сама модель NX нацелена на отслеживание связей и на кеширование, для максимально эффективной сборки различных частей проекта. Так же есть механизм для создания публикуемых библиотек в рамках монорепозитория. Но в плане CI, скорей всего придется всё тонко настраивать под требуемый рабочий процесс. Плюс в нашем случае NX работает над ангуляровской системой сборки, в которой изначально заложена возможность разделения проекта на части.
Мы в своем опыте пока отказались от отдельных релизов подсистем, так как это порождало слишком много проблем как в плане CI, так и в плане поддержки общего кода. Хотя может со временем вернемся к этой практике, так как в рабочем процессе есть некоторая необходимость этого.
Мне не понравилась федерализация. Топорно, сложно, тяжело типизировать. Если нет требования поддержки старых браузеров, проще построить расширения на базе обычных esm. Гибкости больше. И контроля.
А с чем конкретно возникла сложность в типизации? У нас были проблемы в типизации бутстрапа (устали костылить и влепили мужицкий ts-ignore) и точку входа в дочь, если меняется стор ядра (приходится генерировать .d.ts и перекладывать руками в common), а так в остальном проблем не было
дык, при потреблении федерализации откуда типы брать? насколько помню, официальный ответ на гитхабе был в духе "нет совместимости с тайпскриптом". Ну и нет совместимости у федерализации с остальными сборщиками. Что привязывает консьюмеров к вебпаку. Хотя нормального экспорта в esm у вебпака по-моему до сих пор нет. Активно тестят и пишут в соответствующий ишью на гх, слежу в полглаза, но кажется, всё ещё не для прода.
Ну и в целом мне кажется устаревшим подход вебпака к постоению зависимостей. Например, все модули лежат по номерными ключами в глобальном объекте. Не знаю, как в пятой версии, а в четвёрке была проблема с двумя фронтами на одной странице - вебпак одного затирал объект зависимостей другого.
В общем, полно там проблем. Часть из них легаси, часть из них вызвано тем, что вебпак не умеет в esm. а нативные модули уже давно поддерживаются везде + работают из коробки.
Ну и возвращаясь к типам - чтобы консьюмить модули с типами, генерю для каждого модуля d.ts и кладу его в кастомную папку с типами, которая работает как node_modules, импортирую модули как обычные модули из node_modules, в мапингах зависимостей коллбек в духе "если модуль начинается с project-name-*, то рерайтим импорт "вот так". Где "вот так" - динамический импорт esm. Да, он возвращает промис, то top level await тоже уже давно не диковинка.
Ну и нет совместимости у федерализации с остальными сборщиками. Что привязывает консьюмеров к вебпаку.
а должна быть? Сборщик запилил такую вещь и логично, что завязывает на себя, чтобы пополнить комьюнити. Почему это не делают другие - вопрос. Хотя, судя по настроениям - не вопрос, ведь большинству либо страшно браться, либо "фу-фу, нафиг надо" .
Для сборки приложенек - вебпак, для сборки либ - роллап. Для меня ну вот вообще не проблема привязки к сборщику. Можно, конечно, приплести сюда snowpack, vite и все остальное, но для меня скорости стало достаточно, отказавшись от babel в пользу esbuild, а если надо будет собрать все лучшее - там где-то еще должен жить gulp, можно велосипед из сборщиков вокруг него построить, только зачем?
дык, при потреблении федерализации откуда типы брать?
я уже выше писал, что из коммон либы я в своем случае складывал. Неудобно, но не смертельно, либо подцепить кастомную types в tsconfig (что, видимо, вы и сделали).
Например, все модули лежат по номерными ключами в глобальном объекте. Не знаю, как в пятой версии
Лежат точно так же в объекте, но не глобальном, если не указывать scope default. Каждый микрофронт может искать в отдельном скопе себе зависимости и выбрасывать туда, если нет зависимостей
У каждого выбора есть свои сильные и слабые стороны. В случае моем, все сильные стороны перекрыли слабые. И я в целом остался доволен, а предупредить про неприятные моменты - вот цель статьи, потому что нигде это не освещается практически
В чем была проблема хешей для имён в JS/CSS ? Это webpack или любой сборщик автоматом же должны уметь в билде?
Нет, просто в хост приложении загружается uikit и шарится в микрофронт. Сответственно, инжектятся стили с хешами версии ядра.
В микрофронте приложении uikit потребляется из хоста, но если версия будет, например, младше хоста и меняли, допустим, инпут или таблицу - стили отлетали, т.к. в дочернем приложении ожидаются другие хеши для css классов (использовались scss modules). Это как раз случай, когда, вероятно, использовать singleton для библиотеки не лучшее решение, но у нас uikit непонятным образом весит больше 2мб (точнее понятным - некоторую графику загнали в base64 в css и еще куча других проблем) и это мрак полный. Пришлось смириться и быть внимательным, чтобы обновлять единомоментно
Проблема тут еще в том, что uikit нам поставляли со стороны и информациооная поддержка была не лучшего качества - очень долго выбивали ченджлоги, в итоге пришли к тому, переодически высалаются PDF (!!!!) с описанием изменений, про сторибук молчу, больше выглядел как лишняя примочка не понятно для кого
У заказчика есть MVP, необходимо «просто его доработать» (с)
Тоже работаю в Лиге цифровой экономики, знаю некоторых заказчиков и проекты - очень долго, громко и от души смеялся, когда прочитал :)
Мой опыт с Webpack 5 Module Federation