Управління маршрутами у великій програмі Laravel

Файли маршрутів Laravels можуть бути досить зайняті. Перш ніж ви це дізнаєтеся, вам потрібно шукати в файлі маршрутів, щоб знайти що-небудь. Але як ви боретеся з цим?

Підходити до цього можна по-різному, в залежності від того, як би ви віддали перевагу підійти до нього. У цьому уроці я розгляну кілька варіантів, які я бачив, а потім закінчу, як я підходжу до цього і чому я підходжу до цього таким чином.

Наведу простий приклад, але можна трохи задіяти свою фантазію! Уявіть, що ми створюємо додаток API, який дозволяє клієнтам замовляти онлайн з каталогу та дозволяє своїм клієнтам відстежувати відправлення. Постачальник послуг маршруту

Використовуючи постачальника послуг маршруту, ви можете легко додавати додаткові записи маршруту. Давайте розглянемо приклад:

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

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

Це схоже на типовий RouteServiceProvider, який ви отримуєте в рамках свого проекту Laravel. Ваш може відрізнятися залежно від віку вашої заявки. Як ми можемо це розширити? Ми можемо додати додаткове завантаження маршруту в провайдера:

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'));
        });
    }
}

Це не має на меті бути абсолютно точним. Я використовую це більше як приклад з кількома рухомими частинами, які, ймовірно, матимуть щонайменше 75+ маршрутів. Отже, тут ми керуємо цим у межах RouteServiceProvider, тому все є центральним у тому, як ми завантажуємося на маршрутах. Найбільша проблема, яку я знайшов при такому підході, полягає в тому, що коли ви перебуваєте у файлі маршрутів, вам потрібно знати, що ще завантажується. Раніше я працював над дуже великою програмою, яка використовувала цей підхід, і знадобилося багато розумових зусиль, щоб продовжувати повертатися, щоб побачити, чи завантажуються маршрути і чи були вони в порядку, який може викликати проблеми.

Відкриваючи проект Laravel вперше, ви звертаєте увагу на кілька ключових напрямків: красномовні режими, маршрути та тести. Ви відкриваєте файл маршрутів і дивитеся на зареєстровані маршрути, щоб зрозуміти розмір програми та те, як все складено.

Вимагаючи файл

Якщо ви встановите Laravel Breeze, ви помітите, що він додає наступне до ваших маршрутів / веб.php файл:

equire __DIR__ . '/auth.php';

Це завантажується на маршрутах аутентифікації, які постачаються з пакетом, що дозволяє вам зберегти ваш постачальник послуг більш мінімальним і зрозуміти, скільки додаткових файлів потрібно перевірити для перегляду всіх маршрутів. Давайте візьмемо наш наведений вище приклад і додамо маршрути в такий підхід:

// 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';

Це, як на мене, поліпшення підходу постачальника послуг, оскільки ви, швидше за все, матимете кращу видимість у своєму додатку при перегляді файлів маршруту. Однак вимагати файли - це те, що я ненавиджу бачити. Він просто відчуває себе безладним і ледачим.

Переваги полягають у тому, що ви можете побачити речі, необхідні для завантаження на всіх маршрутах, в одному простому місці, де ви очікуєте побачити маршрути. Недоліком, однак, є те, що це просто необхідний метод, який завантажує файл при виконанні цього сценарію.

Як на мене, це можна трохи покращити. Тут немає інформації про те, якою може бути структура URL-адреси або будь-яке додаткове проміжне програмне забезпечення, яке ви знаєте, застосовується до всіх маршрутів.

Групи

маршрутів Це мій кращий підхід. Ми бачимо, що вони використовуються в RouteServiceProvider, звідки я отримав ідею. Основний принцип тут полягає в тому, що у вашому основному файлі маршрутів (routes/api.php в нашому випадку) ми будуємо наші групи маршрутів так, як якби ми додавали наші маршрути вручну, а потім повідомляли цій групі, що їй потрібно використовувати окремий файл.

// 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'),
);

Як видно з вищесказаного, ми якраз використовуємо функцію base_path помічника, щоб завантажити маршрути в потрібному місці. Дивлячись на файл маршрутів, ми можемо побачити, як групи створюють вашу програму, але вона не бере на себе файл - навіть якщо ви в кінцевому підсумку отримаєте 20-30 груп, він все одно досить читабельний.

Звідси ми можемо керувати "ресурсами" та "підресурсами" у виділеному файлі маршрутів, що означає меншу кількість класів імен класів під час імпорту та має спеціальні файли, які ви можете легко зрозуміти ізольовано або у вмісті всієї вашої програми.

Як ви боретеся з когнітивним навантаженням великого файлу маршрутів? Ви знайшли цікавий спосіб, яким хотіли б поділитися? Повідомте нас у Твіттері.