허니스톤/컨텍스트를 사용하여 다중 테넌트 애플리케이션 구축

Laravel의 새로운 컨텍스트 라이브러리와 혼동하지 마십시오. 이 패키지는 다중 컨텍스트 다중 테넌트 애플리케이션을 구축하는 데 사용할 수 있습니다. 대부분의 다중 테넌트 라이브러리에는 기본적으로 단일 '테넌트' 컨텍스트가 있으므로 여러 컨텍스트가 필요한 경우 상황이 약간 까다로워질 수 있습니다. 이 새로운 패키지는 이 문제를 해결합니다.

예제를 살펴볼까요?

예제 프로젝트

예제 애플리케이션의 경우 다음과 같은 글로벌 사용자 기반을 갖게 됩니다. 팀으로 구성되며 각 팀에는 여러 프로젝트가 있습니다. 이는 많은 SaaS(Software as a Service) 애플리케이션에서 매우 일반적인 구조입니다.

다중 테넌트 애플리케이션에서 각 사용자 기반이 테넌트 컨텍스트 내에 존재하는 것은 드문 일이 아니지만 예제 애플리케이션의 경우 사용자가 여러 팀에 합류할 수 있으므로 글로벌 사용자 기반입니다.
글로벌 사용자 기반 대 테넌트 사용자 기반 다이어그램

SaaS로서 팀은 청구 가능한 엔터티(즉, 좌석)가 되며 특정 팀 구성원에게는 팀을 관리할 수 있는 권한이 부여됩니다. 이 예제에서는 이러한 구현 세부 사항을 자세히 다루지는 않지만 추가 컨텍스트를 제공할 수 있기를 바랍니다.

설치

이 게시물을 간결하게 유지하기 위해 Laravel을 시작하는 방법에 대해서는 설명하지 않겠습니다. 프로젝트. 공식 문서뿐만 아니라 이미 이를 위한 더 나은 리소스가 많이 있습니다. 사용자, 팀 및 프로젝트 모델이 포함된 Laravel 프로젝트가 이미 있고 컨텍스트 패키지 구현을 시작할 준비가 되었다고 가정해 보겠습니다.

설치는 간단한 작곡가 추천입니다:

composer install honeystone/context

이 라이브러리에는 Laravel 11부터 Laravel 자체 컨텍스트 기능과 충돌하는 편의 함수인 context()가 있습니다. 이것은 실제로 문제가 되지 않습니다. 우리 함수를 가져올 수도 있습니다:

use function Honestone\Context\context;

또는 Laravel의 종속성 주입 컨테이너를 사용할 수도 있습니다. 이 게시물 전체에서 저는 여러분이 함수를 가져와 그에 따라 사용한다고 가정합니다.

모델

팀 모델 구성부터 시작해 보겠습니다.

<?php declare(strict_types=1);

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\BelongsToMany;
use Illuminate\Database\Eloquent\Relations\HasMany;

