Lift v1.3.0
Аргументы за 30 секунд

Почему Lift?

У каждого PHP-фреймворка есть своя история. У Lift она проста: современный PHP заслуживает фреймворк, не отягощённый решениями, принятыми в 2010 году. Никакого легаси-багажа. Никакой магии. Никаких контейнеров, которые весят больше вашего приложения.

Ландшафт проблем

Проблема
Типичный ответ
Ответ Lift
Тяжёлые DI-контейнеры
Symfony: мощный, но ~2 МБ скомпилированного кэша ещё до запуска вашего кода
Автосвязывание с кэшем рефлексии. Никакого шага компиляции, никакого XML.
Слишком много магии
Laravel: фасады, помощники, макросы — вы никогда не знаете, что и где выполняется
Явные привязки. Каждую зависимость можно отследить в вашей IDE.
Поддержка легаси-PHP
Многие фреймворки тянут за собой PHP 7.x / глобальное состояние / смешанные парадигмы
Только PHP 8.1+. Именованные аргументы, enum, fibers — современный PHP везде.
Рантайм только под FPM
Традиционные фреймворки перезапускают PHP на каждом запросе, теряя прогретое состояние
Первоклассные адаптеры RoadRunner, Swoole и FrankenPHP. Ноль изменений приложения.
Разрастание зависимостей
Slim тянет ~12 пакетов; Laravel поднимает 80+ в свежей установке
Ноль рантайм-зависимостей за пределами PSR. Вы выбираете каждый добавляемый пакет.
Тяжело тестировать
Глобали, статические фасады, последовательности загрузки делают юнит-тесты болезненными
App::handle($req) — без обращения к глобалям. Чистое тестирование вход/выход.
Каша из конфигурационных файлов
config/app.php, config/services.yaml, .env, config/packages/…
Один конструктор, один DI-файл. ENV-переменные читаются напрямую.
Асинхронность — запоздалая мысль
Фреймворки на FPM прикручивают асинхронность через очереди или внешние процессы
Адаптеры персистентных воркеров — это базовый примитив, а не пакет.

Чем Lift отличается

Рантайм-нативный с первого дня

Адаптеры RoadRunner, Swoole и FrankenPHP встроены в фреймворк — это не пакеты сообщества. Каждый рантайм оборачивает тот же $app в крошечный входной скрипт; ваши маршруты, контроллеры и middleware остаются байт-в-байт идентичными.

# оборачиваем тот же $app, затем запускаем сервер
(new RoadRunnerWorker($app))->serve(); → ./rr serve
(new SwooleServer($app))->start(); → php server.php
(new FrankenPhpWorker($app))->serve(); → ./frankenphp run

Поиск статических маршрутов за O(1)

Статические маршруты хранятся в хеш-карте — разрешение это одно чтение массива, без regex-сканирования. Динамические маршруты откатываются к скомпилированному regex только при необходимости. Это измеряется в бенчмарках, а не маркетинговый текст.

Смотреть числа бенчмарков →

Ноль рантайм-зависимостей вне PSR

composer require malinichevvv/lift-php устанавливает ровно PSR-интерфейсы и сам Lift. Никакого Guzzle, никаких аннотаций Doctrine, никакого заброшенного пакета, который вы не можете обновить. Вы владеете своим деревом зависимостей.

Тестируемый без трюков

$app->handle($request) возвращает Response — без суперглобалей, без буферизации вывода, без статического состояния. Каждый обработчик тестируется изолированно. Настоящие интеграционные тесты, а не цепочки замоканной загрузки.

Lift вам подходит, если…

  • Вы строите REST API, микросервис или внутренний инструмент
  • Вам нужен рантайм с персистентным воркером (RoadRunner, Swoole, FrankenPHP)
  • Вам нужна предсказуемая производительность под нагрузкой
  • Вы предпочитаете явные зависимости магии фреймворка
  • Вам нужны тесты, которые проверяют ваш код, а не настройку фреймворка
  • Вы программируете в паре с ИИ-ассистентом и хотите фреймворк, который он генерирует корректно
  • Вы строите Telegram/Slack-бота, сервис вебхуков или ИИ-шлюз

Lift — не тот инструмент, если…

  • Вам нужны готовый каркас аутентификации, шаблоны Blade или Admin UI «из коробки»
  • Ваша команда ожидает опыт «всё включено» в стиле Laravel
  • Вам нужна большая экосистема собственных пакетов (задачи, почта, уведомления…)
  • Вы строите традиционное серверно-рендерящееся HTML-приложение с формами

Готовы попробовать?

Рабочий JSON-API за 8 строк. Никаких конфигурационных файлов. Никаких сервис-провайдеров. Просто PHP.