Sélectionner une page


Dans ce didacticiel, nous rendons votre application Laravel multi-locataire Location pour forfait Laravel.

Il s’agit d’un package mutualisé qui vous permet d’activer n’importe quel locataire d’application Laravel sans avoir à réécrire le code. C’est aussi plug and play que les forfaits de location.

Remarque latérale: ce didacticiel explique les paramètres les plus courants – l’hébergement multiclient de plusieurs bases de données dans plusieurs domaines. Si vous avez besoin d’une configuration différente, c’est possible à 100%. Regardez simplement les documents dans le paquet.

Comment ça fonctionne

Ce package est unique en ce qu’il ne vous oblige pas à écrire votre application d’une manière particulière. Vous pouvez écrire votre application comme vous en avez l’habitude et elle deviendra automatiquement mutualisée en arrière-plan. Vous pouvez même intégrer le package dans une application existante.

Voilà comment cela fonctionne:

  1. Une demande arrive
  2. Le package reconnaît le locataire en fonction de la demande (en utilisant le domaine, le sous-domaine, le chemin, l’en-tête, la chaîne de requête, etc.).
  3. Le package modifie le défaut Connexion à la base de données pour connecter le client
  4. Tous les appels de base de données, appels de cache, travaux dans la file d’attente, etc. sont automatiquement transférés au locataire actuel.

installation

Nous avons d’abord besoin du package avec composer:

composer require stancl/tenancy

Ensuite, nous les exécutons tenancy:install Commander:

php artisan tenancy:install

Cela créera certains fichiers: migrations, fichier de configuration, fichier d’itinéraire et un fournisseur de services.

Faisons les migrations:

php artisan migrate

Enregistrez le fournisseur de services dans config/app.php. Assurez-vous qu’il est dans la même position que dans l’extrait de code suivant:

/*
 * Application Service Providers...
 */
AppProvidersAppServiceProvider::class,
AppProvidersAuthServiceProvider::class,
// AppProvidersBroadcastServiceProvider::class,
AppProvidersEventServiceProvider::class,
AppProvidersRouteServiceProvider::class,
AppProvidersTenancyServiceProvider::class, // <-- here

Créons maintenant un modèle de client personnalisé. Le paquet n’a pas d’avis. Pour utiliser des bases de données et des domaines distincts, nous devons créer un modèle de locataire légèrement personnalisé. A … créer app/Tenant.php Fichier avec ce code:

<?php

namespace App;

use StanclTenancyDatabaseModelsTenant as BaseTenant;
use StanclTenancyContractsTenantWithDatabase;
use StanclTenancyDatabaseConcernsHasDatabase;
use StanclTenancyDatabaseConcernsHasDomains;

class Tenant extends BaseTenant implements TenantWithDatabase
{
    use HasDatabase, HasDomains;
}

Et maintenant, nous demandons au package d’utiliser ce modèle pour les locataires:

// config/tenancy.php file

'tenant_model' => AppTenant::class,

Les deux parties

Le package considère votre application comme deux parties distinctes:

  • l’application centrale – qui héberge la page de destination, éventuellement un tableau de bord central pour gérer les locataires, etc.
  • l’application locataire – c’est la partie que vos utilisateurs (locataires) utilisent. C’est là que la plupart de la logique métier vivra probablement

Déconnecter les applications

Maintenant que nous comprenons les deux parties, séparons notre application en conséquence.

Appli centrale

Tout d’abord, assurons-nous que l’application centrale n’est accessible que dans les domaines centraux.

Aller à app/Providers/RouteServiceProvider.php et assurez-vous que votre web et api Les itinéraires ne sont chargés que dans les domaines centraux:

protected function mapWebRoutes()
{
    foreach ($this->centralDomains() as $domain) {
        Route::middleware('web')
            ->domain($domain)
            ->namespace($this->namespace)
            ->group(base_path('routes/web.php'));
    }
}

protected function mapApiRoutes()
{
    foreach ($this->centralDomains() as $domain) {
        Route::prefix('api')
            ->domain($domain)
            ->middleware('api')
            ->namespace($this->namespace)
            ->group(base_path('routes/api.php'));
    }
}

protected function centralDomains(): array
{
    return config('tenancy.central_domains');
}

Maintenant va à la vôtre config/tenancy.php Classez et ajoutez réellement les domaines centraux.

J’utilise un valet, donc pour moi c’est le domaine central saas.test et les domaines de locataires sont par exemple foo.saas.test et bar.saas.test.

Alors arrêtons ça central_domains Clé:

'central_domains' => [
    'saas.test', // Add the ones that you use. I use this one with Laravel Valet.
],

Application locataire

Passons maintenant à la partie amusante. Cette partie est presque trop facile.

