company_banner

Микрофронтенды: разделяй и властвуй



    Всем привет! Меня зовут Аня, я фронтенд-разработчик в Delivery Club. Хочу рассказать про использование микрофронтендов. Поговорим о том, что же это за зверь такой — микрофронтенд, почему мы решили использовать этот подход в своих проектах и с какими проблемами столкнулись при внедрении.

    Для чего они нам понадобились


    Delivery Club — это не только пользовательское приложение для заказы еды. Наши команды работают над сайтом, приложениями для курьеров и партнёров (ресторанов, магазинов, аптек и т.д.), занимаются прогнозированием времени, оптимизацией доставки и другими сложными задачами. Моя команда создаёт админку для работы с партнёрами. В ней можно управлять меню, создавать акции, отвечать на отзывы, общаться со службой поддержки и делать много других полезных для партнёров вещей. Но мы не единственная команда, которая занимается админкой. Отсюда возникало множество проблем при разработке:

    • Сложно жить с монолитом. Быстро писать код мешали устаревание подходов, фреймворков и зависимостей, а также связанность логики.
    • Совместная разработка. Долго решать конфликты, противоречивость изменений.
    • Проблема с тестированием. Когда прилетали баги от других задач и команд, было непонятно, в чём причины.
    • Развёртывание было зависимое и блокирующее.

    Поэтому нам нужна была возможность:

    • использовать любые инструменты и технологии, снижая риск устаревания;
    • разрабатывать и деплоить независимо;
    • изолировать реализации.

    Устройство проекта


    Для начала расскажу, как сейчас устроен наш проект.

    • Основное старое приложение на AngularJS, к которому мы планируем подключать новые микроприложения.
    • Dashboard-приложение на Angular 6, подключенное через iframe (но оно со временем разрослось и от описанных выше проблем не избавило). К нему подключаются приложения, здесь хранятся старые страницы.
    • Приложения на VueJS, которые используют самописную библиотеку компонентов на VueJS.





    Мы поняли, что ограничения тормозят развитие проекта. Поэтому сформулировали возможные пути:

    • Разделение приложения на страницы по маршрутам.
    • iframe.
    • Микрофронтенды.

    Мы сразу отказались от варианта с iframe (почему мы так решили, читайте ниже). У разделения страниц по маршрутам есть один большой недостаток: дублирование логики в каждом приложении (типа навигации) и вообще всего, кроме специфики страницы. Поддерживать такую систему в актуальном состоянии очень сложно. Поэтому мы выбрали микрофронтенды.

    Что такое микрофронтенды


    По сути, это микросервисы в браузере. В бэкенд-разработке микросервисы используют повсеместно, а в мире фронтенда этот подход встречается редко. Вот что можно почитать и посмотреть о микрофронтендах:


    Сейчас наш проект только переходит на микрофронтенды, наша команда стала первопроходцем. И мы столкнулись с рядом проблем.

    Проблемы внедрения микрофронтендов


    1. Ещё один iframe? Может, уже хватит?


    К великому разочарованию, наше dashboard-приложение открывается внутри iframe (исторически так сложилось), и нам очень не хотелось делать один iframe внутри другого. Однако это был запасной план. Если вдруг что-то пойдёт не так, то просто заворачиваем микрофронтенд в iframe — и готово рабочее приложение.

    Мы видели несколько недостатков:

    • Неудобная навигация. Каждый раз для редиректа на внешнюю ссылку нужно использовать window.postMessage.
    • Сложно верстать в iframe.

    К счастью, нам удалось этого всего избежать, и микрофрентенд мы подключили как веб-компонент с shadow dom: <review-ui-app></review-ui-app>. Такое решение выгодно с точки зрения изоляции кода и стилей. Веб-компонент мы сделали с помощью модифицированного vue-web-component-wrapper. Почитать подробнее о нём можно здесь.

    Что мы сделали:

    1. Написали скрипт, который добавляет ссылку на сборку микрофронтенда в разделе head страницы при переходе на соответствующий маршрут.
    2. Добавили конфигурацию для микрофронтенда.
    3. Добавили в window.customElements тег review-ui-app.
    4. Подключили review-ui-app в dashboard-приложение.

    Так мы сразу убили несколько зайцев. Во-первых, приложение представляет собой кастомный тег, как мы привыкли — компонент. Во-вторых, кастомный тег принимает данные как свойства, следит за ними и выбрасывает события, которые слушает обёртка. Ну и в-третьих, избавились от iframe внутри iframe :)

    2. А где стили?


    Ещё одна неприятная проблема нас ждала дальше. Компоненты в микрофронтенде работали, только вот стили не отображались. Мы придумали несколько решений:

    • Первое: импортировать все стили в один файл и передать его во vue-wrapper (но это слишком топорно и пришлось бы добавлять вручную каждый новый файл со стилями).
    • Второе: подключить стили с помощью CSS-модулей. Для этого пришлось подкрутить webcomponents-loader.js, чтобы он вшивал собранный CSS в shadow dom. Но это лучше, чем вручную добавлять новые CSS-файлы :)

    3. Теперь про иконки забыли!


    Затем мы подключили внутреннюю библиотеку, но в ней не отображались SVG.
    С иконками нам пришлось повозиться подольше. Для их подключения нам пришлось сделать несколько итераций:

    1. Сначала мы попытались подрубить спрайт так же, как и стили, через appendChild. Они подключились, но всё равно не отображались.
    2. Затем мы решили подключить через sprite.mount(this.shadowRoot). Добавили в вебпаке в svg-sprite-loader опцию spriteModule: path.resolve(__dirname, './src/renderers/sprite.js’). Внутри sprite.js экспортировали BrowserSprite, и иконки начали отображаться! Мы, счастливые, подумали, что победили, но не тут-то было. Да, иконки отображались, и мы даже выкатились с этой версией в прод. Но потом нашли один неприятный баг: иконки пропадали, если походить по вкладкам dashboard-приложения.
    3. Наконец, во vue-wrapper мы подключили DcIconComponent (библиотечный компонент, позволяющий работать с библиотечными иконками) и в нём подключили иконки из нашего проекта. Получили отображение без багов :)

    4. Без авторизации никуда!


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

    • Токен с авторизацией передаём с помощью свойств веб-компонента.
    • С помощью AuthRequestInterceptor подключаем токен-запросы для API.
    • Используем токен, пока он не протухнет. После протухания ловим ошибку 401 и кидаем в dashboard-приложение событие «обнови токен, пожалуйста» (ошибка обрабатывается в AuthResponseInterceptor).
    • Dashboard-приложение обновляет токен. Следим за его изменением внутри main-сервиса, и когда токен обновился, заворачиваем его в промис и подписываемся на обновления токена в AuthResponseInterceptor.
    • Дождавшись обновления ещё раз повторяем упавший запрос, но уже с новым токеном.

    5. Нас волнуют зависимости


    Проблема выглядела так: с каждым подключённым микрофронтом тянется бандл. И сколько микрофронтов подключено, столько и бандлов подтянуто. Чтобы избежать этого, мы применили общие зависимости. Вот как мы это реализовали:

    • В микрофронтенд-приложении указываем в webpack.config.prod.js в разделе externals те зависимости, которые хотим вынести:

      module.exports = {
      	externals: {
      		vue: ‘Vue’
      	},

      Здесь мы указываем, что под именем Vue в window можно будет найти зависимость vue.
    • В рамках оболочки (в нашем случае в dashboard-приложении) выполняем npm install vue (и другие npm install-зависимости).
    • В dashboard-приложении импортируем все зависимости:

      import Vue from ‘vue’
      (window as any).Vue = Vue;
    • Получаем удовольствие.

    6. Разные окружения


    Мы имеем три окружения: локальное, тестовое и прод. Сначала у нас была проблема при переходе с тестового окружения на прод: для микрофронтенда приходилось явно прописывать в проекте ссылку.

    Решили мы это следующим образом:

    1. Добавили в микрофронтенд файл, в котором определяем конфигурацию для приложения в runtime браузера. Также добавили в Docker системный пакет, который предоставляет команду envsubst. Она подставляет значения в env.js, который тянет микрофронтенд-приложение, и эти переменные пишутся в window['${APP_NAME}_envConfig'].
    2. Добавили переменные окружения отдельно для прода и отдельно для тестового окружения.

    Так мы решили несколько проблем:

    • настроили локальные моки (раньше приходилось вручную включать их локально);
    • настроили тестовое окружение без дополнительных ручных переключений на прод и обратно.

    Выводы


    Реализация микрофронтендов, их подключение и решение проблем при работе с ними тянулись довольно долго, но это того стоило. Микрофронтенды помогли нам отделить релизы команд друг от друга, разделить кодовую базу и избавиться от долгих решений конфликтов при git merge.

    Думаю, со временем всё больше проектов будут отказываться писать монолит и переходить на более универсальные подходы. Одним из таких подходов могут стать и микрофронтенды. Надеюсь, эта статья поможет кому-то в реализации.
    Mail.ru Group
    Строим Интернет

    Похожие публикации

    Комментарии 34

      +13

      В подобной архитектуре намного больше проблем, чем описано, и код, обслуживающий их, становится настолько сложным и трудноподдерживаемым, что приходится выделять отдельную команду. Участвовал в двух проектах с подобной схемой. В числе других проблем — отсутствие общих компонентов либо большая сложность в их интеграции (обновить шрифт в 10-20 микрофронтах? Поднять версию библиотек, подтянуть иконки? В монолите — час работы, в подобной системе — больше месяца, кроме шуток); подтягивание актуальных версий для локальной разработки (придется писать сложный cli-инструмент с резолвом конфликтов и менеджерингом гит-версий в каждом микрофронте); на поддержку root-обертки тоже нужна команда, со своим флоу поставок и разрастающимися версиями для поддержки обратной совместимости, что выливается со временем в катастрофическое торможение новых релизов; про SSR даже можно не думать; в каждом микрофронте свои подходы и устаревающие конфиги, которые тоже нужно синхронизировать; кратное увеличение времени CI/CD; в браузере общий DOM, соответственно общая раскладка, и если не пользоваться iframe то очень велика вероятность конфликтов стилей или лэйаута; дублирование полифиллов. Перечислять можно еще долго, но закономерный итог — замедление поставок и тонна багов от синхронизации. А что считается "достоинством"? "Свободная реализация компонентов системы разными командами", то есть тотальный зоопарк. Про "независимость поставок", который часто тоже служит аргументом, лучше и не упоминать — в реальности этого нет, наоборот, приходится часто лезть во все репозитории, разбираться в их коде и подходах, и править, влезая в циклы поставок других команд.


      За меньшее (!) время можно переписать легаси-код с полноценным рефакторингом и приведением к современным общим стандартам. Никто не мешает заложить архитектуру, в которой каждая страница — отдельный асинхронно загружаемый модуль, для развития которого не нужно лезть в рут и соответственно не будет конфликтов слияний, при этом он будет иметь доступ к глобальным методам и компонентам (модалки, нотификации, апи, роутинг), что уберет дубляж, будет поддерживать SSR, а апдейт зависимостей можно сразу протестировать на всем приложении. Не идите в эти дебри, тут вы не первопроходцы, а просто пополняете ряды страдальцев, занимающихся вместо продуктовой разработки решением самими же созданных проблем.

        +10

        Ну а чем ещё заниматься толпе программистов, когда их понабрали много, а приложение не ахти какой сложности? Только создавать и героически решать проблемы.)

          +3

          Можно еще писать компонент-тесты, делать подробную документацию к ним, обсуждать подходы типа двойные кавычки или одинарные, писать кастомные правила для ESLint, внедрять дополнительные статические анализаторы кода в CI/CD, делать обертки над многочисленными opensource-зависимостями для "абстракции от конкретной библиотеки", выносить каждое правило в стилях в миксины для "переиспользуемости", достигать какого-то уровня покрытия тестами кода, да мало ли еще бесполезной работы сейчас фронт-ендеры придумывают, лишь бы их бэк-енд был в тепле и достатке.

          –2
          Поднять версию библиотек во всех микрофронтендах сразу? Зачем?
            +9

            Обнаружилась критическая уязвимость, изменилась сквозная функциональность, потребовалась совместимость со свежей/старой/экзотической версией браузера.

              0
              1. Вполне может быть, что быстрее получится протестировать и обновить несколько важных микрофронтендов, и затем подтягивать хвосты, чем переезжать на поправленную версию всем монолитом (если же у вас компактный монолит, то зачем было ехать в микрофронтенды?).

              2. Изменение сквозной функциональности — если это значимый кейс, то вероятно микрофронтенды неправильно организованы и оказались сильно связаны.

              3. По поводу совместимости со свежей/старой версией браузера — обычно проблема не возникает сразу во всех микрофронтендах. Тут как раз двигать всех в светлое будущее может быть вредно.

              PS: Понятно, что если микрофронтенды использованы без нужды и просто потому что это модный тренд, то всё будет плохо. Ну так и микросервисы можно использовать не по назначению.
                +1
                1. Вот это "подтягивание хвостов" только звучит как будто это осуществимо, на деле приходится обновлять компонент (селект к примеру) в библиотеке компонентов для реакта, вью, ангуляра, ставить задачи на все команды по подъему версии, причем они могут быть ниже приоритетом чем задачи от бизнеса, в итоге 5 из 10 микрофронтов обновились через неделю, еще два — через две, еще в трех эти задачи "потерялись" и остались в глубоком бэклоге. В итоге приложение несинхронизировано, баги остаются надолго, стили остаются разными. С десятью обновлениями или тем более редизайном получается такой треш, что смотреть на это все невозможно. Организационно это тоже не решить, так как у команд разные циклы поставок. В монолите же один апдейт и если используется TS, то он не даст оставить "хвосты", придется переводить сразу все — это займет больше времени на задачу, но сэкономит десятки человекочасов (считая время аналитиков, тестировщиков, разработчиков) по сравнению с микрофронтами. Не в идеальном мире живем, когда все всегда доводят задачи до конца.


                2. Микрофронты всегда тесно связаны с рутом, в котором находятся глобальные компоненты и методы — не сделать серию нотификаций или модалок без доступа к информации, какие уже отображены, то же касается и авторизации, методов подключения/дестроя, роутинга. Изменения в каждом — критичны, если не поддерживать обратную совместимость, что сильно ограничивает возможности и раздувает код.


                3. С этим не сталкивался, так как использую автоматический полифиллинг (babel preset-env), соответственно достаточно изменить browserslist в каждом микрофронте, но эту схему используют далеко не все и действительно может стать проблемой.



                Микрофронты — не модный тренд, а метод обхода комплексного рефакторинга систем, чтобы можно было использовать легаси-части и постепенно их переводить на общую схему, имхо. А как по вашему, какое еще может быть у них назначение?

            +1

            Есть категории продуктов, для которых микрофронты — это верный архитектурный выбор.
            Например: набор независимых тулов, каждый из которых разрабатывает отдельная команда.
            В итоге у нас: управляющая база, основной интерфейс, текущий инструмент и какие-нибудь виджеты.


            Ключевое здесь — слабая связность, каждая из частей свободно работает без других.


            И это решило проблемы со скоростью доставки, с тестами. SSR тоже прикручивается. Дублирования стилей — эта проблема уже давно много раз решена.


            Тотальный зоопарк — да. Является ли это проблемой? Далеко не всегда.

              +1

              Смотрите внимательнее, сейчас фокус покажу...


              Приложение для чтения статей. Разрабатывается Аллой. Весит 60 кб.
              Приложение для проведения презентаций. Разрабатывается Борисом. Весит 60 кб.
              Галерея компонент. Разрабатывается Катей. Весит 140 кб.
              Песочница для различных трансформаций. Разрабатывается Денисом. Весит 80 кб.



              Приложение, включающее в себя вышеназванные и ещё немного. Разрабатывается Евгением. Безо всяких микрофронтендов. Весит 170 кб.


              И друг другу все эти люди никак не мешают. А приложения имеют гарантированно единый дизайн, а не лоскутное одеяло, как в единственном исключении.

                +1

                В том лоскутком одеяле прекрасно то, что никто и почти ничто не мешает какой-нибудь команде взять и начать использовать $mol.


                Так были в проде backbone/marionette, knockout, react, vue, angular. ts, flow, coffescript, clojurescript(на счёт прода — не уверен).


                Если бы у нас был бы вдохновитель $mol, а сам фреймворк был бы production ready в 2014-2016, то мы бы использовали.


                А вес бандла — это не так важно в b2b.
                Как-то я выпилил мегабайт неиспользуемого легаси во время рефакторинга. Это не повлияло ни на что.


                А вообще, я думаю присоединиться к сообществу и попробовать.

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

                На моем опыте был только один случай, когда приложение состояло из двухуровневых iframe — виджет встраивался в сайты, и в самом виджете было несколько фреймов из разных доменных зон, связанных по postMessage. Но и там сделал единую точку рендеринга, в которую ходили разные бэкенды за получением локализованного шаблонизированного html, соответственно "зоопарка" не было, просто такой мультифреймовый конструкт с большим оверхедом по доступу к данным соседних "микрофронтендов".


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

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

                Спасибо за комментарии и дискуссию с аргументами. Сейчас мы выбрали для себя такой путь и решили поделиться нашим опытом.

                Мы не станем дробить монолит на очень мелкие приложения, а оставляем возможность отрезать любой объем функциональности. Кстати, деплой у нас теперь занимает кратно меньше времени, а в ближайшее время собираемся его оптимизировать до минуты.

                Касательно ресурсов: мы справляемся без дополнительной команды, прослойки делаем максимально тонкими и простыми, без нагромождений сложной логики.
                0
                CSS прекрасно можно заинжектить в shadowRoot с помощью constructable StyleSheets.
                shadowRoot.adoptedStlyleSheets = ['adoptedCss1', 'adoptedCss2'], перезагрузки из кеша бразуера не будет, и плюсом это ссылка а не копия.
                А если у вас только vue —  смотрите webpack 5 + Module Federation

                Фонты через new FontFace().
                куча времени и кода было бы сэкономлено )
                  +1

                  Не взлетит, adoptedStyleSheets работают только в Chrome и его производных. Эта задача решается подключением внешнего файла стилей внутри shadowRoot, просто через тег link, как и в основном документе. Я обычно ещё инициализацию виджета запускаю в момент, когда стили полностью загружены, но это уже детали конкретной реализации. Стоит отметить, что инлайн стили внутрии shadowRoot могут нарушать CSP, поэтому лучше именно внешний файл.

                    0
                    adoptedStyleSheets это не только хром, к тому же есть полифил.
                    через тег линк — это прекрасно, но перформанс страдает это раз, количество копий css при большом количестве приложений это два, особенно если приложения пользуют один и тот же модуль, например от ui библиотеки и их надо кешировать.
                    Отсутствие возможности управлять css из хоста для всех приложений сразу ну итп.
                      0
                      adoptedStyleSheets это не только хром

                      caniuse.com/mdn-api_document_adoptedstylesheets — а кто еще? А еще покажите полифил который не ломает CSP.
                      но перформанс страдает это раз

                      Это как? Да, браузер должен сделать запрос, и да нужно дождаться загрузки… Но не вижу тут особых страданий, + кэш + prefetch.
                      и их надо кешировать

                      Это делает браузер. Ну или вы можете взять все под полный контроль в ServiceWorker.
                      Отсутствие возможности управлять css из хоста

                      Это не так, есть куча способов, начиная от реализации API через CSS-переменные и заканчивая тем-же сервис воркером…
                        0
                        Задачи у всех разные.

                        20 активных приложений будут иметь 20 копий css в памяти, загрузка каждого css из кеша браузера и парсинг займет ~200ms в зависимости от размера css. Ну и к тому же операция загрузки css асинхронная, а adoptedStyleSheets = нет.

                        Про кеширование имелось ввиду не css, а запущенные микроприложения не выгружаются при переходе из одного в другое.

                        Ну и нагородить, конечно же, можно всякого, но исходя из принципа — делать как можно проще — adoptedStyleSheets это хороший инструмент в умелых руках ))

                        Нативная поддержка в Safari и Firefox отсутствует, но видимо coming soon, ибо стандарт принят консорциумом и активно развивается.
                          +1
                          но видимо coming soon, ибо стандарт принят консорциумом и активно развивается

                          Пока только черновик, к сожалению. То есть, говорить о использовании в продакшене — рановато, особенно если вы в ентерпрайз проекте. Разработчики LitElement, к примеру, эту проблему так и не решили, и если вы используете что-то подобное — будете вынуждены добавлять unsafe-inline в ваш CSP.
                          имелось ввиду не css

                          Тогда причем тут adoptedStyleSheets? В любом случае, у вас есть disconnectedCallback чтобы выгрузить все что вам нужно выгрузить.
                          делать как можно проще

                          Что может быть проще старого доброго
                          <link rel="stylesheet"...
                          ?
                            0
                            ответ выше.
                            — асинхронность.
                            — задержка в ~200ms.
                            — нерациональное использование памяти.
                            — необходимость в куче дополнительного кода при необходимости изменить стили для всех активных приложений.

                            Jedem das seine.
                              0
                              Согласиться могу только с первым пунктом вашего списка, но да, каждому свое.
                  +1
                  Микросервисная архитектура до сих пор не имеет хороших паттернов проектирования и поддержки. У кого-то http запросы, у кого-то amq. Каждый по разному решает как содержать разные версии. Хотя в помощь идут docker, kubernetes и прочий зоопарк. Микросервисная архитектура решает вопросы масштабирования как вычислений(1000 и более нодов на приложение), так и зоны отвественности. 100, 1000 и более разработчиков в одном котле становится нормой. Мне сложно представить фронтенд, который пилят 1000 разработчиков. Я не могу представить распределенный фронтенд. Верю в то, что с развитием скорости сети и серверных мощностей, фронтенд превратится в подобие рдп. Текущий технологии не позволяют хорошо изолировать код, до сих пор ресурсы пилят с оглазкой на медленный интернет. Фронтенд, в отличии от бекенда, варится в одном котле. Положил тухлый компонент к блюду и все блюдо в унитаз. Поэтому и существуют шеф повара, которые все проверяют и контролируют. Думаю ничто не мешает выделять в сторонние модули и компоненты, которые могут лежать в разных репозиториях, вести свои версии. А главный шеф повар будет проверять их перед добавлением в общий котел
                    0
                    Я не могу представить распределенный фронтенд

                    А виджеты от внешних сервисов можете представить? Почти тоже самое, но микрофронтенды — проще, потому что вы, как разработчик, имеете хорошее представление о общей оркестровке на самом верхнем уровне (лично знаете своего шеф-повара). И текущие технологии вполне позволяют сделать все необходимое (изоляцию) без использования тяжеловесных решений типа iframe, статья об этом, собственно.
                      0
                      Статья описывает воду. Где примеры того, как решается задачи ssr, как дружат версии библиотек(касаемо тех, которые сложно изолировать с помощью webpack). Как происходит предотвращение повторных загрузок одинаковых библиотек(для примера был опыт использования d3 + плагины, весили в сжатом виде 1мб). Как происходит подгрузка функционала, который должен быть загружен сразу, но не является базовой. Главное еще не только в том, что решается ли, а какими жертвами.
                      На шарике такое проходил, извращению не было границ)
                        0
                        Статью не я писал, поэтому не могу ответить на все ваши вопросы, но главное — там есть, это изоляция, композиция и контроль жизненного цикла (CustomElements + Shadow DOM). Остальное решаемо, если руки растут из правильного места.
                    +4

                    в 5 вебпаке из коробки есть возможность пилить микрофронтенды — https://webpack.js.org/concepts/module-federation/


                    мы это уже используем в продакшене, если интересно, могу написать статью с гайдом, подводными камнями и т. д.

                      0

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

                        0

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

                          0

                          и не только скрипт, на самом деле, всё, что может собрать вебпак

                          0
                          написал пост как и обещал, буду рад любым вопросам и замечаниям habr.com/ru/post/554682
                        +2
                        В очередной раз убедился, что не бывает единорогов на радуге. В крупных компаниях тоже берут и делают кашу из подходов/библиотек/фреймворков/кода. А потом, когда пытаешься к ним устроиться на работу, рассказывают, какая у них сложная архитектура и если ты не работал с «такой-то» библиотекой, то и иди вон ковыряйся в легаси. Йоп, ребят, да любой в первый день глаза сломает от увиденного, если лезть в недра.
                          +1

                          Крупные компании/проекты когда-то были маленькими.
                          Веб развивается. Конкуренты не дремлют. Пользователям нужны новые фичи. Требования к продуктам меняются очень быстро.


                          И выбор подходов обусловлен параметрами, по которым оптимизируемся.

                          +1
                          Спасибо, что описали «как делать не надо». Очень странная стала разработка: когда у проекта нет времени на нормальный рефакторинг и упрощение легаси архитектуры — они решают её усложнить! Это же абсурд.

                          Вы пишите, что не можете сейчас обновлять билиотеки независимо и это минус, по-вашему. Да это никакой не минус! У вас вместо устаревания одной библиотеки теперь будут устаревать десять. И времени потом их обновить точно не будет. Когда что-то ломается — надо ремонтировать, а не накрывать платочком и ставить сверху новое.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое