Comments 19
"Сборка релиза" убивает большую часть отличий микрофронтендов от модульного фронта.
И да и нет, тут больше как зависимость пакетов. просто один из модулей типа умеет рисовать пони и собачек, а другой ожидает только пони... и вроду у нас должно быть 2 животных а по факту один . ну или оброатное что мы надеемся что модуль умеет больше чем на самом деле и тогда боль
Суть микрофонтендов не в том, кто чего умеет, а в том, что они релизятся независимо друг от друга и общаются только по очерченному контракту. И могут быть основаны на какой-угодно технологии, написаны разными командами.
а я вроде ни где не упоменаю что технологии не могут быть разными, один модуль ангуляр, допустим формы. Сам каркас реакт, а какой-нибудь слайдер свелт или вью. просто подготовка отдельных независимых модулей накладывает определенные обязательства и к этому надо быть готовым
Ну про технологии это скорее бонус, а суть в независимых релизах, которую вы описали как сомнительное преимущество. Микрофронтендовая архитектура позволяет командам пилить свои участки не оглядываясь на ритм других команд. Об этом и первый тут коммент. В чем разница, если у нас релиз собирается, разницы нет.
Я бы не стал на микрофронтендовые модули ставить прикоммитный хук с линтером и тестами. У меня в одной либе стоит билд и преттифай и каждый коммит уже занимает в районе минуты. Линтинг и тесты лучше проверять в CI на пулл-реквесте и не давать мержить пока всё не поправят.
Чем был плох предыдущий подход - монолит?
Монолитное приложение характеризуется высокой связанностью частей системы.
На мой взгляд классическое "смешать тёплое с мягким". Можно сильно запутать между собой микрофронтенды, аналогично тому, как из микросервисов создают "распределенный монолит". А можно создать слабо связанное между модулями одно веб-приложение.
в монолите получить высокую связность гораздо проще и сложнее отслеживать эти самые связи. Но конечно, следить за связностью нужно и там и там, это скорее вопрос архитектуры, который в данной статье не рассмотрен и к теме монолит/микрофронтенд не совсем относится.
Так-то оно так. Только одно но:
в монолите за связностью должен следить кто-то (ревьюер, например), никакие паттерны не дают гарантий и безопасности
в микросервисах вы этого можете добиться ограничением на видимость сервисов и разделением на слои, т.е. архитектурно
Отсюда вывод: микросервисы позволяют эффективнее контролировать уровень связности.
Микросервисы - это не "серебряная пуля". У них есть свои проблема, которые отсутствуют в монолите, например, увеличивающаяся сложность поддержки, более жестокие требования к инфраструктуре, обеспечение консистентности данных при их распределенном хранении, необходимость контрактного тестирования, сложность отладки и профилирования.
Если люди, пишущие код, не способны контролировать его связность, у вас точно так же в микросервисе будет сильная связность. Но таких проектов уже будет не один. Тут надо повышать квалификацию инженеров или вводить тех лида/архитектора для контроля. Но микросервисы вам тут не помогут)
"данный сервер позволит вам хранить картинки, документы и много чего еще не в репозитории, а на отдельном сервере, который может масштабироваться как вашей душе угодно"
Ради любопытства.
Чем в данном конкретном контексте minio принципиально лучше, чем любой web-сервер (apache httpd, nginx, lighttpd, MS IIS и т.д. и т.п.)?
если интересно подробно вот вам пару статей которые позволят понять нюансы https://habr.com/ru/company/veeam/blog/517392/ и вторая https://itsecforu.ru/2020/10/20/%F0%9F%A6%A9-%D0%B8%D0%B7%D1%83%D1%87%D0%B0%D0%B5%D0%BC-minio-%D0%B0%D0%B2%D1%82%D0%BE%D0%BD%D0%BE%D0%BC%D0%BD%D0%BE%D0%B5-%D1%85%D1%80%D0%B0%D0%BD%D0%B8%D0%BB%D0%B8%D1%89%D0%B5-%D0%BE%D0%B1%D1%8A/ Как минимум minio - имеет больше настроек и решает больше задач связанные с файлами статики.
Микрофронтенд, как не скатиться в ад