Forwarded from Книги для программистов
Если ты давно смотришь на Laravel, но каждый раз откладываешь «до выходных, когда будет время» — вот тот самый пинок
Автор объясняет фреймворк так, чтобы опытный PHP-разработчик мог быстро въехать и начать писать живые продакшен-проекты.
Что внутри
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
💻 Подборка новостей по PHP за неделю:
🔹 CakePHP 4.6.3 — исправлены предупреждения о депрекейшнах в PHP 8.4 и 8.5, а также ошибки при работе с подзапросами, которые уже были выполнены.
🔹 PhpStorm 2025.3 — крупное обновление IDE: нативная интеграция Claude Agent, поддержка Laravel «из коробки», совместимость с PHP 8.5, улучшенная работа с дженериками и новая тема Islands.
🔹 Laravel 12.41 — представлен обновлённый современный шаблон писем, добавлены хелперы для длительностей (миллисекунды, недели, месяцы) и команда перезагрузки сервисов во время деплоя.
🔹 Symfony 8.0.2 — maintenance-релиз с исправлениями и улучшениями стабильности.
🔹 Symfony 1–7 декабря — активная работа над багфиксами после релиза Symfony 7.4 и 8.0, опубликован отчёт с SymfonyCon Amsterdam и анонсирована конференция SymfonyCon Warsaw 2026.
Библиотека пхпшника
#свежак
🔹 CakePHP 4.6.3 — исправлены предупреждения о депрекейшнах в PHP 8.4 и 8.5, а также ошибки при работе с подзапросами, которые уже были выполнены.
🔹 PhpStorm 2025.3 — крупное обновление IDE: нативная интеграция Claude Agent, поддержка Laravel «из коробки», совместимость с PHP 8.5, улучшенная работа с дженериками и новая тема Islands.
🔹 Laravel 12.41 — представлен обновлённый современный шаблон писем, добавлены хелперы для длительностей (миллисекунды, недели, месяцы) и команда перезагрузки сервисов во время деплоя.
🔹 Symfony 8.0.2 — maintenance-релиз с исправлениями и улучшениями стабильности.
🔹 Symfony 1–7 декабря — активная работа над багфиксами после релиза Symfony 7.4 и 8.0, опубликован отчёт с SymfonyCon Amsterdam и анонсирована конференция SymfonyCon Warsaw 2026.
Библиотека пхпшника
#свежак
👍4
💡 Совет по Laravel: Форматоры Faker
Поскольку Laravel использует FakerPHP для генерации фиктивных данных, вы можете использовать как
Библиотека пхпшника
📍 Навигация: Вакансии • Задачи • Вопросы с собеса
#vardump
Поскольку Laravel использует FakerPHP для генерации фиктивных данных, вы можете использовать как
numerify, так и bothify для генерации данных по определенному шаблону 🚀.Библиотека пхпшника
📍 Навигация: Вакансии • Задачи • Вопросы с собеса
#vardump
👍8
🚀 Symfony 7.4 — новый LTS, время апгрейда
В конце ноября 2025 вышла Symfony 7.4 — официальная Long-Term Support версия.
Это не просто «ещё одна версия»: 7.4 — серьёзный шаг к упрощению архитектуры и снижению лишнего кода, особенно если вы работаете на PHP 8.2+.
✅ Что реально даёт Symfony 7.4
Многоэкранные маршруты — теперь в атрибуте
Меньше проверок вручную — атрибут
Более гибкая безопасность — с
Унификация событий —
Возможность «допиливать» чужие классы — теперь можно добавлять атрибуты валидации/сериализации к DTO или другим классам, которые вы не контролируете. То есть, если используете сторонний класс — всё равно можно навесить свои ограничения через «прокси-классы».
🔎 Почему это важно
Symfony 7.4 — это не просто «новые фишки», это стремление к чистоте архитектуры, к уменьшению шаблонного кода и увеличению устойчивости. Это значит:
🔸 меньше boilerplate, меньше копипасты;
🔸 легче поддерживать, рефакторить и тестировать код;
🔸 проще масштабировать проекты — меньше «магии» конфигураций, больше явного, понятного кода;
🔸 долгосрочная стабильность: LTS-версия, с поддержкой багфиксов до 2028 и патчей безопасности до 2029.
Если вы всё ещё на Symfony 6.4 или 7.x — сейчас самое время планировать миграцию. Особенно, если проект живёт и будет жить несколько лет.
📅 Что делать прямо сейчас
Проверьте, что ваш PHP ≥ 8.2 — это минимальное требование для 7.4.
Проанализируйте, где у вас используются маршруты, проверки
Поднимите 7.4 на тестовом окружении, прогоните тесты — и постепенно заменяйте устаревшие YAML/аннотации/дублирование на современные атрибуты.
👉 Читать статью
Библиотека пхпшника
В конце ноября 2025 вышла Symfony 7.4 — официальная Long-Term Support версия.
Это не просто «ещё одна версия»: 7.4 — серьёзный шаг к упрощению архитектуры и снижению лишнего кода, особенно если вы работаете на PHP 8.2+.
✅ Что реально даёт Symfony 7.4
Многоэкранные маршруты — теперь в атрибуте
#[Route] env принимает массив. Можно одним маршрутом охватить, например, dev и test, и при этом его не будет в prod. Чисто, понятно, без дублирования.Меньше проверок вручную — атрибут
#[CurrentUser] теперь поддерживает union-типизации. Если в одном фаерволе используются, скажем, AdminUser и Customer, — можно сразу типизировать параметр метода как AdminUser|Customer, без ручных instanceof.Более гибкая безопасность — с
#[IsGranted] можно указывать проверку не для всего метода, а только для конкретных HTTP-методов (GET, DELETE и т.д.). Это даёт возможность держать логику (например, чтение и удаление ресурса) в одном методе, но с разным контролем доступа.Унификация событий —
#[AsEventListener] теперь поддерживает union-типы в сигнатуре: можно одним слушателем обрабатывать сразу несколько событий. Это сокращает дублирование кода и упрощает архитектуру.Возможность «допиливать» чужие классы — теперь можно добавлять атрибуты валидации/сериализации к DTO или другим классам, которые вы не контролируете. То есть, если используете сторонний класс — всё равно можно навесить свои ограничения через «прокси-классы».
🔎 Почему это важно
Symfony 7.4 — это не просто «новые фишки», это стремление к чистоте архитектуры, к уменьшению шаблонного кода и увеличению устойчивости. Это значит:
🔸 меньше boilerplate, меньше копипасты;
🔸 легче поддерживать, рефакторить и тестировать код;
🔸 проще масштабировать проекты — меньше «магии» конфигураций, больше явного, понятного кода;
🔸 долгосрочная стабильность: LTS-версия, с поддержкой багфиксов до 2028 и патчей безопасности до 2029.
Если вы всё ещё на Symfony 6.4 или 7.x — сейчас самое время планировать миграцию. Особенно, если проект живёт и будет жить несколько лет.
📅 Что делать прямо сейчас
Проверьте, что ваш PHP ≥ 8.2 — это минимальное требование для 7.4.
Проанализируйте, где у вас используются маршруты, проверки
CurrentUser, слушатели событий, валидация/сериализация — подумайте, как они могут упроститься.Поднимите 7.4 на тестовом окружении, прогоните тесты — и постепенно заменяйте устаревшие YAML/аннотации/дублирование на современные атрибуты.
👉 Читать статью
Библиотека пхпшника
🔥2
PHP жил, жив и будет жить. А ты?
Рынок требует от PHP-разработчиков всё больше: понимание сложных архитектур, алгоритмическая база, умение работать с высокими нагрузками. Хватит клепать сайты-визитки.
Акция 1 + 2:
Три курса по цене одного. Оплачиваешь самый дорогой, два других — в подарок.
Твой путь к Senior:
— архитектуры и шаблоны проектирования;
— алгоритмы и структуры данных.
Прокачаться
Акция до 31 декабря.
Не знаешь, что выбрать? @manager_proglib
Рынок требует от PHP-разработчиков всё больше: понимание сложных архитектур, алгоритмическая база, умение работать с высокими нагрузками. Хватит клепать сайты-визитки.
Акция 1 + 2:
Три курса по цене одного. Оплачиваешь самый дорогой, два других — в подарок.
Твой путь к Senior:
— архитектуры и шаблоны проектирования;
— алгоритмы и структуры данных.
Прокачаться
Акция до 31 декабря.
Не знаешь, что выбрать? @manager_proglib
😁10🌚2❤1👾1
Forwarded from Библиотека задач по PHP | тесты, код, задания
Что будет выведено данным скриптом?
Anonymous Quiz
6%
CompileError
17%
false
43%
true
19%
1
7%
0
8%
Ничего
🔥1
⚖️ Чем отличается ?: от ?? на самом деле
В проектах их часто путают, хотя работают они по разным правилам. Коротко и по делу — что выбирать и когда.
🔸 Тернарный оператор ?:
Проверяет true/false значение.
📌 Возвращает правую часть, если значение:
❗️ Но если ключ не существует → получите Undefined array key.
Пример:
🔸 Null coalescing оператор ??
Проверяет существует ли ключ и не
📌 Работает безопасно даже если ключ отсутствует.
📌 Возвращает любые значения, в том числе false и пустую строку.
Пример:
⚠️ Частая ошибка
Опечатка → ошибки нет → баг уходит в прод.
🧭 Что использовать?
Используйте ?:, если:
🔸 значение точно существует
🔸 нужно проверять truthiness
Используйте ??, если:
🔸 ключ может отсутствовать
🔸 важно отличать null от false, 0, ''
🔸 работаете с внешними API / неполными payload'ами
🐸 Библиотека пхпшника
📍 Навигация: Вакансии • Задачи • Вопросы с собеса
#элементарный_выбор
В проектах их часто путают, хотя работают они по разным правилам. Коротко и по делу — что выбирать и когда.
🔸 Тернарный оператор ?:
Проверяет true/false значение.
$displayName = $payload['name'] ?: 'Guest';📌 Возвращает правую часть, если значение:
'', null, false, 0 или другая «ложь».❗️ Но если ключ не существует → получите Undefined array key.
Пример:
$payload['name'] = false; // → 'Guest' $payload['name'] не существует → ошибка🔸 Null coalescing оператор ??
Проверяет существует ли ключ и не
null.$displayName = $payload['name'] ?? 'Guest';📌 Работает безопасно даже если ключ отсутствует.
📌 Возвращает любые значения, в том числе false и пустую строку.
Пример:
$payload['name'] = false; // → false$payload['name'] отсутствует → 'Guest'⚠️ Частая ошибка
?? может спрятать баги.$firstName = $payload['frist_name'] ?? 'Guest';Опечатка → ошибки нет → баг уходит в прод.
?: в такой ситуации бы упал и подсветил проблему.🧭 Что использовать?
Используйте ?:, если:
🔸 значение точно существует
🔸 нужно проверять truthiness
Используйте ??, если:
🔸 ключ может отсутствовать
🔸 важно отличать null от false, 0, ''
🔸 работаете с внешними API / неполными payload'ами
📍 Навигация: Вакансии • Задачи • Вопросы с собеса
#элементарный_выбор
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13
Whisp — простая стартовая точка для создания приложений PHP SSH
Whisp — это «чистый PHP» SSH-сервер, который позволяет запускать PHP-скрипты как SSH-приложения: при SSH-подключении вы попадаете не в обычную оболочку, а в PHP-приложение с TUI или CLI.
Можно задать набор «приложений» (скриптов) — и пользователи могут выбирать, куда подключаться, либо указывать имя приложения при SSH.
Требования: PHP 8.2+, расширения FFI, pcntl и libsodium
🔗 Github
Библиотека пхпшника
#инструменты
Whisp — это «чистый PHP» SSH-сервер, который позволяет запускать PHP-скрипты как SSH-приложения: при SSH-подключении вы попадаете не в обычную оболочку, а в PHP-приложение с TUI или CLI.
Можно задать набор «приложений» (скриптов) — и пользователи могут выбирать, куда подключаться, либо указывать имя приложения при SSH.
Требования: PHP 8.2+, расширения FFI, pcntl и libsodium
🔗 Github
Библиотека пхпшника
#инструменты
🤔7❤2🌚1
🛠️ How to: безопасно перейти с «уродливых» URL на чистые и человекочитаемые
Если ваш сайт всё ещё выдаёт адреса вида
🔎 «Уродливые» vs «чистые» URL
Ugly:
Clean:
Чистые URL лучше читаются, повышают CTR и дают поисковикам больше контекста — без магии, только структурное преимущество.
⚠️ Почему миграция опасна без подготовки
Неправильная замена структуры приводит к:
🔸 падению органического трафика
🔸 массовым 404
🔸 потере ссылочного веса
Это решается заранее настроенными 301-редиректами.
✔️ Пошаговый план
1) Аудит
Прокрасьте сайт Screaming Frog’ом, выгрузите все URL. Посмотрите server logs и определите приоритетные страницы.
2) Новая структура
Сформируйте правила для слегов: строчные буквы, дефисы, короткие словосочетания, единый паттерн.
3) Карта соответствия
Создайте таблицу:
4) Настройка 301 редиректов
Предпочитайте серверный уровень (Apache/Nginx).
Пример принципа:
Лучшие практики:
— один редирект вместо цепочек
— единое место хранения правил
— учитывать/очищать query-параметры последовательно
5) Обновление внутренних ссылок
Правьте меню, breadcrumbs, canonical-теги, sitemap.
Заново отправьте sitemap в Search Console.
6) Тестирование
Проверьте на стейдже:
— корректность всех 301
— отсутствие блокировок в robots.txt
— отсутствие утечек старых URL в шаблонах
7) Мониторинг
Первые две недели: ежедневно смотреть GSC, 404, трафик, падения по ключам. Быстро устранять ошибки.
⚙️ Советы разработчикам
Используйте regex-паттерны для массовых правил, но фиксируйте итоговую карту вручную.
Тестируйте редиректы через
Делайте релиз в низкую нагрузку и держите rollback-план.
🔧 Полезные инструменты
Screaming Frog
Google Search Console
Ahrefs/Semrush (бэки)
Серверные логи
📋 Чек-лист после миграции
Все старые URL возвращают 301 → новый канонический URL
Нет цепочек и дублей
Sitemap пересобран и отправлен
Canonical обновлены
404 исправляются оперативно
📚 Подробный разбор и практический кейс
Библиотека пхпшника
📍 Навигация: Вакансии • Задачи • Вопросы с собеса
Если ваш сайт всё ещё выдаёт адреса вида
/product.php?id=12345, вы теряете в удобстве, аналитике и небольшом SEO-профите. Переход на чистые URL — /products/red-running-shoes — даёт выигрыш, но только при корректной миграции, иначе риски высоки.🔎 «Уродливые» vs «чистые» URL
Ugly:
/article.php?id=9876Clean:
/blog/url-migration-best-practicesЧистые URL лучше читаются, повышают CTR и дают поисковикам больше контекста — без магии, только структурное преимущество.
⚠️ Почему миграция опасна без подготовки
Неправильная замена структуры приводит к:
🔸 падению органического трафика
🔸 массовым 404
🔸 потере ссылочного веса
Это решается заранее настроенными 301-редиректами.
✔️ Пошаговый план
1) Аудит
Прокрасьте сайт Screaming Frog’ом, выгрузите все URL. Посмотрите server logs и определите приоритетные страницы.
2) Новая структура
Сформируйте правила для слегов: строчные буквы, дефисы, короткие словосочетания, единый паттерн.
3) Карта соответствия
Создайте таблицу:
old_url → new_url → status → priority → notes → backlinks.4) Настройка 301 редиректов
Предпочитайте серверный уровень (Apache/Nginx).
Пример принципа:
Redirect 301 /product.php?id=987 /products/mens-black-leather-shoesЛучшие практики:
— один редирект вместо цепочек
— единое место хранения правил
— учитывать/очищать query-параметры последовательно
5) Обновление внутренних ссылок
Правьте меню, breadcrumbs, canonical-теги, sitemap.
Заново отправьте sitemap в Search Console.
6) Тестирование
Проверьте на стейдже:
— корректность всех 301
— отсутствие блокировок в robots.txt
— отсутствие утечек старых URL в шаблонах
7) Мониторинг
Первые две недели: ежедневно смотреть GSC, 404, трафик, падения по ключам. Быстро устранять ошибки.
⚙️ Советы разработчикам
Используйте regex-паттерны для массовых правил, но фиксируйте итоговую карту вручную.
Тестируйте редиректы через
curl и автоматические краулеры.Делайте релиз в низкую нагрузку и держите rollback-план.
🔧 Полезные инструменты
Screaming Frog
Google Search Console
Ahrefs/Semrush (бэки)
Серверные логи
📋 Чек-лист после миграции
Все старые URL возвращают 301 → новый канонический URL
Нет цепочек и дублей
Sitemap пересобран и отправлен
Canonical обновлены
404 исправляются оперативно
📚 Подробный разбор и практический кейс
Библиотека пхпшника
📍 Навигация: Вакансии • Задачи • Вопросы с собеса
This media is not supported in your browser
VIEW IN TELEGRAM
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
Please open Telegram to view this post
VIEW IN TELEGRAM
«Я хотел бы знать это раньше. Очереди в Symfony»
Простая очередь не вызывает проблем. Но когда их становится десятки, а через них проходят критичные бизнес-процессы, начинаются вопросы:
как называть очереди, чтобы не запутаться?
как избежать потерь сообщений?
как организовать мониторинг, чтобы видеть, что происходит внутри?
Материал разбирает ключевые ошибки, которые всплывают при проектировании системы очередей, и решения, которые помогают поддерживать инфраструктуру в рабочем состоянии.
❗ Ошибка №1. Хаотичный нейминг ресурсов
Когда сервисов много, а правил нет, RabbitMQ превращается в набор непонятных очередей и exchange'ей. Чтобы избежать «зоопарка», используется единый шаблон именования:
Он позволяет понять:
• кто публикует сообщение;
• что делает событие или команда;
• кто является потребителем;
• какой тип ресурса перед нами;
• является ли очередь failed-контуром.
❗ Ошибка №2. Сырые JSON вместо явных DTO
Если сообщение передаётся как обычная JSON-строка, изменения формата неизбежно ломают часть потребителей.
Решение:
• для каждой очереди заводится отдельный DTO;
• Messenger принудительно десериализует входящее сообщение в этот класс, даже если внешний продюсер не передаёт заголовок type.
Такой подход устраняет скрытые изменения контракта и гарантирует корректное преобразование на всех языках и сервисах.
❗ Ошибка №3. Отсутствие полноценного failed-контра
Если обработчик падает, сообщение легко потерять, особенно при кастомных конфигурациях. Надёжная схема:
• у каждого транспорта — своя failed-очередь;
• у каждой failed-очереди — собственный exchange;
• включён TTL (например, 7 дней), чтобы очередь не разрасталась до бесконечности.
Это обеспечивает прозрачность ошибок и упрощает повторную обработку.
❗ Ошибка №4. «Очереди работают → значит всё в порядке»
Даже если обработчики крутятся, без мониторинга можно не заметить, что сообщения лежат часами.
Минимальный набор наблюдаемости:
• размер очередей и их рост;
• количество ошибок и сообщений в failed-контуре;
• время обработки (P95 / P99);
• отдельные логи по каждому типу сообщений;
• простые алерты: рост очереди, всплеск ошибок, деградация скорости.
📌 Что это даёт командам
• прозрачный нейминг и понятная структура RabbitMQ;
• безопасные и стабильные контракты сообщений;
• предотвращение тихих потерь данных;
• наблюдаемость и предсказуемое поведение очередей;
• возможность быстро находить и устранять проблемы.
🔗 Хабр
Библиотека пхпшника
Простая очередь не вызывает проблем. Но когда их становится десятки, а через них проходят критичные бизнес-процессы, начинаются вопросы:
как называть очереди, чтобы не запутаться?
как избежать потерь сообщений?
как организовать мониторинг, чтобы видеть, что происходит внутри?
Материал разбирает ключевые ошибки, которые всплывают при проектировании системы очередей, и решения, которые помогают поддерживать инфраструктуру в рабочем состоянии.
❗ Ошибка №1. Хаотичный нейминг ресурсов
Когда сервисов много, а правил нет, RabbitMQ превращается в набор непонятных очередей и exchange'ей. Чтобы избежать «зоопарка», используется единый шаблон именования:
{service}.{eventOrCommand}[.{consumer}].{queue|exchange|routingKey}[.{failed}]Он позволяет понять:
• кто публикует сообщение;
• что делает событие или команда;
• кто является потребителем;
• какой тип ресурса перед нами;
• является ли очередь failed-контуром.
❗ Ошибка №2. Сырые JSON вместо явных DTO
Если сообщение передаётся как обычная JSON-строка, изменения формата неизбежно ломают часть потребителей.
Решение:
• для каждой очереди заводится отдельный DTO;
• Messenger принудительно десериализует входящее сообщение в этот класс, даже если внешний продюсер не передаёт заголовок type.
Такой подход устраняет скрытые изменения контракта и гарантирует корректное преобразование на всех языках и сервисах.
❗ Ошибка №3. Отсутствие полноценного failed-контра
Если обработчик падает, сообщение легко потерять, особенно при кастомных конфигурациях. Надёжная схема:
• у каждого транспорта — своя failed-очередь;
• у каждой failed-очереди — собственный exchange;
• включён TTL (например, 7 дней), чтобы очередь не разрасталась до бесконечности.
Это обеспечивает прозрачность ошибок и упрощает повторную обработку.
❗ Ошибка №4. «Очереди работают → значит всё в порядке»
Даже если обработчики крутятся, без мониторинга можно не заметить, что сообщения лежат часами.
Минимальный набор наблюдаемости:
• размер очередей и их рост;
• количество ошибок и сообщений в failed-контуре;
• время обработки (P95 / P99);
• отдельные логи по каждому типу сообщений;
• простые алерты: рост очереди, всплеск ошибок, деградация скорости.
📌 Что это даёт командам
• прозрачный нейминг и понятная структура RabbitMQ;
• безопасные и стабильные контракты сообщений;
• предотвращение тихих потерь данных;
• наблюдаемость и предсказуемое поведение очередей;
• возможность быстро находить и устранять проблемы.
🔗 Хабр
Библиотека пхпшника
🧠 Лайфхак: кеширование результатов и конфигурации в Laravel
🚀 Почему кешировать — и что именно
🔹 Кеш конфигурации и маршрутов
Laravel может сохранять все конфигурационные файлы и маршруты в виде готовых к быстрому использованию кеш-файлов. Это снижает количество файлов, которые фреймворк должен парсить при каждом запросе.
🔹 Кеш результатов запросов, API вызовов и часто запрашиваемых данных
Вместо повторного выполнения тяжёлых SQL-запросов или обращений к удалённым сервисам — результаты можно хранить в кеше и возвращать мгновенно
🧰 Как включить кеш конфигурации и маршрутов
Выполните в терминале проекта:
Если были изменения — сначала очистите, потом заново закешируйте:
📌 Эти команды значительно ускоряют старт приложения и минимизируют парсинг файлов при каждом запросе.
🧠 Кеширование результатов запросов (данных)
Laravel позволяет хранить результаты тяжёлых запросов или вычислений:
📍 Такой код означает:
💾 Laravel проверяет наличие
🔁 Если нет — выполняет запрос, сохраняет результат на 60 минут и возвращает его.
📈 Если есть — сразу отдаёт кеш без SQL-запроса
📦 Выбор драйвера кеша
Laravel поддерживает разные драйверы кеша, каждый с разным уровнем производительности:
⚡️ Redis / Memcached — лучшие для production-сред (in-memory).
📂 File / Database — подойдут для небольших проектов или dev-среды.
Настройка драйвера делается в
⚡️ Дополнительные кеш-стратегии
🔹 View cache — Blade шаблоны можно заранее скомпилировать (
🔹 Event cache — кеш событий Laravel (
🔹 Автоматизация кеша на проде — в CI/CD добавляйте
🧠 Когда использовать
✅ Production-среда: стабильные конфиги/маршруты и высокая нагрузка — кеш даст ощутимый прирост скорости.
⚠️ Разработка: кеш может мешать видеть изменения сразу, поэтому обычно отключают его в dev-окружении.
📌 Запросы к БД: кешируйте только те данные, которые действительно редко меняются — иначе результат устареет и придётся часто инвалидировать кеш.
🐸 Библиотека пхпшника
📍 Навигация: Вакансии • Задачи • Вопросы с собеса
🚀 Почему кешировать — и что именно
🔹 Кеш конфигурации и маршрутов
Laravel может сохранять все конфигурационные файлы и маршруты в виде готовых к быстрому использованию кеш-файлов. Это снижает количество файлов, которые фреймворк должен парсить при каждом запросе.
🔹 Кеш результатов запросов, API вызовов и часто запрашиваемых данных
Вместо повторного выполнения тяжёлых SQL-запросов или обращений к удалённым сервисам — результаты можно хранить в кеше и возвращать мгновенно
🧰 Как включить кеш конфигурации и маршрутов
Выполните в терминале проекта:
php artisan config:cache # кеширует всю конфигурацию
php artisan route:cache # кеширует все маршруты
Если были изменения — сначала очистите, потом заново закешируйте:
php artisan config:clear
php artisan route:clear
php artisan config:cache
php artisan route:cache
📌 Эти команды значительно ускоряют старт приложения и минимизируют парсинг файлов при каждом запросе.
🧠 Кеширование результатов запросов (данных)
Laravel позволяет хранить результаты тяжёлых запросов или вычислений:
use Illuminate\Support\Facades\Cache;
$posts = Cache::remember('index.posts', 60, function () {
return Post::with('comments', 'tags')->get();
});
📍 Такой код означает:
💾 Laravel проверяет наличие
index.posts в кеше;🔁 Если нет — выполняет запрос, сохраняет результат на 60 минут и возвращает его.
📈 Если есть — сразу отдаёт кеш без SQL-запроса
📦 Выбор драйвера кеша
Laravel поддерживает разные драйверы кеша, каждый с разным уровнем производительности:
⚡️ Redis / Memcached — лучшие для production-сред (in-memory).
📂 File / Database — подойдут для небольших проектов или dev-среды.
Настройка драйвера делается в
.env, например:CACHE_DRIVER=redis
⚡️ Дополнительные кеш-стратегии
🔹 View cache — Blade шаблоны можно заранее скомпилировать (
php artisan view:cache).🔹 Event cache — кеш событий Laravel (
php artisan event:cache).🔹 Автоматизация кеша на проде — в CI/CD добавляйте
config:cache и route:cache в деплой-скрипт🧠 Когда использовать
✅ Production-среда: стабильные конфиги/маршруты и высокая нагрузка — кеш даст ощутимый прирост скорости.
⚠️ Разработка: кеш может мешать видеть изменения сразу, поэтому обычно отключают его в dev-окружении.
📌 Запросы к БД: кешируйте только те данные, которые действительно редко меняются — иначе результат устареет и придётся часто инвалидировать кеш.
📍 Навигация: Вакансии • Задачи • Вопросы с собеса
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
⌨️ Топ-вакансий по PHP за неделю
Веб-разработчик (PHP) в продукт из сферы FinTech — до 500 000 ₽, Удалёнка (Москва)
Backend Developer — до 4 000 $, Удаленка (Москва)
Middle+ PHP / Fullstack Developer — до 300 000₽, Офис (Москва)
➡️ Еще больше топовых вакансий — в нашем канале PHP Jobs
Веб-разработчик (PHP) в продукт из сферы FinTech — до 500 000 ₽, Удалёнка (Москва)
Backend Developer — до 4 000 $, Удаленка (Москва)
Middle+ PHP / Fullstack Developer — до 300 000₽, Офис (Москва)
➡️ Еще больше топовых вакансий — в нашем канале PHP Jobs