Symfony *

Обычно процесс разработки API выглядит так: мы пишем контроллер. Затем каким-то образом его документируем. После чего фронтер, опираясь на такую документацию, пишет клиент.

Мы делаем одну и ту же работу трижды.

В прошлой статье я рассказывал, как избавиться от первого дублирования. С помощью бандла sunrise-studio/symfony-openapi можно генерировать OpenAPI-документ из кода, минуя процесс документирования.

Но это решает проблему только наполовину. Если OpenAPI-документ вытекает из кода, то клиент должен вытекать из OpenAPI-документа. Иначе написание клиента – и есть то самое дублирование.

В этой статье я расскажу как замкнуть цепочку:
Controller → OpenAPI → Client → Feature
Где каждый последующий шаг вытекает из предыдущего, а не дублирует его. 

Переход к микросервисной архитектуре неизбежно поднимает вопрос эффективности межсервисного взаимодействия. В PHP традиционный стек на базе PHP-FPM и REST API создает дополнительные накладные расходы: каждый запрос обрабатывается в отдельном процессе, что требует повторной инициализации контейнера зависимостей, загрузки конфигурации и всего контекста приложения. В результате увеличивается latency и снижается пропускная способность сервиса.

В этой статье мы шаг за шагом разработаем высокопроизводительный микросервис на Symfony 7, используя RoadRunner в качестве постоянного приложения-сервера, gRPC для межсервисного взаимодействия и Protocol Buffers для сериализации данных. По итогам вы получите полностью рабочий сервис и поймете, как построить производительную альтернативу классическому стеку PHP-FPM + REST.

В прошлой статье я уже рассказывал, как однажды устроился на работу и получил пачку «интересных» задач: вручную синхронизировать OpenAPI, оформленный в комментариях к коду, с самим кодом в десятке сервисов.

Тогда это звучало как начало анекдота, но мне было не до смеха.

С тех пор я сменил работу. И, как будто вселенная решила проверить моё чувство юмора, я снова вижу API, где контракт живёт рядом с кодом в ручных #[OA\...] атрибутах.

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

Несколько лет я в одиночку пишу сервер для своей 2D MMO RPG. Эта часть — про то, как изменился сам процесс разработки: игровую фичу я по-прежнему придумываю сам, а реализую её уже не один.

Это не демо в духе «модель выдала сниппет». Внутри — настоящая 2D MMO RPG: авторитарный сервер реального времени, тайловые карты, клиент на Unity. ИИ не создал эту систему, а ускорил: то, что раньше занимало дни и недели, теперь укладывается в часы и дни, и в одиночку я держу темп целой команды. Расскажу по порядку, как я к этому пришёл и где у подхода честная граница.

Есть одна мебельная фабрика. Исторически у этой фабрики IT хозяйство было не очень развито и со временем накопилось множество внутренних сервисов для расчета материалов, нагрузки на станки, учета временных затрат работников, доставки и прочего. Исходя из этих расчетов составляется себестоимость продукции. Далее накладывается маржа, и идет расчет доставки и сборки, в зависимости от условий. Фабрика захотела объединить все сервисы в один, основанный на веб, чтобы все расчёты и результаты можно было видеть в одном месте. Было выбрано делать новую веб систему на фреймворке Symfony (PHP).

В Symfony есть встроенный компонент Serializer, который покрывает 90% задач. Но его часто обходят стороной, то ли по привычке, то ли из-за того, что документация показывает только тривиальные примеры. А между тем, Serializer — гибкий и вполне годный инструмент, если понимать его архитектуру.

Разберём, как он устроен.

DI-контейнер — сердечко Symfony. Контроллеры, сервисы, слушатели событий, консольные команды, Voter, нормалайзеры — всё это сервисы, которые живут в контейнере и получают зависимости через него.

Разберём три уровня глубины: autowiring для повседневной работы, теги для расширяемых архитектур, compiler passes для магии уровня фреймворка.

Привет, Хабр!

В каждом проекте рано или поздно появляется логика вида «этот пользователь может редактировать этот пост, а тот нет». И начинается: if ($post->getAuthor() === $currentUser) в контроллерах, в сервисах, в шаблонах. Копипаста расползается, а потом приходит новое требование — «модератор тоже может редактировать, но только в своей категории» — и вы бегаете по двадцати файлам, молясь, что ничего не забыли.