class Team extends Model
{
    protected $fillable = [&#39;name&#39;];

    public function members(): BelongsToMany
    {
        return $this->belongsToMany(User::class);
    }

    public function projects(): HasMany
    {
        return $this->hasMany(Project::class);
    }
}

팀에는 이름, 구성원 및 프로젝트가 있습니다. 애플리케이션 내에서는 팀 구성원만 팀이나 해당 프로젝트에 액세스할 수 있습니다.

자, 프로젝트를 살펴보겠습니다.

<?php declare(strict_types=1);

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\BelongsTo;

class Project extends Model
{
    protected $fillable = [&#39;name&#39;];

    public function team(): BelongsTo
    {
        return $this->belongsTo(Team::class);
    }
}

프로젝트에 이름을 지정하고 팀에 속합니다.

컨텍스트 확인

누군가가 우리 애플리케이션에 액세스하면 해당 사람이 어떤 팀과 프로젝트에서 작업하고 있는지 확인해야 합니다. 작업을 단순하게 유지하기 위해 경로 매개변수를 사용하여 이를 처리하겠습니다. 또한 인증된 사용자만 애플리케이션에 액세스할 수 있다고 가정합니다.

팀이나 프로젝트 컨텍스트 모두: app.mysaas.dev
팀 컨텍스트만: app.mysaas.dev/my-team
팀 및 프로젝트 컨텍스트: app.mysaas.dev/my-team/my-project

경로는 다음과 같습니다.

Route::middleware('auth')->group(function () {

    Route::get('/', DashboardController::class);

    Route::middleware(AppContextMiddleware::Class)->group(function () {

        Route::get('/{team}', TeamController::class);
        Route::get('/{team}/{project}', ProjectController::class);
    });
});

이는 네임스페이스 충돌 가능성을 고려할 때 매우 융통성이 없는 접근 방식이지만 예제를 간결하게 유지합니다. 실제 애플리케이션에서는 이를 약간 다르게 처리해야 합니다(예: anothersaas.dev/teams/my-team/projects/my-project 또는 my-team.anothersas.dev/projects/my-project).

먼저 AppContextMiddleware를 살펴봐야 합니다. 이 미들웨어는 팀 컨텍스트를 초기화하고 설정된 경우 프로젝트 컨텍스트를 초기화합니다.

<?php declare(strict_types=1);

namespace App\Http\Middleware;

use function Honestone\Context\context;

class TeamContextMiddleware
{
    public function handle(Request $request, Closure $next): mixed
    {
        //pull the team parameter from the route
        $teamId = $request->route('team');
        $request->route()->forgetParameter('team');

        $projectId = null;

        //if there's a project, pull that too
        if ($request->route()->hasParamater('project')) {

            $projectId = $request->route('project');
            $request->route()->forgetParameter('project');
        }

        //initialise the context
        context()->initialize(new AppResolver($teamId, $projectId));
    }
}

우선 경로에서 팀 ID를 가져온 다음 경로 매개변수를 잊어버립니다. 매개변수가 컨텍스트에 있으면 컨트롤러에 도달하는 매개변수가 필요하지 않습니다. 프로젝트 ID가 설정되어 있으면 해당 ID도 가져옵니다. 그런 다음 팀 ID와 프로젝트 ID(또는 null)를 전달하는 AppResolver를 사용하여 컨텍스트를 초기화합니다.

<?php declare(strict_types=1);

namespace App\Context\Resolvers;

use App\Models\Team;
use Honeystone\Context\ContextResolver;
use Honeystone\Context\Contracts\DefinesContext;

use function Honestone\Context\context;

class AppResolver extends ContextResolver
{
    public function __construct(
        private readonly int $teamId,
        private readonly ?int $projectId = null,
    ) {}

    public function define(DefinesContext $definition): void 
    {
        $definition
            ->require('team', Team::class)
            ->accept('project', Project::class);
    }

    public function resolveTeam(): ?Team
    {
        return Team::with('members')->find($this->teamId);
    }

    public function resolveProject(): ?Project
    {
        return $this->projectId ?: Project::with('team')->find($this->projectId);
    }

    public function checkTeam(DefinesContext $definition, Team $team): bool
    {
        return $team->members->find(context()->auth()->getUser()) !== null;
    }

    public function checkProject(DefinesContext $definition, ?Project $project): bool
    {
        return $project === null || $project->team->id === $this->teamId;
    }

