Smashing Podcast Episode 6 с Лукой Меззалирой: что такое микро-интерфейсы?

Мы завершаем этот год еще одним подкастом Smashing! На этот раз мы поговорим о микрофронтендах. Что такое микрофронтенд? Чем он отличается от того подхода, который мы могли бы использовать в данный момент? Давайте узнаем об этом от пионера микро-интерфейса Луки Меззалиры.

Показать примечания

Еженедельное обновление

• «Добавление динамических и асинхронных функций на сайты JAMstack», Джейсон Ленгсторф
• «Инструменты количественных данных для UX-дизайнеров», Адонис Радука
• «Создание голосовых навыков для Google Assistant и Amazon Alexa», Трис Толлидей.
• «После спринта 0: альтернатива интеграции команд», Шамси Бринн.
• «Помощь браузерам в оптимизации с помощью свойства CSS Contain», Рэйчел Эндрю.

Микро-интерфейсы

• Сайт Луки Меззалиры
• Лука в Твиттере
• «Микро-интерфейсы, будущее интерфейсных архитектур» на Medium
• Больше статей Луки о микрофронтендах можно найти в его аккаунте на Medium.
• Книга Луки «Фронтальные реактивные архитектуры».

Стенограмма

Дрю Маклеллан: эксперт Google по разработке веб-технологий и менеджер лондонского сообщества JavaScript. Обладая более чем 15-летним опытом, в настоящее время он работает вице-президентом по архитектуре, разрабатывая спортивную видеоплатформу DAZN, которая предоставляет спортивный контент по запросу миллионам пользователей, которые смотрят его в прямом эфире. Он является автором книги Front-End Reactive Architectures for Apress, техническим обозревателем Apress, Packt Publishing, Pragmatic Bookshelf и O'Reilly, а также опытным оратором на технических конференциях по всему миру. Он итальянец, носит красивую бороду и явно хорошо разбирается в веб-платформе. Но знаете ли вы, что однажды он пересек Южную Америку на страусе? Мои потрясающие друзья, пожалуйста, поприветствуйте Луку Меззалиру. Привет, Лука. Как твои дела?

Лука Меззалира: Я разбиваю.

Дрю: Сегодня я хочу поговорить с вами на тему микроинтерфейсов. Это совершенно новая для меня концепция, особенно из-за названия, и я ожидаю, что она нова и для многих наших слушателей. Прежде чем мы перейдем к самим микро-интерфейсам, я думаю, мы должны понять проблему, которую вы хотите решить с их помощью. Так что, возможно, вы могли бы немного рассказать нам о том, как вы смотрите на приложения в более традиционном смысле, и какие проблемы возникают с этими вещами, решением которых, возможно, могут быть микрофронтенды?

Лука: Хорошо, на мой взгляд, это хорошая отправная точка. Поэтому обычно, когда вы реализуете или разрабатываете новый проект с нуля и хотите работать с внешними приложениями, у вас есть несколько архитектур, которые вы можете использовать. Вы можете использовать одностраничное приложение, приложение для рендеринга на стороне сервера или многостраничное приложение, состоящее из простых HTML-страниц. Очевидно, что это очень правильные варианты, и я думаю, что они очень часто используются многими разработчиками. Настоящая проблема, которую мы здесь пытаемся решить, заключается в том, как вы можете масштабировать эти концепции с помощью распределенных команд для сотен разработчиков, работающих над одной кодовой базой, потому что реальность такова, когда вы работаете именно на этих платформах, когда вы думаете о Например, для платформы SaaS вам необходимо иметь несколько разработчиков и несколько команд, работающих над одним и тем же проектом. И, очевидно, то, как вы, например, осуществляете приобретение или удержание, совершенно отличается от того, как вы представляете каталог или как вы показываете конкретную часть платформы.

