+1 vote
by
We need to make a kind of marketplace in laravel with mini sites for each store

The way I see it

2-two platforms on laravel

1- The main site, where all the information from the mini sites is uploaded
2- Platform for mini sites

For each mini site to use its own database, or rather its own prefix in the database
(Each site has its own categories, dynamic pages, products, settings, roughly speaking four tables (so far) in the database for each mini site) and its own .env file

It turns out that you need to implement a connection to different databases for the same project

How it works now:

In the `/bootstrap/app.php' file

Added code

if (isset($_SERVER['HTTP_HOST'])) {
$host = idn_to_utf8($_SERVER['HTTP_HOST'], 0, INTL_IDNA_VARIANT_UTS46);
$envFile = sprintf('site/%s', $host);
if ($host && file_exists(sprintf('%s/%s', $app['path.base'], $envFile))) {
$app->loadEnvironmentFrom($envFile);
}
}
When logging into any domain (linked to this project/server) look for a file with the name of the domain in the folder `site` (it stores settings for connecting to the database) and if available, load it instead of the default `.env` file Then in Routes we check if the database is connected or not В `routes/web.php`

try {
DB::connection()->getPdo();
if(DB::connection()->getDatabaseName()){
}
} catch (\Exception $e) {
abort(404);
}
And then in the same file get the settings for this site (Name, phone ...) and cache them
$domain = $_SERVER['HTTP_HOST'] ?? '';
$site = Cache::remember('setting_domain_'.$domain, 1440, function () {
$site = \App\Setting::get()->keyBy('name')->toArray();
return $site;
});
Enter the data into the `config` function
config(['siteName' => $site['site_name']['value']]);
In the template we get

{{Config::get('siteName')}}

All of this works and seems to fly fine with 10 sites

How will this solution behave with 1000+ sites?

Maybe someone has faced with a similar task and knows how to implement it correctly (with less workload)
by
2-two ... 4

What makes you write like that?

4 Answers

+1 vote
by
It will be fine. You have horizontal scaling, don't you?
Donor sites can be distributed across multiple nodes in a cluster.
by
Thank you, scaling is in the plans
by
nicolaa It must be inherent in the first place.
You can make it even simpler. Each donor, a complete application. Without any prefixes. In the manner of virtual hosting.
0 votes
by
The solution is very stupid and wrong.

It would be correct to use a single database with a normal structure. Tie everything you need (your "categories, dynamic pages, products, settings") to the "mini-site" and that's it.
by
Can you explain in a little more detail why you need to use the same database?

As far as it will be a correct solution if, for example, each sub-site has its own unique categories
1,000 pieces and a total of 1,000 sites, it turns out in the table with the categories will be 1,000,000 records and that's just categories (And then there are products and settings)
0 votes
by
Multitenancy.

It's now that you're only thinking about connecting another base. What about queues? File systems?

1) Leave the .env for the server settings
2) leave configs for configs, not for data storage
3) Remove logic permanently from roots!
4) there is a powerful package https://github.com/tenancy/tenancy/tree/master
by
The work of the queues was planned to perform on the first site, on the sub-sites in the settings of queues to make a connection to the database of the main site, record the task and process it on the main site (tasks from all sites to process on the main site)

Upload files on sub-sites to a separate server

2) leave configs for configs, not for data storage
3) Remove logic permanently from roots!

Can you be a little more specific about that, what's the risk?
0 votes
by
One base, one backend. No additional databases. Exchange with donors via api or parsing.
by
nicolaa How many records do you think are in the Facebook or VK database? This is Marketplace - big Data. Distributed databases.

And secondly, there should be a single category structure for the entire marketplace. And the supplier comes with its own goods, its own price list and its own category of goods, but the goods must be attached to the official structure of the marketplace. The vendor's category structure is its own hassle. The user does not have to see it. He types in, for example, "talking hamster" and he will get hamsters from all suppliers and they will be in the same product group.
by
Can you explain in a little more detail why you need to use the same database?

As far as it will be a correct solution if, for example, each sub-site has its own unique categories
1,000 pieces and a total of 1,000 sites, it turns out in the table with the categories will be 1,000,000 records and that's just categories (And then there are products and settings)
...