Zarządzanie trasami w dużej aplikacji Laravel

Pliki tras Laravels mogą być bardzo zajęte. Zanim się zorientujesz, musisz przeszukać plik tras, aby cokolwiek znaleźć. Jak jednak z tym walczyć?

Możesz podejść do tego na wiele sposobów, w zależności od tego, jak wolisz do tego podejść. W tym samouczku przejdę przez kilka opcji, które widziałem, a następnie zakończę, jak do tego podchodzę i dlaczego podchodzę do tego w ten sposób.

Posłużę się prostym przykładem, ale możesz trochę użyć swojej wyobraźni! Załóżmy, że tworzymy aplikację API, która umożliwia klientom zamawianie online z katalogu i umożliwia klientom śledzenie przesyłek. Dostawca usług wyznaczania

trasy Korzystając z dostawcy usług wyznaczania tras, można łatwo dodawać kolejne wpisy trasy. Rzućmy okiem na przykład:

class RouteServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        $this->configureRateLimiting();

        $this->routes(function (): void {
            Route::middleware('api')
                ->group(base_path('routes/api.php'));
        });
    }
}

Jest to podobne do domyślnego dostawcy RouteServiceProvider, który otrzymujesz w ramach projektu Laravel. Twój może się różnić w zależności od wieku aplikacji. Jak możemy to rozszerzyć? Możemy dodać dodatkowe ładowanie trasy w dostawcy:

class RouteServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        $this->configureRateLimiting();

        $this->routes(function (): void {
            Route::middleware('api')
                ->group(base_path('routes/api.php'));

            Route::middleware('api')
                ->group(base_path('routes/resource/catalog.php'));

            Route::middleware('api')
                ->group(base_path('routes/resource/orders.php'));

            Route::middleware('api')
                ->group(base_path('routes/resource/payments.php'));

            Route::middleware('api')
                ->group(base_path('routes/resource/deliveries.php'));
        });
    }
}

To nie ma być idealnie dokładne. Używam tego bardziej jako przykładu z kilkoma ruchomymi częściami, które prawdopodobnie będą miały co najmniej trasy 75 +. Więc tutaj zarządzamy tym w ramach RouteServiceProvider, więc wszystko jest kluczowe w sposobie ładowania tras. Największym problemem, jaki znalazłem przy tym podejściu, jest to, że w pliku tras musisz wiedzieć, co jeszcze jest ładowane. Wcześniej pracowałem nad bardzo dużą aplikacją, która wykorzystywała to podejście, i wymagało to wiele wysiłku umysłowego, aby wracać, aby sprawdzić, czy trasy są ładowane i czy są w kolejności, która może powodować problemy.

Otwierając projekt Laravel po raz pierwszy, zwracasz uwagę na kilka kluczowych obszarów: Eloquent Modes, Routes i Tests. Otwórz plik tras i przejrzyj zarejestrowane trasy, aby zrozumieć rozmiar aplikacji i sposób łączenia elementów.

Wymaganie pliku

Jeśli zainstalujesz Laravel Breeze, zauważysz, że dodaje on następujące elementy do twoich tras / sieci.php plik:

equire __DIR__ . '/auth.php';

Ładuje trasy uwierzytelniania dołączone do pakietu, co pozwala zachować minimalizację dostawcy usług i zrozumieć, ile dodatkowych plików należy sprawdzić, aby przeglądać wszystkie trasy. Weźmy nasz powyższy przykład i dodajmy trasy w tym podejściu:

// The rest of your `routes/api.php` file
require __DIR__ . '/resource/catalog.php';
require __DIR__ . '/resource/orders.php';
require __DIR__ . '/resource/payments.php';
require __DIR__ . '/resource/deliveries.php';

Dla mnie jest to ulepszenie podejścia dostawcy usług, ponieważ prawdopodobnie będziesz mieć lepszą widoczność w aplikacji podczas przeglądania plików tras. Jednak wymaganie plików jest czymś, czego nienawidzę widzieć. Po prostu czuje się niechlujny i leniwy.

Korzyści polegają na tym, że możesz zobaczyć rzeczy wymagane do załadowania na wszystkich trasach w jednym prostym miejscu, w którym spodziewasz się zobaczyć trasy. Minusem jest jednak to, że jest to tylko wymagana metoda, która ładuje plik podczas wykonywania tego skryptu.

Dla mnie można to nieco poprawić. Nie ma tutaj informacji mówiących, jaka może być struktura adresów URL ani żadnego dodatkowego oprogramowania pośredniczącego, o którym wiesz, że jest stosowane do wszystkich tras.

Grupy tras

To jest moje preferowane podejście. Widzimy, że są one używane w RouteServiceProvider, skąd wziąłem pomysł. Podstawową zasadą jest to, że w twoim głównym pliku tras (trasy/api.php w naszym przypadku) budujemy nasze grupy tras tak, jakbyśmy dodawali nasze trasy ręcznie, a następnie informowaliśmy tę grupę, że musi użyć osobnego pliku.

// The rest of your `routes/api.php` file
Route::prefix('catalog')->as('catalog:')->middleware(['auth:sanctum'])->group(
    base_path('routes/resources/catalog.php'),
);
Route::prefix('orders')->as('orders:')->middleware(['auth:sanctum'])->group(
    base_path('routes/resources/orders.php'),
);
Route::prefix('payments')->as('payments:')->middleware(['auth:sanctum'])->group(
    base_path('routes/resources/payments.php'),
);
Route::prefix('deliveries')->as('deliveries:')->middleware(['auth:sanctum'])->group(
    base_path('routes/resources/deliveries.php'),
);

Jak widać z powyższego, używamy tylko funkcji pomocnika base_path, aby załadować trasy we właściwym miejscu. Patrząc na plik tras, widzimy grupy budujące twoją aplikację, ale nie przejmuje on pliku - nawet jeśli skończysz z 20-30 grupami, nadal jest całkiem czytelny.

Stąd możemy zarządzać "zasobami" i "podzasobami" w dedykowanym pliku tras, co oznacza mniej klas nazw klas podczas importu i posiadanie dedykowanych plików, które można łatwo zrozumieć w izolacji lub w treści całej aplikacji.

Jak zwalczać obciążenie poznawcze obszernego pliku tras? Czy znalazłeś interesujący sposób, którym chciałbyś się podzielić? Daj nam znać na Twitterze.