Конкретно у нас градация оранжевого для визуализации числовой оценки. Чем более яркий цвет, тем лучше оценка. Ярко-оранжевый - 2, самый тусклый оттенок - 0, а если стоит N/A, то серый.
Изначально мы сделали светофор: красный, желтый, зеленый. Но пользователям не очень зашло, так как привычные цвета в наших дизайнах оранжевый, белый, серый. Попробовали текущий вариант и остановились на нем, так как он вызывал поменьше вопросов. Конечно, не исключено, что в будущем изменится и есть варианты, которые проверим позже
Да, сейчас тоже понимаем, что microfront-discovery - единая точка отказа. На данный момент не выбрали, что будем использовать в качестве альтернативы.
за счет высокой производительности, простого api не требующего обслуживания и изменения, а так же за счёт кажущейся стабильности и надёжности он у нас не обновлялся.
Именно по этой причине у нас разделены microfront-api и microfront-discovery.
Кажется, тут вариант один - каким-либо образом клиент сам должен уметь резолвить пути:
1) Как у вас сопоставлением паттернов между микрофронтом и местом его хранения - самый простой вариант. Но у нас данные лежат во внутреннем s3 и из внешней сети не достать, поэтому склоняюсь ко второму варианту.
2) Использовать k8s (примерно так). Все необходимые ресуры де-факто хранятся в s3 хранилище, можно навесить service (externalName) + ingress и выполнять релизы через кубер. В таком случае discovery заменяется кубером причем для каждого микрофронта отдельно. Если сюда добавить custom resource definition, чтобы скрыть эту логику с сервисом и ингрессом, то получается довольно декларативно. Похожий подход был рассказан в докладе на Holy JS 2020
Не понял, что значит "динамическая федерация", "синхронная на промисах". Можете раскрыть, что подразумеваете под этим?
> В последних итерациях пришли сбору всех и мержингу в одну большую структуру
А что именно содержится в этом JSON? Если там по аналоги с нашим манифестом инфа о shared, то как вы обеспечиваете актуальность версий, например, в package.json одно, а в yarn.lock другое?
Конкретно у нас градация оранжевого для визуализации числовой оценки. Чем более яркий цвет, тем лучше оценка. Ярко-оранжевый - 2, самый тусклый оттенок - 0, а если стоит N/A, то серый.
Изначально мы сделали светофор: красный, желтый, зеленый. Но пользователям не очень зашло, так как привычные цвета в наших дизайнах оранжевый, белый, серый. Попробовали текущий вариант и остановились на нем, так как он вызывал поменьше вопросов. Конечно, не исключено, что в будущем изменится и есть варианты, которые проверим позже
В таком случае у нас синхронная федерация. Promise based remote loading в нашем случае достаточно
Да, сейчас тоже понимаем, что microfront-discovery - единая точка отказа. На данный момент не выбрали, что будем использовать в качестве альтернативы.
Именно по этой причине у нас разделены microfront-api и microfront-discovery.
Кажется, тут вариант один - каким-либо образом клиент сам должен уметь резолвить пути:
1) Как у вас сопоставлением паттернов между микрофронтом и местом его хранения - самый простой вариант. Но у нас данные лежат во внутреннем s3 и из внешней сети не достать, поэтому склоняюсь ко второму варианту.
2) Использовать k8s (примерно так). Все необходимые ресуры де-факто хранятся в s3 хранилище, можно навесить service (externalName) + ingress и выполнять релизы через кубер. В таком случае discovery заменяется кубером причем для каждого микрофронта отдельно. Если сюда добавить custom resource definition, чтобы скрыть эту логику с сервисом и ингрессом, то получается довольно декларативно. Похожий подход был рассказан в докладе на Holy JS 2020
Не понял, что значит "динамическая федерация", "синхронная на промисах". Можете раскрыть, что подразумеваете под этим?
> В последних итерациях пришли сбору всех и мержингу в одну большую структуру
А что именно содержится в этом JSON? Если там по аналоги с нашим манифестом инфа о shared, то как вы обеспечиваете актуальность версий, например, в package.json одно, а в yarn.lock другое?