Перетяжка, Карта дня
Перетяжка, Карта дня
Перетяжка, Карта дня

Как перевести проект на Laravel: пошаговый план перехода

Как перенести проект на Laravel за 7 шагов. Подготовка, миграция и тестирование. Советы для оптимизации работы вашего приложения на PHP.

190 открытий3К показов
Как перевести проект на Laravel: пошаговый план перехода

Когда код устаревает, его поддержка превращается в борьбу с хаосом. После пересмотра архитектуры приходит пугающее осознание: нужно переезжать на более современный стек. Однако непонятно, с чего начать.

В этой статье пошагово разберем перенос вашего проекта на Laravel. Вы узнаете, как мигрировать с минимальными рисками для разработки и пользователей.

Шаг 1. Готовимся к миграции

Посмотрите структуру проекта, чтобы выявить слабые места.

Архитектура далека от идеала, если проект вырос на хаотичных добавлениях новых функций.

Проанализируйте:

  • Вид проекта. Ваша разработка — это монолит, модульная система, API, микросервис?
  • Зависимости. Определите, какие библиотеки использует проект. Совместимы ли они с Laravel?
  • Базу данных. Если в БД встречаются дубли, отсутствуют ограничения, это нужно исправить заранее.

В качестве теста на совместимость перепишите небольшую часть на Laravel. Возьмите один простой модуль и посмотрите, насколько это жизнеспособно.

Стратегии перехода

Выберем стратегию перехода:

  • Big Bang,
  • Поэтапный перенос.

Стратегия Big Bang — это полная остановка текущего проекта и создание новой версии на Ларавел с нуля.

Подход идеален для устаревших и запутанных систем.

Из минусов — высокие риски. Во время разработки текущая версия может растерять пользователей. К тому же сроки реализации могут затянуться.

Стратегия с постепенным переходом выглядит надежнее.

Система продолжает работать, а вы поэтапно меняете ее «под капотом».

Единственный нюанс — готовьтесь к сложностям поддержки, когда часть системы заработает в новой архитектуре, а часть останется в старой.

Выбор подхода зависит от проекта

Если систему легко поддерживать, то более безопасен постепенный переход.

Проект напоминает спагетти-код? Плохие новости — Big Bang неизбежен.

Шаг 2. Разворачиваем новое окружение на Laravel

Чтобы установить фреймворк, выполните команду:

			composer create-project laravel/laravel имя-проекта
		

Прежде чем работать с кодом, настроим окружение.

