S
Само слово микрофронтенд выглядит забавно)
Size: a a a
2021 June 28
КС
Понял, спасибо! Мне удалось откопать сейчас один минус связанный с роутингом через порты:
Вычитал что некоторые паблик wi-fi точки доступа могу блокировать некоторые порты
Вычитал что некоторые паблик wi-fi точки доступа могу блокировать некоторые порты
p
по факту два варианта только: {svc1,svc2,svc3}.example.com или example.com/{svc1,svc2,svc3}
DS
Делай как удобно вам. Как по мне удобней на поддоменах. В том же kubernetes это проще будет менеджить, чем один ingress для всех "микрофронтендов" с разными path
DS
угу, и правда =)
DS
так если фронтенды наружу торчат и на него клиенты ходют, какие еще порты. 80/443 все. Делать другие порты для фронтенда как по мне моветон. Ну и гаранитй не будет, что не заблокировует провайдер
КС
да, вот щас как раз так и сделал и подумал что как-то не очень и захотел разобраться а как же все же лучше
DS
@bintoll а чисто ради интереса. Сколько микроразработчиков пилят один микрофронтенд? Это все деплоется в microk8s?
КС
там чуть другая система микрофронтендов. Есть базоваое приложение, которое доступно по 80/443. А там уже базовое приложение само ркестрит какие микрофронты ему подгружать в зависимости от роутинга
DS
ну тем не менее это будут запросы из клиента, на другие "микрофронтенды", соотвествеено клиент будет ходить на них.
DS
разница есть. Особенно если они в разных ns. validating хук дефолтный от nginx ingress даже такое скорее всего не разрешит
DS
Да, я так делаю и сам. Но вроде в разных ns один и тот же домен хук не дает юзат. Мб я и ошибаюсь - надо затетсить или код хука посмотреть
КС
такая архитектура
КС
ну да я к тому что сам пользователь не видит изменения порта когда ходит по страницам, для него это всегода 80/443