В 2017 году был запущен проект Bref с целью запуска PHP в бессерверной среде на AWS Lambda.

В 2020 году начались замеры количества запросов (или заданий, cron-задач, вызовов и т.д.), которые обрабатываются с его помощью каждый месяц. Это было сделано для того, чтобы показать AWS, что PHP заслуживает большего внимания и поддержки.

Ежемесячно данные добавлялись в электронную таблицу, и их количество постоянно растет. Как упомянуто в заголовке, на сегодняшний день с помощью PHP на Lambda обрабатывается более 40 миллиардов запросов в месяц.

Методика замеров описана в документации.

Кратко: каждые 100 вызовов среды выполнения отправляется несколько байтов данных через UDP. Эти данные полностью анонимны (вот содержимое пакета: Invocations_100:1|c\nLayer_fpm_100:1|c), а использование UDP гарантирует, что передача занимает всего несколько микросекунд (она неблокирующая). Эти байты доходят до небольшого сервера на EC2, который увеличивает счетчик в CloudWatch.

Наличие этой метрики оказалось крайне полезным во взаимодействии с AWS — теперь проект Bref воспринимается ими гораздо серьезнее. Примерно 1 из 1000 вызовов AWS Lambda — это PHP с Bref.

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

Кроме того, удалось интегрировать счётчик метрик в режиме реального времени (почти реального времени, данные кэшируются на несколько минут) на главной странице проекта: bref.sh

⚙️ Улучшаем производительность кода с AI

Обнаружили в профилировщике тормозящий код? Попробуйте этот промпт, чтобы AI помог вам оптимизировать его:

📝 Промпт:

Analyze the following PHP code and suggest optimizations for better performance. Identify bottlenecks, improve memory usage, and recommend alternative approaches.

// Вставьте ваш код здесь

💡 Дополнительные возможности:

— Добавьте Refactor it using modern PHP features (e.g., OPcache, JIT, Fibers), если хотите использовать новейшие возможности PHP.
— Добавьте Optimize it for concurrency using Swoole or ReactPHP, если важна многопоточность и высокая нагрузка.
— Добавьте Suggest a profiling strategy using Xdebug or Blackfire, если нужна диагностика.

💬 Какие инструменты вы используете для профилирования кода?

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

♻️ Переопределение с помощью интерфейса

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

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

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

❓ PDO или ORM?

PDO — для тех, кто ценит полный контроль. Пишете SQL вручную, понимаете, что происходит под капотом. Гибкость максимальна, но код засоряется повторениями, а сложные запросы становятся испытанием при развитии проекта.

ORM (Eloquent, Doctrine) — путь удобства. Работаете с объектами вместо SQL, код становится чище, а разработка быстрее. Но магия абстракции может привести к неожиданным SQL-запросам, проблемам с производительностью и сложной отладке.

💬 Вы за прозрачность и контроль или удобство и скорость разработки? Какой путь выбираете вы?

Библиотека пхпшника #междусобойчик

Богатые и анемичные сущности в PHP с Doctrine: как правильно структурировать бизнес-логику

Статья обсуждает концепцию Rich Entities (богатых сущностей) в разработке на PHP, особенно в контексте сложных бизнес-приложений, использующих Doctrine ORM для объектно-реляционного отображения. В статье проводится сравнение Rich Entities с традиционным подходом Anemic Entities (анемичных сущностей) и объясняется, как богатые доменные модели могут привести к лучшей инкапсуляции бизнес-логики и улучшению поддерживаемости.

Анемичные сущности:

🔸 Это сущности, которые служат только контейнерами данных, не содержащими бизнес-логики.

🔸 Логика переносится в сервисные классы, что приводит к фрагментированному коду, трудностям с тестированием и слабой инкапсуляции.

🔸 Этот подход часто используется в приложениях с преобладанием операций CRUD, но может привести к дублированию кода и хрупким архитектурам.

Богатые сущности:

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

🔹 Бизнес-правила (например, проверка корректности платежей) проверяются внутри сущности, что помогает поддерживать согласованность модели и её близость к реальному домену.

