Как спроектировать крупное приложение на vue?

Хочется получить ответ от разработчиков, кто делал крупные ентерпрайз приложения на vue.

Сегодня зашла дискуссия о том, что проектировать нужно в духе "микросервисов", где каждый отдельный модуль продукта - отдельное приложение на vue, но соединенный в один интерфейс с помощью проксирования nginx. Грубо говоря, имеем кучу сайтов в одном сайте.

То есть, для каждого модуля свои vuex, router, свои зависимости и прочее. Но, по мнению коллег, в случае выхода новых фреймворков, мы безболезненно перепишем один модуль за другим, если понадобится. Так ли это на самом деле, и оправданы ли затраты ресурсов ради этого?

Я выступил противником данного подхода. Он кажется тяжелым, сложным и никто так вроде бы не делает. Я лично такой практики не встречал. SPA фреймворк на то и SPA.

Собственно, за "классический" spa я и выступаю - да, на выходе мы получим огромный бандл из всех модулей, где каждого конкретному пользователя нужна лишь небольшая его часть (например, разные модули для разных отделов, где каждый пользуется своим функционалом, и он никак не пересекается с другим). Это является главным контраргументом моего подхода - то, что, вероятно, определенный код может попасть в нежелательные руки и вообще.

Хотелось бы обсудить этот кейс, и как лучше подойти к проектированию приложения.

Для большей наглядности, как пример, можно разобрать приложение CRM, где одним нужна только страница выгрузки отчетов, а вторым, скажем, аналитика продаж.
  • Вопрос задан
  • 2228 просмотров
Пригласить эксперта
Ответы на вопрос 4
bootd
@bootd
Гугли и ты откроешь врата знаний!
Хорошо бы знать, что у вас за проект и какие задачи он решает.
на выходе мы получим огромный бандл из всех модулей
- это почему же так?
А webpack для чего придумали? vue cli 3 вроде как из коробки вместе в webpack уже умеет всё разделять на модули, ну и вам самим никто не мешает сделать полностью модульную структуру так, как вам хочется, вручную настроив сборку проекта.

Для большей наглядности, как пример, можно разобрать приложение CRM, где одним нужна только страница выгрузки отчетов, а вторым, скажем, аналитика продаж.

Есть ещё nuxt.js в котором сделано ещё больше для модульности, там модули все загружаются тогда, когда они реально нужны. Т.е. у вас 10 страниц, у каждой своя логика, на пол мегабайта. При заходе на сайт, логика 10 страниц не будет загружена, а лишь тогда, когда вы зайдёте на страницу. Ну и опять же, никто не мешает и там добавить своих правил для webpack, если что-то не устроит. Следовательно, если определённому типу менеджеров нужна лишь определённая часть сайта, то зайдя на нужную ему страницу он загрузит логику этой страницы, но не десятка других.

А верстать всё это вы как собираетесь?
А раз это мини сайты в одном большом сайте, как вы собираетесь делать общие стили и компоненты?

То есть, для каждого модуля свои vuex, router
- ну а кто мешает вам на файлики разбить хранилище и роутер?

У vuex есть свойство modules - куда и импортируем модуль хранилища
У Router по сути тоже самое https://stackoverflow.com/questions/46590760/vue-j... вот статья для примера.

Ну и всё же, даже если всё вот так разделить, где целиком отдельные spa друг от друга, а как вы связывать их собираетесь 1 целое?
Типа написали плагин и что, теперь его во все 10 разных модулей подключать?
Типа, есть шапка, одна на весь сайт, создал компонент, что, тоже ходить и в каждый подключать?

Ну, так должно же быть у них что-то общее между собой, делающее всё это единым сервисом.
Как бы да, есть яндекс, который сумел создать единый UI для своих проектов, но и проекты у него никак не связаны между собой, а если и связаны, то не сайты друг с другом, а как бы общая база яндекса связана с проектами.
Как я понял, в вашем примере, модули - это яндекс музыка, карты, новости и т.п. Зачем всё это объединять в 1 проект? ИМХО Если я так понял, то нужно не просто отдельные модули делать, а отдельные сайты.