Лука: Итак, по моему опыту, я много работаю с одностраничными приложениями. Я работаю с приложением для рендеринга на стороне сервера, но в какой-то момент в DAZN меня попросили подумать о способе масштабирования нашей технической команды. И мне нужно придумать … если для бэкэнда у нас есть какое-то решение, которое в данном случае является микросервисами, поэтому мы можем независимо масштабировать наши API и учитывать масштаб и объем для конкретной пропускной способности на конкретном API. С внешним интерфейсом действительно сложнее, потому что, если подумать, у вас нет технических проблем, которые нужно решать, когда вам нужно масштабировать, например, если вы используете одностраничное приложение. Вероятно, для рендеринга на стороне сервера у вас есть некоторые, но, например, в одностраничном приложении они распределены по своей природе, потому что они находятся на стороне клиента, а не на стороне клиента.

Лука: Таким образом, единственное, что они загружают, — это просто некоторые статические файлы, такие как CSS, HTML и JavaScript, которые обслуживаются CDN, и в этом случае вы можете соответствующим образом масштабироваться, это не большая проблема. Но настоящая проблема заключается в том, как вы масштабируете команды, работающие на одной платформе, потому что иногда проблемы, с которыми сталкивается одна команда, могут полностью отличаться от проблем, с которыми сталкивается другая команда, и обычно вы пытаетесь найти много компромиссов между вещами. Потому что, если подумать, давайте попробуем подумать о нормальном варианте использования. Поэтому обычно, когда вы запускаете платформу, вы начинаете с малого. Итак, вы пытаетесь создать это быстрое одностраничное приложение, а также у вас есть свой монолит, поэтому вы просто настраиваете все в своем CICD только один раз для внешнего интерфейса и внутреннего интерфейса, а затем начинаете повторять свою логику. Но реальность такова, что когда вы добились успеха, вам нужно развивать эту часть, и не всегда поддержание одной и той же архитектуры может, скажем, принести пользу вашему бизнесу, потому что, возможно, вы сможете найти некоторые узкие места.

Лука: Теперь вернемся к части одностраничного приложения. Поэтому, если мы хотим масштабировать одностраничную часть приложения, проблема не техническая, а с людьми, если хотите. Итак, как мы можем масштабировать команды, работающие над одним и тем же приложением. Итак, что я сделал несколько лет назад, так это начал рассматривать возможную архитектуру и принципы, которые позволили бы мне масштабировать как интерфейс, так и сервер. Итак, работайте над принципами бэкэнда, чтобы вы могли найти микросервисы. Я начал искать другое решение, и они вышли с микроинтерфейсами, которые в начале мы даже не называли так, потому что, очевидно, много лет назад не было, скажем, такого имени для этой конкретной архитектуры. .

Лука: Но реальность состоит в том, чтобы взять монолит, то есть одностраничное приложение, и нарезать его таким образом, чтобы мы могли сосредоточиться на крошечной проблеме. Так что это меньшая проблема, чем все приложение, и мы пытаемся решить ее наилучшим образом. С технической точки зрения. Очевидно, что это приведет к тому, что у вашего внешнего приложения будут независимые части, которые можно будет развернуть в рабочей среде, не затрагивая все остальные. Таким образом, основная проблема для Micro-frontend заключается в том, чтобы попытаться найти способ взять одностраничное приложение или приложение, отображаемое на стороне сервера, и создать из них артефакт, скажем, максимально приближенный к бизнес-домену, и может быть развернут независимо. .

Дрю: Я имею в виду, что вы упомянули микросервисы на серверной части. Таким образом, концептуально это похожее решение проблемы. Микросервисы работают на серверной части, но переносятся на внешний интерфейс. Это грубая эквивалентность или это больше связано с этим?

Лука: Да. Нет, это способ решить ту же проблему, с которой мы пытаемся решить микросервисы на серверной части, но на этот раз на переднем конце. Обычно, когда я начинал это путешествие в начале, вы знаете, вы начинаете думать об этом и начинаете оценивать разные подходы. И за последние несколько месяцев я придумал то, что они называют схемой принятия решений по микро-интерфейсу, которая в основном состоит из четырех шагов, которые они используют, скажем, для того, чтобы определить подход для микро-интерфейса, потому что если до сих пор мы обычно выбирают один фреймворк, который спроектировал для нас архитектуру, и мы реализуем его поверх этой архитектуры. Если вы думаете об angular или думаете о React или Redux. У вас есть все необходимые части, но вы не принимаете архитектурные решения. Вы должны были бы принять дизайнерские решения или то, как вы реализуете эту конкретную архитектуру.

