Как я ушёл от REST и начал жить проще с Inertia.js

Привет! Меня зовут Сергей Чивирда, я PHP-разработчик в digital-агентстве IBRUSH. Мы в основном занимаемся дизайном и веб-разработкой. И сегодня я расскажу, как упростил себе жизнь, отказавшись от REST.

Как всё устроено обычно и что в этом не так

Если вы хоть раз писали современное веб-приложение, то наверняка шли по классической схеме: фронт на Vue или React, бэк на Laravel, Express или чем-то подобном. Между ними REST API. Иногда вместо REST используют GraphQL. Вроде всё по канону, но на практике возникает куча лишних проблем.

Первое, что раздражает — дублирование логики. Маршруты, валидация, обработка ошибок — всё приходится делать и на фронте, и на бэке. Получаются два мира, два набора кода, две точки отказа.

Плюс техническая возня. CORS, токены, CSRF-защита — всё это надо настраивать, поддерживать и отлаживать. А ещё ведь хочется, чтобы проект нормально индексировался поисковиками. Тогда подключаются Nuxt, Next, пререндеринг, мета-теги и куча других инструментов.

Inertia.js — простое решение, которое сработало

В какой-то момент я наткнулся на Inertia.js, и это был очень приятный сюрприз. Inertia — это не библиотека или фреймворк в привычном смысле. Это клей, который соединяет Laravel и Vue (или React), позволяя строить полноценные интерфейсы без отдельного API.

Фронтенд работает как обычное SPA, а бэк продолжает жить как Laravel-приложение: маршруты, контроллеры, middleware — всё привычно. Вместо return view() используем Inertia::render(), передаём данные, и они попадают напрямую во Vue-компонент как props.

То есть вы работаете в едином стеке. Валидация, авторизация и маршрутизация на сервере, без дублирования. Нет проксей, CORS и прочих сложностей. Просто Laravel отдаёт Vue-компоненты, и всё это отлично работает вместе. Интерфейс ведёт себя как SPA, но архитектура проще.

Если сравнивать с Livewire, то подход другой. В Livewire основной акцент на рендеринг HTML на сервере и обмен данными через AJAX. В случае с Inertia весь интерфейс строится на Vue или React, но без отдельной REST-инфраструктуры.

Пример на практике

Вот как это выглядит в реальном коде.

В контроллере Laravel просто пишем:

			return Inertia::render('Users/Index', [

    'users' => User::all()

]);
		

На фронте есть компонент Users/Index.vue, который принимает данные как props. Это всё. Не нужно писать отдельный API, сериализовывать данные, обрабатывать запросы вручную. Просто работаем с контроллером и компонентом.

Адреса страниц остаются стандартными, как в Laravel. Например, по маршруту /users Laravel отдаёт страницу, где Vue-компонент рендерит список пользователей. Переходы происходят быстро и без перезагрузки, как в SPA.

Что я получил в реальной работе

Когда я впервые использовал Inertia в боевом проекте, первым делом заметил, насколько сократилось количество кода. Не нужно писать отдельные контроллеры и для фронта, и для бэка, соединять их, думать о форматах данных и обрабатывать ошибки с двух сторон.

API как таковой просто исчез. А вместе с ним исчезли и проблемы с CORS, CSRF, токенами и заголовками. Всё работает как в монолите. Если возникает ошибка, ты сразу видишь, где именно она произошла. Не нужно прыгать между фронтом и бэком, выискивая источник бага.

Разработка стала быстрее. Когда фронт и бэк находятся в одном проекте, они не конфликтуют. Не нужно ждать, пока кто-то сделает API. Просто открываешь редактор и сразу реализуешь всю страницу целиком. Это особенно удобно, если ты один или в небольшой команде.

С SEO и SSR тоже стало проще. Поскольку рендер идёт на сервере, контент виден поисковикам, а настройка метатегов и пререндеринг выполняются привычными средствами Laravel.

И, пожалуй, главный плюс — всё работает единообразно. Авторизация, сессии, валидация, ошибки — всё в одной системе, без дублирования. Это упрощает отладку и снижает количество багов.

Когда Inertia может не подойти

Как и любой инструмент, Inertia не универсален. Он отлично показывает себя, когда фронт и бэк разрабатываются вместе, в рамках одного репозитория и одной команды. В таком случае он просто идеален.

Но если у вас фронтенд и бэкенд разделены по командам и живут в разных проектах — лучше выбрать REST или GraphQL. Inertia для такой архитектуры не подходит.

Также он не заменяет полноценный API. Если вам нужен мобильный клиент или вы планируете отдавать данные сторонним приложениям — API придётся реализовать отдельно.

И ещё один момент. Если вы собираетесь использовать Nuxt или Next.js для SSR — Inertia здесь не поможет. У него свой подход, который не интегрируется с этими фреймворками.

Так что всё зависит от задач.

Итог

Если вы фуллстек-разработчик и работаете в Laravel, очень советую попробовать Inertia. Он позволяет писать фронт и бэк в одном стеке, без лишней головной боли. Вы продолжаете использовать привычные инструменты Laravel — контроллеры, middleware, сессии, валидацию — но при этом создаёте интерфейс с Vue или React. Компоненты, реактивность, быстрые переходы — всё это на месте.

И главное — не нужно прыгать между двумя мирами. Порог входа очень низкий. Начать можно хоть с одной страницы.

Мой совет: попробуйте Inertia на небольшом проекте. Например, сделайте личный кабинет, блог или список задач. Скорее всего, вам понравится. Мне — точно зашло.