Вы идете в ногу со временем и в вашем веб-приложении используются самые передовые технологии? Тогда вы определенно используете микро-интерфейсы! Довольно провокационный вариант, не так ли? 
Все эти трудности и трудности, но ради чего? Ваш интерфейс в любом случае устареет через пару месяцев, и вам лучше инвестировать в компоненты многократного использования.
Ничто не сравнится с монолитом! Тоже довольно узкая точка зрения, не так ли? Скорее всего вы согласились с первым или вторым абзацем.
Однако, как всегда бывает в разработке программного обеспечения, ответ лежит где-то посередине:
Все зависит от ситуации!Все, кто меня знает, знают, что я большой любитель монолитов .
Да, в последнее время я разрабатываю много микро-интерфейсов и даже создал элегантный каркас Piral , который помогает в создании крупных проектов на микрофронтенде.
Но в то же время мы не используем его без уверенности, что он подойдет для решения наших задач.
Чтобы получить реальное представление о том, как построить фронтенд-приложение с использованием независимых компонентов, прочтите Эта статья Джонатан Саринг (англ.
Она рассказывает историю Bit.dev как они прошли множество испытаний и добились успеха в создании собственного клиентского приложения с использованием микроинтерфейсов, которые интегрируются во время сборки (они делают это, используя свой собственный продукт - Кусочек ).
Причины использовать Монолит
Многие утверждают, что выбор между монолитным и микро-интерфейсом следует делать исходя из размера приложения.Я считаю, что это не совсем так.
Конечно, если приложение действительно маленькое, то монолитная архитектура потенциально сокращает время переписывания приложения до такой степени, что все выглядит дорогим и раздутым.
Однако для меня настоящим показателем являются перспективы бизнеса.
Если приложение должно быть достаточно статичным, не обновляться очень часто и оснащено функциями, которые должны быть доступны каждому, то монолит — отличный выбор.
Монолит легко разработать, легко развернуть и легко протестировать, по крайней мере, когда монолит небольшой.
Это, конечно, не заслуга монолита: любую систему легко понять, когда она небольшая и посвящена решению одной задачи.
Короткий:
- последовательность
- надежность
- производительность
Причины использовать микрофронтенды
Предполагается, что микроинтерфейсы предназначены для гигантских приложений, с которыми могут справиться только крупные предприятия.Хотя такие условия и поощряют использование микрофронтендов, в них нет необходимости.
Даже небольшое приложение может извлечь выгоду из микроинтерфейсов.
Например, у нас может быть целевая страница, содержащая некоторую информацию, которую необходимо обновлять каждый день.
Конечно, мы можем подключить его к бэкенду, но тогда нам придется поддерживать больше вещей, просто чтобы опубликовать один (возможно, очень конкретный) фрагмент. Вместо этого, возможно, лучшим решением было бы опубликовать его как часть внешнего интерфейса и использовать напрямую.
Большие приложения боятся «наследия».
Наличие устаревшего кода или отказ от использования новейших и лучших инструментов приведет к провалу проекта.
Это связано либо с отсутствием критических обновлений, либо с неспособностью привлечь новых разработчиков.
Микроинтерфейсы обеспечивают хороший выход из этой ситуации, позволяя фрагментам отличаться друг от друга в зависимости от лежащих в их основе технических решений.
Если поставить правильный вызов, микрофронтенды могут превзойти своих монолитных предков.
Микрофронтенды — это гибкое решение во многих отношениях.
В результате этого он сопровождается различными проблемами по сравнению с обычным фронтендом.
Однако как только эти проблемы (например, производительность или согласованность) будут решены, решение не обязательно окажется более сложным, чем его монолитный аналог.
На самом деле, отдельные части (то есть настоящие микро-интерфейсы) гораздо проще понять и поддерживать.
Фактически, это значительно сокращает время адаптации нового разработчика, делая решение более удобным для программистов.
Кратко:
- масштабируемость
- гибкость
- независимость
Соглашения и сотрудничество
Какая структура команды лучше всего подойдет для каждой модели? Очевидно, что микроинтерфейсы позволять иметь более распределенные команды, где монолит требует тщательной координации между командами, что обычно приводит к созданию одной центральной команды, построенной на строгой иерархии.Конечно, из этих крайностей есть исключения, но в большинстве случаев истина близка к этому наивному предположению.
В зависимости от структуры приложения микроинтерфейсы могут иметь одну центральную группу, отвечающую за сквозные проблемы и управление.
Остальные команды можно считать вспомогательными.
В каждом из них от 1 до 5 разработчиков в зависимости от объема функций.
Координация между командами практически не требуется, хотя некоторая согласованность с владельцами бизнеса или центральной командой желательна.
Каждая группа поддержки может работать по собственному графику и выпускать релизы, когда они будут готовы.
Разные команды работают над разными частями приложения.
В отличие от микрофронтенда, монолит состоит либо из одной команды, либо из большой центральной команды и нескольких мелких, занимающихся отдельными функциями приложения.
Однако в любом случае между командами будет слаженность.
Существует сценарий, в котором дополнительные команды также достаточно велики и работают независимо.
Именно здесь в игру вступают такие понятия, как «связь» и «схватка из схваток».
Как только мы слышим эти термины, мы понимаем, что это много согласований, много встреч и большая потеря эффективности.
Одна большая команда, создающая одно приложение На первый взгляд потеря эффективности звучит как недостаток, но имейте в виду, что каждое разрабатываемое приложение со временем теряет эффективность разработки.
Это вполне естественно и часто даже в какой-то степени желательно.
Ведь это означает, что продуктом пользуются реальные клиенты, и изменения нужно хорошо продумать и согласовать.
Как обычно, вопрос не в том, «есть ли потеря эффективности», а в том, «насколько неэффективен процесс».
Развертывание
Одним из наиболее важных вопросов для любого проекта является метод развертывания.Я видел проекты на микро-фронтендах, которые были развернуты полностью в одно время.
Каждый микрофронтенд был выпущен в одном большом конвейере CI/CD. Я категорически против этой модели.
Если мы будем публиковать все одновременно, то преимущества микрофронтендов теряются.
Для этого лучше подойдет эффективный монолит с многоразовыми пакетами и монорепозиторием, а не проект на микрофронтендах.
Что мы теряем, делая объединенный релиз?
- Независимость (команды должны работать вместе, готовиться к этому и т. д.)
- Кэширование (все ресурсы становятся недействительными одновременно, а не каждый ресурс становится недействительным только при его изменении)
- Скорость (нужно согласовать дату публикации, а это означает дополнительную потерю эффективности)
- Последовательность (мы знаем, что все детали обновлены до последних версий)
- Надежность (мы можем провести только одну дымовую проверку, чтобы убедиться, что все в порядке)
- Знакомство (вместо постоянных изменений приложение будет обновляться только через определенные промежутки времени)
Хотя микрофронтенды можно использовать в обоих этих подходах, в большинстве случаев монолиту остаются только крупные совместные релизы.Микрофронтенды также можно развертывать в группах.
Например, у нас может быть несколько «основных» микроинтерфейсов, разработанных одной или несколькими командами.
Эти основные микроинтерфейсы можно развертывать вместе.
Этот смешанный подход может стать хорошим компромиссом, позволяющим избежать потери скорости, независимости и возможности кэширования, сохраняя при этом согласованность, надежность и привычность.
Это система, которая уже достаточно хорошо известна по мобильным операционным системам (или большинству операционных систем в целом):
- сторонние приложения находятся в собственном цикле выпуска
- некоторые основные приложения могут обновляться независимо
- С новым релизом ОС поставляются и новые версии основных приложений.
Возможность настройки стратегии развертывания — одно из преимуществ микрофронтендов.
Заключение
Выбор между монолитным и микроинтерфейсом не должен быть трудным.Обычно, не особо раздумывая, можно начать с монолита.
Решение о переходе на микрофронтенды все равно можно принять, когда это необходимо.
Однако оба типа проектов имеют свои преимущества и недостатки.
Мы всегда должны стараться найти золотую середину, которая наилучшим образом решит нашу проблему.
Если это монолит, отлично! Если мы дойдем до микрофронтендов, это тоже здорово! Не волнуйтесь о людях, рассказывающих вам, что современно и что лучше всего.
Лучше подумайте о своей проблеме и постарайтесь найти лучшее решение.
Это также нечто большее, чем просто техническая и деловая перспектива — не пренебрегайте своей командой (учитывайте опыт каждого, насколько они открыты для различных решений и т. д.).
Теги: #разработка сайтов #фронтенд #фронтенд-разработка #микрофронтенды #monolith #front-end #monolith #микрофронтенды
-
Из Чего Сделаны Японцы?
19 Oct, 24 -
Передатчик Для Георадара Fmcw
19 Oct, 24
