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