А теперь представим ситуацию. Вы разработали микрофронтенд на ваших любимых технологиях. Допустим это 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 3 для медиа сервера, накатил ubuntu. И понял что ubuntu не поддерживает gpu mali. Т.е. картинка рисуется, но что называется на минималках. Браузер например уже рисует страницы с большим трудом, про видео вообще молчу. Кто сталкивался с проблемой и как решал?
Какие то очень странные утверждения и без единого примера. На картинках видно что квадратные фигурки не вписываются в более мелкие круглые, но где в этом практический смысл?
Я правильно понимаю что этой картинкой вы хотите сказать что если вам поставили задачу дополнить интерфейс вы будете дорабатывать вьюху? А что есть вариант не дорабатывать?
Просто потому что по плану логика должна выполняться в определенном порядке, но архитектура создана так, что принудительно заставляет ее разрываться, тем самым ставя нас в положение, когда мы не можем легко доказать последовательность.
Простой пример почему это не так. Вы не можете запустить 64 битную программу на 32 битной системе. Там есть четкой деление что вы делаете и типы под эти задачи, 32 битные для 32 битных систем, 64 битные для 64 битных систем, и автотипы значение которых выбирается от платформы компиляции.
Вы путаете типизацию с валидацией. Типизация должна заблокировать сборку при использовании типа short для 8 битного процессора. Потому что у железа просто нету 16 битного регистра. Валидация проверять удовлетворяет ли значение условию.
А не проще поставить умный автомат в электрощит?
Вроде этого:
А теперь представим ситуацию. Вы разработали микрофронтенд на ваших любимых технологиях. Допустим это 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 у меня проскакивает мысль: Миллениалы изобрели бутстрап.
Я недавно взял orange pi 3 для медиа сервера, накатил ubuntu. И понял что ubuntu не поддерживает gpu mali. Т.е. картинка рисуется, но что называется на минималках. Браузер например уже рисует страницы с большим трудом, про видео вообще молчу. Кто сталкивался с проблемой и как решал?
Тем временем C#, Kotlin, Typescript и другие ...
Monkey patching это анти-паттерн. В интернете можно найти подробные статьи почему его лучше не использовать.
Имею SSD диск ADATA. Ресурс 300 TBW, умер на 24 TBW. Просто перестал записывать данные. Вот она и предсказуемость.
Какие то очень странные утверждения и без единого примера. На картинках видно что квадратные фигурки не вписываются в более мелкие круглые, но где в этом практический смысл?
Я правильно понимаю что этой картинкой вы хотите сказать что если вам поставили задачу дополнить интерфейс вы будете дорабатывать вьюху? А что есть вариант не дорабатывать?
Добро пожаловать в асинхронный мир.
Простой пример почему это не так. Вы не можете запустить 64 битную программу на 32 битной системе. Там есть четкой деление что вы делаете и типы под эти задачи, 32 битные для 32 битных систем, 64 битные для 64 битных систем, и автотипы значение которых выбирается от платформы компиляции.
Вы допускаете ровно ту же ошибку что и царь из этой сказки. Пытаетесь делать валидацию средствами типизации.
В рантайме нету типизации. Она существует только на этапе написания кода, в некоторых языках еще в мете сборки для рефлексии.
Вы путаете типизацию с валидацией. Типизация должна заблокировать сборку при использовании типа short для 8 битного процессора. Потому что у железа просто нету 16 битного регистра. Валидация проверять удовлетворяет ли значение условию.