Лука: Итак, в микро-интерфейсе вам нужно сделать шаг назад. Поэтому нам нужно подумать о том, как мы хотим сначала нарезать наше приложение. Так что обычно есть два варианта для этого. Вы можете разрезать по горизонтали, чтобы иметь несколько микроинтерфейсов в одном представлении, или вы можете разрезать по вертикали. Поэтому вы всегда загружаете один микро-интерфейс за раз. И это решение является довольно важным, потому что затем оно будет каскадно включать некоторые другие варианты, которые у вас есть на основе первоначального решения. Итак, во-первых, как я уже сказал, вы решаете, как вы хотите нарезать свое приложение. Второй — как вы хотите составить свое приложение. Итак, вы хотите иметь, например, оболочку приложения, которая загружает один или несколько микроинтерфейсов в одном и том же представлении. Вы хотите иметь, я не знаю, сервер приложений, который составляет различные фрагменты ваших приложений, такой другой микро-интерфейс, а затем предоставляет окончательный вид вашему пользователю. Или вы хотите использовать включенную сторону края, это стандарт, который находится внутри CDN, чтобы составить страницу и обслуживать ее там.

Лука: Это три варианта, которые у вас есть. И потом, помимо сочинения, вам нужно подумать, как вы хотите маршрутизировать. Итак, как вы направляетесь, я не знаю, /login или /signin к части каталога или конкретному объекту детали. Также здесь у вас есть три варианта. Вы можете сделать это на сервере приложений, вы можете сделать это на уровне CDN с помощью Lambda Edge или любых других веб-воркеров в CloudFlare или чем-то еще. Или можно сделать клиентский сайт. Итак, у вас есть логика внутри оболочки вашего приложения, которая говорит: «Хорошо, теперь для этого конкретного URL-адреса вам нужно загрузить другое представление или другой микро-интерфейс». И последнее, как вы общаетесь с Micro-frontend.

Лука: Обычно, если у вас есть несколько микро-интерфейсов на одной странице, управление этим взаимодействием становится более сложным, потому что вам нужно поддерживать независимость разных микро-интерфейсов. Это означает, что у вас не может быть никаких ссылок на структуру страницы. Поэтому обычно вы можете использовать такие вещи, как настраиваемые события или счетчик событий, который внедряется внутри каждого отдельного микроинтерфейса. И тогда Микро-фронтенд общается вместе. Очевидно, что в другом случае, когда у вас есть, скажем, вертикальное разделение вашего микро-интерфейса, это намного проще, потому что внутри вертикали в основном представлением вертикального микро-интерфейса является одностраничное приложение или одна страница. И в этом случае проще, скажем, создавать и делиться общим состоянием по всему микрофронтенду.

Лука: Тогда, если вы думаете о том, чтобы иметь несколько микро-интерфейсов вместе, вам следует избегать состояний, которые являются общими для всех микро-интерфейсов, потому что в противном случае вы связываете вещи. Вместо целостной концепции здесь есть развязка и независимое развертывание. И поэтому, скажем, проблемы горизонтального разделения, которое является первым решением, которое вы должны принять, или вертикального разделения, совершенно разные, и нам нужно очень хорошо знать, какое из них подходит для нашего варианта использования.

Дрю: Значит, микрофронтенды — это не конкретное техническое решение, а скорее шаблон проектирования, который вы бы реализовали в любой технологии, подходящей для конкретной проблемы, которую вы пытаетесь решить?

Лука: Да, больше, чем технология, я хотел бы видеть, что мы выбираем правильную архитектуру для правильной работы. Просто чтобы дать вам пример, я говорил … есть известный фреймворк, довольно новый для Micro-frontend, он называется фреймворк Luigi, который был выпущен SAP с открытым исходным кодом. Что они делают, так это создают несколько фреймов, в которые они помещают свой микро-интерфейс. Итак, теперь, если вы думаете об этом, скажем, используя iframe в настоящее время, вы находитесь на общедоступном веб-сайте, который может быть проблематичным из-за SEO или других обязательных функций.

