Laravel: Artisan і планувальник
20 питань · ~20 хв · Версія v3.0
Увійдіть, щоб продовжити
Власні команди з аргументами й опціями, коди виходу, ізоляція й сигнали, виклик команд з коду, розклад, частота, фонові й щосекундні завдання - питання всіх рівнів, від junior до lead.
- За спробу
- 20
- У пулі
- 43
- Проходжень
- 0
- Середній бал
- -
- Пройшли на 70%+
- -
Питання для підготовки
20 питаньКонтролер - це клас, що групує логіку обробки запитів. Створюють його генератором Artisan; файл з'являється в app/Http/Controllers.
php artisan make:controller PostController # порожній
php artisan make:controller PostController --resource # 7 CRUD-методів
php artisan make:controller PostController --model=Post # з type-hint моделі
php artisan make:controller Api/PostController --api # без create/edit
php artisan make:controller PhotoController --invokable # один метод __invoke
Згенерований resource-контролер містить методи, що відповідають RESTful-конвенції:
class PostController extends Controller
{
public function index() {} // GET /posts
public function create() {} // GET /posts/create
public function store(Request $request) {} // POST /posts
public function show(Post $post) {} // GET /posts/{post}
public function edit(Post $post) {} // GET /posts/{post}/edit
public function update(Request $request, Post $post) {} // PUT/PATCH
public function destroy(Post $post) {} // DELETE
}
Прапорець --resource поєднується з Route::resource('posts', PostController::class), яка реєструє всі ці маршрути одним рядком.
Artisan - CLI Laravel. Він прискорює рутину: генерацію класів, міграції, очищення кешу, запуск черг тощо.
php artisan list # усі команди
php artisan make:model Post -mfsc # модель + міграція, фабрика, сідер, контролер
php artisan migrate
php artisan queue:work
php artisan tinker # інтерактивна REPL-консоль
Під капотом Artisan побудований на Symfony Console. Можна писати власні команди через make:command.
Планувальник дозволяє описати періодичні завдання прямо в коді. У Laravel 11+ розклад визначається в routes/console.php через фасад Schedule:
use Illuminate\Support\Facades\Schedule;
Schedule::command('reports:send')->dailyAt('08:00');
Schedule::job(new PruneLogs)->weekly();
Schedule::call(fn () => Cache::flush())->hourly();
На сервері потрібен лише один cron-запис, що щохвилини викликає планувальник:
* * * * * cd /app && php artisan schedule:run >> /dev/null 2>&1
Корисні модифікатори: withoutOverlapping(), onOneServer(), runInBackground().
Згенерувати клас і описати логіку в handle():
php artisan make:command SendReports
class SendReports extends Command
{
protected $signature = 'reports:send {--month=}';
protected $description = 'Розіслати місячні звіти';
public function handle(): int
{
$this->info('Відправка...');
return self::SUCCESS;
}
}
Аргументи й опції описуються в $signature. Команду можна запускати вручну або ставити в розклад через Schedule::command('reports:send')->monthly().
migrate:rollback відкочує останній «батч» міграцій, викликаючи їхні методи down():
php artisan migrate:rollback # останній батч
php artisan migrate:rollback --step=1 # рівно одну міграцію
migrate:reset відкочує всі міграції по черзі. migrate:refresh - відкочує все й накатує заново. migrate:fresh - видаляє всі таблиці й накатує міграції з нуля, взагалі не заглядаючи в down().
Що з цього небезпечне в проді: усі чотири. Кожна знищує дані, а migrate:fresh робить це найшвидше й без шансу на down(). У проді припустимий лише php artisan migrate.
Laravel сам питає підтвердження в продакшн-середовищі, і саме тому --force не варто вписувати в скрипти «щоб не заважало».
Практика, що рятує:
- Перевіряйте відкат локально одразу після написання:
migrate→migrate:rollback --step=1→migrate. Половина міграцій має неробочийdown(), і виявляється це в найгірший момент. - Пишіть
down()чесно, а якщо відкат неможливий - хай кидає виняток, це краще за мовчазну порожню реалізацію. - Не редагуйте вже застосовану міграцію - додавайте нову. Виправлений файл не перезастосується там, де він уже відпрацював.
- Видалення колонки й перейменування - окремими релізами від коду, що їх читає, інакше деплой ламає працюючий застосунок у проміжку.
Прочитати - ще не значить знати
20 питань, по одному на екран, ~20 хв. Після завершення - розбір кожної помилки з посиланням на питання.