Symfony Voters — механизм, который выносит всю логику авторизации в одно место. Не аутентификации (тип кто ты?), а именно авторизации (что тебе можно?). Разберём, как это работает.

REST API на Symfony писать удобно, но есть одна скучная особенность: контроллеры быстро начинают обрастать повторяющимся кодом. Парсинг запроса, валидация, однотипная JSON‑обёртка, try/catch с преобразованием исключений в HTTP‑ответы. Всё это несложно, но со временем размазывается по десяткам эндпоинтов и отвлекает от основной задачи.

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

Каждый раз, когда хотелось быстро попробовать что‑то на Symfony, начиналась одна и та же история: поднять контейнер с PHP‑FPM или FrankenPHP, провалиться в контейнер, поставить symfony/skeleton, настроить Nginx или Caddyfile, прописать переменные окружения... И всё это до того, как написана хоть одна строчка кода.

DI‑контейнер, консольные команды, компонентная архитектура... Ни для кого не секрет, Symfony заметно ориентируется на Java‑экосистему. Почему бы не попробовать сделать что‑то подобии start.spring.io подумал я.

Так появился пет-проект symfony-init.dev

Привет, я Андрей! Ну где ты был, ну открывай статью скорей :)

За технической инфой я обращался к команде разработчиков, в том числе к backend-разработчику Сергею Колеватову. Он пояснил мне за все технические штуки, а я уже поведаю вам подробнее.

В этот раз расскажу об опыте создания внутренней системы для госкомпании. Загвоздка, как всегда, была в сроках и ресурсах. А продукт нужен сразу порядочный. Готовый шаблон, Symfony Forms и «грязный» код. Выбор пал на скорость вместо качества — продукт запущен за 2 месяца, ноооо… мы получили «технический долг». Как к этому пришли и как решили проблему, расскажу прямо сейчас.

Tailwind 4, дизайн-токены, AI-генерация через Claude Code, Telegram Mini App, модульная архитектура CRUD, 20+ палитр из коробки и генератор собственных. MoonShine 4 большое обновление админ панели для проектов на Laravel и других фреймворках. Вместо часов настройки полей — один промпт. Вместо танцев с CSS — система дизайн-токенов. Вместо мобильного приложения — интеграция с Telegram. За 11 месяцев разработки мы переосмыслили то, как должна создаваться админ-панель в 2025 году. Внутри — полный технический разбор.

В версии PHP 8.5 появился оператор |> — так называемый pipe operator. Он давно используется в других языках (F#, Elixir, OCaml) и активно применяется в JavaScript. Его основная цель — упростить передачу результата одной операции в следующую, делая код более читаемым и линейным.

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

Привет! Меня зовут Никита Титков, я бэкенд-разработчик в Банки.ру. 

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

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

Давайте разбираться!

Laravel завоевал авторитет у бизнеса и программистов за эффективность решения задач. Автор не раз встречал суждение среди коллег, что опыт разработки на Symfony и Laravel равнозначны. Это миф. Ниже — 7 ловушек Laravel и практичных решений без отказа от фреймворка.

Привет, Хабр!

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

Искал реализацию EAV (Entity-Attribute-Value) паттерна на PHP или Symfony и не нашел. Типичная задача, но, на удивление, нет таких библиотек. Решил сделать свою [EAV bundle](https://github.com/maxkain/eav-bundle). Есть достаточно подробная документация...

Обзор развития проекта Boson PHP — платформы для создания десктопных приложений на веб-технологиях. Новый сайт, обновленная документация, веб-компоненты (главная фишка проекта), и технические особенности разных ОС.

Привет, Хабр!

Сергей Пантелеев и Данил Щуцкий собрали ключевые новости PHP и Laravel за июль. Будьте в тренде — читайте обзор! 🚀

«Redis умирает на 200k RPM, Prometheus не успевает скрейпить 50 серверов, а бизнес требует real-time дашборды. Знакомо?»

Пятница, 18:00. Дашборд в Grafana показывает timeout'ы при сборе метрик. Redis, который хранит данные для prometheus_client_php, жрёт 8GB памяти и 100% CPU. Prometheus не успевает опросить все 50+ серверов за отведённые 15 секунд. А в понедельник запускается Black Friday...

Эта статья — о том, как мы перешли с pull на push модель для мониторинга PHP-приложения в highload, почему выбрали UDP + Telegraf вместо классического подхода, и как теперь собираем метрики PHP с 50+ серверов без единого timeout'а.