Лука: Но в случае SAP, если подумать, у них есть корпоративное приложение, где они могут управлять браузером, который использует пользователь, они могут контролировать среду, им не нужно быть доступными на множестве или другая версия браузера. Таким образом, для них эти вещи позволяют им иметь определенные области приложения, которые являются постоянными, и у них есть определенные области, которые изменяются независимо без каких-либо проблем. Но очевидно, что решение iframe не сработает в другой ситуации. Просто чтобы привести еще один пример, Spotify, мы используем iframes в начале. На самом деле настольная публикация по-прежнему состоит из нескольких фреймов, и каждый отдельный фрейм — это крошечное приложение, которое делает, я не знаю, просто музыкальный проигрыватель или просто их рекомендацию, что бы это ни было. Они пытаются использовать тот же подход в Интернете, но в этом году отказались от него, чтобы вернуться к одностраничному приложению.

Лука: И это означает, что они объясняют, почему в техническом блоге они говорили, что очевидно, если вы примените это к миллионам пользователей, использующих iframe, которые должны каждый раз загружать один и тот же файл поставщиков. И тогда у вас будет дублироваться множество зависимостей, и время взаимодействия с вашей страницей будет больше. Так что на самом деле этот подход может подойти для определенных случаев использования, но он не должен подходить для всех. Вот почему я говорю, как я описал ранее, если у вас есть структура принятия решений, которая поможет вам решить эти проблемы, и вы можете начать говорить: «Хорошо, я нарезал приложение таким образом, поэтому у меня есть доступные варианты». когда я хочу сочинять, когда я хочу маршрутизировать, когда я хочу общаться, он должен направлять вас, чтобы принять правильное решение в нужное время.

Лука: Тогда очевидно, что помимо этих четырех решений есть много других. Например, как вы создаете согласованность в системе дизайна, которая у вас есть во всем микро-интерфейсе. Или я не знаю, как вы управляете зависимостями и избегаете столкновения зависимостей внутри микроинтерфейса, но реальность такова, что те четыре решения, о которых я упоминал ранее, позволят вам затем быстро принять все остальные, не имея проблема чрезмерного обдумывания, что является лучшим решением, потому что вы уже установили краеугольный камень, четыре столпа, которые позволят вам принять все остальные решения… я не говорю простым способом, но более быстрым способом, чем обзор или спектр возможностей.

Дрю: Вы упомянули ранее, как Micro-frontend может помочь со структурой команд внутри вашей организации и с большим количеством людей, работающих над одним и тем же приложением. Каковы некоторые из последствий, и есть ли какая-то разница, если ваши команды распределены или расположены вместе, или есть ли какие-то проблемы, с которыми вы сталкиваетесь при этом?

Лука: Да. Итак, я могу рассказать вам историю DAZN. Это компания, в которой я работаю. В настоящее время в DAZN у нас был хороший вызов. Итак, в настоящее время у нас более 300 человек, которые работают над передней и задней частью нашей платформы. Это OTT-платформа, которая транслирует спортивные мероприятия по всему миру в прямом эфире. И самое интересное, что всеми микросервисами мы более или менее умеем управлять, и у нас есть распределенные команды. Итак, у нас есть четыре центра разработки. Мы хотели бы разместить команды в каждом отдельном центре разработки на переднем крае, и мы попробовали этот подход, и он работает очень хорошо. Таким образом, с помощью Micro-frontend мы смогли предоставить разные бизнес-домены в разных местах и ​​обеспечить перекрестную связь между командами внутри определенного бизнес-домена, потому что в худшем случае, если вам нужно поговорить с другой командой в том же бизнес-домене. , вы просто дойдете до своего стола пешком. Если вместо этого вам нужно обсудить конкретную вещь в команде дистрибьюторов, например, с кем-то в Лондоне, а не в Амстердаме, или вместо компании в Польше, вы просто организуете звонок.

Лука: Но такие виды общения более редки, чем те, которые происходят между командами в одном месте. И именно поэтому мы начали работать над этим. Итак, первое, что они сделали, это посмотрели, как наши пользователи взаимодействуют с нашим сайтом, как устроена компания. И когда мы определяем четыре ключевые области, над которыми мы работаем, в настоящее время это приобретение и удержание, скажем, портирование их основного приложения на несколько телевизоров и мобильных устройств и наличие основной области, которой для нас является видеоплеер и фаза обнаружения наш контент. И, наконец, все элементы бэк-офиса. Я смог определить эти четыре области, и мы выделили эти четыре области для каждого отдельного центра разработки.

