How to design a large vue application?

Question

Software design

I would like to get an answer from the developers who made large enterprise applications on vue.
Today there was a discussion about what needs to be designed in the spirit of "microservices", where each individual product module is a separate vue application, but connected into one interface using nginx proxying. Roughly speaking, we have a bunch of sites in one site.
That is, each module has its own vuex, router, dependencies, and so on. But, according to colleagues, if new frameworks are released, we will painlessly rewrite one module after another, if necessary. Is this really so, and are the expenditures of resources justified for this?
I opposed this approach. It seems heavy, complicated, and no one seems to do that. I personally have not seen this practice. SPA framework for that and SPA.
Actually, I stand for the "classic" spa - yes, at the output we will get a huge bundle of all modules, where each specific user needs only a small part of it (for example, different modules for different departments, where everyone uses their own functionality, and he does not does not overlap). This is the main counter-argument of my approach - that it is likely that certain code can fall into unwanted hands and in general.
I would like to discuss this case, and how best to approach the design of the application.
For greater clarity, as an example, you can disassemble the CRM application, where one needs only a report upload page, and the second, say, sales analytics.

Answer 1

We did large projects with vue, but it was not a full-fledged spa and not a microservice architecture. We just had multiple entries that we used for different sections.
My opinion, if none of you have dealt with microservices before, then don’t take it on the go. Threaten a lot of time just for one frame and not the fact that everything will work well in terms of reliability and safety.
I would start with a monolith, but with the expectation that later it could be broken into parts at minimal cost. Firstly, get the first version faster, secondly, over time, the boundaries of the modules will be more visible, it will be easier to understand what exactly can or should be allocated to the microservice, you will see with your own eyes what and what it communicates with. In order to correctly define these boundaries during the first design, you need to have some experience with microservices. I understand that you do not have it or it is minimal.
In my opinion, the most important plus of microservices is that the cost of an error in an architecture decision (microservice) is reduced, because it is easier to rewrite it than to edit and refactor. Well, it’s also good that you can update in parts, not to rebuild everything at once with each calculation. In a monolith, the further, the more difficult it is to change something globally and it is very important not to make a mistake at the initial stage.
Painlessly rewriting the module to vue is no problem in any case. Only if you don’t decide to switch to Angular, then I doubt that it can be used pointwise in the project. We once had a big legacy project, a monolith that was on jq, we first decided to add knockout, we didn’t like it, then continued on vue.

Answer 2

It would be nice to know what kind of project you have and what tasks it solves.

at the output we will get a huge bundle of all modules

- why is that so?
What was webpack for? vue cli 3 seems to be able to divide everything into modules out of the box together with webpack, and no one bothers you to make a fully modular structure the way you want by manually setting up the project build.
There is also nuxt.js, which has done even more for modularity, where modules are all loaded when they are really needed. Those. you have 10 pages, each with its own logic, half a megabyte. When you visit the site, the logic of 10 pages will not be loaded, but only when you enter the page. Well, again, no one bothers to add your own rules for webpack there, if something doesn’t suit you. Therefore, if a certain type of manager needs only a certain part of the site, then by going to the page he needs, he will load the logic of this page, but not a dozen others.
And how are you going to arrange all this?
And since these are mini sites in one big site, how are you going to make common styles and components?

That is, each module has its own vuex, router

- Well, who's stopping you from splitting the storage and the router into files?
Vuex has a modules property - where we import the storage module
. Router is essentially the same https://stackoverflow.com/questions/46590760/vue-j... here is an example article.
And yet, even if everything is divided like this, where are completely separate spas from each other, but how are you going to connect them as one whole?
Like they wrote a plugin and what, now connect it to all 10 different modules?
Like, there is a header, one for the entire site, created a component, what, also go and connect to each one?
Well, they must have something in common with each other, making it all a single service.
No matter how yes, there is Yandex, which managed to create a single UI for its projects, but its projects are not related to each other in any way, and if they are connected, then it’s not sites with each other, but, as it were, a common Yandex database is connected with projects.
As I understand it, in your example, the modules are Yandex music, maps, news, etc. Why combine all this into one project? IMHO If I understand that, then you need to do not just separate modules, but separate sites.
Unfortunately, I poorly understand what you have there for VASYA Enterprise, in order to sit and think in general + I never heard the arguments of your colleagues' architecture in your question.

Answer 3

I wrote this way and that. There are always problems, different of course. IMHO, microservices are a little easier, because isolation of modules and their interaction must be thought through. And so, large means it’s hard to maintain in any way, due to the large flow of requirements. I would start with a monolith, and if a convenient module comes up, I would take it out into a separate service.

Answer 4

Colleagues do not understand that rewriting simply will not work. You will have to do a ui kit and a binding for working with api at least for each framework from scratch, but this is usually the most labor-intensive, and the rest is in most cases a stupidly routine modeling of a system from these bricks. They just think that a different framework is like a different orm and a router, and the rest is plus or minus the same, and they say all that needs to be done is to replace the calls in the repository.
Microservices at the front do not work well in a complex system, problems of transparent gluing during the transition, problems of including pieces of another service (analysts and users do not care that this is a different system). Specifically, vue with a monolith has another problem, when it becomes really large, then problems with hot-reload and assembly begin, all this starts to take a hefty amount of time, there are no noticeable performance drops in runtime.
From my own experience, I can say that you need to start with a monolith, when it is clear what the system is like, then you can start to take out ui-kit / abstractions for working with api, etc. things. The problem of including the left code is solved with the help of ordinary Git submodules. That is, for customer 1, repo with 1/2 submodules, for customer 2, repo with 1/3 submodules, that is, there is a split only at the git level, but in fact it is a monolith. Yes, there is a lot of hemorrhoids, but it will work. If the assembled files are supplied, then everything is even simpler, you can replace the router and store file during the assembly, and only what is required will get into the final assembly.