К сожалению, я слабо понимаю, что у вас там за ВАСЯ иентерпрайз, что бы в целом посидеть и подумать + я так и не услышал в вашем вопросе доводов архитектуры ваших коллег.
Ответ написан
@kttotto
все, что .NET
Мы делали крупные проекты с vue, но это не было полноценным spa и не микросервисная архитектура. У нас просто было несколько entry, которые мы использовали для разных разделов.

Мое мнение, если никто из вас раньше не имел дело с микросервисами, то с ходу не беритесь. Угрохаете кучу времени просто на один каркас и не факт, что все будет работать хорошо с точки зрения надежности и безопасности.

Я бы начал с монолита, но с расчетом на то, чтобы потом его с минимальными затратами можно было разбить на части. Во первых быстрее получите первую версию, во вторых со временем виднее будут видны границы модулей, легче будет понять, что именно можно или нужно выделить в микросервис, вы воочию увидите что и с чем общается. Чтобы при первом проектировании правильно эти границы определить, нужно иметь какой то опыт с микросервисами. Я так понял, что у вас его нет или он минимальный.

На мой взгляд, самый главный плюс микросервисов в том, что уменьшается стоимость ошибки решения по архитектуре (микросервиса), ибо его легче переписать, чем править и рефакторить. Ну и еще хорошо, что обновлять можно частями, не пересобирать сразу все при каждой выкладке. В монолите, чем дальше, тем сложнее то-то глобально изменить и очень важно на начальном этапе не ошибиться.

Безболезненно переписать модуль на vue проблем нет при любых раскладах. Только если не решите на ангуляр перейти, тут я сомневаюсь, что его можно точечно использовать в проекте. У нас как то был большой легаси проект, монолит, который был на jq, мы сначала решили добавить knockout, нам не понравилось, дальше продолжали на vue.
Ответ написан
@ofigenn
Я писал и так и эдак. Проблемы всегда есть, разные конечно. ИМХО, с микросервисами чуть проще, т.к. изоляция модулей и их взаимодействие продумывать обязательно надо. А так, крупное, значит по-любому тяжело поддерживать, из-за большого потока требований. Я бы начал с монолита, и если подвернется удобный модуль, вынес бы его в отдельный сервис.
Ответ написан
@grinat
Коллеги не понимают что переписать просто не выйдет. Ui kit и обвязку для работы с api как минимум для каждого фреймворка с нуля придется делать, собсно это обычно самое трудозатратное, а остальное в большинстве случаев тупо рутинная лепка системы из этих кирпичиков. Они просто думают, что другой фреймфорк это типа другая орм и роутер, а прочее плюс минус одинаковое и мол все что нужно будет сделать, это заменить вызовы в репозитори.

Микросервисы на фронте плохо работают в сложной системы, проблемы прозрачной склейки при переходе, проблемы включения кусков другого сервиса(аналитикам и пользователям пофиг что это другая система). Конкретно у вуе с монолитом другая проблема, когда он становится реально большим, то начинаются проблемы с hot-reload и сборкой, все это начинает занимать здоровенное количество времени, в рантайме просадок по производительности заметных нет.

Из своего опыта могу сказать что начинать надо с монолита, когда будет ясно что система из себя представляет, то можно начинать выносить ui-kit/абстракции для работы с api и т.п. вещи. Проблема включения левого кода решается с помощью обычных гитовских сабмодулей. То есть для заказчика 1, репо с сабмодулями 1/2, для заказчика 2, репо с сабмодулями 1/3, то ест разбитие есть только на уровне гита, а фактически это монолит. Да, там немало геммороя, но работать будет. Если поставляются собранные файлы, то все еще проще, можно во время сборки заменять файл роутера и стора, и попадет в итоговую сборку только то что требуется.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы