Hi.Events

Опенсорс платформа для управления мероприятиями и продажи билетов

🔗 Github

Библиотека пхпшника

#инструменты

⚡️ How-to: serverless Symfony/PHP на AWS без Redis для сессий

У serverless есть ловушка: Lambda требует stateless, а PHP-сессии по умолчанию живут в файлах. В AWS Lambda это «песок»: инстанс исчез — сессия исчезла. Частый костыль — Redis/ElastiCache, но это уже VPC, обслуживание и лишние расходы. В статье предлагают более «чистый» вариант: хранить сессии и CSRF-токены в DynamoDB.

Идея простая: заменить файловый session handler на DynamoDB-backed, добавить TTL для авто-истечения и использовать Lambda Function URL (без API Gateway). В итоге приложение остаётся действительно serverless: масштабируется само, не требует инфраструктуры под Redis и платит «по факту». Отдельно разбираются single-table паттерны (сессии/CSRF/сущности в одной таблице), нюансы генерации URL в Symfony и честные компромиссы: cold start, стоимость на высоком стабильном трафике и гонки при параллельных вкладках.

🔗 Читать статью

Библиотека пхпшника

⌨️ Топ-вакансий по PHP за неделю

Middle PHP-разработчик (Fullstack) — от 200 000 до 250 000 ₽, Удалёнка/Офис (Москва)

PHP Developer — 200 000 —‍ 400 000 ₽, Удаленка (Москва)

Middle PHP-разработчик, Symfony (SaaS, b2b) — Договорная, Удалёнка (Москва)

➡️ Еще больше топовых вакансий — в нашем канале PHP Jobs

«Как я ускорил установку PHP-зависимостей в 5 раз с помощью Go»

PHP-разработчик решил проверить простую гипотезу:
что будет, если убрать PHP-runtime и сделать установку зависимостей по-настоящему параллельной?

Результат — go-composer: совместимый (почти) с Composer инструмент, написанный на Go.

Почему обычный Composer медленный
Коротко и без иллюзий:

• интерпретируемый PHP
• последовательная загрузка пакетов
• тяжёлый runtime даже для простых операций
• медленный SAT-resolver зависимостей

В CI это превращается в минуты ожидания.

Что сделал go-composer
Ключевая идея — конкурентная модель Go:
• параллельная загрузка всех пакетов (goroutines)
• один скомпилированный бинарник (~10 MB)
• отсутствие PHP runtime overhead
• эффективная работа с памятью

Архитектура (упрощённо)
Пайплайн выглядит так:
1️⃣ Парсинг composer.json / composer.lock
2️⃣ Resolver строит граф зависимостей
3️⃣ Пакеты загружаются параллельно
4️⃣ Генерируется совместимый autoload
5️⃣ Результат — привычный vendor/

Самое интересное внутри
Parallel Installer — сердце ускорения
Каждый пакет:

• скачивается
• проверяется по SHA-256
• распаковывается
• добавляется в lock

И всё это — одновременно, а не по очереди.

Бенчмарки (MacBook M1, 300 Mbps)
Результаты выглядят болезненно честно:
• Monolog (3 пакета): 3–4× быстрее
• Symfony app (36 пакетов): 4–5× быстрее
• Laravel app (80+ пакетов): до 5× быстрее

Что уже работает
✅ composer.json / composer.lock (чтение)
✅ semver (^, ~, >=, ||, *)
✅ PSR-4 / PSR-0 / classmap
✅ Packagist (P2 API)
✅ проверка хэшей

Что не работает (и это важно)
❌ Composer scripts
❌ Composer plugins
❌ VCS-репозитории
❌ Private Packagist
❌ полная совместимость composer.lock

👉 в продакшен — пока нет

Почему появился go-composer.lock
Полной совместимости с composer.lock пока нет, поэтому:
• если lock есть — используется он
• если нет — создаётся go-composer.lock
• флагами можно управлять поведением

Это честный технический компромисс.

👉 Хабр

Библиотека пхпшника

🧠 Оптимизируйте автозагрузку в Symfony с помощью Service Container preloading

🚀 Что такое preloading в контексте Symfony

Symfony пользуется Service Container, который создаёт множество PHP-классов и зависимостей для каждого запроса. Чтобы снизить накладные расходы на автозагрузку и повторную компиляцию этих классов на каждом запросе, можно включить OPcache-preloading — когда PHP загружает классы один раз на старте процесса и держит их в памяти.

Preloading помогает избегать многократного вызова автозагрузчика и снижает I/O-операции, потому что классы уже готовы к использованию до первого запроса.

⚙️ Как это работает в Symfony
1. Symfony может сгенерировать специальный preload-файл, который содержит список нужных классов — часто это файл вроде:

var/cache/prod/App_KernelProdContainer.preload.php

Этот файл включает в себя наиболее важные классы контейнера и зависимостей.

2. В php.ini нужно указать путь к этому файлу в директиве opcache.preload:

opcache.preload=/path/to/project/var/cache/prod/App_KernelProdContainer.preload.php
opcache.preload_user=www-data

