Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
Использование нескольких фреймворков резко увеличит размер render-blocking resources. Также породит много дубликатов кода. Это сделает первоначальную загрузку сайта намного более долгой, что для современного проекта недопустимо.
www.scientiamobile.com/mobile-site-visitors-abandon-more-than-3-seconds
www.scientiamobile.com/mobile-site-visitors-abandon-more-than-3-seconds
Ни в коем случае мы не призываем использовать различные фреймворки в 1 проекте. Это бывает необходимо только в определенных сценариях. Но возможность быстро сменить фреймворк является плюсом. И этот фреймворк больше подходит для реализации админ панелей, там где не нужно использовать SSR. По поводу скорости первой загрузки, так как все модули динамически импортируются, клиент загружает только необходимый бандл.
Статья ведь о микросервисах во фронтенде. Микросервисы предполагают, что часть функционала дублируется в каждом сервисе, и при загрузке грузятся сразу несколько сервисов, пусть даже в одном бандле. Это делает проект тяжеловесным.
По моему опыту во фронтенде, любые дополнительные уровни абстракции никогда не являются полностью «плюсом». Это всегда компромисс. И чем больше этих абстракций, тем более этот компромис в сторону минуса, чем плюса. Как бы красиво что-то не выглядело с точки зрения архитектуры или креативных идей, во фронтенде они все в конечном счете проходят проверку вопросами производительности. В общем все, что выполняется у пользователя в браузере, должно быть с технической точки зрения как можно более простым — если вы хотите, чтобы он заходил на ваш сайт часто. А тяжеловесные абстракции и новейшие архитектурные идеи лучше оставить там, откуда они пришли и где хорошо работают — в бекенде.
По моему опыту во фронтенде, любые дополнительные уровни абстракции никогда не являются полностью «плюсом». Это всегда компромисс. И чем больше этих абстракций, тем более этот компромис в сторону минуса, чем плюса. Как бы красиво что-то не выглядело с точки зрения архитектуры или креативных идей, во фронтенде они все в конечном счете проходят проверку вопросами производительности. В общем все, что выполняется у пользователя в браузере, должно быть с технической точки зрения как можно более простым — если вы хотите, чтобы он заходил на ваш сайт часто. А тяжеловесные абстракции и новейшие архитектурные идеи лучше оставить там, откуда они пришли и где хорошо работают — в бекенде.
Если вам нужно что-то простое и быстрое, нет ничего быстрее статики и этот подход часто оправдан, особенно для лендингов. Но для сложных веб приложений нужно хорошо продумывать архитектуру. Это делается для того, чтобы ваше приложение можно было легко масштабировать, легко добавлять новый функционал, проверять бизнес теории. Иначе, это все может превратиться в ад из кода, и каждый новый разработчик первым делом будет предлагать все переписать. Чтобы избежать дублирование кода, можно вынести свои ui компоненты (инпуты таблицы модальные окна ...) в отдельную библиотеку.
интересно что скажет бизнес, когда Вы придете и скажите, вот для того чтоб мы избавиться от вендор лока, нам нужна универсальная UI либа, и для этого нам нужно n-ое количество человека часов. Я бы с попкорном понаблюдал за этим)
Когда пишуться приложения, обычно происхоидт так, а давайте что нибудь сделаем посмотрим что будет, сделали, посмотрели. Что дальше?
Бизнес: Надо добавить фичу
Программист: Надо сделать рефаткоринг
Бизнес: Фича важнее.
и так по кругу.
Когда пишуться приложения, обычно происхоидт так, а давайте что нибудь сделаем посмотрим что будет, сделали, посмотрели. Что дальше?
Бизнес: Надо добавить фичу
Программист: Надо сделать рефаткоринг
Бизнес: Фича важнее.
и так по кругу.
вот для этого случая я и создал этот фреймворк. Готовых ui либ много, под любой фреймворк.
Бизнес говорит давайте быстро что-то сделаем — вы ему быстро пишете новый модуль. И вам не нужно думать о том, что вы сейчас испортите все приложение, новый модуль гораздо проще рефачить чем все приложение. Если бизнесу идея не зашла этот модуль можно легко удалить, и не нужно думать что что-то может поломаться.
Бизнес говорит давайте быстро что-то сделаем — вы ему быстро пишете новый модуль. И вам не нужно думать о том, что вы сейчас испортите все приложение, новый модуль гораздо проще рефачить чем все приложение. Если бизнесу идея не зашла этот модуль можно легко удалить, и не нужно думать что что-то может поломаться.
готовых Ui либ много, но чтоб они были одинаковые для всех фреймворков я пока знаю только один. А нужно чтоб не только выглядели одинаково компоненты, но нужно чтоб еще чтоб поведение было одинаковое. Я ниже написал, микрофрнтенд это скорей процесс, чем разработка. И этот процесс нужно будет воткнуть в текущую инфраструктуру. Начиная работы с репозиторием, версионирования модулей, инркементальный деплой, процесс сборки. Я все думаю описать все то, с чем я столкнулся и как это решал.
Еще раз мы не призываем использовать разные фреймворки и городить зоопарк технологий. Но бывают сценарии когда это необходимо, но это компромисс, и на моей практик такие компромиссы были. Бывает когда хочется перейти на другой фреймворк, или попробовать новый фремворк, так как в мире js они часто появляются. Это можно легко сделать, не переписывать все с 0, а только для новых задач использовать новые инструменты, и со временем переписать старые модули на новые технологии. А если новые технологии не понравились, можно легко от них избавиться.
> Если вам нужно что-то простое и быстрое,
Нет, я имел в виду вообще любые веб-проекты. Любой проект, как бы он сложно не выглядел, во фронтенде он должен быть как можно более производительным, а значит как можно более простым.
> Это делается для того, чтобы ваше приложение можно было легко масштабировать, легко добавлять новый функционал, проверять бизнес теории
Когда на первом месте стоит пользователь этого приложения, а не модные идеи/удобная работа в команде/повышенная легкость масштабирования/принесенный опыт архитектур из java/желание вписать в резюме новый стек и так далее, то идея использовать микросервисы во фронтенде просто не возникнет.
> Чтобы избежать дублирование кода, можно вынести свои ui компоненты (инпуты таблицы модальные окна ...) в отдельную библиотеку.
Во фронтенде каждый микросервис будет иметь свои зависимости, у каждой зависимости будет своя версия и так далее. Если выносить общие зависимости в отдельную библиотеку, то каждая команда должна будет постоянно это обсуждать — например, перед апдейтом какого-то плагина из общей библиотеки с версии 1.0.17 до 1.0.18, и соотвественно вносить изменения в каждый из своих сервисов. Это нивелирует идею микросервисов (параллельная разработка и уменьшение зависимостей между командами), и в итоге только добавляет излишнюю сложность.
Нет, я имел в виду вообще любые веб-проекты. Любой проект, как бы он сложно не выглядел, во фронтенде он должен быть как можно более производительным, а значит как можно более простым.
> Это делается для того, чтобы ваше приложение можно было легко масштабировать, легко добавлять новый функционал, проверять бизнес теории
Когда на первом месте стоит пользователь этого приложения, а не модные идеи/удобная работа в команде/повышенная легкость масштабирования/принесенный опыт архитектур из java/желание вписать в резюме новый стек и так далее, то идея использовать микросервисы во фронтенде просто не возникнет.
> Чтобы избежать дублирование кода, можно вынести свои ui компоненты (инпуты таблицы модальные окна ...) в отдельную библиотеку.
Во фронтенде каждый микросервис будет иметь свои зависимости, у каждой зависимости будет своя версия и так далее. Если выносить общие зависимости в отдельную библиотеку, то каждая команда должна будет постоянно это обсуждать — например, перед апдейтом какого-то плагина из общей библиотеки с версии 1.0.17 до 1.0.18, и соотвественно вносить изменения в каждый из своих сервисов. Это нивелирует идею микросервисов (параллельная разработка и уменьшение зависимостей между командами), и в итоге только добавляет излишнюю сложность.
> Производительность зависит не от данного фреймворка, а от реализации определенных модулей и компонентов. Данный фремворк не работает с DOM деревом. Он просто создает и уничтожает модули.
>Еще раз — каждый модуль собирается в отдельный бандл и подгружается только тогда когда пользователь этот модуль использует.
> Если вам нужно поменять версию библиотеки, в любом случае вам нужно рефачить весь проект. Какой бы вы подход не использовали.
>Еще раз — каждый модуль собирается в отдельный бандл и подгружается только тогда когда пользователь этот модуль использует.
> Если вам нужно поменять версию библиотеки, в любом случае вам нужно рефачить весь проект. Какой бы вы подход не использовали.
Производительность зависит не от данного фреймворка
Производительность зависит не от вашего фреймворка, а от самого решения использовать микросервисы, так как это всегда новые абстракции + дублированный код
Данный фремворк не работает с DOM деревом
Подлючаемые модули будут работать с дом-деревом. Но даже это не столь важно. Ресурсы, блокирующие рендеринг, не обязательно работают с DOM-деревом.
Еще раз — каждый модуль собирается в отдельный бандл и подгружается только тогда когда пользователь этот модуль использует.
Еще раз — в каждом модуле будет дублированный код, это неизбежно при использовании микросервисов
Если вам нужно поменять версию библиотеки, в любом случае вам нужно рефачить весь проект
Посмотрите на свою папку node_modules, загляните в файл package-lock. Каждый плагин имеет версию. Есть громадное количество причин, почему нужно сделать апгрейд того или иного плагина. Часто это происходит автоматически, в зависимости от проекта. Ну и если это будет общая библиотека для всех микросервисов, то внесение любого нового плагина / неизбежные изменения в существующих все равно нужно будет согласовывать с каждым сервисом в отдельности.
> Еще раз) Производительность зависит от реализации модуля и от фремворка (Vue React ...) Данный фрйемврок заменяем вам роутер. И отвечает за создание и уничтожения модуля.
> Проблема версий никуда не уйдет. Если вы используете 1 версию и решили ее поменять при любом подходе нужно эту проблему решать во всем приложении.
> Дублирование кода — это уже как вы решите. Если вы делаете полностью независимый модуль, который можно переиспользовать в другом проекте, тогда лучше сделать его максимально изолированный (даже со своими внутренними ui компонентами) зато потом вы его легко вставите в любой проект, подключите к api и все заведется. Если это не требуется, то можно использовать либо готовую либо написать свою ui библиотеку. И дублирование кода у вас сведется к минимуму или к 0. На моей практике дублирование кода не было. Каждый модуль отвечает за сваю бизнес логику, и даже работает с разными микросервисами на бэке.
> Проблема версий никуда не уйдет. Если вы используете 1 версию и решили ее поменять при любом подходе нужно эту проблему решать во всем приложении.
> Дублирование кода — это уже как вы решите. Если вы делаете полностью независимый модуль, который можно переиспользовать в другом проекте, тогда лучше сделать его максимально изолированный (даже со своими внутренними ui компонентами) зато потом вы его легко вставите в любой проект, подключите к api и все заведется. Если это не требуется, то можно использовать либо готовую либо написать свою ui библиотеку. И дублирование кода у вас сведется к минимуму или к 0. На моей практике дублирование кода не было. Каждый модуль отвечает за сваю бизнес логику, и даже работает с разными микросервисами на бэке.
Проблема версий никуда не уйдет
Я не говорил, что проблема версий уйдет, если не использовать микросервисы — я говорил, что эту проблему придется решать для каждого сервиса отдельно. Это создает дополнительную сложность и нивелирует плюсы микросервисов как параллельной разработки.
Дублирование кода — это уже как вы решите
В который раз говорю, это не так. Микросервисы как подход очень способствуют дублированию кода. Это неизбежно. Идея не нова (https://micro-frontends.org/), и то, что это добавляет абстракций и дубликатов, предполагается прямо в самом подходе микросервисов.
то то я думал что все сервисы которыми я пользуюсь грузятся по несколько минут)
Я пришел к тому что на данный момент, продуктовые проекты, уже давно на скорость рендеринга забили. Главное чтоб красиво было)
Я пришел к тому что на данный момент, продуктовые проекты, уже давно на скорость рендеринга забили. Главное чтоб красиво было)
Значит это плохие сервисы, программисты не думали над архитектурой, и как в каких случаях доставлять контент пользователю.
я вас умоляю))) не всегда программист может сделать хорошо, даже если очень хочет. если руководство, мягко сказать, другого взгляда) Классика ведь, ты говоришь нужно сделать вот так, а тебе, давай сделаем тут костыль, тк нужно показать красивые графики релизов. Руководству важно, что бы была красивая картинка. А как там работает, ведь у руководства крутой мак.
Ну так тогда может и не нужно париться по поводу производительности)) если руководству и так норм) Мы же разрабатываем продукт не для себя, а для конкретных пользователей) если пользователи руководство, а у них крутые маки, можно сделать максимально просто и не думать об производительности )
так в том говне разбираться нам) и когда собираешь проект, и получаеться ~50 метров билд в зипе, становиться грустно, а сделать то не чего не можешь)
Для этого и можно использовать наш фреймворк. Новая хотелка — новый модуль. Каждый модуль собирается в отдельный бандл. Понравилась бизнес идея, быстро переработали модуль, сделали максимально все круто, не понравилась — просто удалили.
я не сколько не против микрофронта, а даже за, я к тому что в реальности достаточно сложно продвинуть. я сам сейчас именно этой задачей и занимаюсь, но тут скорей повезло с руководством. Проблема микрофрнтенда, это то что нет каких то бестпрактикс, нет готовый решений, тк микрофрнтенд, это скорей процесс, чем разработка. И вот тут начинаются проблемы, которые вот сейчас их решаю.
А почему $$rout, а не $$route?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Микросервисы во фронтенде