Лука: Очевидно, что между этими областями есть какие-то точки соприкосновения, но есть и способы, которые вы можете, скажем, смягчить, и провести первоначальный семинар с разными командами, которые находятся в разных местах, а затем, например, работать над одним и тем же контрактом API, или та же цель с наличием некоторых контрольных точек во время разработки. Но хорошая вещь в подходе, которая позволила подойти с помощью Micro-frontend, заключается в том, что мы, наконец, глубоко понимаем, как работала наша система. Мы садимся и анализируем, как мы были структурированы, и мы изменили не только то, как мы влияли на вещи, но и то, как работала компания. И это был своего рода отличный подход от того, что они видели до сих пор. Но это доказывает, что это работает довольно хорошо в том случае, если каждая отдельная команда может взаимодействовать с командой, находящейся в том же месте в том же домене.

Лука: Значит, они говорят на одном языке, если вы говорите о дизайне, ориентированном на предметную область. И это то, что если им нужно взаимодействовать с другими командами, они могут буквально разделить мастерскую или лететь в другой центр разработки, и это меньше, чем проблема. Но таким образом мы, скажем, увеличиваем пропускную способность и уменьшаем накладные расходы на связь, а также степень зависимости, которая происходила в другой ситуации, над которой они работали.

Дрю: И нужно ли всем этим командам использовать стандартизированную среду JavaScript? Должны ли они все кодироваться в одних и тех же вещах, все они должны быть либо React, либо Angular, или обеспечивать совместимость между ними, или люди могут использовать разные вещи для разных микро-интерфейсов?

Лука: Ага. Поэтому в DAZN мы решили разделить наш микро-интерфейс по вертикали, и это решение позволило нам свободно выбирать технологию, которая нам нужна для каждого отдельного микро-интерфейса. Учитывая, что каждый раз мы загружаем один микро-интерфейс за раз, и это означает, что, например, то, как у нас есть целевая страница, отличается от пути входа / регистрации. Итак, мы можем обновить… сейчас мы в основном используем React. Но если, например, я помню, когда React 16 был релизом, который мы могли выпустить в рабочей версии React 16, а также если он не был в стабильной версии только для целевой страницы, и посмотреть, работает ли он, не затрагивая все другие команды.

Лука: А потом со своей скоростью, в своем собственном темпе они обновляли свои собственные вещи. Так что это также позволяет нам, скажем, опробовать новые технологии или новые предположения, которые у нас есть в существующем приложении, с определенным количеством пользователей. Потому что мы реализуем также версии-кандидаты для внешнего интерфейса. Мы реализуем, скажем, несколько практик, которые позволяют нам просто попробовать определенное время в продакшене и посмотреть, как все работает.

Лука: Прелесть этих подходов в том, что мы можем независимо выбрать правильный инструмент для нужной работы, а не иметь общий знаменатель для всего стека. Потому что, как вы можете себе представить, когда вы начали работать над проектом, решение, которое вы приняли в первые несколько лет, вероятно, отличается от решения, которое вы приняли на траектории, когда компания растет, бизнес развивается, и они становятся более зрелыми. а задача совсем другая. Так что это не было бы достаточно гибким или гибким, если вы думаете об этом, тот факт, что мы придерживаемся того же решения, которое приняли два года назад. В частности, такая организация, как DAZN, в которой мы увеличиваем количество сотрудников практически с нуля до 3000 человек за три года. Так что, как вы можете себе представить, это был огромный рост, и это был огромный рост как для компании, так и для пользовательской базы.

Дрю: Существует ли установленный способ для разных микроинтерфейсов обмениваться данными и общаться друг с другом, например, просто чтобы идти в ногу с одним и тем же представлением, или есть способ сделать это?

