Why is my approach to web application architecture bad?

Question

PostgreSQL

In design and programming, I am guided by two principles: readability and simplicity, and I believe that the less code, the better. I'm trying to implement my application logic primarily in PostgreSQL (using views and, in a pinch, functions) and I want to generate validation rules on the Node.js server and client (in React.js) based on the constraints in my PostgreSQL database. Those. generate code during server startup where possible. Although many checks still have to be imperatively described on the Node.js server, at least for now.
Actually, hands have not yet reached the generation of validators, it is a matter of time, as well as two-way custom linking of changes in the UI and database tables. But the scheme on the basis of which it will be generatedalready exists, as well as an API for accessing database tables, with pagination and sorting.
The choice of Node.js is not accidental, since theoretically it is possible to write code on it that will work both on the client and on the server. I was surprised that there is still no suitable framework that would use the same models (the same files) both on the client and on the server. After I imagine how it is possible to make the UI binding to the server fully configurable and two-way dependent on the database, the task of making common models will not be so difficult, but vital. True, you will have to rewrite almost all the code so that it works with the methods of the models, and not with the query builder or the wrapper around the API.
If binding the UI to the data in the database takes a month or a maximum of two, then rewriting to use models takes several weeks.

Answer 1

The fact that your approach does not know the words flexibility, maintenance, and many others, he also does not know. Over the past couple of years, I worked on 3 projects, not a single project had only one database. The data was stored in 2-3 databases, pulled through api from third-party services, in general, the database was never put at the head of the table. Imagine the situation, here you are sawing a project for 2-3 years, and then the customer tells you that he needs to move to another database, or he needs to additionally pull data and process it from another storage, install a search engine. Are you duplicating all the logic? And then, in large projects, the database is usually the first bottleneck, by heaping more logic on the database, you make this place even narrower. Now the approach is not data first, and even more so not a database. Better look at the DDD approach,