LINUX.ORG.RU

Грамотная архитектура фронта на vue

 ,


0

2

Встала задача переписать достаточно крупный легаси проект, работающий сейчас на angular 1.4.9 и sails (порядка 170к строк в сумме, в базе сотни тысяч записей).

Проект - админка компании, которая производит gps устройства. Каждый модуль призван автоматизировать работу разных отделов, будь то бухгалтерия, логистика, техподдержка и т.д.

В качестве фреймворка на фронт выбран Vue ввиду того, что есть достаточный опыт и несколько предвзятая симпатия.

Сейчас остро стоит вопрос архитектуры. Я выступаю за монолит, но я крупных приложений пока и не разрабатывал.

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

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

-Есть внутренняя бизнес-логика, а есть модули, которыми пользуются сторонние компании. Любая утечка кода не в те руки, может обернуться крахом для компании. Доступ к этим модулям будет по правам, но на выходе ведь в любом случае имеется один собранный js файл. Из этого так же вытекает проблема подгрузки большого количества ненужного кода клиентом, которому доступен только один модуль.

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

Из решений, на которые упал глаз это Nuxt и single-spa, но эти же решения, в свою очередь, являются утяжелением и усложнением проекта, на мой взгляд.

Сразу оговорюсь, что опыта разработки у меня едва ли будет год. Почти весь этот год я работал над этим же легаси и знаю всю кухню изнутри. Сейчас подвернулась такая замечательная возможность, которой я бы хотел воспользоваться, и хочется сделать всё как можно ближе к идеалу.

В случае архитектурных ошибок или выходов новых технологий, будет проще переписать каждый модуль по отдельности

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

Ford_Focus ★★★★★ ()
Ответ на: комментарий от Ford_Focus

Тем временем некоторые из моих 1с поделок уже второй десяток починают, и кода там знакомого уже между строк только увидеть. А вот успешных переписываний не видать*. Возможно зависит от того, сколько техдебта вносит программист в погоне за мам смотри как я могу вместо нормального процедурного кода.

Впрочем веб-костыли столько не живут, возможно к ним это и не применимо. По сабжу предлагаю подумать не о форме, а о содержании в первую очередь. Собрать в кучу проблемы, выкинуть 90% как не mission critical, для остальных понять решение и решить на имеющемся ангуляре, не тратя бюджетов на uiту для резюме.

* когда вспоминаю, сколько решений и проб/ошибок пришлось пройти для написания этого всего, и кто-то потом говорит «а давайте быстренько перепишем на Х», это уже ни смеха, ни слез не вызывает.

anonymous ()
Ответ на: комментарий от no-such-file

Сейчас миграция с версии на версию не вызывает каких-то диких проблем. Запустил скрипт миграции и поехало, ну может пару/тройку багов придётся поправить.

serioja ()

Parcel посмотри, почитай документацию, что вы так на Webpack все зависли? Есть же ещё Rollup, там легко несколько бандлов создаётся, один - для ядра, и остальные для фич, фичи грузятся по правам (бекендом теги script подключаются/рендерятся в зависимости от роли пользователя), и после подгрузки через vue-router + vuex прекрасно всё работает.

menangen ★★★★★ ()
Ответ на: комментарий от menangen

там легко несколько бандлов создаётся

Оно же требует загрузчик. Пол года назад попробовал подключить через System.js, ничего не понял. Документации по нему не было совсем. Сейчас иначе?

spoonbob ()
Последнее исправление: spoonbob (всего исправлений: 1)
Ответ на: комментарий от menangen

У тебя в комментарии был озвучен сплиттинг через Rollup. Parcel какой смысл рассматривать, если они с вебпаком одной жирноты — шило на мыло

spoonbob ()
Последнее исправление: spoonbob (всего исправлений: 1)
Ответ на: комментарий от menangen

В rollup сплитинг по-прежнему эксперементальный. Не все хотелки учтены, а те, что учтены в некоторых комбинациях выдают ошибку. Плюс чанки загружаются через System.js, который не самый дружелюбный инструмент

spoonbob ()
Ответ на: комментарий от spoonbob

Я Rollup ручками настраивал, vue и прочий vendor в жирный entry, остальные entry собираются отдельно как AMD, к примеру. И подгружаются также руками (кодом) на странице, если ты не хочешь жирноты - всё ручками, и всё самописное. Но я выбрал parcel, не понял что там жирное, это тебе не webpack, не надо.

menangen ★★★★★ ()