Лука: Да, есть. Это зависит от того, какую из рамок принятия решений вы выберете. Потому что, если вы собираетесь взять вертикальный срез, это стало очень просто. Итак, для общения через Micro-frontend у нас есть оболочка приложения, которая загружается в Micro-frontend внутри себя. И что он делает, так это хранит все, что должно быть, скажем, общим для разных микроинтерфейсов или в веб-хранилище, либо в сеансе, либо в локальном хранилище, либо в памяти. И затем на основе этой информации загружается микро-интерфейс, который может получить из оболочки приложения эту информацию, а затем использовать ее, исправить или изменить ее. Это полностью зависит от того, как вы разделяете приложение, но в этом случае, просто для примера, если вы думаете, что когда вы являетесь аутентифицированным пользователем и вам нужно перейти на страницу входа, когда вы входите и API-интерфейсы используются и они предоставляют токен JWT, Micro-frontend передает их в оболочку приложения, и оболочка приложения, начиная с которой мы сохранили их веб-хранилище.

Лука: Затем, после этого оболочка приложения загружает новую аутентифицированную область для этого конкретного приложения и этих аутентифицированных областей, они извлекают токен JWT из оболочки приложения и выполняют либо обновление токена доступа, либо проверяют некоторые данные, начиная с Токен JWT. Таким образом, он использует в основном информацию, которая была произведена другим микро-интерфейсом на их собственном колесе.

Дрю: Звучит как очень интересная концепция, и я потенциально вижу много больших преимуществ в такой работе, но, конечно же, не обошлось без проблем. Есть ли какие-то особые вещи, с которыми труднее иметь дело при такой архитектуре?

Лука: Я думаю, что в первую очередь главная проблема, которую я вижу, — это изменение мышления. Потому что раньше мы привыкли иметь, скажем, техлидов или ведущих разработчиков, которые решали все вокруг всего приложения и принимали все решения. Теперь, наконец, мы переходим от этого централизованного объекта к децентрализованному объекту, который является локальным для каждого штата. Как вы можете себе представить, это приносит некоторые проблемы, потому что если раньше у нас был кто-то, кто отслеживал путь, то теперь у нас есть, скажем, несколько человек наверху, определяющих правильный путь внутри своей области, и это огромный сдвиг. мышления.

Лука: С другой стороны, я думаю, что иногда сложность заключается в том, чтобы признать, что неправильная абстракция может быть, скажем, дороже, чем дублирование кода. И это то, что я знаю, что есть кое-что, что я нашел очень сложным в управлении разработчиками, потому что они думают: «Хорошо, теперь я могу повторно использовать этот объект или эту конкретную библиотеку сотни раз в проекте», но реальность совсем другая. Я видел библиотеку компонентов, которые были абстрактными, и они тратили много времени на то, чтобы сделать это как лучший код или лучший в идеальной форме. Но реальность использовалась всего дважды. Так что усилие сделать это было не совсем таким. Я видел на другой стороне библиотеки, что они начали с пары вариантов использования для определенного компонента. А потом таких вариантов использования стало 10, а затем код перестал поддерживаться.

Лука: Таким образом, попытка добавить новую функцию в тот же компонент может быть скорее рискованной, чем полезной. Поэтому я думаю, что еще одна вещь, которую нам нужно понять с Micro-frontend, — это то, насколько мы хотим поделиться им и насколько мы хотим дублировать. И нет никакого вреда, честное слово, в дублировании. В нашем случае, например, у нас есть дублирование нижнего колонтитула и верхнего колонтитула, и мы сделали это в основном потому, что за четыре года трижды изменили верхний колонтитул. Итак, как вы можете себе представить, тот факт, что мы централизуем их, назначаем команде и создаем внешнюю зависимость для всех команд, всех сотен разработчиков, которые у нас есть, — это, скажем так, проблема, которая приносит пользу компании, потому что мы не добавляем огромную ценность.

Лука: В то же время в настоящее время мы рефакторим наши общие библиотеки, которые будут библиотекой платежей, потому что, очевидно, в платежах есть некоторая логика, и если мы хотим изменить один раз, мы не хотим применять это дважды в нескольких частях. код. Мы хотим иметь только одну библиотеку, которая является источником правды, но для верхнего и нижнего колонтитула, а также если есть несоответствие или для пикселя или есть функция, которая развернута, например, через неделю, это не повредит заявление.

