Спасибо за статью. Но все же спрошу: "Что бы что?" немного уточнений: - главная страница, обычно, как разводящая, с акциями и предложениями. Не посадочная, туда трафик приходит в меньшей мере, чем на страницу каталога или товара (да, я понимаю, что оптимизация на примере главной, в рамках единого развертываемого модуля могло оптимизировать и остальные страницы, но тут от вас нет контекста по архитектуре, потому предполагаю, что все же микрофронт). - правки, которые вы выполнили, в большей мере влияют на первый вход пользователя на сайт. далее у него кешируется большинство статических ресурсов и они в меньшей мере влияют на его путь в отличии от бека (про оптимизацию которого нет в статье ни слова)
т.е. вот вы улучшили перформанс главной страницы, как это повлияло на вашего пользователя? На какие бизнесовые метрики повлияло изменение технических? Есть ли корреляция?
Спасибо за статью. У нас тоже микрофронты, но на своей реализации. Вот только недавно пришли к выводу, что service-discovery (как у вас microfront-discovery) это единая точка отказа для всей системы. У нас он statefull потому с репликацией там ну такое. Это привело к тому, что за счёт высокой производительности, простого api не требующего обслуживания и изменения, а так же за счёт кажущейся стабильности и надёжности он у нас не обновлялся. В итоге инфра при обновлении версии helm заставила нас перерелизить SD. Было очень потно. Более 50 микрофронтов ссылались на него,а в одной из прошлых версий нашего фреймворка микрофронтов прилага падала, когда теряла связь с SD. И даже заранее проверив версии было страшновато. В итоге решили, что лучше конфиги разбитые на локал, дев и прод. Т.е. микрофронты не меняют свое место публикации, убираем лишний сервис с обслуживания, освобождаем ресурсы на его работу, фреймворк микрофронтов на основе используемых паттернов api может сам сапоставить куда стучать за ремоутами, состав фронта по ремоутам не меняется внезапно, без релиза, только версионность потому возможно конфиг проще в поддержке
спасибо за перевод. купил. еще не читал. жаль, что у этой книги нет формата PDF. Последнее время стараюсь читаю на электронной книге. Тот же "Грокаем стриминг" вашего издательства в бумажном исполнении уже после первого активного прочтения разлетелся в переплете. И теперь это конструктор
Ну ведь команда не появится из воздуха, да и платить им надо. Да и распределение ресурсов существующих команд тоже не поможет, иначе они со своими задачами не справятся((
А что вы делаете, если в основном используется react 16, а тут появилась команда, которой нужен "вот прям кровь из носу" 18 версия, у которой есть различия в api? Ну или любую другую либу. А так же как решаете вопрос с дедупликацией множества вот таких зависимостей и treeshaking?
Разговоры разговаривать это прекрасно. Можно и год общаться по поводу того, в чьей ответственности та или иная функциональность. Как бы не забываем, любой проект в большой компании это бюджеты и возможности продвижения себя или команды. Большая компания это всегда дофига политики и интересантов того или иного. Спасают только жёсткое разграничение ответственности, правила, а так же некий внешний контроль, желательно автоматизированный.
Микрофронты абсолютно не про перформанс для клиента. Даже больше, ты как часть становишься зависим от многих. А они приследуют свои бизнес метрики, потому влияние на твой микрофронт это последнее, что беспокоит сторонние команды. Микрофронты - это про оптимизацию процессов поставки и разработки продуктов.
После прочтения статьи я так и не понял, как вы ускорили сайт в 10 раз, зачем вы переходили на Nuxt, что в итоге изменилось? поясню Не хватает контекста, что именно пытались исправить. Если вы ускорили сайт: - Или улучшили перформанс лайтхауса в 10 раз, то он раньше был 4? https://pagespeed.web.dev/analysis/https-www-alta-profil-ru/726ug8gc7y?form_factor=mobile - тут ща на мобилке (десктоп не смотрим, он ни на что не влияет) 43 балла. - Или вы изменили метрики Web Vitals? но тогда какие они раньше были? - Или метрики из RUM и ваш конечный пользователь смог быстрее навигироваться. - Или какой нить пресловутый 95 перцентиль на GET запрос за HTML или данными из бековых систем. Ради чего переход на Nuxt и с какой именно технологии? Почему именно Vue? ИМХО, личный опыт показывает, что на РУ рынке проще найти квалифицированного (мидла или сеньора) react разработчика, а вот vue сложнее. Зачем было переходить на Vue и оставлять подключенный jquery? Как изменился time-to-market при смене технологического стека, ведь по сути ради этого вообще весь "рефакторинг". Сколько времени занял перевод со старого стека на новый, силами скольких разрабов? Сколько было изменено сопутствующих систем, пайпланов и тестов (я вижу на сайте товары с ценой в ноль рублей, могу их положить в корзину и даже оформить заказ. Проверь заказ №С-201687. вы конечно написали, что все что на сайте не публичная оферта, но такое)? Как переход на новый стек изменил объем органического трафика и уникальных пользователей, конверсии в корзину? Статья больше про куски Nuxt, но не про ускорение.
извини, но вообще ничего не скажу, чтобы не сказать глупости т.к. не знаю вашу текущую архитектуру, текущие проблемы поставки\разработки\поддержки, где именно узкое горлышко перформанс (и какие именно метрики туда вкладываются), кто ваш клиент (и его технические ограничения), а самое главное "разделить монолит что бы что?" (блин, Дорофеев покусал). Т.е. что именно хочется решить этим рефакторингом архитектуры. Ведь это может потянуть за собой переделку тестов, пайплайнов... Я бы предложил первым делом понять ограничения проекта, с чем они связаны и как это аффектит на вашего пользователя. Вдруг вы смотрите на перформанс по 99 перцентилю и пытаетесь его решить, а там проблема при попадании на холодный кеш. При разбивании так же я бы приложил учитывать, что это за тип приложения (какой нить бекофис или клиентское приложение) т.к. в какой-то момент есть шанс того, что пользователь через все эти react-lazy так или иначе выкачает себе полностью все. Но при этом обвязки в виде асинхронности не бесплатны.
если планируется использовать разные фреймворки\технологии работы с фронтом, то проще использовать подход eventbus и общаться сообщениями через какой-то общедоступный узел (хоть body). Это даст тебе слабосвязанность и фреймворк агностность (хз есть такое слово или нет))). Но при этом я бы (да и всех, кого знаю) не советовал на одном продукте использовать разные фреймворки. Производительность такого приложения пойдет ко дну
Еще забыл. за частую микрофронты — это забыть про дедупликацию. Module federation может это делать, но с учетом, что все добросовестно указали свои зависимости. Но также из-за этого treeshaking не допустим, т. к. ты не знаешь, какой кусок этой либы нужен в другом микрофронте.
Со своей стороны могу сказать, что немного не согласен, что микрофронтовая архитектура лучше монолитной. Тут, как и в любом архитектурном решении "it depends". Каждый случай надо рассматривать индивидуально. Зависит от компании и ее организации (часто организация определяет архитектуру проектов), от самого проекта и требований по нему. За частую, хорошо структурированный код в монолите будет лучше, чем множество отдельных частей сайта, разбросанных по отдельным "микрофронтам". Качественнее и проще тестируемость. Меньше бандл. Проще контроль за кешами. Ресурсов монолиты жрут меньше (если в целом посмотреть). Микрофронты дают гибкость при росте команд. Когда есть четкое разделение зон ответственности (иначе канибализация и постоянны терки между командами). Быстрее time to market за счет снижения области тестирования. Проще интегрировать новых людей т.к. в меньшее кол-во кода и зону ответственности их надо погружать.
Так же есть проблема конфликта версий используемых библиотек в разных микрофронтах, что может привести к крашу всего приложения на клиенте. Еще не стоит забывать, что один из микрофронтов может переставть отвечать и это должно быть учтено, как со стороны дизайна и клиентского пути, так и со стороны тестирования и фоллбеков
у нас микрофронтовость может быть реализована несколькими вариантами: - билдтайм - рантайм - SSI
Если мы говорим про билдтайм, то больше похоже на то, что другие фронты, как либы интегрируются в твой бандл. Сложно назвать это "микрофронтовостью", однако такой подход имеет право на жизнь. Просто добивается бандл, но мы тут хоть немного можем влиять на оптимизацию.
Если мы говорим про рантайм (например module federation) то появляется лишняя асинхронность, которая может повлиять на web vitals, ведь ты не можешь гарантировать скорость ответа за новым чанком с JS который повлияет на рендер Если мы говорим про рантайм и SSI ты не контролируешь, что другая команда вставила в свой микрофронт, а значит твой перформанс больше не твой, а общий. Они могут обмазаться библиотеками, сложными вычислениями и прочим, ты это не контролируешь. Так же обвязка, которая позволяет сделать модули, асинхронными не является "бесплатной". Хотя иногда можно подумать, что это экономия на спичках.
Мой опыт. Проблема у этого в том, что каждая команда своего микрофронта будет преследовать свои метрики (бизнесовые) и для них их метрики в приоритете, особенно при учете наличия беклога и ограничений по ресурсам команды. Вообще вся проблемы микрофронтов в меньшей мере технические, а в большей именно организационные.
имхо, он помог понять, что мы хотим и куда следует развивать продукт. какие ограничения для нас представляет монолит, готовы ли мы с ним мириться и соответствует ли он планам нашей трансформации из функциональных в продуктовые команды. У АЕМ есть свои плюсы и минусы, а так же огромный функционал, который он предоставляет, но он не будет использован по тем или иным причинам. SPA подход в АЕМ, стабилизировался намного позже начала реализации платформы микрофронтов. Да, в рамках эксперимента мы попробовали реализовать часть функционала на aem spa react. Но это не решение проблем. Просто перенос рендера со стороны htl на react и клиентский роутинг с обменом портянками json. Ведь билд и поставка так и оставались в зоне ответственности АЕМ (по крайней мере по тем рекомендациям со стороны adobe, которые существовали на тот момент). А это опять возвращает нас к длинным релизам и конфликту фич разных команд. На сколько знаю, некоторое время назад, АЕМ таки смог реализовать Headless режим адекватный, но еще раз повторюсь, когда начинали разработку платформы микрофронтов, у АЕМ это было в зачаточном состоянии с весьма скудной документацией и необходимостью обновить версию АЕМ (что так же весьма не приятный процесс)
и оплату мобильный официант принимает qr кодом? я верно понимаю, что ради сканирования qr были объединены 2 функционально разных приложения? сорь, реально интересно т.к. я всегда думал, что касса как отдельный терминал который выполняет узкоспециализированную задачу и более никто ее не выполняет в целях безопасности
хм. я думал, что мобильное приложение для официанта не имеет прямой доступ к кассе, а касса - это отдельное приложение и/или устройство которое получает данные с сервера транзакций
сорь, но достаточно внимательно. мой опыт показывает, что зачастую переписать и отрефакторить - это разные уровни задачи по времезатратам и бюджету. Если у вас иной опыт, то я завидую вашему опыту. я веб разраб и для меня не очевидно какие именно нативные функции необходимы для официанта в приложении, быстродействие ему не нужно т.к. бизнес логики кроме отправить запрос в rest api ему тоже не нужно, на мой взгляд. Даже nfc функционал зачем ему? (@SergeiArsyonov тут наверное к тебе вопрос) по поводу того что js (ts) это другой мир - соглашусь. но с вашего позволения обновлю ваши знания о js и теперь там есть приватные методы и свойства (https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Classes/Private_class_fields)
Спасибо за статью.
Но все же спрошу: "Что бы что?"
немного уточнений:
- главная страница, обычно, как разводящая, с акциями и предложениями. Не посадочная, туда трафик приходит в меньшей мере, чем на страницу каталога или товара (да, я понимаю, что оптимизация на примере главной, в рамках единого развертываемого модуля могло оптимизировать и остальные страницы, но тут от вас нет контекста по архитектуре, потому предполагаю, что все же микрофронт).
- правки, которые вы выполнили, в большей мере влияют на первый вход пользователя на сайт. далее у него кешируется большинство статических ресурсов и они в меньшей мере влияют на его путь в отличии от бека (про оптимизацию которого нет в статье ни слова)
т.е. вот вы улучшили перформанс главной страницы, как это повлияло на вашего пользователя? На какие бизнесовые метрики повлияло изменение технических? Есть ли корреляция?
Спасибо за статью. У нас тоже микрофронты, но на своей реализации. Вот только недавно пришли к выводу, что service-discovery (как у вас microfront-discovery) это единая точка отказа для всей системы. У нас он statefull потому с репликацией там ну такое. Это привело к тому, что за счёт высокой производительности, простого api не требующего обслуживания и изменения, а так же за счёт кажущейся стабильности и надёжности он у нас не обновлялся. В итоге инфра при обновлении версии helm заставила нас перерелизить SD. Было очень потно. Более 50 микрофронтов ссылались на него,а в одной из прошлых версий нашего фреймворка микрофронтов прилага падала, когда теряла связь с SD. И даже заранее проверив версии было страшновато. В итоге решили, что лучше конфиги разбитые на локал, дев и прод. Т.е. микрофронты не меняют свое место публикации, убираем лишний сервис с обслуживания, освобождаем ресурсы на его работу, фреймворк микрофронтов на основе используемых паттернов api может сам сапоставить куда стучать за ремоутами, состав фронта по ремоутам не меняется внезапно, без релиза, только версионность потому возможно конфиг проще в поддержке
спасибо за перевод. купил. еще не читал.
жаль, что у этой книги нет формата PDF. Последнее время стараюсь читаю на электронной книге. Тот же "Грокаем стриминг" вашего издательства в бумажном исполнении уже после первого активного прочтения разлетелся в переплете. И теперь это конструктор
Ну ведь команда не появится из воздуха, да и платить им надо. Да и распределение ресурсов существующих команд тоже не поможет, иначе они со своими задачами не справятся((
А что вы делаете, если в основном используется react 16, а тут появилась команда, которой нужен "вот прям кровь из носу" 18 версия, у которой есть различия в api? Ну или любую другую либу. А так же как решаете вопрос с дедупликацией множества вот таких зависимостей и treeshaking?
Разговоры разговаривать это прекрасно. Можно и год общаться по поводу того, в чьей ответственности та или иная функциональность. Как бы не забываем, любой проект в большой компании это бюджеты и возможности продвижения себя или команды. Большая компания это всегда дофига политики и интересантов того или иного. Спасают только жёсткое разграничение ответственности, правила, а так же некий внешний контроль, желательно автоматизированный.
Микрофронты абсолютно не про перформанс для клиента. Даже больше, ты как часть становишься зависим от многих. А они приследуют свои бизнес метрики, потому влияние на твой микрофронт это последнее, что беспокоит сторонние команды. Микрофронты - это про оптимизацию процессов поставки и разработки продуктов.
После прочтения статьи я так и не понял, как вы ускорили сайт в 10 раз, зачем вы переходили на Nuxt, что в итоге изменилось?
поясню
Не хватает контекста, что именно пытались исправить. Если вы ускорили сайт:
- Или улучшили перформанс лайтхауса в 10 раз, то он раньше был 4? https://pagespeed.web.dev/analysis/https-www-alta-profil-ru/726ug8gc7y?form_factor=mobile - тут ща на мобилке (десктоп не смотрим, он ни на что не влияет) 43 балла.
- Или вы изменили метрики Web Vitals? но тогда какие они раньше были?
- Или метрики из RUM и ваш конечный пользователь смог быстрее навигироваться.
- Или какой нить пресловутый 95 перцентиль на GET запрос за HTML или данными из бековых систем.
Ради чего переход на Nuxt и с какой именно технологии? Почему именно Vue? ИМХО, личный опыт показывает, что на РУ рынке проще найти квалифицированного (мидла или сеньора) react разработчика, а вот vue сложнее.
Зачем было переходить на Vue и оставлять подключенный jquery?
Как изменился time-to-market при смене технологического стека, ведь по сути ради этого вообще весь "рефакторинг".
Сколько времени занял перевод со старого стека на новый, силами скольких разрабов? Сколько было изменено сопутствующих систем, пайпланов и тестов (я вижу на сайте товары с ценой в ноль рублей, могу их положить в корзину и даже оформить заказ. Проверь заказ №С-201687. вы конечно написали, что все что на сайте не публичная оферта, но такое)?
Как переход на новый стек изменил объем органического трафика и уникальных пользователей, конверсии в корзину?
Статья больше про куски Nuxt, но не про ускорение.
извини, но вообще ничего не скажу, чтобы не сказать глупости т.к. не знаю вашу текущую архитектуру, текущие проблемы поставки\разработки\поддержки, где именно узкое горлышко перформанс (и какие именно метрики туда вкладываются), кто ваш клиент (и его технические ограничения), а самое главное "разделить монолит что бы что?" (блин, Дорофеев покусал). Т.е. что именно хочется решить этим рефакторингом архитектуры. Ведь это может потянуть за собой переделку тестов, пайплайнов...
Я бы предложил первым делом понять ограничения проекта, с чем они связаны и как это аффектит на вашего пользователя. Вдруг вы смотрите на перформанс по 99 перцентилю и пытаетесь его решить, а там проблема при попадании на холодный кеш.
При разбивании так же я бы приложил учитывать, что это за тип приложения (какой нить бекофис или клиентское приложение) т.к. в какой-то момент есть шанс того, что пользователь через все эти react-lazy так или иначе выкачает себе полностью все. Но при этом обвязки в виде асинхронности не бесплатны.
если планируется использовать разные фреймворки\технологии работы с фронтом, то проще использовать подход eventbus и общаться сообщениями через какой-то общедоступный узел (хоть body). Это даст тебе слабосвязанность и фреймворк агностность (хз есть такое слово или нет))).
Но при этом я бы (да и всех, кого знаю) не советовал на одном продукте использовать разные фреймворки. Производительность такого приложения пойдет ко дну
Еще забыл. за частую микрофронты — это забыть про дедупликацию. Module federation может это делать, но с учетом, что все добросовестно указали свои зависимости. Но также из-за этого treeshaking не допустим, т. к. ты не знаешь, какой кусок этой либы нужен в другом микрофронте.
Со своей стороны могу сказать, что немного не согласен, что микрофронтовая архитектура лучше монолитной. Тут, как и в любом архитектурном решении "it depends". Каждый случай надо рассматривать индивидуально. Зависит от компании и ее организации (часто организация определяет архитектуру проектов), от самого проекта и требований по нему.
За частую, хорошо структурированный код в монолите будет лучше, чем множество отдельных частей сайта, разбросанных по отдельным "микрофронтам". Качественнее и проще тестируемость. Меньше бандл. Проще контроль за кешами. Ресурсов монолиты жрут меньше (если в целом посмотреть).
Микрофронты дают гибкость при росте команд. Когда есть четкое разделение зон ответственности (иначе канибализация и постоянны терки между командами). Быстрее time to market за счет снижения области тестирования. Проще интегрировать новых людей т.к. в меньшее кол-во кода и зону ответственности их надо погружать.
Так же есть проблема конфликта версий используемых библиотек в разных микрофронтах, что может привести к крашу всего приложения на клиенте.
Еще не стоит забывать, что один из микрофронтов может переставть отвечать и это должно быть учтено, как со стороны дизайна и клиентского пути, так и со стороны тестирования и фоллбеков
у нас микрофронтовость может быть реализована несколькими вариантами:
- билдтайм
- рантайм
- SSI
Если мы говорим про билдтайм, то больше похоже на то, что другие фронты, как либы интегрируются в твой бандл. Сложно назвать это "микрофронтовостью", однако такой подход имеет право на жизнь. Просто добивается бандл, но мы тут хоть немного можем влиять на оптимизацию.
Если мы говорим про рантайм (например module federation) то появляется лишняя асинхронность, которая может повлиять на web vitals, ведь ты не можешь гарантировать скорость ответа за новым чанком с JS который повлияет на рендер
Если мы говорим про рантайм и SSI ты не контролируешь, что другая команда вставила в свой микрофронт, а значит твой перформанс больше не твой, а общий. Они могут обмазаться библиотеками, сложными вычислениями и прочим, ты это не контролируешь. Так же обвязка, которая позволяет сделать модули, асинхронными не является "бесплатной". Хотя иногда можно подумать, что это экономия на спичках.
Мой опыт.
Проблема у этого в том, что каждая команда своего микрофронта будет преследовать свои метрики (бизнесовые) и для них их метрики в приоритете, особенно при учете наличия беклога и ограничений по ресурсам команды.
Вообще вся проблемы микрофронтов в меньшей мере технические, а в большей именно организационные.
имхо, он помог понять, что мы хотим и куда следует развивать продукт. какие ограничения для нас представляет монолит, готовы ли мы с ним мириться и соответствует ли он планам нашей трансформации из функциональных в продуктовые команды.
У АЕМ есть свои плюсы и минусы, а так же огромный функционал, который он предоставляет, но он не будет использован по тем или иным причинам.
SPA подход в АЕМ, стабилизировался намного позже начала реализации платформы микрофронтов. Да, в рамках эксперимента мы попробовали реализовать часть функционала на aem spa react. Но это не решение проблем. Просто перенос рендера со стороны htl на react и клиентский роутинг с обменом портянками json. Ведь билд и поставка так и оставались в зоне ответственности АЕМ (по крайней мере по тем рекомендациям со стороны adobe, которые существовали на тот момент). А это опять возвращает нас к длинным релизам и конфликту фич разных команд.
На сколько знаю, некоторое время назад, АЕМ таки смог реализовать Headless режим адекватный, но еще раз повторюсь, когда начинали разработку платформы микрофронтов, у АЕМ это было в зачаточном состоянии с весьма скудной документацией и необходимостью обновить версию АЕМ (что так же весьма не приятный процесс)
оке. пасиб
и оплату мобильный официант принимает qr кодом?
я верно понимаю, что ради сканирования qr были объединены 2 функционально разных приложения?
сорь, реально интересно т.к. я всегда думал, что касса как отдельный терминал который выполняет узкоспециализированную задачу и более никто ее не выполняет в целях безопасности
хм. я думал, что мобильное приложение для официанта не имеет прямой доступ к кассе, а касса - это отдельное приложение и/или устройство которое получает данные с сервера транзакций
ага, это больше со ссылкой на вот этот коммент https://habr.com/ru/company/r_k/blog/578386/#comment_23493888
сорь, но достаточно внимательно.
мой опыт показывает, что зачастую переписать и отрефакторить - это разные уровни задачи по времезатратам и бюджету. Если у вас иной опыт, то я завидую вашему опыту.
я веб разраб и для меня не очевидно какие именно нативные функции необходимы для официанта в приложении, быстродействие ему не нужно т.к. бизнес логики кроме отправить запрос в rest api ему тоже не нужно, на мой взгляд. Даже nfc функционал зачем ему? (@SergeiArsyonov тут наверное к тебе вопрос)
по поводу того что js (ts) это другой мир - соглашусь. но с вашего позволения обновлю ваши знания о js и теперь там есть приватные методы и свойства (https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Classes/Private_class_fields)