Я не понимаю микро интерфейс
Вчера, вернувшись с прогулки с собакой, увидел в твиттере какие-то объявления, люди на меня, просят поделиться своими мыслями о Дэне Абрамове.микро интерфейсИдея:
Если вы следите за мной, то знаете, что я очень увлекаюсь микро-интерфейсом, я работаю с ними некоторое время, а также сохраняю непредвзятость, анализируя разные способы, чтобы понять их плюсы и минусы.
Если вы не подписаны на меня, но интересуетесь этой темой с технической точки зрения, загляните в мойСредний дом, и многие другие ресурсы на микрофронтендах, просто ищите на Medium или используйте свою любимую поисковую систему.
Я не могу охватить все темы, обсуждаемые в Твиттере, но давайте начнем с самого начала и посмотрим, смогу ли я помочь добавить некоторыеконтекст(В этой статье вы все чаще будете слышать слово 😁) фронтенд-микротема.
Отказ от ответственности
первый,Я пишу это не для того, чтобы кого-то обвинить или напасть, даже не для того, чтобы начать войну на социальных платформах, я уважаю любое мнение, иногда у меня такое же мнение, как у других, иногда нет, такое поведение приносит инновации и новые идеи, поэтому я полностью согласен с этим.
Учитывая, что в некоторых твитах, начатых Дэном, упоминалось мое имя, я хотел поделиться своими мыслями, потому что я действительно верю, что мы действительно можем говорить о микро-фронтендах, предоставляя всем преимущества часто задаваемых вопросов, которые я получаю еженедельно. Социальные сети, личная электронная почта, публикации презентаций и многое другое.
Другие обращались ко мне по поводу вышеупомянутого твита: я не ответил прямо на твит, потому что обсуждение интересной темы, такой как тема в 280 символов, на самом деле является ограничительным и легко неправильно понять или упустить важные детали.
Почему микрофронтенды, а не хорошая компонентная модель?
Компоненты, безусловно, правильные решения, многие компании используют их каждый день с большим успехом, но они не панацея; проект, команда, бизнес и вообще должны вписываться в их контекст, иначе мы как будто пытаемся вписаться квадрат в круг, мы не всегда получаем то, что ожидаем.
Исследуйте новые возможности, бросайте вызов нашим убеждениям и «стандартному способу ведения дел», продвигайте нашу отрасль вперед, укрепляйте существующие стандарты или вводите новые.
Начнем с этого,Микрофронтенды не пытаются заменить компоненты, возможно, у нас нет чего-то подходящего для всех проектов, например компонентов, это не панацея.
Нашей целью должно быть использование правильного инструмента для правильной работы. Помните, что разработка программного обеспечения является эмпирической, а не научной.
Я видел большие организации с ужасной кодовой базой и действительно успешным продуктом, и я видел полную противоположность, когда мы не можем просто смотреть на одну сторону медали.
До сих пор я пробовал только масштабные микрофронтенды (около 200 человек — фронтенд- и бэкенд-инженеры — работали над одним и тем же проектом) в сочетании с микросервисами и командным владением, что отлично работает по сравнению с предыдущей моделью нашей компании. Хорошо.
Могут ли они работать над небольшими проектами? В идеале так и должно быть, но я хотел сначала попробовать.
В теории все выглядит прекрасно, а когда дело доходит до деталей, понимаешь ограничения и находишь новые вызовы. Если у вас есть опыт, я буду рад услышать от вас!
Что касается микрофронтендов, то есть разные варианты, например, мы можем использовать iframe для создания окончательного вида или использоватьВключение на стороне Edge или Включение на стороне клиента, даже используя такую стратегию предварительного рендеринга, какOpen ComponentsилиInterface FrameworkИ кешировать результаты на уровне CDN. Другой способиспользовать оркестратор, он обслуживает SPA, одну HTML-страницу или приложение SSR, координатор может быть на границе, источнике или клиенте, примером координатора может бытьSingle-SPA.
Эти методы предполагают, что у нас есть два основных подхода к определению размера микрофронтенда:
- Часть пользовательского интерфейса, которая может соответствовать компоненту, но не обязательно должна иметь отношение сопоставления 1-к-1 с компонентом.
- Весь бизнес-домен, может соответствовать SPA, отдельной HTML-странице или приложению SSR.
У них есть свои плюсы и минусы, лично я предпочитаю последний, но он также не является пуленепробиваемым, и важно понимать ограничения каждого подхода и то, повлияют ли эти ограничения на окончательный результат проекта.
Микрофронтенды — это определенно технология, которая влияет на вашу организацию, она обеспечивает изоляцию между командами, избегает чрезмерной централизации и позволяет командам местное решение .
Это не означает, что эти команды не могут договориться о стратегии или соглашении об API, микроинтерфейсы позволяют командам идти по пути, которому они могут следовать, не координируя каждое техническое решение с другими командами, которые могут повлиять на кодовую базу, но мы позволяем им ошибаться. быстро, создавать и развертывать самостоятельно, соблюдая определенные границы, определенные организацией (языки, поддерживаемые компанией, лучшие практики и т. д.).
Я лично работал в разных организациях, и новые участники дают хорошее представление о том, как изменить «основную библиотеку», но часто используются в политике, поскольку изменения не приносят немедленной выгоды, эти предложения остаются в отставании в состоянии ожидания.
Децентрализация командного принятия решений, вероятно, одна из лучших вещей, которые может сделать компания, поскольку эта команда живет с продуктовыми командами и бизнес-экспертами, говорящими на одном языке каждый день, они находятся на вершине игры, а централизация теряет Контекст, некоторые ограничения предоставленные иногда не нужны.
Когда компания может установить некоторые технические границы в рамках конкретной сферы бизнеса, команда может проявить себя наилучшим образом, могут быть допущены некоторые ошибки, но восстановление происходит очень быстро, потому что объем работ, который необходимо изменить, меньше, чем полное приложение.
понимать контекст
Дэн прав в своем примере, но он не учитывает контекст разговора, он пытается продвигать решение, которое должно работать для всего, но это не так.
Самое главное в контексте любого решения — это понимание технической реализации отдельными участниками, командами или организациями.
За последнее десятилетие я видел много проектов, написанных схожим образом, с одной и той же архитектурой, с похожими шаблонами... но с разными результатами и разными проблемами на пути, как я уже говорил ранее,Разработка программного обеспечения является эмпирической, а не научной.
Теперь, когда мы лучше понимаем, какие методы мы можем использовать для успешной реализации проектов, мы больше не используем универсальную структуру или архитектуру, мы пытаемся использовать правильный инструмент для правильной работы.
Если в проекте должны использоваться широко используемые компоненты, и проект увенчался успехом, то абсолютно нормально, вероятно, конечный результат проекта, среда, вовлеченные участники и процессы, установленные для реализации проекта, делают библиотеку общих компонентов подходящим планом решения. .
В то же время другие сценарии могут потребовать другого подхода, нестандартного мышления, поскольку традиционные подходы не дают предсказуемых результатов.
Контекст является ключевым, понимание бизнеса, среды, в которой мы работаем, результатов, на которые мы ориентируемся, связаны с нашим контекстом.
Таким образом, наличие библиотеки компонентов для абстрагирования функциональности сотен (если не тысяч) компонентов похоже на наличие нескольких SPA, где код дублируется, а не содержится в библиотеке или во многих из них.
Контекст заставляет нас принимать решения, которые иногда не ожидаются другими, в прошлом мы узнали много правил/руководств, таких как DRY (не повторяйтесь) или DIE (копирование — это зло), они вполне применимы, но не так. мы должны уважать догму, какой бы ни была причина. Потому что иногда мы делаем это по уважительной причине.
Не поймите меня неправильно, я не утверждаю, что копирование большого количества кода — это лучшая практика, но иногда это неизбежное зло, которое позволяет двигаться вперед быстрее.
Дублирование кода может сделать наши команды более автономными, поскольку они не используют код, более сложный из-за абстракции, и не зависят от внешних команд.
Как всегда, нам нужно быть вдумчивыми при копировании кода, что имеет смысл абстрагировать код или копировать, а контекст определяет наше решение.
Абстракция часто обходится дороже, чем дублирование кода, и если вы применяете неправильную абстракцию в масштабе, мы генерируем сложный код, вызывая разочарование у членов команды, что, в свою очередь, приводит к худшему поведению, такому как игнорирование централизованного подхода в пользу принятия «Меньше». подход «соответствие назначению», реализованный командой в собственной кодовой базе, приводит к меньшему контролю над общим решением.
Так что да, давайте избегать дублирования кода, но сбалансируйте это в своих решениях, потому что вы будете удивлены, если решите эти проблемы в нужных частях вашего приложения.
Несколько технологических стеков
Я полностью согласен с Федерико в том, что любая технология, которую мы можем выбрать и захотеть, может стать источником катастрофы... так что, если мы будем использовать только лучшие детали?
Микрофронтенды не навязывают другой технологический стек, тот факт, что они поддерживают этот подход, не означает, что мы должны следовать ему.
Как и в мире микросервисов, мы не получаем 20 разных языков в одной системе, потому что каждый из них самоуверен и привносит в систему свое видение, поддерживая разные экосистемы. так как не приносит большой пользы.
Но компромиссы могут быть полезными, мы можем выбрать из ограниченного списка языков или фреймворков те, которые действительно работают.
Внезапно мы перестаем быть тесно связанными с одним стеком технологий, мы можем проводить рефакторинг старых проектов, поддерживающих предыдущий стек, и новый проект, который медленно, но неуклонно внедряется в производство без необходимости в версии большого взрыва (см.режим убийства), мы можем использовать разные версии одной и той же библиотеки или фреймворка в продакшене, не затрагивая все приложение, мы можем опробовать новые фреймворки или подходы, наблюдать фактическую производительность в действии, и мы можем нанимать лучших из разных сообществ людей и многое другое. преимущества.
Когда у нас есть возможность использовать несколько технологических стеков, есть некоторые рекомендации, которые действительно помогают получить от этого огромные преимущества, и только когда есть хаос, а не общая цель, обратная сторона или катастрофа становятся реальностью.
Обратите внимание на размер пакета кода
Я очень уважаю Дэна Шаппира и посетил семинар в Сан-Хосе во время конференции Fluent в прошлом году.
Он дает массу полезных идей о том, как оптимизировать наши веб-приложения, и, безусловно, является гуру оптимизации производительности.
Я думаю, что комментарии, которые Дэн поделил здесь, действительно зависят от контекста (опять же), например, использование микроинтерфейсов и разбиение приложения на несколько SPA, разрешение загрузки только части приложения, отделение библиотеки от кодовой базы приложения, что позволяет нам увеличить TTL в CDN файлов поставщика услуг, если пользователю требуется быстрое обращение туда и обратно, браузер также улучшает стратегию кэширования, обслуживая файлы непосредственно с диска, а не выполняя несколько круговых обращений.
Наконец, рабочие на стороне сервера могут смягчить эту проблему с помощью стратегии кэширования зависимостей, если это целесообразно в конкретном случае.
Теперь неизбежно, что если мы плохо упакуем зависимости, это повлияет на время загрузки, но это не повлияет на микро-интерфейс, это повлияет на SPA.
Вероятно, как и в случае с микрофронтендом, вы также можете делиться зависимостями (см.Single-SPA) или если вы скажете «нет», в последнем случае, в зависимости от того, как используется ваше приложение, например, если мы можем понять поведение пользователя в нашем приложении, мы можем «нарезать» приложение на наши пользователи, которые потребляют «путешествие» внутри микрофронтенд и начать новое путешествие внутри другого.
Что мы можем обнаружить, так это то, что наши пользователи приходят на нашу платформу, чтобы совершить путешествие, и в этом случае они будут загружать только те зависимости и код, которые им нужны в микроинтерфейсе, а не все зависимости, используемые во всем приложении.
Точно так же пользователь может перемещаться в нашем приложении случайным образом, в этом случае он будет загружать некоторые зависимости несколько раз, но в этом случае команда решает, как облегчить его путешествие и улучшить производительность, чтобы обеспечить лучший опыт.
Закон Парето (правило 80/20): «...для многих событий примерно 80 % последствий исходят из 20 % причин».
Управление API с помощью микроинтерфейсов может быть сложным, но не таким важным, как работа с другими архитектурами. В нашем случае мы переходим от сервисного словаря, где перечислены все доступные API, к конкретным для каждого микроинтерфейса, это требует немного больше работы, но это оптимизирует полезную нагрузку, совместно используемую сервером и клиентом, показывая только те API, которые представляют интерес для этого микроинтерфейса. Очевидно, что не всегда возможно иметь API, связанный только с одним микрофронтендом, в этом случае нам нужны внешние зависимости и связь между командами, но это очень ограничено по сравнению с повседневной работой.
Я хочу подчеркнуть здесь, что микроинтерфейсы не идеальны, но сочетание передового опыта может привести к тому, что наши проекты будут соответствовать высоким стандартам: правильная работа, правильный инструмент, помните?
Суммировать
Я действительно считаю, что использование правильных инструментов для правильной работы имеет важное значение, монолиты, микросервисы, компоненты, библиотеки, микроинтерфейсы — это инструменты и методы для самовыражения, наше намерение — это только один аспект «решения» (техническая сторона), и, очевидно, влияние на бизнес использования этих технологий и инструментов.
Микрофронтенды действительно могут помочь организации двигаться быстрее, внедрять инновации в сфере бизнеса и изолировать сбои, и в то же время я не против монолитных приложений любой формы и формы, я не (полностью) против централизации, хотя я часто все библиотеки чрезмерно оптимизированы, чтобы не фокусироваться на том, куда движется бизнес, а добавлять уровень бессмысленной абстракции, который снижает производительность разработчиков, а не ускоряет ее.
Поскольку команда не может слишком сильно влиять на работу другой команды, централизация часто приводит к разочарованию в командах, поскольку внешние зависимости трудно разрешить.
Я знаю, что есть несколько способов пройтиВнутренний открытый исходный кодЧтобы смягчить проблему, я также не могу дать слишком много информации об этом подходе, но из нескольких разговоров, которые я слышал, и чатов, которые у меня были, для некоторых инженеров, которые используют внутренние источники в компании, если у вас есть разные code Sharing Responsibility for Libraries, это, безусловно, отличный подход, не стесняйтесь комментировать этот пост, если у вас есть опыт в этом.
Принятие взвешенных решений — секрет успеха.
Наконец, помнитеКонтекст является ключом к пониманию решений.Архитекторы часто пишут ADR (Запись архитектурного решения). Эти документы помогают любому сотруднику компании понять, почему было принято решение, описывая контекст, доступные варианты, выбранные варианты и, в конечном счете, последствия этого решения.
Я часто вижу, как люди осуждают решения других компаний или коллег, не понимая контекста, в котором было принято решение, хотя на самом деле контекст важнее самого решения, потому что, как бы страшно или совершенно неуместно это ни звучало, на самом деле может быть является лучшим (или единственным) вариантом для данного конкретного контекста.
Как всегда, я открыт для дискуссий, и я уверен, что люди не согласятся с некоторыми пунктами, изложенными в этом посте, но это то, что касается обмена нашим опытом и убеждениями! 🤓