Мне попадалось интересное видео где на Orange Pi 5 тестируют M.2 разъем и засовывают туда 4 разных устройства и все отлично работает. К сожалению теперь не могу найти.
Интересно у нас статьи про мини пк вышли почти одновременно. Вижу что спрос на такие ПК будет только расти. Но Orange Pi 5 на фоне этого компьютера выглядит гораздо привлекательнее. Цена таже, а производительность и ресурсов много больше. Бонусом пассивное охлаждение.
В моей компании используется доп. надстройка над anyconnect и подружить openconnect с этой надстройкой не самая простая задача. Но даже если подружить ИБ будет сильно ругаться.
Смотря что было зашито на диске до этого. Если например андройд, то не подойдет. Потому что насколько я понял записывается и загрузчик для самой железки.
Если до этого стоял линукс, то подойдет dd или balena ether. dd сам лично не пробовал, ибо основной комп на винде, а вот balena ether работает исправно.
У esbuild есть существенный недостаток, он не поддерживает все возможности typescript. Как альтернативу рекомендую использовать связку rollup + swc + post-css. Скорость даже чуть лучше, и полная поддержка typescript.
А теперь представим ситуацию. Вы разработали микрофронтенд на ваших любимых технологиях. Допустим это Angular 9.10, jQuery 2.15 и Moment 2.14, сборка Webpack + MF. А теперь вам пришла задача: Вам нужно провести интеграцию вашего микрофронтенда с популярным продуктом другой компании. Популярный внешний продукт является хостовым приложением, вы в него встраиваете микрофронтенд. Хостовый продукт написан на React, заботиться о SEO и Клиентских метриках. Производительность для них крайне важный вопрос. А теперь вы приходите в этот продукт и говорите: А обеспечьте ка мне в зависимостях Angular, jQuery, Moment нужной мне версии, а еще у меня MF от Webpack, поэтому выкиньте свою сборку на Vite, а еще из-за моих тяжелых библиотек у вас Seo и Клиентские метрики просядут. Предугадайте последствия?
И понятное дело что вы уже не разрабатываете на Angular, jQuery и Moment. Но разработчики vue, svelte и тп. именно так воспринимают React + Redux и все остальные ваши любимые зависимости как вы сейчас восприняли Angular, jQuery и Moment.
Шарятся в пределах одной группы микрофронтендов. Например шапка, футер, переиспользуемые формочки переиспользуют одни и теже зависимости. Встраиваемые виджеты оплаты уже имеют другие зависимости.
И да и нет. Нет - в том плане что мы не используем реакт для микрофронтенда. Вместо него мы используем его легковесную альтернативу Preact. React + React Dom весит 128 kb, Preact весит 3.5 kb. Т.е. в 36 легче. Есть где разгуляться. Да - в том плане что в каждой группе микрофронтендов свой экземпляр Preact. Получается что на странице 2-4 экземпляра Preact + Preact на хостовом приложении. Это все еще в 6 раз легче 1 пошаренного Реакта.
Шаринг в MF работает только до тех пор пока у вас небольшой проект. Далее у вашей команды начнутся конфликты на тему что один разработчик хочет новый реакт, а другой говорит что пока не может поддержать новую версию реакта.
В моем случае было 15 внешних партнерских ресурсов + тильда. Заставить кого либо использовать нужную версию Реакта - нереально. Заставить апгрейдить версии Реакта одновременно - нереально. Заставить кого либо использовать реакт вместо вуе - нереально. Заставить шарить реакт на вуе проекте - нереально. Заставить настраивать кого либо MF там где его нет - нереально. Затащить MF в тильду - нереально.
А такое решение на базе микробиблиотек + динамический импорт отлично справляется со всеми перечисленными проблемами.
МТС огромная компания с большим набором технологий. Распределение примерно такое же как и по индустрии. Большинство проектов это реакт, так же распространены вуе и ангуляр. Тильда это самое не популярное решение, но и к нему иногда прибегают.
Например ваш микрофронтенд может быть реализован на react 18 с новыми хуками, а основное приложение на react 15 где новых хуков нет. И таким образом вы не сможете пошарить единый реакт между микрофронтендом и хостовым приложением.
В описанном же мною подходе команда реализующая микрофронтенд независима от технологий хостового приложения. В т.ч. свободно обновляет версии используемых библиотек. Главное не использовать тяжелых зависимостей.
Вопрос коммуникации микрофронтендов тут не затрагивался. Но легко реализуется либо через пропсы микрофронтенда, как с обычными компонентами, либо через общий Event Bus.
Имелось ввиду без фреймворком разработки микрофронтендов, типа Webpack Module Federation, Single-SPA, SystemJS и т.п..
Но на самом деле данный подход можно использовать и без реакта, и вообще каких либо библиотек, и даже инструментов сборки. Браузер нативными средствами подтянет все импорты доступные по http/s.
Но все же лучше использовать микробиблиотеки и делать оптимизирующую сборку для клиентов.
Мне попадалось интересное видео где на Orange Pi 5 тестируют M.2 разъем и засовывают туда 4 разных устройства и все отлично работает. К сожалению теперь не могу найти.
Интересно у нас статьи про мини пк вышли почти одновременно. Вижу что спрос на такие ПК будет только расти. Но Orange Pi 5 на фоне этого компьютера выглядит гораздо привлекательнее. Цена таже, а производительность и ресурсов много больше. Бонусом пассивное охлаждение.
В моей компании используется доп. надстройка над anyconnect и подружить openconnect с этой надстройкой не самая простая задача. Но даже если подружить ИБ будет сильно ругаться.
Смотря что было зашито на диске до этого. Если например андройд, то не подойдет. Потому что насколько я понял записывается и загрузчик для самой железки.
Если до этого стоял линукс, то подойдет dd или balena ether. dd сам лично не пробовал, ибо основной комп на винде, а вот balena ether работает исправно.
Неа, как то вылетело из головы его попробовать =)
Но скоро попробую его на Raspbery Pi 3, этот негодяй опять скушал флешку. Нет мочи больше терпеть это безобразие.
Фейсбук видимо решил прислушаться к моей статье, несмотря на то что любители css мне слили карму
https://habr.com/ru/articles/707510/
* сарказм
У esbuild есть существенный недостаток, он не поддерживает все возможности typescript. Как альтернативу рекомендую использовать связку rollup + swc + post-css. Скорость даже чуть лучше, и полная поддержка typescript.
Сеньор? Серьезно? Это вопросы из учебника для джуниоров. Сеньоры в это области даже не работают.
А не проще поставить умный автомат в электрощит?
Вроде этого:
А теперь представим ситуацию. Вы разработали микрофронтенд на ваших любимых технологиях. Допустим это Angular 9.10, jQuery 2.15 и Moment 2.14, сборка Webpack + MF. А теперь вам пришла задача: Вам нужно провести интеграцию вашего микрофронтенда с популярным продуктом другой компании. Популярный внешний продукт является хостовым приложением, вы в него встраиваете микрофронтенд. Хостовый продукт написан на React, заботиться о SEO и Клиентских метриках. Производительность для них крайне важный вопрос. А теперь вы приходите в этот продукт и говорите: А обеспечьте ка мне в зависимостях Angular, jQuery, Moment нужной мне версии, а еще у меня MF от Webpack, поэтому выкиньте свою сборку на Vite, а еще из-за моих тяжелых библиотек у вас Seo и Клиентские метрики просядут. Предугадайте последствия?
И понятное дело что вы уже не разрабатываете на Angular, jQuery и Moment. Но разработчики vue, svelte и тп. именно так воспринимают React + Redux и все остальные ваши любимые зависимости как вы сейчас восприняли Angular, jQuery и Moment.
Шарятся в пределах одной группы микрофронтендов. Например шапка, футер, переиспользуемые формочки переиспользуют одни и теже зависимости. Встраиваемые виджеты оплаты уже имеют другие зависимости.
И да и нет. Нет - в том плане что мы не используем реакт для микрофронтенда. Вместо него мы используем его легковесную альтернативу Preact. React + React Dom весит 128 kb, Preact весит 3.5 kb. Т.е. в 36 легче. Есть где разгуляться. Да - в том плане что в каждой группе микрофронтендов свой экземпляр Preact. Получается что на странице 2-4 экземпляра Preact + Preact на хостовом приложении. Это все еще в 6 раз легче 1 пошаренного Реакта.
Шаринг в MF работает только до тех пор пока у вас небольшой проект. Далее у вашей команды начнутся конфликты на тему что один разработчик хочет новый реакт, а другой говорит что пока не может поддержать новую версию реакта.
В моем случае было 15 внешних партнерских ресурсов + тильда. Заставить кого либо использовать нужную версию Реакта - нереально. Заставить апгрейдить версии Реакта одновременно - нереально. Заставить кого либо использовать реакт вместо вуе - нереально. Заставить шарить реакт на вуе проекте - нереально. Заставить настраивать кого либо MF там где его нет - нереально. Затащить MF в тильду - нереально.
А такое решение на базе микробиблиотек + динамический импорт отлично справляется со всеми перечисленными проблемами.
МТС огромная компания с большим набором технологий. Распределение примерно такое же как и по индустрии. Большинство проектов это реакт, так же распространены вуе и ангуляр. Тильда это самое не популярное решение, но и к нему иногда прибегают.
Промазал. Del.
Например ваш микрофронтенд может быть реализован на react 18 с новыми хуками, а основное приложение на react 15 где новых хуков нет. И таким образом вы не сможете пошарить единый реакт между микрофронтендом и хостовым приложением.
В описанном же мною подходе команда реализующая микрофронтенд независима от технологий хостового приложения. В т.ч. свободно обновляет версии используемых библиотек. Главное не использовать тяжелых зависимостей.
Вопрос коммуникации микрофронтендов тут не затрагивался. Но легко реализуется либо через пропсы микрофронтенда, как с обычными компонентами, либо через общий Event Bus.
К сожалению нет. Данная реализация является частью продукта и доступна только сотрудникам МТС.
Вообще чисто технически это возможно. Но не могу придумать задачу которую сможет решить данный подход.
А что вы имеете ввиду под автодискавери микрофронтов?
Имелось ввиду без фреймворком разработки микрофронтендов, типа Webpack Module Federation, Single-SPA, SystemJS и т.п..
Но на самом деле данный подход можно использовать и без реакта, и вообще каких либо библиотек, и даже инструментов сборки. Браузер нативными средствами подтянет все импорты доступные по http/s.
Но все же лучше использовать микробиблиотеки и делать оптимизирующую сборку для клиентов.
При упоминании Tailwind у меня проскакивает мысль: Миллениалы изобрели бутстрап.