SwooleApp: Легковесный фреймворк для Swoole

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


SwooleApp закрывает именно эту дыру — это лёгкий каркас для долгоживущих PHP-приложений без лишнего boilerplate.

Что такое SwooleApp
SwooleApp — фреймворк для PHP, работающий как постоянно запущенный сервер, а не «PHP-скрипт на запрос».
Это даёт:
❌ без перезапуска PHP на каждый запрос
⚡ меньше overhead и выше RPS
♻️ переиспользование ресурсов (Redis, БД, кэши)
🧵 асинхронность и фоновые задачи из коробки

Что есть внутри
Роутинг через PHP 8 attributes
Middleware
Task Workers для блокирующих операций
Встроенный «cron» (Cyclic Jobs)
State Container для пулов соединений и shared-ресурсов
Минимальная и прозрачная архитектура

Пример приложения (готово к запуску)
В репозитории есть demo-проект с Docker:
REST API для Redis (get / set)
Фоновая задача с имитацией тяжёлой работы
Циклическая джоба (лог раз в 10 секунд)
Middleware с замером времени
docker-compose up → всё работает

Ключевая идея: State Container
SwooleApp использует долгоживущие воркеры, поэтому:
пулы Redis / БД создаются один раз при старте
соединения переиспользуются
нет постоянного connect/disconnect
⚠️ Важно: контейнер изолирован на воркер — 4 воркера = 4 пула. Это ограничение архитектуры Swoole.

Task Workers — зачем они нужны
Любая блокирующая операция = стоп HTTP-воркера.
Решение:
HTTP-воркер отдаёт задачу в Task Worker
сам продолжает обслуживать запросы
результат возвращается асинхронно
Так сервер не «залипает» на sleep(), I/O или тяжёлых запросах.

Почему не Laravel / Symfony + Swoole
Коротко и честно:
они проектировались под stateless PHP-FPM
глобальное состояние → утечки памяти
ORM без пулов соединений
много блокирующего кода
для стабильности нужно слишком много воркеров
В итоге теряется смысл Swoole.
SwooleApp проектировался сразу под long-living процессы, без костылей.

Кому подойдёт
микросервисы и API
high-load
real-time / async
если хочется Swoole, но без боли
если Laravel/Symfony на Swoole разочаровали
Это не замена Laravel, а лёгкий каркас для другой задачи.

👉 Хабр

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

🎅 Секретный Санта для айтишников от Proglib.academy

Весь этот год команда Академии запускала курсы для айтишников. А под Новый год мы запускаем новый курс по ИИ-агентам и ставим под ёлку самый свежий стек 2025 года и обучение проектированию автономных нейросетевых экосистем — от LLM и ReAct-циклов до мультиагентных систем, LangGraph, AutoGen и продакшн-практик.

🎁 Хотим дарить подарки и приглашаем вас поучаствовать в конкурсе:

1️⃣ Упомяните курс Академии у себя в блоге.
2️⃣ Пришлите скрин сюда.
3️⃣ Получите секретный промокод на 10 000 ₽ при оплате любого курса.

Подходит всё — соцсети, блоги, Telegram-каналы от 300 подписчиков и более.

🎄 Акция действует до Нового года.

Win-win, всё как мы любим!

🧠 Обрабатывайте большие наборы данных порциями (Chunk) в Laravel

⚡ Почему это важно
Когда в таблице тысячи или миллионы записей, обычный get() или all() загрузит все строки в память сразу — это:
❌ сильно расточительно по памяти,
❌ может привести к падению по OOM,
❌ скрипт может не успеть выполнить работу целиком.
Для таких ситуаций Laravel предлагает метод chunk(), который загружает данные частями (порциями) вместо всего набора сразу.

🧰 Что делает chunk()
Метод chunk() берет определённое количество записей за раз и передает их в callback для обработки. Laravel автоматически загрузит следующую партию после завершения предыдущей.

use App\Models\User;

User::chunk(200, function ($users) {
 foreach ($users as $user) {
 // обработка каждого пользователя
 }
});

📌 В этом примере Laravel:
загружает 200 пользователей за раз,
обрабатывает их,
затем переходит к следующей партии.

🧠 Почему это круто
✨ Снижение пикового потребления памяти
Вместо загрузки всей таблицы в память — всего 200 записей. Это позволяет обрабатывать десятки и сотни тысяч строк без OOM.
✨ Меньше рисков таймаута
Когда вы делаете работу по частям, выполнение разбивается на небольшие, предсказуемые блоки.
✨ Гибкость для batch-обновлений/экспортов
Дизайн идеально подходит для миграций, обновлений атрибутов, экспортов CSV и фоновых задач.

🔍 Немного про chunkById() и улучшения
Если код обновляет записи внутри цикла, обычный chunk() может вести себя непредсказуемо, потому что набор может меняться. В таких случаях лучше использовать chunkById(), который гарантирует постоянный порядок по id и предотвращает пропуски/повторы при обновлениях.

User::chunkById(200, function ($users) {
 foreach ($users as $user) {
 $user->update(['active' => true]);
 }
});