Дрю: Итак, есть ли какие-то контрольные признаки, на которые люди должны обращать внимание, оценивая приложение и думая: «О да, это был бы хороший кандидат для перехода на архитектуру типа Micro-frontend?»

Лука: Да, так что мое предложение будет в первую очередь: я бы не стал начинать новый проект с Micro-frontend, если мы точно не знаем, как он должен быть построен. И обычно очень маловероятно, что у вас есть эта информация, потому что, особенно если у вас есть новая платформа или новый проект, и вы работаете над этим впервые, найти эту информацию может быть нетривиально. Обычно я предлагаю начать с существующей архитектуры, которая будет представлять собой одностраничное приложение, а затем развивать ее. В частности, например, я обнаружил, я думаю, что использование микроинтерфейса для устаревших приложений или когда мы хотим заменить определенную часть приложения, или когда у нас есть проект, который мы хотим развивать и масштабировать для нескольких команд, это три варианта использования. то, что я чувствую очень сильным, может подойти архитектуре Micro-frontend. Очевидно, это не означает, что отныне все должно быть сделано на микро-фронтенде, потому что микро-фронтенд вовсе не панацея.

Лука: Они представляют собой дополнительную архитектуру, которую мы можем использовать во внешнем мире. И до сих пор у нас было определенное количество архитектур, теперь у нас есть дополнительная. Но это много проблем, потому что, очевидно, вам нужно, если перед рендерингом на стороне сервера или одностраничным приложением есть четкие шаблоны, которые были изучены, а затем реализованы несколькими фреймворками и так далее. В настоящее время Micro-frontend — это один из способов сделать что-то. Но добавление структуры принятия решений, вероятно, должно позволить людям принимать правильные решения для своих вариантов использования. Потому что зачастую существует множество неправильных представлений о том, что такое микро-фронтенд и как его нужно использовать. И многие люди думают, что, может быть, скажем, это зло, я не знаю, иметь слишком много библиотек в одном представлении или другие вещи.

Лука: Реальность такова, что вам нужно глубоко понять концепцию, понять, как ее реализовать, а затем вы можете начать работать над этим. Я полностью согласен с тем, что есть технические проблемы и есть много решений, которые вы должны принять, и вы не можете просто начать прямо сейчас, когда перед вами редактор, пишущий код и думающий, хорошо, теперь я создаю микро-интерфейс. архитектура. Потому что вам нужно понимать концепцию, понимать контекст и создавать, а также управлять этим, потому что сложность заключается не только в написании кода, но и в понимании того, как все части сочетаются друг с другом в части CICD, части SEO и так далее.

Лука: Таким образом, микроинтерфейс обеспечивает, скажем так, определенный уровень гибкости и требует больших усилий для определения права управления. Потому что, когда у вас есть право управления, все будет гладко. Часто и, к сожалению, я бы сказал слишком часто, я видел компании, которые не тратят достаточно времени на управление, например, на понимание CICD, потому что они не считают это важным. Но вместо этого для Micro-frontend, как и для микросервисов, наличие права на автоматизацию позволит вам ускорить разработку. Если вы не потратите достаточно времени на автоматизацию, вы рискуете получить больше бремени, чем пользы.

Дрю: Думаю, в мире веб-разработки часто бывает так, что люди рискуют погрузиться в разработку технического решения, прежде чем они действительно поймут проблему. И похоже, что в случае с Micro-frontend вам нужно увидеть проблему, а затем внедрить решение, чтобы знать, какую проблему вы решаете. Я предполагаю, что сама природа микро-интерфейса позволяет очень легко начать интеграцию в существующее приложение, обнаружить небольшую проблему и заменить его микро-интерфейсом, чтобы решить эту проблему. Это разумное предложение?