🔹 Этот подход лучше соответствует принципам SOLID (например, Принцип Единой Ответственности и Принцип Открытости/Закрытости).

Преимущества богатых сущностей:

🔸 Улучшенная тестируемость: Тестирование становится проще, так как бизнес-логика находится внутри сущности, что позволяет создавать более фокусированные тесты, ориентированные на домен, без необходимости в множестве заглушек или сервисных слоях.

🔸 Лучшая читаемость кода: API сущности отражает домен (например, $order->pay() вместо $orderService->payOrder()), что делает код более понятным и легче воспринимаемым.

🔸 Инкапсуляция и целостность домена: Сущность управляет своим состоянием и поведением, гарантируя, что бизнес-ограничения соблюдаются и поддерживаются.

Статические методы create():

В статье рекомендуется использовать статические методы create() для создания сущностей, чтобы гарантировать их создание в валидном состоянии. Это позволяет избежать создания неполных или некорректных объектов и концентрирует логику инициализации в одном месте.

Сервисный слой против логики сущности:

🔹 Часто бизнес-логику переносят в сервисный слой (например, OrderPaymentService), но это может привести к слабой инкапсуляции и дублированию кода.

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

Когда использовать богатые и когда анемичные сущности:

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

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

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

Buggregator — удобная отладка

Buggregator — это идеальный инструмент отладки, который работает как сервер VarDumper, профилировщик Xhprof, локальный SMTP-сервер, локальный Sentry и многое другое.

Ознакомьтесь с постом Павла Бучнева о профилировании PHP (Laravel) приложений с помощью xhprof.

Библиотека пхпшника #инструменты

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

🔎 Laravel 12.4: Поддержка конвейеров в построителе запросов
Команда Laravel выпустила версию 12.4.0, которая включает метод pipe() для построителя запросов, возможность условного пропуска миграций, метод Arr::sole() и другие улучшения. ​

🔎 Eloquent: Приведение строк к HTML в Laravel 12.4
Начиная с версии 12.4, в Laravel можно автоматически приводить атрибуты Eloquent к HTML-строкам с помощью кастомного класса AsHtmlString. Это позволяет безопасно работать с HTML-содержимым в моделях. ​

🔎 Релизы Symfony 6.4.20 и 7.2.5
Symfony объявил о выходе версий 6.4.20 и 7.2.5, содержащих важные исправления и улучшения. Рекомендуется обновиться до этих версий для обеспечения стабильности и безопасности приложений. ​

🔎 Неделя Symfony #952 (24–30 марта 2025 года)

Библиотека пхпшника #свежак

Как использовать принцип инверсии управления в Laravel? 

​Принцип инверсии управления (Inversion of Control, IoC) в Laravel реализуется с помощью сервис-контейнера, который управляет зависимостями между классами и их внедрением. Это позволяет создавать гибкую и тестируемую архитектуру приложений.

В нашем примере:

Определяется интерфейс PaymentGatewayInterface с методом charge, который должен быть реализован любым платежным шлюзом.

Класс StripePaymentGateway реализует этот интерфейс, предоставляя конкретную логику для обработки платежей через Stripe.

Класс OrderProcessor зависит от PaymentGatewayInterface. Вместо создания экземпляра конкретного платежного шлюза внутри себя, он получает его через конструктор, что соответствует принципу инверсии управления.

В сервис-контейнере Laravel регистрируется связь между PaymentGatewayInterface и его реализацией StripePaymentGateway с помощью метода $app->bind().

Создание экземпляра OrderProcessor осуществляется через сервис-контейнер с помощью метода $app->make(), который автоматически внедрит необходимые зависимости.

Использование IoC в Laravel позволяет:​

🔸 Разделить ответственность между классами, делая их более независимыми и удобными для тестирования.

🔸 Легко заменять реализации зависимостей, например, для использования другого платежного шлюза, достаточно зарегистрировать новую реализацию в контейнере.

🔸 Упрощает тестирование, позволяя подменять реальные реализации зависимостей на заглушки или моки.