Благодаря этому PHP заранее закеширует эти классы в OPcache ещё до обработки первого запроса.

3. Symfony поддерживает теги container.preload и container.no_preload, чтобы тонко настраивать, какие классы должны (или не должны) попадать в preload. Это даёт контроль над тем, какие части приложения загружаются заранее.

📈 Почему это даёт преимущество
🔹 Меньше автозагрузки: после preload’а PHP не вызывает автолоадер для этих классов, что снижает число системных вызовов и ускоряет отклик.
🔹 Более быстрый контейнер: код контейнера (сервисы, зависимости) часто входит в preload-список — это ускоряет его инициализацию.
🔹 Оптимизация OPcache: preload’енные классы остаются в памяти OPcache между запросами, снижая накладные расходы на парсинг и компиляцію PHP-файлов.

В реальных измерениях включение preload помогало снижать количество вызовов автозагрузки и ускорять работу приложения, сокращая время отклика и снижая нагрузку на CPU.

🧠 Когда использовать
✅ Production-среда: preload лучше всего раскрывает себя на стабильно работающем приложении без частых изменений файлов.
✅ Большие проекты: где много сервисов и зависимостей — preload помогает устранить значительный слой задержек.
⚠️ Dev-окружение: preload менее нужен, так как код часто изменяется — потребуется частый рестарт сервера/OPcache при изменениях.

📌 Практические рекомендации
➤ Убедитесь, что файл preload действительно сгенерирован — в некоторых проектах его может не быть по умолчанию.
➤ Настройте OPcache: включите opcache.enable_cli, увеличьте memory_consumption, max_accelerated_files, и установите validate_timestamps=0 на проде для стабильной загрузки.
➤ Используйте теги container.preload и container.no_preload, чтобы включать только действительно нужные классы — это помогает избегать загрузки лишнего.

📌 Итог
Оптимизация автозагрузки через OPcache preloading в Symfony — это мощный способ ускорить приложение на уровне PHP-рантайма:
✔️ сокращает работу автозагрузчика,
✔️ уменьшает I/O и время инициализации контейнера,
✔️ даёт заметный прирост производительности без изменения бизнес-логики.

Библиотека пхпшника

PHP в 2026

Если коротко: PHP не стагнирует. Он аккуратно, но системно взрослеет — и в 2026 это особенно заметно.

PHP 8.5
Релиз без «вау-революций», но с полезными доработками: pipe-operator, клонирование объектов с модификацией, улучшения замыканий, нормальные stack trace даже для fatal error. Это не хайп, а качество жизни.

Partial Function Application → PHP 8.6
Вот здесь начинается магия. PFA раскрывает pipe-operator по-настоящему: меньше анонимных функций, больше читаемого функционального кода. PHP медленно, но уверенно учится декларативности — и это хороший знак.

Pattern Matching (RFC)
Пока в обсуждении, но потенциал огромный. Более выразимые match-конструкции и is-проверки — шаг к более строгому и понятному коду.

FrankenPHP
Кандидат на будущее PHP-рантайма по умолчанию. Drop-in замена PHP-FPM, +10% производительности «из коробки», worker-mode, бинарные сборки, современный HTTP. Без боли — с профитом.

Mago
Линтер, форматтер и статический анализатор на Rust. Быстро. Строго. Практично. Пример того, как экосистема учится у других языков.

Async PHP / TrueAsync
Сложно, долго, но перспективно. Пока фокус на CPU-тасках и потоках, но если дойдём до удобного async I/O — PHP сильно выиграет в серверных сценариях.

PHPverse — возвращается в 2026
Онлайн-конфа показала, что комьюнити живо и массово. Это важно.

Tempest
Новый взгляд на PHP-фреймворки: современная архитектура, активное OSS-сообщество, третий мажорный релиз на подходе.

🔗 Ссылка на статью

Библиотека пхпшника

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

Библиотека пхпшника

#vardump

Какая функция используется для сортировки массива в естественном порядке (без учета регистра)?

Правильный ответ лежит в канале задач

💻 Подборка новостей по PHP за неделю:​

🔹 Statamic 6 Beta — CMS официально перешёл в beta-стадию после 21 alpha-релиза. Команда уверена в стабильности и обещает скорый выход stable-версии.

🔹 Laravel 12.47.0 — добавлены @includeIsolated для изолированных Blade-инклюдов, Cache::withoutOverlapping() для безопасных операций с блокировками, а также улучшена поддержка enum по всему фреймворку.

🔹 PHP 8.5.2, 8.3.30 и 8.4.17 — багфикс-релизы с улучшением стабильности. Пользователям PHP 8.5 настоятельно рекомендуется обновиться.

🔹 Symfony 12–18 января — улучшен HTTP Cache attribute, доработаны атрибуты событий контроллеров, опубликованы детали SymfonyLive Paris 2026 и представлена сертификация Symfony 8.

🔹 Filament v5 — релиз с поддержкой Livewire v4 и новым инструментом Blueprint. Обновление ориентировано на совместимость и минимальные риски при апгрейде.

Библиотека пхпшника

#свежак

💡Совет по Laravel: Eager Loading с конкретными столбцами

