Комментарии 6
Спасибо за статью. У нас тоже микрофронты, но на своей реализации. Вот только недавно пришли к выводу, что service-discovery (как у вас microfront-discovery) это единая точка отказа для всей системы. У нас он statefull потому с репликацией там ну такое. Это привело к тому, что за счёт высокой производительности, простого api не требующего обслуживания и изменения, а так же за счёт кажущейся стабильности и надёжности он у нас не обновлялся. В итоге инфра при обновлении версии helm заставила нас перерелизить SD. Было очень потно. Более 50 микрофронтов ссылались на него,а в одной из прошлых версий нашего фреймворка микрофронтов прилага падала, когда теряла связь с SD. И даже заранее проверив версии было страшновато. В итоге решили, что лучше конфиги разбитые на локал, дев и прод. Т.е. микрофронты не меняют свое место публикации, убираем лишний сервис с обслуживания, освобождаем ресурсы на его работу, фреймворк микрофронтов на основе используемых паттернов api может сам сапоставить куда стучать за ремоутами, состав фронта по ремоутам не меняется внезапно, без релиза, только версионность потому возможно конфиг проще в поддержке
Да, сейчас тоже понимаем, что microfront-discovery - единая точка отказа. На данный момент не выбрали, что будем использовать в качестве альтернативы.
за счет высокой производительности, простого api не требующего обслуживания и изменения, а так же за счёт кажущейся стабильности и надёжности он у нас не обновлялся.
Именно по этой причине у нас разделены microfront-api и microfront-discovery.
Кажется, тут вариант один - каким-либо образом клиент сам должен уметь резолвить пути:
1) Как у вас сопоставлением паттернов между микрофронтом и местом его хранения - самый простой вариант. Но у нас данные лежат во внутреннем s3 и из внешней сети не достать, поэтому склоняюсь ко второму варианту.
2) Использовать k8s (примерно так). Все необходимые ресуры де-факто хранятся в s3 хранилище, можно навесить service (externalName) + ingress и выполнять релизы через кубер. В таком случае discovery заменяется кубером причем для каждого микрофронта отдельно. Если сюда добавить custom resource definition, чтобы скрыть эту логику с сервисом и ингрессом, то получается довольно декларативно. Похожий подход был рассказан в докладе на Holy JS 2020
Немного не ясен момент - у вас все-таки динамическая федерация или синхронная на промисах?
Идея с плагином для манифестов интересная, но я в своих проектах держал отдельно с каждым фронтом json, который его описывает. В последних итерациях пришли сбору всех и мержингу в одну большую (относительно, для прода минифицируется и чистится от dev переменных) структуру, которая запрашивается шеллом в рантайме + содержит переменные окружения (динамическая федерация).
В крайнем проекте, все это упаковано в nx и генерируется его инструментами
Не понял, что значит "динамическая федерация", "синхронная на промисах". Можете раскрыть, что подразумеваете под этим?
> В последних итерациях пришли сбору всех и мержингу в одну большую структуру
А что именно содержится в этом JSON? Если там по аналоги с нашим манифестом инфа о shared, то как вы обеспечиваете актуальность версий, например, в package.json одно, а в yarn.lock другое?
Можете раскрыть, что подразумеваете под этим?
Синхронная федерация - это когда адрес прописывается в remotes. Динамическая - когда в рантайме дергается get/init вебпака (примерно, как тут)
А что именно содержится в этом JSON?
Переменные окружения, адрес ремоута, filename, exposes, некоторая бизнес-информация
Если там по аналоги с нашим манифестом инфа о shared, то как вы обеспечиваете актуальность версий
Фронтовым монорепозиторием + отдельно в той структуре генерируется информация о шареде - все версии жестко зафиксированы и не имеют права фронты без согласования трогать каким-либо образом бибилиотеки (установка, обновление и т.д.). Ну и жесткие правила гитфлоу. В общем, доверия никакого никому с частичной атоматизацией)
Не смотря на возможность работать в отдельный репах, с module federation я в принципе не сторонник такого подхода + приходилось работать не всегда работать с самыми квалифицированными кадрами, отчего упаковка в монорепу с единым списком библиотек стал единственным подходящим вариантом для работы
Микрофронтенды на Module Federation — наш опыт. Часть 2