Что такое Laravel

Laravel — full-stack PHP-фреймворк для веб-приложений, API, очередей, консольных команд и фоновых задач. Он стоит поверх обычного PHP, Composer-пакетов, HTTP-слоя и базы данных: язык остаётся тем же, но типовые части приложения уже собраны в единый каркас. Поэтому Laravel удобно читать как практическое продолжение тем Composer, Packagist и composer.json, Autoloading и PSR-4, SAPI и суперглобалы и PDO и подключение к базе.

В современной ветке Laravel 13.x документация описывает фреймворк как структуру для приложения с dependency injection, database abstraction, queues, scheduled jobs, testing и другими готовыми подсистемами. В реальном проекте Laravel обычно даёт не одну библиотеку, а набор договорённостей: где лежат routes, controllers, models, migrations, config, views, console commands и tests.

flowchart TD A[HTTP-запрос] --> B[public/index.php] B --> C[Bootstrap приложения] C --> D[Middleware] D --> E[Router] E --> F[Controller или closure] F --> G[Service container] F --> H[Eloquent / Query Builder] H --> I[(Database)] F --> J[Blade view или JSON response] J --> K[HTTP-ответ]
flowchart TD
    A[HTTP-запрос] --> B[public/index.php]
    B --> C[Bootstrap приложения]
    C --> D[Middleware]
    D --> E[Router]
    E --> F[Controller или closure]
    F --> G[Service container]
    F --> H[Eloquent / Query Builder]
    H --> I[(Database)]
    F --> J[Blade view или JSON response]
    J --> K[HTTP-ответ]
Упрощённый путь web-запроса в Laravel: framework связывает HTTP, middleware, routing, DI, базу и ответ.

Request lifecycle: от HTTP-запроса до ответа

Типичный web-запрос попадает в public/index.php, проходит bootstrap приложения, middleware, роутер и controller, а затем возвращается как HTTP response. Это не отменяет базовые правила из HTTP-заголовки, ответы и редиректы: заголовки, статус-коды, cookies и redirect всё равно должны быть корректными. Laravel просто даёт слой абстракций над этим процессом.

Минимальный route может быть closure:

use Illuminate\Support\Facades\Route;

Route::get('/health', function () {
    return ['ok' => true];
});

Но в нормальном приложении поведение обычно уносят в controller:

use App\Http\Controllers\ArticleController;
use Illuminate\Support\Facades\Route;

Route::get('/articles/{article}', [ArticleController::class, 'show'])
    ->name('articles.show');

Controller группирует обработчики связанных запросов. Это не магия MVC ради MVC: когда в routes/web.php остаются только маршруты, а логика живёт в классах, приложение проще тестировать, искать и менять. Сами routes бывают web и API: routes/web.php обычно идёт с session state и CSRF-защитой, а API-роуты делают stateless-поведение и часто требуют отдельной аутентификации, например через Sanctum.

Быстрое повторение
Почему Laravel-проект обычно не держит всю логику прямо в `routes/web.php`, хотя closure-route технически работает?

Service container и facades

Service container — центральный механизм Laravel для dependency injection. Если controller требует конкретный service-класс в конструкторе, контейнер может создать его автоматически через reflection:

final class InvoiceController
{
    public function __construct(
        private InvoicePdfRenderer $renderer,
    ) {}

    public function show(Invoice $invoice)
    {
        return $this->renderer->render($invoice);
    }
}

Когда зависимость — интерфейс, контейнеру нужно явно сказать, какую реализацию подставлять. Обычно это делают в service provider:

use App\Contracts\InvoiceRenderer;
use App\Services\DomPdfInvoiceRenderer;

public function register(): void
{
    $this->app->bind(InvoiceRenderer::class, DomPdfInvoiceRenderer::class);
}

Facades выглядят как статические вызовы, но фактически проксируют вызов к объекту из container. Например, Cache::get('key') не означает, что вся система cache — набор глобальных static-методов. Facade Cache достаёт binding из контейнера и вызывает метод на реальном сервисе. Это удобно, но в доменном коде лучше не превращать facades в замену зависимостей везде подряд: constructor injection обычно яснее показывает, что классу действительно нужно.

Быстрое повторение
Что происходит, когда controller просит concrete service-класс в конструкторе, например `InvoicePdfRenderer`?

Eloquent, migrations и база данных

Eloquent — ORM Laravel. Каждая таблица обычно получает model-класс, через который читают, создают, обновляют и удаляют записи. Например:

use App\Models\Article;

$article = Article::query()
    ->where('slug', $slug)
    ->firstOrFail();

Model — не просто DTO. В нём могут быть relationships, casts, accessors, scopes, factories и правила mass assignment. Это удобно, но важно помнить границу: Eloquent помогает писать бизнес-код выразительно, а не отменяет SQL, индексы, транзакции и ограничения СУБД. Для сложных запросов всё равно полезно понимать Prepared statements и SQL injection и Транзакции и режимы ошибок PDO.