🧠 Продвинутые приёмы
💡 Жадная загрузка связей: если в обработке вам нужны связи (->with('profile')), загружайте их вместе с батчами — это предотвращает N+1-проблемы внутри chunk.

User::with('orders')->chunk(200, function ($users) {
 foreach ($users as $user) {
 // $user->orders уже загружены
 }
});

💡 Используйте в фоновых командах или джобах: chunk() отлично подходит для консольных команд и jobs, которые работают с большими массивами данных и не должны завершиться по таймауту.

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

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

WANTED: PHP-МАСТЕР

Обвиняется в написании качественного кода на PHP, вопреки всем мемам. Мы ищем того, кто поднимет планку обучения в PHP-сообществе.

Приметы:

— в совершенстве знает PHP (знание Python или Go приветствуется);
— умеет готовить современные фреймворки и чистую архитектуру;
— готов делиться знаниями с большой аудиторией;
— хочет стать медийным экспертом.

Условия:

— гонорар за разработку материалов;
— рост личного бренда и узнаваемости;
— поддержка команды Proglib.

Сдаться властям

P.S. Видел пхпшника, который пишет как бог? Сдай его нам.

Знаете ли вы, что Laravel предоставляет метод missing() для настройки поведения привязки модели маршрута по умолчанию, когда модель не найдена? 🚀

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

#vardump

PHP-разработчик в мире AI: создаём агентов и внедряем в прод 🐘

Думали, AI — это только Python? На самом деле, главное — это архитектура и API. Мы научим вас строить мультиагентные системы, которые усилят любой проект.

Чему вы научитесь:

— строить «мозг» агента с помощью паттерна ReAct;
— оркестровать процессы в удобном интерфейсе n8n;
— соединять агентов в команды через CrewAI и AutoGen;
— внедрять RAG для поиска по базам знаний за миллисекунды.

Станьте тем, кто не просто пишет код, а создаёт автономные интеллектуальные системы.

Узнать подробности 🚀

💡Совет по Laravel: Отказ как «Не найдено»

При определении шлюзов или политик из соображений безопасности мы часто предпочитаем возвращать код 404 вместо 403. Laravel предоставляет для этой цели метод denyAsNotFound() 🚀

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

#vardump

🚀 Variable Scope, References, Closures & use в PHP

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

🧠 1. Область видимости (Scope)
Где переменная живёт и умирает.
• Local — существует только внутри функции
• Global — доступна везде, но требует global (плохая практика)
• Static — локальная, но помнит состояние между вызовами
📌 Static — ключ к счётчикам, генераторам ID, singleton-паттернам
❌ Global — почти всегда архитектурный запах

🔗 2. Ссылки (&) — работа с оригинальными данными
По умолчанию PHP копирует значения.
С & — вы работаете с той же памятью.
• Передача аргументов по ссылке
• Алиасы переменных
• Опасность в foreach (&$v) → обязательно unset($v)
📌 Используйте осознанно. Ссылки — мощный, но острый инструмент.

🧩 3. Closures — функции с памятью
Анонимные функции, которые можно:
• передавать
• хранить
• выполнять позже
И главное — они помнят контекст, где были созданы.

🎯 4. use — захват переменных
Closure не видит внешний scope автоматически.
• use ($var) — захват по значению
• use (&$var) — захват по ссылке
📌 Это основа колбеков, фильтров, middleware, event-handlers.

📍 5. Лексическая область видимости
Правило простое, но критичное:

Closure использует переменные из места создания,
а не из места выполнения.

Это объясняет 90% «магических» багов с колбеками.

💻 6. Реальный кейс
array_filter, array_map, usort — без closures + use они бесполезны.
Динамические условия, конфигурации, runtime-логика — всё строится на этом.

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

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

Что выведет данный код?

Как синхронизировать блокчейн и базу данных без расхождений

Одна из ключевых проблем блокчейн-бэкенда — точно отразить on-chain состояние в off-chain базе.
Не «примерно», не «потом поправим», а один в один.

В статье разобран production-подход на PHP:
— создание off-chain сущности до вызова блокчейна
— ожидание подтверждения транзакции в Soroban
— декодирование XDR через Stellar SDK
— корректная работа с I128, timestamp и enum
— маппинг результата смарт-контракта в Doctrine entity
— фиксация как успешных, так и failed-транзакций

Если вы строите off-chain логику поверх Stellar — это обязательный паттерн, а не опция.

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

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

🗂️Библиотека: разделение базового файла PHPStan

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

Основные возможности:

🔸Разделение базового файла: Пакет разбивает общий файл phpstan-baseline.neon на отдельные файлы в директории baselines/, где каждый файл соответствует конкретному идентификатору ошибки.

🔸Поддержка форматов: Поддерживаются как форматы neon, так и php для базовых файлов.

🔗 GitHub

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

How to: Web3 на PHP (Symfony 7.4) — без магии и костылей

Миф «PHP умер» не подтверждается уже больше десяти лет.
Миф «PHP не подходит для Web3» — из той же категории.

