How can Laravel's multi-to-Multi-link model be used in a distributed manner, such as using a user table on another server?

Recently I encountered a problem when working on an App background interface. Currently, the server where the article table is located is a separate node, and the user table is on another node server. Article Server article table Article Details table Article favorites link intermediate table user Server user performance... recently encountered a problem when working on an App background interface.
Currently, the server where the article table is located is a separate node, and the user table is on another node server.

Article Server

• Article table

• Document Details table

• Add link intermediate tables to favorites

User Server

• User table

The problem now is that the article Server accepts the user_id sent by the App client, and can only query by hand, and then combine the json response packet format to return the result. The laravel model is not easy to use.

Is there any way to use a model without a table?

Reply content:

Recently I encountered a problem when working on an App background interface.
Currently, the server where the article table is located is a separate node, and the user table is on another node server.

Article Server

• Article table

• Document Details table

• Add link intermediate tables to favorites

User Server

• User table

The problem now is that the article Server accepts the user_id sent by the App client, and can only query by hand, and then combine the json response packet format to return the result. The laravel model is not easy to use.

Is there any way to use a model without a table?

This is equivalent to a small distributed system. It is better to associate two servers in the form of interfaces or services.
There is no need to use many-to-many models. laravel's associated relational models cannot deal with these complex scenarios.
It cannot be considered that the model relationship is elegant. The decoupling and servitization between systems, and the interface is a more elegant implementation solution.

Another question is, if user_id is often used in your article table, why not add a redundant field of user_id in the article table?