В корне проекта для этого есть файл конфигурации .env:

  • APP_NAME: имя приложения, чтобы оно отображалось в логах и заголовках.
  • APP_URL: адрес, на котором приложение будет доступно (например, http://localhost).

В будущем запланирована интеграция с существующей базой, поэтому лучше сразу настроить подключение.

Подключение БД

Laravel использует Eloquent ORM для взаимодействия с базой.

Настройка БД выполняется в том же разделе .env:

			DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=имя_базы
DB_USERNAME=логин
DB_PASSWORD=пароль
		

Для тестирования подключения запустите команду:

			php artisan migrate:status
		

Настройка маршрутов

Маршруты изначально хранятся в файлах routes/web.php (для страниц) или routes/api.php (для REST API).

В качестве примера добавим базовый маршрут приветствия:

			Route::get('/welcome', function () {
    return 'Добро пожаловать в новое приложение!';
});
		

Если у вас проект с десятками пользовательских маршрутов, интегрируйте их постепенно.

Шаг 3. Переносим модели данных и бизнес-логики

Eloquent ORM работает с классами, представляющими таблицы в базе данных.

Чтобы перенести существующую таблицу, нужно создать модель:

			php artisan make:model Product
		

Этот класс автоматически подключается к таблице с именем products.

Когда название таблицы не соответствует модели, это можно указать явно:

			protected $table = 'items';
		

Если в таблице есть нестандартные поля (например, столбцы с именами вроде created_time вместо created_at), их тоже можно легко обработать:

			const CREATED_AT = 'created_time';
		

Переносим схему БД

Laravel использует механизм миграций для управления таблицами в базе и сиды для внесения данных.

Перенос структуры БД выполняется командой:

			php artisan make:migration create_products_table
		

Миграция создается в папке database/migrations.

Переносим данные

Если текущая БД уже содержит данные, их можно перенести через сиды: файлы, которые заполняют таблицы данными.

Создаем сид:

			php artisan make:seeder ProductSeeder
		

Внутри метода run описываем данные:

			DB::table('products')->insert([
    ['name' => 'Apple', 'price' => 150],
    ['name' => 'Samsung', 'price' => 31000],
]);
		

Переводим бизнес-логику в сервисы и фасады

Старый проект состоит из функционала, размазанного по контроллерам? Улучшим структуру и сделаем код независимым. С этим помогут сервисы и фасады.

Сервисы — это классы, которые объединяют бизнес-логику в одном месте.

Например, если проект выполняет расчеты цен и скидок, можно создать класс:

			php artisan make:class PriceService
		

В этом классе описана бизнес-логика:

			class PriceService {
    public function calculateFinalPrice($price, $discount) {
        return $price * (1 - $discount / 100);
    }
}
		

Теперь сервис можно вызывать в контроллерах и моделях.

Фасады — это статический интерфейс к сервисам, который делает вызовы более читаемыми.

Например:

			class PriceFacade extends Facade {
    protected static function getFacadeAccessor() {
        return PriceService::class;
    }
}
		

С фасадом вызов становится простым:

			PriceFacade::calculateFinalPrice(100, 15);
		

Шаг 4. Перенос маршрутов и контроллеров

Начнем с маршрутов. Они определяют, как пользователи будут взаимодействовать с приложением.

Если в старом проекте использовались API-запросы для работы с внешними сервисами или мобильными приложениями, перенесем их в api.php и добавим префикс api для маршрутов:

			Route::get('/products', [ProductController::class, 'index']);
Route::post('/orders', [OrderController::class, 'store']);
		

Теперь про контроллеры. Они отвечают за логику обработки запросов и взаимодействие с моделями. В Laravel контроллеры работают по правилам MVC (Model-View-Controller).

Пример обычного метода контроллера:

			public function show($id)
{
    $product = Product::findOrFail($id);
    return view('products.show', compact('product'));
}
		

Laravel определяет маршруты групповыми методами — по префиксам, middleware или зонам авторизации.

Middleware — это посредники, которые обрабатывают запросы до их поступления в приложение.

Навесим middleware на маршруты, требующие авторизации пользователя:

			Route::middleware(['auth'])->group(function () {
    Route::get('/profile', [ProfileController::class, 'show']);
    Route::get('/settings', [SettingsController::class, 'edit']);
})
		

Политики контролируют доступ к определенным ресурсам, например, правку или удаление записей.

Пример метода политики:

			public function update(User $user, Product $product)
{
    return $user->id === $product->owner_id;
}
		

Политики можно подключать к маршрутам или напрямую вызывать в контроллерах.

Шаг 5. Перенос фронтенда и представлений

Если ваш старый проект использует обычные HTML-файлы, они легко преобразуются в Blade.

Blade — это встроенный механизм шаблонов. С его помощью создают пользовательские интерфейсы.

Например, перенесем главную страницу сайта:

			


    Главная страница


    Добро пожаловать!


		

Blade-версия:

			

    {{ $title ?? 'Главная страница' }}


    Добро пожаловать!


		

Теперь можно динамически передавать данные из контроллера:

			return view('welcome', ['title' => 'Мой сайт']);
		

Blade поддерживает механизм наследования, который упрощает работу с повторяющимися частями интерфейса.

Интегрируем Vue.js или React

Vue.js/React подключают, когда нужен динамичный и интерактивный интерфейс. Например, для SPA, реалтайм-функционала, сложных форм или фильтров.

Blade и JavaScript можно комбинировать: используйте Blade для рендеринга начального интерфейса и Vue.js/React для обработки интерактива.

Динамический интерфейс без JS

Livewire — это инструмент для создания интерфейсов без необходимости обращаться к внешним библиотекам JavaScript. Преимущество в том, что весь код пишется на PHP.

Livewire пригодится для динамических форм, фильтрации таблиц, уведомлений. Он упрощает код, сохраняя гибкость.

Шаг 6. Оптимизируем и тестируем проект

Отправная точка улучшения производительности — работа с Blade-шаблонами. Laravel сам их оптимизирует, но есть практики по дополнительному ускорению:

  • Минимизация логики в представлении. Злоупотребление PHP внутри Blade замедляет рендеринг страниц. Вместо описания сложной логики в шаблонах ее лучше перенести в контроллер.
  • Кэширование шаблонов. Работу приложения можно ускорить за счет запуска кэширования всех шаблонов, сокращая время компиляции — «php artisan view:cache».
  • Переиспользование. Если фронтенд состоит из повторяющихся фрагментов, рекомендуется использовать Blade-компоненты.

В приложениях SPA оптимизируем фрагменты JavaScript.

Laravel Mix генерирует минифицированные CSS и JS. Проверьте размер этих файлов в папке public/js. Если их вес больше 1 МБ:

  • Удалите лишние пакеты.
  • Используйте динамическую загрузку маршрутов или компонентов.

Для Vue можно использовать динамическую загрузку, чтобы не грузить весь фронтенд сразу:

			const ProductCard = defineAsyncComponent(() => import('./components/ProductCard.vue'));
		

Тестирование

Убедимся, что приложение работает корректно.

Проверим, например, что страница приветствия открывается и показывает нужный текст:

			$response = $this->get('/');
$response->assertStatus(200)->assertSee('Добро пожаловать');
		

Если используете Vue.js или React, для проверки компонентов применяйте Jest или Mocha.

Тест, который проверяет, что компонент отобразил нужный текст:

			expect(wrapper.text()).toContain('Сообщение для пользователя');
		

Если приложение работает с API:

			$response->assertJsonStructure([
    '*' => ['id', 'name', 'email']
]);
		

Для проверки приложения под нагрузкой можно использовать Artillery или JMeter.

Шаг 7. Разворачиваем и запускаем проект

Перенесли данные, создали маршруты и контроллеры, внедрили представления, оптимизировали приложение и протестировали его. Остался последний шаг — развернуть проект на сервере и запустить его.

Выбор сервера зависит от предпочтений и нагрузок:

  • Если важна скорость и масштабируемость, выбирайте Nginx. Он быстрее работает под высокой нагрузкой.
  • Если важен простой подход, используйте Apache. Он интегрируется с большинством систем.

Фоновые задачи можно связать с Supervisor. Инструмент автоматически запускает воркеров при сбоях, обеспечивая бесперебойную обработку задач.

Автоматизация развертывания

Чтобы релиз прошел безболезненно, нужен рабочий процесс CI/CD. Например, в GitHub Actions можно настроить сценарий, который:

  1. Проверит качество кода.
  2. Установит зависимости.
  3. Выполнит миграции.
  4. Зальет проект на сервер.

Предусмотрите откат, например, через Spatie Laravel Backup. Если что-то пойдет не так, у вас должна быть возможность вернуть предыдущую версию.

Инструмент Sentry поможет отслеживать ошибки, а New Relic — оценивать производительность.

Заключение

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

Следите за новыми постами
Следите за новыми постами по любимым темам
190 открытий3К показов