Pour informer certains locataires de code de cela, il vous suffit de:

  • Déplacez les migrations vers le tenant/ annuaire
  • Déplacer les itinéraires vers tenant.php Fichier de route

C’est ça.

Les migrations dans ce dossier particulier indiquent au package d’effectuer ces migrations lors de la création d’un client. Si des itinéraires sont inclus dans ce fichier d’itinéraire particulier, le paquet est invité à identifier les locataires sur cet itinéraire.

Si vous avez une application existante, faites-le avec votre code. Si vous utilisez une nouvelle application, suivez cet exemple:

Par défaut, vos itinéraires de locataire ressemblent à ceci:

Route::middleware([
    'web',
    InitializeTenancyByDomain::class,
    PreventAccessFromCentralDomains::class,
])->group(function () {
    Route::get("https://laravel-news.com/", function () {
        return 'This is your multi-tenant application. The id of the current tenant is ' . tenant('id');
    });
});

Ces itinéraires ne sont accessibles que sur les domaines de locataires (et non sur les domaines centraux) PreventAccessFromCentralDomains L’intergiciel applique cela.

Faisons un petit changement pour sauvegarder tous les utilisateurs de la base de données afin que la multi-location fonctionne réellement. Ajoutez ceci au groupe middleware:

Route::get("https://laravel-news.com/", function () {
    dd(AppUser::all());
    return 'This is your multi-tenant application. The id of the current tenant is ' . tenant('id');
});

Et maintenant les migrations. Déplacez simplement les migrations liées à l’application client vers le database/migrations/tenant Annuaire.

Exemple: pour avoir des utilisateurs dans les bases de données client, nous déplaçons la migration de la table utilisateur vers Database / Migrations / Tenant. Cela empêche la création de la table dans la base de données centrale. Au lieu de cela, il est créé dans la base de données du client lors de la création d’un client.

Essayez-le

Et maintenant, créons des locataires.

Nous n’avons pas encore de page de destination pour que les locataires se connectent, mais nous pouvons en créer une pour l’artisanat!

Alors ouvrons-nous php artisan tinker et créer des locataires. Les locataires ne sont en réalité que des modèles. Vous les créez donc comme tous les autres modèles éloquents.

Notez que nous utilisons Identification de domaine Ici. Assurez-vous donc que les domaines que vous utilisez pointent vers votre application. J’utilise un valet donc j’utilise *.saas.test pour les locataires. Lorsque vous utilisez php artisan servevous pouvez utiliser foo.localhost, par example.

    >> $tenant1 = Tenant::create(['id' => 'foo']);
    >> $tenant1->domains()->create(['domain' => 'foo.saas.test']);
>>>
    >> $tenant2 = Tenant::create(['id' => 'bar']);
    >> $tenant2->domains()->create(['domain' => 'bar.saas.test']);

Et maintenant, créons un utilisateur dans la base de données de chaque locataire:

AppTenant::all()->runForEach(function () {
    factory(AppUser::class)->create();
});

Et c’est tout – Nous avons une application multi-locataires!

Quand vous visitez foo.saas.test (ou l’équivalent de votre environnement) verra un vidage des utilisateurs.

Quand vous visitez bar.saas.testVous verrez un dépotoir par différents utilisateurs. Les bases de données sont 100% séparées et le code que nous utilisons – AppUser::all() – n’a rien à savoir sur la location! Tout se passe automatiquement en arrière-plan. Vous écrivez simplement votre application comme vous en avez l’habitude sans avoir à penser à vous-même, et tout fonctionne.

Maintenant, bien sûr, vous avez une application plus complexe dans l’application locataire. Un SaaS qui draine simplement les utilisateurs ne ferait probablement pas beaucoup de bien. C’est donc votre travail – écrivez la logique métier qui sera utilisée par vos locataires. Le paquet s’occupe du reste.

le Bail pour Laravel L’aide du projet ne s’arrête cependant pas là. Le package s’occupe de tout le gros du travail lié à la multi-location pour vous. Cependant, lors de la création d’un SaaS, vous devez écrire vous-même la logique de facturation, le flux d’intégration et des normes similaires. Si vous êtes intéressé, le projet propose également un produit premium: le passe-partout SaaS multi-locataires. Il est conçu pour vous faire gagner du temps en vous offrant les fonctionnalités SaaS que vous auriez normalement à écrire vous-même. Tout est emballé dans une application multi-locataire prête à l’emploi. Vous pouvez en savoir plus Ici.

Remarque finale: ce didacticiel est destiné à vous montrer à quel point il est facile de créer une application multi-locataire. Il est court pour votre commodité. Veuillez consulter les packages pour plus d’informations Tutoriel de démarrage rapide ou la Documentation.

Bonne chance avec votre SaaS!



Source link

Recent Posts