Комментарии 10
Шел 2024й. Программисты учились делать декомпозицию систем правЕльно...
Давненько тут не было архитектурных задач да еще и лонгридом.
Ща прочитаю и как великий архитектор скажу что я обо всем этом думаю
Когда-то давно, всё что вы описали, называлось портлетами) Хорошо что архитекторы за 100500 денег не просто так едят свой хлеб, а за 20 лет наконец придумали новое название, разбавив модными(а в иностранной среде уже давно нет) микросервисами.
Что вы думаете насчет замены iframe - module federation?
Супер гуд.
В бекенде/Фулл стаке (то что ближе к моей работе)
К сожалению, сама архитектура module federation построена на идеи того, что у вас сборка фронта из исходников происходит.
В случае использования фулл-стак фреймворков такое не подойдет, тк происходит или частичный или полный рендер страниц. И тут можно сделать 3 отступления:
* Классические фреймворки(RnR, Django, Laravel), где просто генерируются страницы - можно с этим что то сделать, но это крайней степени костыль, вряд ли кто то будет так заморачиться, тут проще с iframe сделать. Касательно классики - тут я подразумеваю, что у нас фреймворк именно фуллстак, а не только апишка. Когда есть фронт отдельно от этих фреймворков - там можно такое замутить.
* Jmix / VAADIN - тут можно прям сделать сразу все, если отключить дев сборку и получать не за-chunk-анный / minify-енный билд, его теоретически можно подтягивать в отдельное приложение, где есть вебпак или другая сборка, из разных проектов все это в один собирается и мы делаем аналог. Вот вроде и круто, а вроде на прод такое не запустишь, ибо страшно.
* Next/Nuxt - если исхольовать их как фуллстак(в случае каких то простых сервисов с большим UI и малой бекендной логикой) - то можно придумать, как извернуться и собрать все это
ПС - в любом из случаев - проще написать маленький фронтеенд и поставить на нем iframe, а от этой архитектуры отталкиваться
Фронтент
Тут мне кажется, он раскрывается на максимум, когда у тебя исходники лежать, желательно в монорепозитории и вы не хотите строить микросервисный фронтент - вы делаете модульную федерацию. Это по концепции, как раз, ближе к Self-Contained Systems, но в фронтенде. И получается есть выбор писать фронт, писать микро-фронт и федерацию. Ноооо, как по мне, все термины, которые содержать federation обычно более применимы к экосистеме Node/JS, ведь +- вся эта движуха пошла с apollo
В первую очередь - RpS, который ложиться на систему с общим Layout. Вторая - проработка кейсов с CORS/CSRF и XXS - тут у нас будут ссылки на какие то системы, логично, что ссылки кто-то захочет заабузить, потому стоит с осторожностью относиться к приведению ссылок и написанию таких приложений, внимательно следить за сериализацией данных в браузере и осторожно вносить фичи "которые упростят жизнь пользователю". На безопасность стоит обращать больше всего внимания при построении "микро-фронтентдов" на фуллстак фреймворках.
Еще один минус - это DevUX. Если вы будете строить большую систему, придется тестировать и по отдельности и вместе. В общем, над UI придется париться. Если у вас стартап, то лучше начать с монолита, а потом уже думать, куда лучше уходить. Если enterprise - то, тут люди привыкли к сложностям, тут скорее будет легче с root layout-ом.
Опять же, в статье говорил, придется с заказчиком уставливать стандарт того, как выглядит UI. Постановки, изменения, постановки, регламенты. В общем, много боли с согласованиями.
Не верю. Невозможно в реальном приложении разделить подсистемы так, чтобы отдельные "приложения" были отдельными колонками, как на картинке над гипсовым мужиком.
Пример. Система биллинга электроэнергии. Разделим ее на подсистему с потребителями (адреса, фамилии, явки) и подсистему сбора и хранения показаний. Ну и как вы представите форму ввода показаний, где должны отображаться фамилия, имя, отчество, адрес, текущие и прошлые показания, плюс до кучи результаты расчета расхода, плюс счета с начислениями?
Вот этот вот зелененький квадратик вверху колонки. Почему у него нет связей с другими подсистемами?
Можно и не верить, но есть факты.
Вот ссылки на статьи innoq которые пилят подобные e-commerce SCS приложения:
- https://www.innoq.com/en/cases/kommunikationsportal-edeka/|
- https://www.innoq.com/en/cases/best-in-industry-e-commerce-plattform-fuer-elektronikkomponenten/
Вообще да, подход трудно реализовать, так как нужна специальная область, где домены легко разбиваются, но опять же это проблема не подхода, а архитектуры.
Микросервисы прагматика: как построить большую систему с помощью пачки монолитов