@bayareacoder That's exactly the multi tenant architecture. The good thing about RC is that the multi shop support is already done by just doing a couple of things. What I did to accomplish that was to use the shopId as the owner of the data. Meaning the shopId is the Tenant ID.
One of the biggest problems you probably will face is tenant identification. There are some strategies to do it.
In the admin you can identify the shop with the account that logs in into the app. There is a key in the Mongo Accounts collection that you can use to handle more than one shop per Account (adminUIShopIds). To do that you have to make some changes in the admin. Switching between shops in the admin can be accomplished by changing the shopId parameter in the URL. This approach is known as a URL-based identification and I think it fits very well in the admin. Also, keep in mind to grant the proper permissions to each account to handle multiple shops. But you can start handling one shop per account and see if that fits your needs.
So that way you have a single point of administration to all shops.
On the other hand to identify the storefronts you can use the hydra configuration. As you know, there are a couple of public queries in the API. That means that you don't need a token to fetch the data, so you can use the shopId to get the corresponding data to each shop. You can pass that data through environment variables.
But if you want to identify user on each storefront you have to send the shopId (Tenant Id) to the identity service and also create a record in hydra service that allows the storefront to create the login_challenge necessary to interact with the login service.
Before you deploy your storefront you have to add to the .env file those variables OAUTH_CLIENT_ID and OAUTH_CLIENT_SECRET. You have to do some changes to the identity service as well to create an account from the storefront in the corresponding shopId.
But the way, Hydra doesn't create users, just authorize third apps to connect with the login in order to generate access tokens. You don't want unknown apps trying to fetch sensitive data from your API directly.
Security is very serious in this multitenat approach.
If you want to automate the creation of shops, you can use vercel to create deployments depending on a provided configuration. That way you just focus your effort in maintain the API infrastructure and give the accountability to handle storefronts infrastructure to a third service. And another reason is that vercel is amazing and has a very well documented API :D
That's it, I think that's a good summary of all the things you need to implement multitenant architecture.
For us, the shopId is the owner of the data. We have a 1-1 relation between accounts and shops, but we support multiple shops per account using the adminUIShopIds. The shopId in the accounts collection indicates what tenant it belongs to. We manage permissions by granting the proper groups to each account when it's created.
Yes we are using a select component that allows us to administrate each shop that the account has assigned. For instance, if an account has, lets say four shops, the select component list each shop, and the user can select the shop and the admin fetch the corresponding data to that shop. It's very practical indeed, but for now, our use case for this functionality is for the primary shop that handles other shops. It's working very well at the moment.
You are right I'm not sure if that works in your case since you are not using Hydra. But your implementation sounds very tricky, so I can't help without having more specific details.
We use vercel to deploy shops. We created a plugin to integrate a vercel with RC. The problem with deploying storefronts in your infrastructure is that you are charged for resources that do not core for your business. At least that's how we see it in our case. So we just want to have the core services in our infrastructure and depending on each client we use logflare and sentry to monitor each storefront from vercel.
I hope that helps you.