    public function deserialize(array $data): self
    {
        return new static($data['team'], $data['project']);
    }
}

여기서 조금 더 진행됩니다.

정의( ) 메서드는 해결되는 컨텍스트를 정의하는 역할을 담당합니다. 팀은 필수이고 팀 모델이어야 하며 프로젝트가 승인되고(즉, 선택 사항) 프로젝트 모델(또는 null)이어야 합니다.

resolveTeam()은 초기화 시 내부적으로 호출됩니다. 팀 또는 null을 반환합니다. null 응답의 경우 ContextInitializer에 의해 CouldNotResolveRequiredContextException이 발생합니다.

resolveProject()도 초기화 시 내부적으로 호출됩니다. 프로젝트 또는 null을 반환합니다. 이 경우 정의에 따라 프로젝트가 필요하지 않으므로 null 응답으로 인해 예외가 발생하지 않습니다.

팀과 프로젝트를 확인한 후 ContextInitializer는 선택적 checkTeam() 및 checkProject() 메서드를 호출합니다. 이러한 방법은 무결성 검사를 수행합니다. checkTeam()의 경우 인증된 사용자가 팀의 구성원인지 확인하고 checkProject()의 경우 프로젝트가 팀에 속하는지 확인합니다.

마지막으로 모든 확인자에는 deserialization() 메서드가 필요합니다. 이 메서드는 직렬화된 컨텍스트를 복원하는 데 사용됩니다. 특히 대기 중인 작업에서 컨텍스트를 사용할 때 이런 일이 발생합니다.

Now that our application context is set, we should use it.

Accessing the context

As usual, we’ll keep it simple, if a little contrived. When viewing the team we want to see a list of projects. We could build our TeamController to handle this requirements like this:

<?php declare(strict_types=1);

namespace App\Http\Controllers;

use Illuminate\View\View;

use function compact;
use function Honestone\Context\context;
use function view;

class TeamController
{
    public function __invoke(Request $request): View
    {
        $projects = context(&#39;team&#39;)->projects;

        return view('team', compact('projects'));
    }
}

Easy enough. The projects belonging to the current team context are passed to our view. Imagine we now need to query projects for a more specialised view. We could do this:

<?php declare(strict_types=1);

namespace App\Http\Controllers;

use Illuminate\View\View;

use function compact;
use function Honestone\Context\context;
use function view;

class ProjectQueryController
{
    public function __invoke(Request $request, string $query): View
    {
        $projects = Project::where(&#39;team_id&#39;, context(&#39;team&#39;)->id)
            ->where('name', 'like', "%$query%")
            ->get();

        return view('queried-projects', compact('projects'));
    }
}

It’s getting a little fiddly now, and it’s far too easy to accidentally forget to ‘scope’ the query by team. We can solve this using the BelongsToContext trait on our Project model:

<?php declare(strict_types=1);

namespace App\Models;

use Honeystone\Context\Models\Concerns\BelongsToContext;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\BelongsTo;

class Project extends Model
{
    use BelongsToContext;

    protected static array $context = [&#39;team&#39;];

    protected $fillable = [&#39;name&#39;];

    public function team(): BelongsTo
    {
        return $this->belongsTo(Team::class);
    }
}

All project queries will now be scooped by the team context and the current Team model will be automatically injected into new Project models.

Let’s simplify that controller:

<?php declare(strict_types=1);

namespace App\Http\Controllers;

use Illuminate\View\View;

use function compact;
use function view;

class ProjectQueryController
{
    public function __invoke(Request $request, string $query): View
    {
        $projects = Project::where(&#39;name&#39;, &#39;like&#39;, "%$query%")->get();

        return view('queried-projects', compact('projects'));
    }
}

That’s all folks

From here onwards, you’re just building your application. The context is easily at hand, your queries are scoped and queued jobs will automagically have access to the same context from which they were dispatched.

Not all context related problems are solved though. You’ll probably want to create some validation macros to give your validation rules a little context, and don’t forget manual queries will not have the context automatically applied.

If you’re planning to use this package in your next project, we’d love to hear from you. Feedback and contribution is always welcome.

You can checkout the GitHub repository for additional documentation. If you find our package useful, please drop a star.

Until next time..

---

This article was originally posted to the Honeystone Blog. If you like our articles, consider checking our more of our content over there.

위 내용은 허니스톤/컨텍스트를 사용하여 다중 테넌트 애플리케이션 구축의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!