Микросервисы во фронте — это просто архитектурный подход к разработке. Как и любой подход он имеет свои плюсы и минусы. Скорость приложения скорее зависит от кода, который может быть не оптимизированный, а не от архитектурного подхода. С дублированием кода есть проблема, но она не критичная, и во многих случаях эту проблему можно решить.
НО есть много плюсов:
— например для различных устройств вы можете отдавать различные микросервисы чтобы ваш микросервис работал максимально производительно и максимально удобно для данного устройства.
— можете легко сменить фреймворк
— программист погружается в работу только конкретного микросервиса
и много других плюсов.
> Объем работы по писку и замене уязвимых мест зависит не от подхода (микросервис, монолит), а от количества кода и тех мест где используется старая библиотека.
> То что в микросеврисах есть дублирование кода — это понятно, но в данном случае это можно решить и минимизировать эту проблему.
> Еще раз) Производительность зависит от реализации модуля и от фремворка (Vue React ...) Данный фрйемврок заменяем вам роутер. И отвечает за создание и уничтожения модуля.
> Проблема версий никуда не уйдет. Если вы используете 1 версию и решили ее поменять при любом подходе нужно эту проблему решать во всем приложении.
> Дублирование кода — это уже как вы решите. Если вы делаете полностью независимый модуль, который можно переиспользовать в другом проекте, тогда лучше сделать его максимально изолированный (даже со своими внутренними ui компонентами) зато потом вы его легко вставите в любой проект, подключите к api и все заведется. Если это не требуется, то можно использовать либо готовую либо написать свою ui библиотеку. И дублирование кода у вас сведется к минимуму или к 0. На моей практике дублирование кода не было. Каждый модуль отвечает за сваю бизнес логику, и даже работает с разными микросервисами на бэке.
Еще раз мы не призываем использовать разные фреймворки и городить зоопарк технологий. Но бывают сценарии когда это необходимо, но это компромисс, и на моей практик такие компромиссы были. Бывает когда хочется перейти на другой фреймворк, или попробовать новый фремворк, так как в мире js они часто появляются. Это можно легко сделать, не переписывать все с 0, а только для новых задач использовать новые инструменты, и со временем переписать старые модули на новые технологии. А если новые технологии не понравились, можно легко от них избавиться.
> Производительность зависит не от данного фреймворка, а от реализации определенных модулей и компонентов. Данный фремворк не работает с DOM деревом. Он просто создает и уничтожает модули.
>Еще раз — каждый модуль собирается в отдельный бандл и подгружается только тогда когда пользователь этот модуль использует.
> Если вам нужно поменять версию библиотеки, в любом случае вам нужно рефачить весь проект. Какой бы вы подход не использовали.
Для этого и можно использовать наш фреймворк. Новая хотелка — новый модуль. Каждый модуль собирается в отдельный бандл. Понравилась бизнес идея, быстро переработали модуль, сделали максимально все круто, не понравилась — просто удалили.
вот для этого случая я и создал этот фреймворк. Готовых ui либ много, под любой фреймворк.
Бизнес говорит давайте быстро что-то сделаем — вы ему быстро пишете новый модуль. И вам не нужно думать о том, что вы сейчас испортите все приложение, новый модуль гораздо проще рефачить чем все приложение. Если бизнесу идея не зашла этот модуль можно легко удалить, и не нужно думать что что-то может поломаться.
Ну так тогда может и не нужно париться по поводу производительности)) если руководству и так норм) Мы же разрабатываем продукт не для себя, а для конкретных пользователей) если пользователи руководство, а у них крутые маки, можно сделать максимально просто и не думать об производительности )
Если вам нужно что-то простое и быстрое, нет ничего быстрее статики и этот подход часто оправдан, особенно для лендингов. Но для сложных веб приложений нужно хорошо продумывать архитектуру. Это делается для того, чтобы ваше приложение можно было легко масштабировать, легко добавлять новый функционал, проверять бизнес теории. Иначе, это все может превратиться в ад из кода, и каждый новый разработчик первым делом будет предлагать все переписать. Чтобы избежать дублирование кода, можно вынести свои ui компоненты (инпуты таблицы модальные окна ...) в отдельную библиотеку.
Ни в коем случае мы не призываем использовать различные фреймворки в 1 проекте. Это бывает необходимо только в определенных сценариях. Но возможность быстро сменить фреймворк является плюсом. И этот фреймворк больше подходит для реализации админ панелей, там где не нужно использовать SSR. По поводу скорости первой загрузки, так как все модули динамически импортируются, клиент загружает только необходимый бандл.
НО есть много плюсов:
— например для различных устройств вы можете отдавать различные микросервисы чтобы ваш микросервис работал максимально производительно и максимально удобно для данного устройства.
— можете легко сменить фреймворк
— программист погружается в работу только конкретного микросервиса
и много других плюсов.
Да это исправим )
> То что в микросеврисах есть дублирование кода — это понятно, но в данном случае это можно решить и минимизировать эту проблему.
> Проблема версий никуда не уйдет. Если вы используете 1 версию и решили ее поменять при любом подходе нужно эту проблему решать во всем приложении.
> Дублирование кода — это уже как вы решите. Если вы делаете полностью независимый модуль, который можно переиспользовать в другом проекте, тогда лучше сделать его максимально изолированный (даже со своими внутренними ui компонентами) зато потом вы его легко вставите в любой проект, подключите к api и все заведется. Если это не требуется, то можно использовать либо готовую либо написать свою ui библиотеку. И дублирование кода у вас сведется к минимуму или к 0. На моей практике дублирование кода не было. Каждый модуль отвечает за сваю бизнес логику, и даже работает с разными микросервисами на бэке.
>Еще раз — каждый модуль собирается в отдельный бандл и подгружается только тогда когда пользователь этот модуль использует.
> Если вам нужно поменять версию библиотеки, в любом случае вам нужно рефачить весь проект. Какой бы вы подход не использовали.
Бизнес говорит давайте быстро что-то сделаем — вы ему быстро пишете новый модуль. И вам не нужно думать о том, что вы сейчас испортите все приложение, новый модуль гораздо проще рефачить чем все приложение. Если бизнесу идея не зашла этот модуль можно легко удалить, и не нужно думать что что-то может поломаться.