Лука: Да, я бы сказал так. В этом случае единственное, что я бы посоветовал, если мы начнем таким образом, — это больше смотреть на вертикальные срезы, а не на горизонтальные, потому что в противном случае вам нужно решить так много проблем, давайте предположим, что вы используете Angular и вы хотите перейти на новую версию Angular. Если вам нужно, чтобы две версии Angular жили вместе без использования I-frame, это может быть сложно или даже невозможно. Так что если вы начинаете, то вы аспект не с... если вы проверяете вызов, не с технической точки зрения, а с точки зрения бизнеса. Может быть, например, вы можете взять, я не знаю, часть входа в систему, которую вы хотите написать, с другой версией или той же версией, но с более обновленной версией фреймворка, и это может быть хорошим способом. И тогда вы идете по пути. Это может быть хорошим способом медленно, но стабильно заменить конкретное приложение.

Лука: В нашем случае мы в основном применили шаблон душителя, хорошо известный для микросервисов, но на внешнем интерфейсе. Итак, на основе URL-адреса, а также на основе браузера и страны пользователя. Так медленно, но неуклонно, в основном мы убивали монолит, который в данном случае был одностраничным приложением, выпуская наше новое приложение чаще и наблюдая за поведением пользователей, если это улучшало опыт, это вызывало какие-либо проблемы в нашей системе. или не. И это позволило нам обеспечить немедленную ценность для бизнеса, но в то же время позволило нам проверить наши предположения и посмотреть, движемся ли мы в правильном направлении или нет.

Дрю: Звучит как очень привлекательное решение некоторых проблем, с которыми, я уверен, сталкиваются многие люди. Если бы я, как разработчик, захотел больше узнать о Micro-frontend, с чего бы лучше всего начать?

Лука: Да, так что в настоящее время я трачу много своего свободного времени, пытаясь отстаивать эту архитектуру, потому что я думаю, что существует много неправильных представлений. На моем аккаунте Медиум. Я написал несколько статей, которые также доступны там. Записал много видео с конференций, которые без проблем можно найти на YouTube. И еще одна вещь, которую я хотел бы предложить, если вы ищете какой-то пример кода на некоторых фреймворках, тот, с которого я бы порекомендовал начать, — это один SPA, в основном потому, что он имеет подход с вертикальным срезом, его легче подобрать и вы можете начать понимать преимущества этой архитектуры. Тогда есть много других, которые доступны. Before I mentioned Luigi framework, as well as many others that are currently out there that are allowing you to compose multiple Micro-frontends in the same view.

Luca: Like another one in my head is TailorJS is another interesting. But definitely there is open components that is one developed by Open Table. But in general there are plenty of opportunity if you start to search about Micro-frontend, they're out there.

Drew: That sounds great. Is there anything else that you wanted to talk about with regard to the Micro-frontends?

Luca: Yeah. Personally I would suggest to take an open mind approach on learning this architecture and this approach, technical approach, mainly because I believe that there is a lot of good, but we need to, let's say, invest a bit of time and spend a bit of time to deeply understand how the things are working. Because obviously there isn't, just one way to do things. We are used that we take a framework and immediately we start to work on it and it's super productive, if you think about that.

Luca: But in this case you need to spend a bit of more time understanding, as you said a couple of times, the problem. Understand which is the pattern that would allow you to express better not only from a technical point of view but those two from our organizational point of view, the solution that you have in mind.

Drew: So I've been learning all about Micro-frontend today. What have you been learning about lately?

Luca: Recently there are two things that I'm learning. So last week I was in Las Vegas during the AWS event and is obviously a cloud conference. Pretty amazing, 70,000 people, a lot of sessions that were spreading several hotels in Vegas. And there for me, a serverless is a paradigm that I'm studying the most because I truly believe that in the future that will be the way how we are going to design and implement software and obviously AWS is very prominent on this approach.

Luca: And the second topic is around management and how to be a leader of a tech team. Because obviously I'm SVP of architecture. I have a team of architects that I'm leading and you can never rest because you need to not only to be on top of the technical side, but you need also to understand the people problems, understand how you can make them successful. Because obviously if they are successful, you are successful. You are first a technical facilitator to a certain extent. So that for me, those for me are the two things that currently I'm studying on top of exploring the Micro-frontend world.

Drew: If you, dear listener, would like to hear more from Luca, you can follow him on Twitter where he's @LucaMezzalira or find his activities collected together at Lucamezzalira.com. Thanks for joining us today, Luca. Did you have any parting words?

Luca: No, but thank you very much for listening up to now.