Знаете ли вы, что при использовании eager loading с отношениями вы можете указать именно те столбцы, которые вам нужны? Это уменьшит использование памяти 🚀

Библиотека пхпшника

#vardump

⚙️ PHP JIT: почему PHP уже не «медленный»

Фразу «PHP простой, но небыстрый» пора отправлять в архив. С выходом PHP 8.0 в язык пришёл JIT — Just-In-Time компиляция.

Суть простая: PHP во время выполнения замечает часто используемый код и компилирует его прямо в машинные инструкции. Меньше работы для Zend Engine, больше — напрямую для CPU.
Важно понимать: JIT не ускоряет всё подряд. В типичных веб-приложениях на Laravel узкие места — это база данных, сеть и I/O. Там JIT почти бесполезен.

Зато в очередях, воркерах, аналитике и массовой обработке данных прирост в 2–5× — реальность.

👉 Подробнее с примерами и бенчмарками — на Medium

Библиотека пхпшника

Что будет результатом работы кода в 8+?

🧠 DSL vs паттерны: что выбрать в проекте

В разработке часто встаёт вопрос: использовать ли DSL (Domain Specific Language) или опираться на дизайн-паттерны. Оба подхода помогают структурировать работу с данными и бизнес-логикой, но дают разный результат.

🔍 В чём разница

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

DSL описывает действия напрямую. Язык ближе к предметной области и проще для восприятия, особенно когда задачи сложные или действия цепочкой. Он позволяет выразить логику в явном виде и сократить количество лишних запросов и пост-обработки.

⚠️ Ограничения DSL

🔸 Создание DSL требует серьёзной подготовки: язык должен быть достаточно гибким, чтобы покрывать текущие и будущие сценарии.
🔸 Поддержка DSL может быть трудозатратной, особенно если доменные действия часто меняются.
🔸 Строковые DSL работают как «фронтенд кода» — за ними скрывается движок, который тоже нужно развивать.

✅ Когда что выбрать
Если предметная область хорошо понятна и устойчива — стоит строить DSL.
Если действия ещё уточняются, а изменения происходят часто — лучше опираться на паттерны.
В сложных проектах возможен гибрид: паттерны для структуры и расширяемости, DSL для выражения бизнес-логики.

💬 А как у вас в проектах? Чаще используете паттерны или внедряете DSL?

👉 Читать статью

Библиотека пхпшника

#элементарный_выбор

🛠️regexpbuilderphp — регулярные выражения, понятные человеку

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

🔗Github

#инструменты

How to: масштабировать до миллиарда документов в Symfony

Цены на бензин меняются по несколько раз в день. В итоге получается адский датасет: десятки гигабайт CSV и сотни тысяч записей цен за сутки. Если грузить это «как в SQL» (по документу на каждую цену), MongoDB быстро превращается в кладбище индексов и медленных агрегаций.

Как делают по-взрослому: сначала разбираем структуру данных (станции отдельно, цены отдельно), потом проектируем схему под запросы. Главный трюк — bucket pattern: складывать цены не по одной записи, а «ведрами» по станция + тип топлива + день, внутри хранить массив цен за день. Так документов становится в разы меньше, а дневные графики и «последнюю цену» можно доставать быстро.

Дальше — импорт не через «всё в память», а по дням: читаем CSV → временная коллекция → агрегация в bucket-документы → добавляем экстремумы (min/max) и предагрегаты (средние) → подтягиваем данные станции и денормализуем только то, что реально нужно.

👉 Читать статью

🧠 Rate Limiting — защита от перегрузки и злоупотреблений

🔹 Rate Limiting — это ограничение количества запросов, которое клиент может сделать за определённый период. Он предотвращает DoS-атаки, brute-force, резкий рост нагрузки и аварийные ситуации.

📌 В Laravel
Laravel имеет встроенную поддержку через middleware throttle, а также гибкий API для кастомных правил:
✔️ ограничение на количество запросов за минуту/час;
✔️ разные лимиты для разных пользователей (по ID, API-ключу или IP);
✔️ кастомные сообщения об ошибке.
Пример стандартного ограничения:

Route::middleware(['throttle:60,1'])->group(function () {
 Route::get('/posts', [PostController::class, 'index']);
});

🧾 Это ограничит пользова­теля до 60 запросов в минуту.
Для более гибкого контроля можно определить лимитер в App\Providers\RouteServiceProvider:

RateLimiter::for('api', function ($request) {
return Limit::perMinute(100)->by($request->user()?->id ?: $request->ip());
});
```

🧾 Такой подход позволяет задавать разные лимиты для аутентифицированных и анонимных пользователей.

📌 В Symfony
Symfony тоже имеет встроенный Rate Limiter с разными алгоритмами (фиксированное окно, sliding window, token bucket). Он может быть применён к маршрутам через сервисы и конфигурацию.

⚠️ Но для защиты от реальных DoS-атак лучше комбинировать приложение с ограничением на уровне веб-сервера или прокси (NGINX, Cloudflare), поскольку встроенный rate limiter требует загрузки Symfony для каждого запроса.

Библиотека пхпшника