Комментарии 18
Но я так понимаю, это связано со спецификой SSR-ориентированной архитектуры у автора. Пойду почитаю, что там внутри.
А может стоило использовать такой фреймворк, где изначально продумана система горизонтального масштабирования разработки? Например, в $mol вы можете независимо разрабатывать несколько приложений и отдельно разрабатывать обвязку, которая объединяет разрозненные приложения в единый портал. Например, берём вот эти приложения, реализованные независимо, без оглядки на объединение:
50 строчек кода и у нас получился единый портал, где они замечательно друг с другом сынтегрированы.
У меня сейчас постоянно стоит задача генерировать огромное количество CRUD интерфейсов, которые изредка обрастают доп логикой. Насколько с такой задачай справится mol?
Отлично справится. Можно сделать виджет редактирования сущности, который берёт описание схемы сущности и строит по нему форму редактирования. Так, например, сделан редактор компонент. Он анализирует код компонент и строит интерфейс для их настройки.
Помню, в стародавние времена различных вордпрессов и прочих конструкторов сайтов была популярна такая тема: цеплять разные плагины. Облако тегов, фоточки, ужасающе мигающая херня, календарь…
Чем эти микрофронтенды отличаются от классических модулей? На бэке понятно: у каждого микросервиса свой процесс, взаимодействие осуществляется средствами межпроцессной коммуникации (чаще всего по сети). Что у нас в случае микрофронтенд SPA? Модули фронта, которые общаются между собой по сети через сервер?
Возникают еще проблемы, не озвученные в статье:
- Для каждого микро-приложения используются свои технологии. Как уменьшить размер бандлов, загружаемых на клиент? Ведь у нас для каждой фичи свой фреймворк. А может даже разные версии одной библиотеки. На беке то такой проблемы нет.
- У нас вдруг запланирован редизайн. Как согласованно обновить N разных приложений со своим подходом к стилям? Или это должны делать N команд параллельно? Не слишком ли расточительно?
- Вряд ли все микро-приложения будут активно развиваться в течение всего жизненного цикла продукта. Большая часть это сделал — забыл. А основная активность сосредоточена только в паре-тройке разделов. Как тогда управлять техническим долгом, обновлять зависимости? Не окажемся ли мы потом с кучей разрозненного хлама?
Последнее мне вообще напомнило разработку на классических серверных MVC фреймворках лет 7 назад. Когда разные страницы имели свой независимый набор подключенных JS-библиотек.
Такое чувство, что этот подход применим только для каких то очень больших сайтов, где параллельно только фронтом должны заниматься десятки человек. Или наоборот, когда нужно быстро наваять среднее приложение, а договариваться об архитектуре не хочестя. Главное, чтобы потом поддерживать это приложение не тебе =)
У нас вдруг запланирован редизайн. Как согласованно обновить N разных приложений со своим подходом к стилям? Или это должны делать N команд параллельно? Не слишком ли расточительно?
У нас на бэке вдруг запланирован переход с RESTish на GraphQL или даже grpc, как согласованно обновить N разных приложений со своим подходом к работе с внешними API. Или это должны делать N команд параллельно? Не слишком ли расточительно?
Вряд ли все микро-приложения будут активно развиваться в течение всего жизненного цикла продукта. Большая часть это сделал — забыл. А основная активность сосредоточена только в паре-тройке разделов. Как тогда управлять техническим долгом, обновлять зависимости? Не окажемся ли мы потом с кучей разрозненного хлама?
У нас на бэке… Ну вы поняли :)
P.S. Я понимаю, что проблемы фронта сложнее аналогичных на бэке, всё-таки в одном пространстве эти микрофронтенды работают и без специальных усилий по изоляции очень быстро получим, как мнимум, конфликты. Где-то конфликты версий, а где-то синглтоны одного микрофронта будут работать со вторым неожижанно для обоих
Не, ну на беке микросервисы хотя бы повышают отказоустойчивость и улучшают балансировку нагрузки. Теоретически. Если правильно их приготовить :) Но я и на беке не люблю, когда микросервисами злоупотребляют.
А тут просто какое-то натягивание архитектуры фронта на структуру отделов компании-разработчика.
Ну, одно из обоснований перехода на микросервисы (на бэке) не повышение и балансировка, а чёткое разделение ответственностей "отделов". Даже одно из определений микросервиса гласит что-то вроде "микросервис — изолированный сервис, который легко пишется и(или) поддерживается одной командой (не помню, 3-12 человек из определения этого у меня в голове, или просто инфа о нормльном размере команды)".
На крупном проекте архитектура фронта, позволяющая раделить влияние модулей, разрабатываемых разными фронт или фулстэк командами, очень крутая штука. Боюсь только, что на том уровне как на бэке — слабодостижимая. Не уверен даже, что можно нормально использовать в одном проекте на одной версии фреймворка для одного модуля JS, а для другого TS. JS-команда скорее всего откажется писать декларации типов для свогео модуля, а TS либо будет писать их проклиная JS, или передут на implicit any, сначала только для того модуля, а потом начнётся протечка и в TS.
На первый взгляд, такая «система» вносит дополнительную сложность и добавляет ограничения.
На том же Angular 2+ при правильно спланированной архитектуре нет никаких проблем «разбить» монолит на полностью автономные модули, зависящие только от общих сервисов(«ядра»).
При некотором желании, не проблема организовать автоматизированную систему сборки «микрофронтов» в конечное приложение.
Основная идея и достоинство микросервисов – это возможность обновлять версии используемых фреймворков по частям, сервис за сервисом. Если у вас все модули фронтенда основаны на одном фреймворке, то мигрировать на новую версию по частям не получится, только весь фронтенд целиком.
А есть где посмотреть более-менее реальный пример, хотя бы с разными версиями одного фреймворка?
Нет таких, все спрятаны в интранетах. Потому что если показать такой незалогиненному пользователю, он сразу убежит.
P.S. а если серьезно, можно попробовать посмотреть на Wrike, у них раньше был микс ExtJS + Angular, не знаю как сейчас.
Микрофронтенды: о чем это мы?