Пока Node.js доминирует во фронтенде dApp’ов, PHP + Symfony стабильно закрывают инфраструктурную часть Web3:
🔸 индексируют on-chain данные в off-chain хранилищах
🔸 управляют enterprise-кошельками и ключами
🔸 связывают Web2-бизнес-логику с Web3-протоколами

В статье разобрана production-ready Web3-интеграция на Symfony 7.4 и PHP 8.3+:
🔹 работа с блокчейном через JSON-RPC
🔹 взаимодействие с ERC-20 контрактами
🔹 аутентификация через Sign-In with Ethereum (без паролей)
🔹 обработка on-chain событий через Symfony Messenger

👉 Полный разбор архитектуры и кода — в статье

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

Хуки свойств в PHP: геттеры и сеттеры не нужны

В PHP 8.4 появилась долгожданная возможность — хуки свойств.
Это встроенная логика чтения и записи значения прямо в объявлении свойства. Без отдельных методов, без шаблонных getSomething() и setSomething().
Код становится компактнее, выразительнее и проще для сопровождения.

🤔 В чём была проблема раньше
До этого у разработчиков было всего два варианта:
🧱 классический подход с приватными полями и методами доступа;
⚙️ promoted-properties из конструктора — удобно, но без логики.
Минус был общий:
❌ негде аккуратно разместить валидацию;
❌ сложно добавить логирование изменений;
❌ неудобно реализовать ленивые вычисления;
❌ класс быстро разрастался вспомогательными методами.

✨ Что изменилось с хуками
Теперь PHP позволяет перехватывать:
👀 момент чтения свойства;
✍️ момент записи значения.

При этом:
📌 снаружи используется привычный доступ к свойству;
🧠 внутри — чётко определённое место для логики;
🧩 в одном классе можно сочетать обычные свойства и свойства с хуками.

🧮 Виртуальные свойства
PHP 8.4 позволяет создавать свойства без собственного хранилища.

Такие свойства:
🪄 не занимают память;
🔄 вычисляются при каждом обращении;
🧩 выступают как интерфейс к другим данным объекта.

Полезно для:
объединённых представлений данных;
вычисляемых значений;
упрощения публичного API модели.

🧬 Наследование и контроль поведения
Хуки полностью поддерживают наследование:
🔁 поведение можно расширять или переопределять;
🔒 отдельные хуки можно пометить как final;
🧱 контроль инвариантов остаётся на стороне базового класса.
По возможностям это сопоставимо с методами, но на уровне свойств.

⚠️ Важные ограничения
Есть особенности, которые важно учитывать:
🚫 хуки несовместимы с readonly-свойствами;
🔗 изменение по ссылке может обойти логику записи;
🧪 не все внутренние функции PHP вызывают хуки одинаково.
Это не ошибки, а архитектурные компромиссы.

🔗 Хабр

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

🎄 С Новым годом, коллеги!

Этот год был насыщенным: релизы, оптимизации, неожиданные баги, долгожданные фичи и много практики с реальными проектами на PHP. Экосистема продолжает развиваться — язык взрослеет, инструменты становятся стабильнее, а требования к качеству кода только растут.

✨ Небольшое напоминание на праздники
Коллеги, давайте в эти дни немного выдохнем.
🧠 Переключимся от дедлайнов и продакшена
☕ Дадим мозгу восстановиться
📚 И, самое главное, спокойно вспомним лучшие посты этого года, начиная с завтрашнего дня

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

Спасибо, что читаете, обсуждаете и думаете вместе.
Хороших праздников, чистого кода и спокойных логов 🎆

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

💾 Новый тренажёр по SQL

Разработчик создал SQL Noir — интерактивную детективную игру, где расследования ведутся с помощью SQL-запросов.

Погружаешься в сюжет и решаешь загадки с реальными SQL-запросами.

🔗 Ссылка

#лучшее2025

Laravel: Менее известные, но полезные команды Composer

Composer — это основной инструмент для управления зависимостями в PHP. Если вы работаете с Laravel, то наверняка уже знакомы с такими командами, как composer install и composer update. Однако у Composer есть менее известные, но очень полезные команды, которые могут значительно упростить вашу работу над проектом.

1. composer outdated
Эта команда показывает, какие зависимости вашего проекта устарели. Она выводит список всех пакетов, для которых доступны более новые версии, указывая текущую и последнюю версии. Это удобный способ следить за обновлениями и безопасностью проекта без необходимости сразу обновлять все пакеты.

2. composer show
С помощью этой команды можно получить подробную информацию обо всех установленных пакетах. Кроме того, если указать конкретное имя пакета, можно узнать его описание, текущую версию и зависимости. Например:

composer show backpack/crud

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

3. composer why
Если вы хотите понять, почему определённый пакет установлен в проекте, используйте команду composer why. Она покажет, какие зависимости требуют установки данного пакета. Это особенно полезно для анализа сложной цепочки зависимостей.

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

5. composer check-platform-reqs
При работе на разных платформах может возникнуть необходимость убедиться, что все необходимые расширения PHP установлены. Команда composer check-platform-reqs проверяет, соответствует ли ваша система требованиям, указанным в composer.json. Она также проверяет версию PHP и расширения.

#лучшее2025