Как стать автором
Обновить

Комментарии 12

Глаз цепляется за «Разделение переднего конца» и подобные ошибочки машинного перевода :)

Если не секрет — зачем большое приложение переделывать с angular на vue? Какая мотивация, как продали бизнесу эту идею и получили добро на реализацию?
Здесь нельзя однозначно ответить на этот вопрос, много существует причин. На чем писать — дело не вкуса. У каждой технологии есть свои преимущества. У нас существуют модули, которые намного проще писать на vue, разработка будет быстрее, вес и время сборки намного быстрее, подобрать команду в разы легче чем команду, которая знает ангулар. Да и не обязательно микро-приложение должно иметь другую технологию, можно выбрать ангулар, я здесь описываю возможность, иногда появляется необходимость в ее использовании.
Никогда не понимал зачем микросервисы нужны на фронте. Прочел аргументацию в статье и все равно не убедительно. На бэкенде (откуда их притащили) микросервисы нужны в первую очередь для того, чтобы масштабировать нагрузку, причем делать это максимально эффективно (а не дублировать целиком ноду). И мало кто в здравом уме стал бы делать микросервисы только для того, чтобы отдельные части могли разрабатываться отдельно и далее по пунктам. Для всего этого придумали модули, компоненты и т.д.
Прошу прощения за краткость содержания, раз не смог вас убедить в локальной необходимости ее использования. Существуют разные проекты, от маленьких до огромных. Frontend приложения уже не те, что раньше. В них присутствует бизнес логика, и не маленькая. Множество больших компаний уже были вынуждены перейти на эту архитектуру. Это очень логично и удобно — работать с чем то маленьким, чем с чем то большим. В том же коде вы же создаете метод, стараетесь сделать так, чтобы ответственность у него была одна, с ним удобно работать, поддерживать и тестировать. Вот и представим, что методы — это наши модули.
Вот и представим, что методы — это наши модули

Может, тогда и называть это не микросервисами, а модулями? К термину «модуль» лично у меня вопросов нет. Правда, это не что-то новое, модное, молодежное, а давно известное
все растет по возрастанию, принцип остается тот же. Меняется только реализация.
Что мы имеет в самом низу?
Здоровый метод, в нем есть к примеру удаление элемента с таблицы, отправка запроса на сохранение, прокидывание уведомления и что то еще. Что делать? Создаем отдельно методы на удаление элементов,….
Все хорошо, что делаем дальше? В раскиданных хаотично файлах, мы пытаемся найти смысл и понимаем, что на самом деле там куча разных методов, которые относятся к разным частям проекта. Что делаем, разбиваем проект на модули.
Что мы видим дальше? У нас куча разных модулей, которые относятся к разным, сложным бизнес задачам. Что можно сделать с этим? Разбить большие бизнес задачи на отдельные проекты. На самом верху будет контейнер, в нем будут лежать микро-приложения. По мне вполне аккуратно и удобно.

Я как-то продал идею микросервисы на бэке за счёт независимого деплоя. Бизнес немного не устраивало, что деплой часто изменяющихся частей приложения приводил к даунтайму других. И как водится стейкхолдеры и пользователи у этих частей были разные со разными KPI из-за чего возникали конфликты. Реальные, не технические.

Этот ваш "я как-то продал" и есть фактически определяющая штука микросервисной архитектуры. Независимые release/deployment цыклы сервисов. Это то чем микросервисный подход отличаются от модульного монолита например.

"Определяющих" штук у микросервисной архитектуры много, и они как бы субъективны. Для кого-то это горизонтальное масштабирование рантаймов, для кого-то независимая разработка и деплой.

Не так уж много. Вот две главных из них вы и назвали причем вместе. ;) По отдельности это не определят МС-сы.

Я к тому, что свойств, плюсов у МСА много, но определяющим фактором при принятии решения переходить на неё обычно какое-то одно, остальные, так, бесплатный бонус.

Что делать, если один из фрагментов недоступен / не может отрисоваться.
действительно, какие тут есть варианты?

Я работал в одной из 15 команд на большом проекте. И вот иметь возможность деплоить независимо от других — хорошее ускорение разработки. Команды вертикальные, где каждая имеет свои микросервисы и свой фронт. Сервисы собираются в консуле, а фронтенд в огромном монолите с ангулар модулями.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории