Is it good practice to structure a Vue app like this?

Question

Vue.js

I recently posted an application architecture question for ERP on a toaster. There was a heated discussion, but I did not see any specific solution.
But in the course of reflection came the following thought. I’ll make a reservation right away that it is most likely somewhat contrary to the component approach of Vue.
The point is to leave only presentational logic to vue. Transfer all business logic to separate controllers, thus creating the "core" of the application, which will process all the data, communicate with the server, and give ready-made data that will only need to be rendered. This (ideally) will allow you to abstract a little from the framework of a particular framework, in case the need arises to switch to another.
How good is this practice?

Answer 1

Good afternoon.
It's not entirely clear what you mean by controllers and business logic in this context. Vue itself doesn't talk to the server and its use case is purely rendering
related . What, in fact, is written in their official guide :
One of the concepts that can be called business logic in relation to vue (and any other spa) is probably the state of the application. You cannot separate the state from the view, because the reactive data display is based on it, without which, in fact, you will not have a spa, but a pumped templating engine working at the front. I can't even imagine doing something like this.
If your idea is only to move the data collection from the application state into a separate module with which the view will interact - well, this is your architectural decision, I guess.
In my opinion, the best solution is to use an additional view store plugin (vuex). In this module, you can store requests to the server, data processing logic, and so on. quirks related to business logic without reinventing the wheel.

Answer 2

Absolutely correct idea. The point is not even that you can abstract from the view template, but that this will make it possible to reuse controllers / services within the application, get rid of the need to use third-party state storage libraries, cache data through static methods and centrally process API requests.

Answer 3

For the kernel, this is too much logic. You need to divide the tasks that the application performs into parts. For example, in one application you work with data in the database, in another application you work with reports.
As they say in our Navy - Keep it simple.

Answer 4

Sounds like a good idea, but why? Do you have a management on github and press f5 every 5 minutes, waiting for a new release of some framework? The main frameworks seem to be quite stable, there are hundreds of libraries for them, a lot of documentation, well, there won’t be, for example, in view3 backwards compatibility, so what? It will not solve some super-specialized tasks that other frameworks / versions of the same framework cannot handle. Finish writing in view3, react 20 will come out, followed by angular 35. So why this race?

Answer 5

So after all, a very sound and mature idea from an architectural point of view. A framework for anything out there is just a minor implementation detail. The whole value of the system is its business rules, use cases and their purity of implementation. Indeed, when implementing a spa, it is important to make a border between the layer that works with business rules and the layer that simply draws the State, or the view model. As a result, each part will do its own thing, and as a bonus, it is easy to ab-test at least all front-frameworks at the same time.