Comprenons d'abord la différence entre une location unique et une location multilocation
Location unique:
Chaque client possède sa propre instance logicielle, sa propre base de données et ne sert qu'à un seul client. Ici, le logiciel peut être personnalisé pour répondre aux exigences spécifiques du client car il est indépendant.
Locations multiples:
Dans ce cas, une seule instance d’application logicielle sert plusieurs clients. Ici, nous appelons chaque client comme locataire. Ici, nous pouvons modifier les règles de l'interface utilisateur et les règles métier, mais nous ne pouvons pas modifier le code de l'application puisque la même architecture est partagée par plusieurs clients. C’est économique puisque les coûts de développement et de maintenance du logiciel sont partagés entre les clients. Mais les mises à jour ne peuvent être effectuées que par le fournisseur.

Avantages :
1. Un seul matériel qui gère plusieurs clients.
2. Réduction des coûts. Les coûts peuvent être partagés entre tous les clients.
3. Facilité d'entretien
4. La configuration peut être modifiée sans toucher à la base de code.
5. De nouveaux locataires peuvent être ajoutés facilement puisqu'il s'agit d'une architecture partagée.
Désavantages:
La personnalisation de la base de données sera difficile à gérer puisqu'il s'agit d'une base de données unique partagée entre plusieurs clients avec différents locataires.
Il existe milia, acts_as_tenant et apartment gem pour gérer la multi-location dans l'application Rails.
Appartement Gemme :
Ce joyau adopte une manière différente de gérer la multi-location. Cela fonctionne en créant une autre base de données pour chaque locataire. Pour PostgreSql, il crée un autre schéma pour chaque locataire. J'aime cette approche car, dans cette situation, l'information est vraiment désengagée. La base de données n'est pas partagée et si vous devez effacer les informations d'un client, tout ce que vous avez à faire est simplement de supprimer sa base de données (ou son modèle). Il prend également en charge les ascenseurs et permet le basculement automatique entre les locataires du client et automatise ainsi la logique de commutation.
Cette gem nous aide à gérer la multi-location dans une application Rails.
Ajoutez la ligne ci-dessous à votre fichier Gemfile et procédez à l'installation du bundle.
joyau 'appartement'
Pour générer le fichier d'initialisation de l'appartement, exécutez la commande ci-dessous :
bundle exec rails génère appartement: installer
config.exclusive_models = %w{ Locataire }
Ici, nous pouvons spécifier les locataires qui ont une portée globale, comme le modèle d'authentification qui est commun à tous les locataires.
Ici, je vais créer un client avec des sous-domaines, ainsi, chaque fois que le client se connecte à l'application, l'appartement récupère les sous-domaines et interroge la base de données en fonction du sous-domaine du locataire.
rails g scaffold Nom du client : chaîne domaine_tenant : chaîne
faire
base de données rails: migrer
Nous devons créer le locataire de l'appartement, une fois que nous avons créé le client.
Apartment::Tenant.create('tenant_name') - Pour créer un locataire
Utilisez le rappel after_create dans votre modèle pour créer des locataires.
def create_tenant Apartment::Tenant.create(tenant_domain) fin
Une fois le callback ci-dessus exécuté, toutes les migrations seront exécutées sous ce locataire respectif.
La commutation des sous-domaines sera gérée automatiquement lorsque nous demanderons l'application avec des sous-domaines. Ci-dessous se trouve la ligne de configuration pour changer les locataires en fonction du sous-domaine.
Rails.application.config.middleware.use 'Appartement :: Ascenseurs :: Sous-domaine'
Pour basculer entre les locataires
Appartement ::Tenant.switch !('tenant_name')
Toutes vos requêtes ActiveRecord seront acheminées vers le locataire spécifique lorsque le commutateur est sollicité.
Switch sera dans la portée racine lorsque vous l'appellerez sans arguments.
Même le changement de locataire peut être effectué sur la base du premier sous-domaine, mais nous devons définir la configuration dans le fichier d'initialisation. Nous pouvons même exclure certains sous-domaines ici, comme le sous-domaine normal.
config.middleware.use 'Appartement :: Ascenseurs :: FirstSubdomain'
Appartement :: Ascenseurs :: FirstSubdomain.exclusive_subdomains = ['www']
Nous pouvons également interdire aux utilisateurs de créer certains domaines tels que www, admin. Ces domaines ne seront pas disponibles pour les utilisateurs pendant qu'ils sont enregistrés.
Il faut décommenter la ligne de configuration ci-dessous dans le fichier d'initialisation de l'appartement.
Apartment::Elevators::Subdomain.exclusive_subdomains = ["public", "www" et "admin" ]
Nous pouvons également changer, en fonction de l'hôte complet. Ici, nous devons trouver le nom du locataire correspondant dans le hachage en utilisant la ligne de configuration suivante. Nous devons ajouter la ligne ci-dessous à votre application.rb
config.middleware.use 'Appartement :: Ascenseurs :: HostHash', {'example.com' => 'example_tenant'}
Supprimer les locataires :
La commande ci-dessous peut être utilisée pour supprimer des locataires :
Appartement ::Tenant.drop('tenant_name')
Veuillez consulter la ressource officielle de Gem pour trouver plus de documentation.