Migrations — version control для схемы базы. Они описывают, какие таблицы и колонки надо создать или изменить:

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration {
    public function up(): void
    {
        Schema::create('articles', function (Blueprint $table) {
            $table->id();
            $table->string('title');
            $table->string('slug')->unique();
            $table->text('body');
            $table->timestamps();
        });
    }

    public function down(): void
    {
        Schema::dropIfExists('articles');
    }
};

Команды php artisan migrate, migrate:status, migrate:rollback, migrate --pretend и migrate --force — часть production-дисциплины. На бою особенно важны idempotent-подход, бэкапы, понимание destructive-операций и то, что несколько серверов не должны одновременно пытаться менять одну и ту же схему.

Быстрое повторение
Что означает предупреждение: «Eloquent не отменяет SQL»?

Blade и вывод HTML

Blade — шаблонизатор Laravel. Он компилирует .blade.php в PHP-код и даёт директивы вроде @if, @foreach, @csrf, @include, components и layouts. Самое важное правило безопасности: {{ $value }} экранирует вывод через HTML entities, а {!! $value !!} выводит HTML без экранирования.

<h1>{{ $article->title }}</h1>

<form method="POST" action="{{ route('articles.store') }}">
    @csrf
    <input name="title" value="{{ old('title') }}">
    <button type="submit">Сохранить</button>
</form>

Это напрямую связано с XSS, экранирование вывода и шаблоны. Laravel помогает безопасным default-поведением, но не спасает, если разработчик сознательно вставляет пользовательский HTML через {!! !!} или смешивает контексты: HTML body, HTML attribute, JavaScript, URL и CSS требуют разных правил.

Artisan, queues и экосистема

Artisan — CLI Laravel. Через него создают классы, гоняют migrations, запускают queue workers, смотрят routes и пишут собственные команды:

php artisan list
php artisan route:list
php artisan make:controller ArticleController
php artisan make:model Article -m
php artisan queue:work

Queues дают единый API поверх разных backend-ов: database, Redis, Amazon SQS, Beanstalkd, sync-драйвер для разработки и другие варианты. Идея простая: HTTP-запрос не должен ждать тяжёлую работу, если её можно отложить. Отправка email, обработка изображения, webhook retry, генерация отчёта — типичные queue jobs. Подробная эксплуатационная сторона связана с Очереди, фоновые задачи и воркеры и PHP-FPM, RoadRunner и долгоживущие воркеры: воркер живёт дольше одного запроса, поэтому память, singleton-состояние, retry, timeout и failed jobs становятся частью архитектуры.

Экосистема Laravel шире core framework: Sail для Docker-разработки, Horizon для Redis queues, Sanctum и Passport для auth/API, Cashier для billing, Scout для поиска, Telescope и Pulse для наблюдаемости, Reverb и Echo для realtime, Octane для долгоживущего runtime, Pint для code style. Это сильная сторона Laravel, но и источник зависимости от framework-way. Если проекту нужен маленький PSR-7 middleware-stack без full-stack соглашений, стоит сравнить Laravel с Symfony, Yii, Slim и Mezzio и общей статьёй Выбор PHP-фреймворка.

Где Laravel особенно уместен

Laravel хорошо подходит для CRUD-приложений, админок, SaaS, API с background jobs, проектов с Blade/Livewire/Inertia-фронтендом и команд, которым важны conventions. Он особенно силён, когда нужно быстро собрать production-приложение с auth, forms, validation, database, emails, queues, scheduler и тестами без сборки инфраструктуры из отдельных пакетов вручную.

Главный риск — путать удобство с отсутствием архитектуры. Route::get(..., fn () => DB::table(...)) может быть нормальным прототипом, но в большом проекте быстро превращается в смесь SQL, HTTP, HTML и бизнес-логики. Хороший Laravel-код не обязательно «толстый framework-код»: он всё ещё опирается на Классы, объекты и видимость, Неймспейсы и use, PHPDoc, generics и статический анализ, тесты и аккуратные границы между слоями.

См. также

Источники

  1. Laravel 13.x Documentation — Installation
  2. Laravel 13.x Documentation — Release Notes
  3. Laravel 13.x Documentation — Service Container
  4. Laravel 13.x Documentation — Facades
  5. Laravel 13.x Documentation — Routing
  6. Laravel 13.x Documentation — Controllers
  7. Laravel 13.x Documentation — Blade Templates
  8. Laravel 13.x Documentation — Eloquent ORM
  9. Laravel 13.x Documentation — Database Migrations
  10. Laravel 13.x Documentation — Artisan Console
  11. Laravel 13.x Documentation — Queues