Очень интересный вопрос. В моей парадигме хост страница отвечает за позиционирование блока, если он не абсолютно спозиционирован и сам блок, если абсолютно. Более того, в моей парадигме и кнопка и сама форма — суть один фрагмент (не сервис!)). Т.е. поведение кнопки и, соответственно, позиционирование формы всегда будет соответствовать настройкам (модели), которую вы передадите при инициализации фрагмента.
Ну даже не знаю… В моем понимании, плагины — это всего-лишь возможность расширить функционал существующей системы. Они никак не помогут исправить или изменить исходный функционал системы. И тем более не решают задачи независимой разработки, независимых технологий и свободы выбора архитектуры.
Но безусловно, некое сходство можно найти между плагинами и микросервисным фронтендом.
Если уж совсем на чистоту, то сам по себе микросервисный подход на бекенде тоже можно методами последовательных приближений сравнить с OSGI, которым пользовались довольно безуспешно в монолитах.
serjoga
1. Мне он не нужен, чтобы писать на разных фреймворках, но он мне критически необходим для организации изоляции фрагментов на странице. И да, как только веб компоненты начнут нам приносить еще какую-то пользу кроме возможности объявить кастомный тег, мы обязательно используем их во фрагментах. Но фишка в том, что фрагменту не важно как он написан. С использованием web components или нет. Работать все равно будет хорошо и целей своих достигнет.
2. Тут слишком глубоко :) Не понял.
3. Ну это очень спорные утверждения. Это получается, что если дать любому джуну material-ui, он любой интерфейс за день замонстрячит?
4. Все верно говорите, есть шаренные хранилища в браузере. Также как и куча шаренных хранилищ на бекенде — БД, кеш, CDN, сервер конфигурации, idm и много всего другого.
Borz
Я понимаю уровень фрустрации, который вношу подобным названием, но все-таки я вижу принципиальную разницу между подходами. IDE может быть написана разными командами, даже достаточно независимыми, но все равно она билдится в некий единый бандл. И как только эта компиляция прошла — все, владелец модуля не может обновить только свой кусок. Также на лицо остальные минусы модульного подхода типа завязки на определенную технологию и невозможность использования узко специализированной.
1. Стандарт WebComponents еще не принят полностью. Остаются очень важные (ключевые) части, по которым нет согласия. В браузерах поддерживается по факту только Custom Tag. А вот важнейший Shadow Dom не поддерживается много где (https://caniuse.com/#feat=shadowdomv1), а где поддерживается — есть отличия в поведении. Только не говорите мне о полифилах!!! Если браузер не может изолировать два дом дерева друг от друга, то никакой полифил этого сделать не сможет.
3. «К-во команд равно к-во микросервисов +1 (product team)» — в этом случае вы приходите к моей архитектуре. Только мне еще и продакт тим не нужна. У нас один микросервис — это, например, админка, црм, каталог, цмс.
2. Product Team, как в вашем плане, собирающий интерфейс из веб компонентов станет бутылочным горлышком. Ему придется понимать как работает каждый компонент в отдельности. Ведь именно от этой команды будут зависеть 70% результата.
3. Использовать единый фреймворк — да! Это круто. Но есть узкие задачи. Есть команды с разной историей и опытом.
4. «Понятие «микросервисы» не применимо на фронтенде, среда то одна ;)» — ошибаетесь. Я так же могу сказать, что понятие микросервисов не применимо на бекенде — система, на которой они крутятся, одна же! Самое важное не то, что эти фрагменты в конце концов оказываются на одной странице, а в том, что мы даем возможность делать куски этого финального интерфейса достаточно независимыми и действительно независимыми командами. А значит подход микросервисный.
Здравствуйте! Немного ортогональный вопрос теме статьи :) В целом, не вижу никакого смысла в использовании GraphQL для общения между микросервисами. Но скажу, что мы активно его используем для взаимодейсвия между фронтом и беком.
Те самые фрагменты GraphQL, на которые вы дали ссылку — это совершенно не те фрагменты, о которых я разговаривал. Это просто дополнительные возможности языка запросов в GraphQL.
Как раз не так :) Команды у нас поделены вертикально. Именно поэтому очень важно поделить и фронт на микросервисы и сделать его куски действительно независимыми. Иначе мы могли бы жить с одним жирным SPA князь кактус.
С SEO решаем вопрос также как его решают все разработчики SPA — серверный рендеринг. Микросервисный фронтенд не сильно его усложняет, т.к. каждый фрагмент по сути — отдельный SPA.
Бекенд кейс валидный, но к топику не относится, т.к. работа идёт с персистант состоянием. Тут уже давно придуманы RabbitMQ и всякие Kafka.
А вот фронтенд кейс не очень хороший. У вас есть два микросервис, которые работают с общим состоянием, но при этом состояние это хранят в разных местах. Это сразу же архитектурный промах. В моем понимании эти два фрагмента должны иметь общий сторадж (в вашем случае локалсторадж) и обмениваться эвентами только для того, чтобы сообщить, что данные надо обновить. Далее все решится само.
Есть другие кейсы, где это действительно нужно? Т.к. реализовать персистант шину на клиенте не сложно. Хоть и не понятно зачем.
Я думал о ситуации, когда новая версия категорически отметает обратную совместимость.
Такое безусловно может быть. В этом случае и тут можно использовать canary deployment. На данный момент наша разработка этого не поддерживает, но не вижу ничего сложного в реализации.
это было бы очень круто, научить ее отправлять в «свежеподнятый» компонент все неполученные им в момент простоя сообщения
Очень не однозначная фича, не находите? Подписаться на события, которые были до подключения. А что если эти события устарели? А что если события взаимоисключающие? А что если события были отменены? А главное — вы можете придумать бизнес кейс для этого?
Внутри что-то шевелится, пытаясь как-то намекнуть, что в микросервисах одна из самых главных вещей это все-таки масштабируемость и fault-tolerance, а в однопоточном фронте это несуществующая проблема, но это холивор и к делу не относится.
Тоже люблю философствовать, поэтому позвольте прокомментировать. На мой взгляд, вы перечислили не одну вещь, а две разных :) И забыли третью очень важную — независимость (в том числе независимость обновлений). Вот именно это вполне достижимо и приносит очень хорошие плоды. А в целом, масштабируемость для фронта — это пока что-то непонятное. Но вот fault-tolerance вполне себе проявляется в нашем подходе. Например, если один из микросервисов упадет или не поднимется в облаке, любой другой, кто хочет показать в себе его кусок, просто ничего не покажет на этом месте. И пользователь сможет продолжать выполнять задачи присущие только не упавшему микросервису. Вуаля :)
Да, вы правы, проблема версионности тут встает в полный рост. Тот подход, который вы описали для мира бекенда, называется canary deployment. Но это не единственный способ решить поставленную задачу. Также можно сделать, чтобы микросерис А версионировал свой API. Т.е. любой эндпоинт микросервиса А будет иметь версию. Например, /microserviceA/api/v1/endpointA. Микросервис должен гарантировать, что при любом изменении контракта этого эндпоинта, он получит новую версию, но старая продолжит работать по-старому.
Вся эта проблема возникает по причине так называемой runtime зависимости. Т.е. зависимость, которую невозможно проверить во время компиляции.
То же самое происходит и с фрагментами и с платформой, которая их менеджит. Приведу пример решения этой проблемы в платформе. У нас есть артефакт, который подключают к себе на страницу все микросервисы — он никак не версионируется (в URL нет ничего, говорящего о версии), но внутри него любой метод версионирован по принципу версионирования API микросервисов (methodA_v1, methodA_v2...). Кроме того, мы поставляем статическую зависимость (для каждого фреймворка свою), которая по сути является оберткой для вызова тех самых методов с версией. Она версионируется и вызывает соответствующую версию метода. Следовательно, не важно с какой версией обертки собран фрагмент, он сможет работать независимо от того, есть ли уже более новая версия зависимости runtime.
Вы описываете все равно подход со статической линковкой компонентов. Моя же задача сделать так, чтобы если микросервис А использует часть из микросервиса Б, то после обновления микросервиса Б, микросервис А тут же получил обновления без пересборки и перезаливки докер образа. Это и есть принципиальный бенефит микросервисного фронта — только микросервис Б отвечает за то как будут выглядеть и работать принадлежащие ему куски.
Именно кода? Практически никакого. Команды продолжают разрабатывать на своих любимых фреймворках. Иногда даже идет сокращение кода, когда не приходится писать для своего нового фреймворка очередную реализацию авторизации или локализации.
Очень интересно! Но есть ощущение, что понятие фичи в вашем рассказе размыто. Создалось ощущение, что вы фичей как раз называете микросервис. У нас фича — это некая функция микросервиса. И да, она может состоять из чего угодно (чаще всего из FE API, js+css), фключаться и отключаться по запросу. Вот только в нашем понимании, каждый фрагмент может состоять в свою очередь из фич, которые очень даже взаимосвязаны. С другой стороны, взаимосвязанность фрагментов мы не приветствуем. Их цель — разделение ответственности и прочие плюшки микросервисной архитектуры.
В целом, и такой подход используется — есть фрагмент «общая шапка», в котором ссылки на разные микросервсы, в каждый из которых этот фрагмент вставлен. Переходы между микросервисами осуществляются с перезагрузкой.
Но как быть с примером из статьи? Есть корзина, владелец которой один микросервис, а отобразить надо в другом (при том с сохранением состояния при переходе)
Собственно вы и ответили на вопрос — у вас есть реестр подобных веб компонент и если микросервис не зарегистрировал там его, то и на странице не покажется.
Пока получается, что вы прошли тем же самым путём. Чем вдохновлялись?
меня лишь возмутило одновременное наличие различных технологий на странице, но как вы указали в последнем комментарии, что это специфика вашего проекта.
Я бы все-таки не совсем такой вывод сделал — это специфика микросервисного подхода для крупных проектов. Где UI — это не один портал или один рабочий стол, а целый набор разнородных инструментов, которые так или иначе друг с другом связаны по бизнес процессам. Наша компания тут не уникальна. Гугл, например — каждый сервис может выбрать свой фреймворк для написания (некоторые вообще свои рожают). Мейл — то же самое. Рамблер. Яндекс все-таки пытается стек держать консистентным, но в принципе тоже разные фреймворки попадаются.
Справедливости ради — пока мы выбрали в качестве стандарта де-факто Angular 2+ (6 прямо сейчас) и выбор другого фреймворка для конкретного микросервиса должен быть очень мотивирован.
И еще, когда мы переходили с Angular 1 на Angular 2+ — мы почувствовали все бенефиты подхода, когда микросервисный фронт может одновременно работать на нескольких технологиях.
Спасибо за то, что делитесь опытом. Если я понял ваш подход, то каждый микросервис оборачивается в веб-компонент или IFRAME для обеспечения изолированности на странице. А кто занимается построением каждой страницы? А каким образом обеспечивается консистентность, если в конфигурации конкретного тенанта нет какого-то микросервиса? А каким образом обеспечивается взаимодействие кусочков? А как сделана авторизация? А как решаете проблемы перформанса, которые неизбежно приходят?
Так вот вся соль в том, что в этой статье я описал именно решение задач, которые встают в момент, когда мы говорим — каждый микросервис отвечает за те куски экрана, которые к нему относятся. А уже как сам микросервис обеспечит изоляцию — это его выбор. Кто-то пытается идти с веб-компонентами — мы не советуем, т.к. спецификация поддерживается очень слабо в самых важных местах. Кто-то заморачивается на специфичность стилей и поставке бандла без внешних зависимостей. Кто-то действительно использует IFrame, если это интеграция с 3rd party. Важен общий подход — если есть кусок UI микросервиса, то только команда этого микросервиса должна за него отвечать.
Ну не скажи. Мы наоборот решили организационную проблему в бекенде (сильная связанность, боттл нек команды, отсутствие ответственного за функционал) методом деления на микросервисы. А дальше уже решили ту же самую проблему во фронтенде. Технический способ давно известен.
Вы хотели поругать наш подход, но в результате пришли к нашему же выводу:
Всё независимое выкинуть в разные проекты (разные технологии/фреймворки), а что имеет связь в рамках одной страницы в рантайм должно быть одним проектом на одной технологии
Именно так. Только вы это называете проектом, а мы — микросервисом. И да, микросервис написан на едином фреймворке и поддерживается единой командой.
А теперь давайте с конца прокомментирую ваши замечания.
Вам всё равно придется при изменении глобальной зависимости (от которой зависят все фрагменты, а этих сервисов даже в статье перечислено много) править код во многих фрагментах
Тут вы и правы и не правы. От глобальных зависимостей никуда не деться, хотя свести их к минимуму — вполне возможно. (Кстати, предлагаемый вами, модульный подход увеличивает dependency hell.) Другое дело, что мы об этом очень хорошо подумали заранее и добавили версионирование этой зависимости. Версионируется не только сам артифакт, но и рантайм зависимость — даже если в барузере подгружена новая версия общей зависимости, ваш код со старой будет продолжать работать.
Ни в коем случае, всё в модулях!
Модули потом все равно в единый бандл компилируются. Или вы имеете в виду, что каждый модуль компилируется в js отдельно и подгружается в браузер независимо? Тогда мы перейдем к обсуждению проблем — асинхронности подгрузки модулей, dependency management, производительность.
Значит выбран неподходящий для вашей задачи фреймфорк, но уж точно не позволять в одном проекте писать на разных.
Тут вы не уловили мою мысль. Наш проект — это сложная система, состоящая из выделенных частей (микросервисов). Разными фреймворками могут пользоваться разные части. Но понятно, что каждая часть обычно написана на едином фреймворке. В некоторых экзотических случаях могут использоваться специализированные фреймворки для решения конкретных задач в конкретном месте одной части. Но это уже выбор каждой части в отдельности.
Модули на 100% реализуют микросервисный подход во фронте
Если мы с вами одно и то же подразумеваем под микросервисном подходом (читай начало статьи), то раскройте, пожалуйста, мысль с модульным подходом. Будет интересно.
Но безусловно, некое сходство можно найти между плагинами и микросервисным фронтендом.
Если уж совсем на чистоту, то сам по себе микросервисный подход на бекенде тоже можно методами последовательных приближений сравнить с OSGI, которым пользовались довольно безуспешно в монолитах.
1. Мне он не нужен, чтобы писать на разных фреймворках, но он мне критически необходим для организации изоляции фрагментов на странице. И да, как только веб компоненты начнут нам приносить еще какую-то пользу кроме возможности объявить кастомный тег, мы обязательно используем их во фрагментах. Но фишка в том, что фрагменту не важно как он написан. С использованием web components или нет. Работать все равно будет хорошо и целей своих достигнет.
2. Тут слишком глубоко :) Не понял.
3. Ну это очень спорные утверждения. Это получается, что если дать любому джуну material-ui, он любой интерфейс за день замонстрячит?
4. Все верно говорите, есть шаренные хранилища в браузере. Также как и куча шаренных хранилищ на бекенде — БД, кеш, CDN, сервер конфигурации, idm и много всего другого.
Borz
Я понимаю уровень фрустрации, который вношу подобным названием, но все-таки я вижу принципиальную разницу между подходами. IDE может быть написана разными командами, даже достаточно независимыми, но все равно она билдится в некий единый бандл. И как только эта компиляция прошла — все, владелец модуля не может обновить только свой кусок. Также на лицо остальные минусы модульного подхода типа завязки на определенную технологию и невозможность использования узко специализированной.
1. Стандарт WebComponents еще не принят полностью. Остаются очень важные (ключевые) части, по которым нет согласия. В браузерах поддерживается по факту только Custom Tag. А вот важнейший Shadow Dom не поддерживается много где (https://caniuse.com/#feat=shadowdomv1), а где поддерживается — есть отличия в поведении. Только не говорите мне о полифилах!!! Если браузер не может изолировать два дом дерева друг от друга, то никакой полифил этого сделать не сможет.
3. «К-во команд равно к-во микросервисов +1 (product team)» — в этом случае вы приходите к моей архитектуре. Только мне еще и продакт тим не нужна. У нас один микросервис — это, например, админка, црм, каталог, цмс.
2. Product Team, как в вашем плане, собирающий интерфейс из веб компонентов станет бутылочным горлышком. Ему придется понимать как работает каждый компонент в отдельности. Ведь именно от этой команды будут зависеть 70% результата.
3. Использовать единый фреймворк — да! Это круто. Но есть узкие задачи. Есть команды с разной историей и опытом.
4. «Понятие «микросервисы» не применимо на фронтенде, среда то одна ;)» — ошибаетесь. Я так же могу сказать, что понятие микросервисов не применимо на бекенде — система, на которой они крутятся, одна же! Самое важное не то, что эти фрагменты в конце концов оказываются на одной странице, а в том, что мы даем возможность делать куски этого финального интерфейса достаточно независимыми и действительно независимыми командами. А значит подход микросервисный.
Те самые фрагменты GraphQL, на которые вы дали ссылку — это совершенно не те фрагменты, о которых я разговаривал. Это просто дополнительные возможности языка запросов в GraphQL.
Как раз не так :) Команды у нас поделены вертикально. Именно поэтому очень важно поделить и фронт на микросервисы и сделать его куски действительно независимыми. Иначе мы могли бы жить с одним жирным SPA князь кактус.
С SEO решаем вопрос также как его решают все разработчики SPA — серверный рендеринг. Микросервисный фронтенд не сильно его усложняет, т.к. каждый фрагмент по сути — отдельный SPA.
Бекенд кейс валидный, но к топику не относится, т.к. работа идёт с персистант состоянием. Тут уже давно придуманы RabbitMQ и всякие Kafka.
А вот фронтенд кейс не очень хороший. У вас есть два микросервис, которые работают с общим состоянием, но при этом состояние это хранят в разных местах. Это сразу же архитектурный промах. В моем понимании эти два фрагмента должны иметь общий сторадж (в вашем случае локалсторадж) и обмениваться эвентами только для того, чтобы сообщить, что данные надо обновить. Далее все решится само.
Есть другие кейсы, где это действительно нужно? Т.к. реализовать персистант шину на клиенте не сложно. Хоть и не понятно зачем.
Такое безусловно может быть. В этом случае и тут можно использовать canary deployment. На данный момент наша разработка этого не поддерживает, но не вижу ничего сложного в реализации.
Очень не однозначная фича, не находите? Подписаться на события, которые были до подключения. А что если эти события устарели? А что если события взаимоисключающие? А что если события были отменены? А главное — вы можете придумать бизнес кейс для этого?
Тоже люблю философствовать, поэтому позвольте прокомментировать. На мой взгляд, вы перечислили не одну вещь, а две разных :) И забыли третью очень важную — независимость (в том числе независимость обновлений). Вот именно это вполне достижимо и приносит очень хорошие плоды. А в целом, масштабируемость для фронта — это пока что-то непонятное. Но вот fault-tolerance вполне себе проявляется в нашем подходе. Например, если один из микросервисов упадет или не поднимется в облаке, любой другой, кто хочет показать в себе его кусок, просто ничего не покажет на этом месте. И пользователь сможет продолжать выполнять задачи присущие только не упавшему микросервису. Вуаля :)
Вся эта проблема возникает по причине так называемой runtime зависимости. Т.е. зависимость, которую невозможно проверить во время компиляции.
То же самое происходит и с фрагментами и с платформой, которая их менеджит. Приведу пример решения этой проблемы в платформе. У нас есть артефакт, который подключают к себе на страницу все микросервисы — он никак не версионируется (в URL нет ничего, говорящего о версии), но внутри него любой метод версионирован по принципу версионирования API микросервисов (methodA_v1, methodA_v2...). Кроме того, мы поставляем статическую зависимость (для каждого фреймворка свою), которая по сути является оберткой для вызова тех самых методов с версией. Она версионируется и вызывает соответствующую версию метода. Следовательно, не важно с какой версией обертки собран фрагмент, он сможет работать независимо от того, есть ли уже более новая версия зависимости runtime.
Надеюсь, что не очень сумбурно :)
Но как быть с примером из статьи? Есть корзина, владелец которой один микросервис, а отобразить надо в другом (при том с сохранением состояния при переходе)
Собственно вы и ответили на вопрос — у вас есть реестр подобных веб компонент и если микросервис не зарегистрировал там его, то и на странице не покажется.
Пока получается, что вы прошли тем же самым путём. Чем вдохновлялись?
Я бы все-таки не совсем такой вывод сделал — это специфика микросервисного подхода для крупных проектов. Где UI — это не один портал или один рабочий стол, а целый набор разнородных инструментов, которые так или иначе друг с другом связаны по бизнес процессам. Наша компания тут не уникальна. Гугл, например — каждый сервис может выбрать свой фреймворк для написания (некоторые вообще свои рожают). Мейл — то же самое. Рамблер. Яндекс все-таки пытается стек держать консистентным, но в принципе тоже разные фреймворки попадаются.
Справедливости ради — пока мы выбрали в качестве стандарта де-факто Angular 2+ (6 прямо сейчас) и выбор другого фреймворка для конкретного микросервиса должен быть очень мотивирован.
И еще, когда мы переходили с Angular 1 на Angular 2+ — мы почувствовали все бенефиты подхода, когда микросервисный фронт может одновременно работать на нескольких технологиях.
Так вот вся соль в том, что в этой статье я описал именно решение задач, которые встают в момент, когда мы говорим — каждый микросервис отвечает за те куски экрана, которые к нему относятся. А уже как сам микросервис обеспечит изоляцию — это его выбор. Кто-то пытается идти с веб-компонентами — мы не советуем, т.к. спецификация поддерживается очень слабо в самых важных местах. Кто-то заморачивается на специфичность стилей и поставке бандла без внешних зависимостей. Кто-то действительно использует IFrame, если это интеграция с 3rd party. Важен общий подход — если есть кусок UI микросервиса, то только команда этого микросервиса должна за него отвечать.
Именно так. Только вы это называете проектом, а мы — микросервисом. И да, микросервис написан на едином фреймворке и поддерживается единой командой.
А теперь давайте с конца прокомментирую ваши замечания.
Тут вы и правы и не правы. От глобальных зависимостей никуда не деться, хотя свести их к минимуму — вполне возможно. (Кстати, предлагаемый вами, модульный подход увеличивает dependency hell.) Другое дело, что мы об этом очень хорошо подумали заранее и добавили версионирование этой зависимости. Версионируется не только сам артифакт, но и рантайм зависимость — даже если в барузере подгружена новая версия общей зависимости, ваш код со старой будет продолжать работать.
Модули потом все равно в единый бандл компилируются. Или вы имеете в виду, что каждый модуль компилируется в js отдельно и подгружается в браузер независимо? Тогда мы перейдем к обсуждению проблем — асинхронности подгрузки модулей, dependency management, производительность.
Тут вы не уловили мою мысль. Наш проект — это сложная система, состоящая из выделенных частей (микросервисов). Разными фреймворками могут пользоваться разные части. Но понятно, что каждая часть обычно написана на едином фреймворке. В некоторых экзотических случаях могут использоваться специализированные фреймворки для решения конкретных задач в конкретном месте одной части. Но это уже выбор каждой части в отдельности.
Если мы с вами одно и то же подразумеваем под микросервисном подходом (читай начало статьи), то раскройте, пожалуйста, мысль с модульным подходом. Будет интересно.