Symfony Init — генератор стартового Symfony-проекта. Удобный способ быстро собрать базовую конфигурацию (версия PHP, сервер, БД/кэш, популярные пакеты) и сразу получить готовый проект под Docker. HA-кластер MySQL с Keepalived + Orchestrator. Пошаговый разбор, как организовать отказоустойчивость с VIP и автоматическим промоушеном реплики, включая важные нюансы про split-brain и semi-sync. Fastpath-блокировки и PostgreSQL 18. Объяснение причины ожиданий LWLock:LockManager и того, как изменения в PG18 уменьшают конкуренцию на блокировках при сложных схемах и большом числе индексов.
PHPHP.today
Самые свежие новости из мира PHP. Обновленные стандарты. Лучшие практики с примерами кода. Как писать чистый, читаемый и понятный код. Сотрудничество - @NikolasSumrak
КатегорияNewsЯзыкRUДобавлен06 июл. 2026 г.КачествоПроверен
Подписчики2.5K
Сред. просмотры13.3K
ERR148.5%
Цена-- RUB
Цена / подписчик--
Цена / просмотр--
Метрики обновлены: 06 июл. 2026 г.
Последние посты
Я поймал себя на мысли, что мы часто описываем «схему данных» сразу в трёх местах (DTO/validator/OpenAPI), а потом героически синхронизируем. Тут предлагают отдельный DSL под контракты данных — language-agnostic и без привязки к протоколу. Даже если не брать инструмент целиком, идеи про единый источник правды для схем можно утащить в любой PHP-проект. Scedel: DSL для описания схем данных Если у вас PHP-приложение всё ещё живёт на MySQL 5.7 «потому что работает», вот очень приземлённый способ перестать спорить на уровне веры и посмотреть на разницу с 8.0 через реальные нагрузки и метрики. Мне особенно нравится, когда сравнение не «в вакууме на бенчмарке», а с оговорками, где обновление реально даст профит, а где — только головную боль. MySQL 5.7 vs 8.0 в Yandex Cloud: что изменилось на практике Тема не «про PHP напрямую», но для бэкендера около PHP полезная: что будет, если внутрь PostgreSQL начать аккуратно протаскивать C++-абстракции, и где за это придётся платить. Читается как заметки человека, который реально пожил в кодовой базе Postgres и пытается сделать жизнь разработчика проще, не превратив всё в зоопарк. С++ внутри PostgreSQL: удобство против традиций История про open source API, но я здесь за кусок про ускорение поиска в PostgreSQL: триграммы/GIN и вот это всё, когда «вроде работает», а потом находишь индекс и внезапно получаешь почти x2. Люблю такие статьи за честные «грабли» и за то, что после них хочется пойти и проверить свои самые медленные запросы в проекте. Как я оптимизировал Postgres почти в 2 раза и что из этого вынес
Я присмотрелся к схеме «Laravel в проде», где Traefik стоит на входе, а внутри крутится FrankenPHP (и да, это уже не «классический PHP на каждый запрос»). Идея простая: разнести web/воркеры, нормально завернуть всё в Docker Compose, добавить healthcheck’и — и получить инфраструктуру, которую не стыдно показывать SRE. Вот тут разбор со схемой и практическими деталями: Архитектура Laravel для продакшена: Traefik + FrankenPHP Понравился кейс «RAG на PHP», потому что он без магии: как быстро собрать внутреннюю базу знаний, где PHP (Symfony) не просто «вяжет шаблоны», а реально участвует в пайплайне поиска. Автор показывает, как жить с чанкингом, гибридным поиском в Qdrant и что делать, чтобы MVP не развалился на первом же “а давайте ещё вот этот тип документов”. Забираю как готовый маршрут “сегодня вечером поднять прототип”: RAG на PHP + Qdrant: быстрый MVP для внутренней базы знаний Я залип на разбор роутинга в Waypoint: там не «мы написали ещё один роутер», а инженерная попытка выжать максимум из алгоритмов + OPcache shared memory, и при этом не упасть в рефлексию на каждом запросе. Особенно цепляет трёхуровневый матчинг (хеш + trie + fallback) и подход к генерации кода под кеш. Если вы любите ковырять внутренности фреймворков/либ — это прям вкусно: Как устроен роутинг в Waypoint: три уровня матчинга, zero-Reflection dispatch и кеш через OPcache shared memory Я давно люблю истории из серии «всё зелёное, а система уже полумёртвая», и тут прям такая: стойка деградирует, реплика отваливается, отказоустойчивость исчезает, а 5xx почти ноль — и поэтому никто не кричит “инцидент!”. Хороший короткий чек по тому, почему одних HTTP-метрик недостаточно и как незаметно потерять safety net на базе. Применимо к любому PHP-продакшену с PostgreSQL: Когда стойка умирает, а 5xx остаётся нулевым. Разбор скрытой деградации PostgreSQL
1. DDD и CQRS на PHP без Symfony — автор собрал «лёгкий стек» из трёх пакетов (DI-контейнер, DataMapper поверх PDO и PSR-15 роутер) и показал, как на этом реально поднять DDD-приложение без вечной боли «домен отдельно, Doctrine-энтити отдельно». Мне особенно зашло, что упор не на «ИИ написал код», а на то, где проходит граница ответственности: архитектуру всё равно держишь в голове ты, а ИИ может очень быстро закрыть имплементацию и тесты. DDD и CQRS на PHP без Symfony: собираем легковесный стек с помощью ИИ 2. Production-ready роутер за один вечер: PSR-15, атрибуты, middleware pipeline, кеш под OPcache, типизация и PHPStan level 9 — и всё это не как «пет-проект на выходные», а как библиотека, которую реально не стыдно тащить в проект (и даже публиковать). Полезно почитать хотя бы ради разборов edge-cases и того, как автор заставлял ИИ не просто генерить код, а проходить статанализ/тесты до зелёного. Как я написал production-ready PHP-роутер за один вечер с помощью ИИ 3. Кейс из Битрикса, но по сути про архитектуру синка и поиск: как не превратить 85 дилерских сайтов в SEO-дубли при централизованном каталоге, как разделить поля на «Lock/Edit» (и реально защитить редактируемое от перезаписи фидом), плюс отдельная вкусная часть про Manticore Search для артикулов со спецсимволами (когда дефисы/точки/слэши ломают поиск). Это прям «земля и прод», где PHP-код — лишь верхушка айсберга интеграционной логики. Федеративная архитектура дилерских сайтов: Bitrix, Manticore Search и OpenAI Batch API для каталога на 50k SKU 4. Ещё один практичный интеграционный кейс: портал запчастей + REST API для дилеров (разные 1С, разные структуры данных), где ключевая идея — «эталонный справочник» и минималистичный API вместо попыток “свести всё магией”. Понравилось, что автор не романтизирует: показывает ограничения (КИИ, стек, безопасность), и как из этого всё равно собрать систему, которая живёт и обновляет остатки/статусы без ручного ада. Интеграция 40+ дилеров через REST API: как мы построили портал запчастей крупнейшего сельхозпроизводителя в России
Я снова поймал себя на том, что «оптимизация PHP» для многих всё ещё = «поставь Nginx и помолись». Тут ребята сравнили WordPress на OpenLiteSpeed против классического LEMP на реальных нагрузках (RPS/latency/TTFB/CPU/RAM) — отличный материал, чтобы спорить не вкусом, а цифрами: WordPress с OpenLiteSpeed vs классический LEMP: реальные бенчмарки Если у вас microservice/database-per-service, то «дайте мне просто побольше железа» очень быстро превращается в дорогую привычку. Понравилось, что автор раскладывает sizing PostgreSQL по шагам (диск/RAM/CPU + базовые параметры на старте), чтобы потом не выяснять, что вы год платили за воздух: Считаем ресурсы под PostgreSQL Мини-напоминалка из серии «казалось бы, очевидно, но…»: как в PHP корректно понять, определена ли переменная, и не попасться на классическую ловушку isset() с null (плюс зачем это внезапно важно, когда к проекту прикручен статанализ): Как в PHP узнать определенна ли переменная (для версии PHP 7.4 и выше) Классный практический разбор по PostgreSQL: как совместить обычный поиск, полнотекстовый и «семантический» (и почему наивные подходы начинают разваливаться на реальных данных). Если вы делаете поиск в PHP-приложении и думаете «вынесу в отдельный сервис потом», вот тот самый «потом», которое лучше наступить заранее: Создание системы по управлению цифровыми активами для базы данных PostGIS. Часть 2. Работа с текстом Для тех, кто любит держать руку на пульсе: свежий обзор январского коммитфеста PostgreSQL 19 — что обсуждали, что движется, и какие изменения маячат на горизонте (полезно хотя бы понимать, куда едет платформа, на которой у нас половина продов): PostgreSQL 19: Часть 4 или Коммитфест 2026-01