Создание шаблона приложений Symfony 7 с помощью FrankenPHP, Docker, PostgreSQL и php 8.4

В статье рассказывается, как создать универсальный шаблон для запуска проектов на Symfony, таких как монолитные приложения или API. Основой является сервер приложений FrankenPHP, написанный на Go, с использованием PostgreSQL в качестве реляционной базы данных. Для организации работы контейнеров используется Docker и Compose.

Основные этапы разработки:
1. Организация структуры проекта
Проект имеет простую структуру: одна папка для файлов Docker и другая для исходного кода Symfony. Основной файл конфигурации compose.yml размещается в корне проекта. Он описывает два основных контейнера:

🔸База данных PostgreSQL.
🔸Приложение Symfony, использующее FrankenPHP.

2. Настройка окружения для разработки
Для разработки создается файл compose.override.yml, позволяющий настраивать дополнительные порты, монтировать директории и включать Xdebug. Это упрощает отладку и разработку.

3. Создание Dockerfile для приложения
Dockerfile имеет несколько стадий:

🔹Базовый образ на основе Debian Bookworm и FrankenPHP.
🔹Разработка: включает зависимости, такие как Xdebug, и файлы конфигурации для разработки.
🔹Продакшн: оптимизированный образ с использованием OPcache и минимизацией зависимостей.

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

5. Конфигурация FrankenPHP
FrankenPHP работает через прокси-сервер Caddy. Используются конфигурации, рекомендованные в официальной документации, с возможностью настройки количества рабочих процессов и режима работы.

6. Symfony и дополнительные инструменты
Установлены зависимости, обеспечивающие высококлассный опыт разработки, включая Code Sniffer, phpstan, Rector, а также пакеты Symfony, такие как Doctrine ORM, Twig и инструменты для тестирования.

7. Оптимизация для продакшна
Для продакшна предусмотрена отдельная стадия сборки, где уменьшается нагрузка за счет использования OPcache и других оптимизаций. Создается файл composer.override.prod.yml, описывающий настройки для продакшн-окружения.

⚙️ Подпишись на нашу еженедельную email-рассылку, чтобы быть в курсе последних открытий и тенденций в мире бэкенда.

В еженедельных письмах ты найдешь:
● Языки программирования и фреймворки для бэкенда
● Архитектура и проектирование серверных приложений
● Базы данных и управление данными
● Безопасность и защита данных
● Облачные технологии и DevOps
● API и интеграции
● Тестирование и отладка
● Инструменты и утилиты для бэкенд-разработчиков
● Лучшие практики и паттерны проектирования

👉Подписаться👈

Моки — это инструмент для тестирования поведения объектов в изолированных условиях. Они позволяют заменить реальные зависимости на их имитацию, чтобы избежать обращения к внешним ресурсам, которые могут замедлить выполнение тестов.

Зачем нужны моки
Основная задача моков — проверять взаимодействие между объектами. Это достигается за счёт возможности задать ожидаемое поведение и проверить, насколько реальные вызовы совпадают с этими ожиданиями. Например, можно проверить, сколько раз вызывается метод и с какими параметрами.

Типичные ошибки при использовании моков
1. Отсутствие ожиданий
Если задать только возвращаемое значение без проверки взаимодействий, тест может не обнаружить проблемы.
✅ Правильный подход: указывать, какие методы должны вызываться и с какими параметрами.

2. Мокирование конкретных классов вместо интерфейсов
Моки лучше создавать на основе интерфейсов, так как они реже меняются, чем реализации.

3. Чрезмерное использование моков
Излишнее мокирование усложняет тесты и может указывать на проблемы с проектированием.

4 .Маскировка плохого дизайна
Если моки используются для тестирования тесно связанных компонентов, это может быть признаком нарушения принципа разделения ответственности.

5. Полная зависимость от моков
Хотя моки полезны, они не заменяют другие виды тестов, такие как интеграционные или end-to-end тесты.

Как распознать неправильное использование моков
🔸Тесты не отражают реальные сценарии, что приводит к игнорированию критичных ошибок в продакшене.
🔸Тесты слишком сильно связаны с реализацией, из-за чего частое обновление моков становится необходимостью.
🔸Чрезмерная сложность тестов делает их трудными для чтения и поддержки.

Выжимаем максимум скорости из PHP

При запуске PHP-приложений крайне важно правильно выбрать веб-сервер. Чтобы объективно оценить производительность популярных решений, было проведено тестирование не на искусственных данных, а на реальных примерах. Цель исследования заключалась не в создании рейтинга веб-серверов для PHP-приложений. Была цель показать, в каких условиях каждый сервер сможет продемонстрировать наилучшие результаты.

PHP Frameworks Bench

Библиотека для создания бенчмарков внутри PHP-фреймворков.

Как работает HTTP Kernel в Symfony?

HTTP Kernel (HTTP ядро) в Symfony — это ключевой компонент фреймворка, отвечающий за обработку HTTP-запросов и формирование ответов. Он реализует шаблон проектирования Front Controller и координирует весь жизненный цикл запроса и ответа.

Основной процесс работы HTTP Kernel

1. Получение запроса:
Входной файл (index.php) получает HTTP-запрос и передаёт его в ядро.

2. Маршрутизация:
Ядро использует компонент маршрутизации, чтобы определить, какой маршрут соответствует запросу, и какой контроллер должен быть вызван.

3. Вызов контроллера:
После определения маршрута вызывается соответствующий контроллер, который обрабатывает запрос и возвращает данные.

4. Формирование ответа:
Контроллер возвращает объект ответа, который может быть модифицирован дополнительными обработчиками (например, добавление заголовков).

5. Отправка ответа:
HTTP ядро отправляет готовый ответ обратно клиенту.

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

Основные компоненты
🔹 Запрос и ответ:
Symfony использует объект запроса, который содержит все данные HTTP-запроса (заголовки, параметры, тело и т.д.), и объект ответа, который формирует конечный HTTP-ответ.

🔹 Маршрутизация:
Компонент маршрутизации сопоставляет URL запроса с маршрутами, указанными в конфигурации, и определяет, какой контроллер и параметры использовать.

🔹 Контроллер:
Контроллер — это метод, который выполняет бизнес-логику, принимает параметры из запроса и возвращает ответ.

🔹 События:
Во время обработки запроса ядро генерирует события, на которые могут подписываться обработчики. Это позволяет изменять запрос, контроллер или ответ на разных этапах обработки.

🔹 Постобработка:
После того как ответ отправлен клиенту, могут выполняться задачи, которые не требуют немедленного завершения (например, отправка логов или очистка кэша).

Этапы обработки запроса
✔️Клиент отправляет HTTP-запрос.
✔️Ядро принимает запрос и вызывает маршрутизацию.
✔️Контроллер выполняет бизнес-логику.
✔️Генерируется HTTP-ответ.
✔️Ответ модифицируется при необходимости (например, добавляются заголовки).
✔️Готовый ответ отправляется клиенту.
✔️Выполняются завершающие задачи.

#вопросы_с_собеседований

Почему вам стоит задуматься о переходе на PHP 8.4?

В этой статье на медиуме рассматриваются основные причины, по которым вы можете захотеть обновить свои PHP-проекты до версии 8.4.

Будьте осторожны при использовании whereYear; даже если ваш столбец проиндексирован, он не будет использован, и база данных выполнит полное сканирование таблицы. Вместо этого лучше использовать диапазоны 🚀.

«Наконец я попробовал Pest для PHP и Laravel, а затем перешел на него.»

Pest — это современный инструмент для тестирования в PHP, созданный в 2021 году Нуну Мадуро, инженером Laravel. Pest быстро стал популярным благодаря своей интеграции с экосистемой Laravel и упрощению процесса тестирования. Основанный на PHPUnit, Pest сохраняет его мощь, но добавляет более удобный и лаконичный синтаксис.

Основное отличие Pest — это использование замыканий вместо классов для определения тестов. Такой подход делает код компактнее и проще для восприятия. Например, тест, проверяющий истинность условия, в Pest выглядит как одна строка, а не как целый класс, что ускоряет разработку и облегчает чтение кода.

Важной частью успеха Pest стала его привлекательная консоль, которая предоставляет четкий и понятный вывод тестов. Pest также поддерживает большинство возможностей PHPUnit, включая провайдеры данных, хуки (аналог setUp и tearDown), фильтрацию и группировку тестов. Однако Pest пошел дальше, предложив функции, которые делают его уникальным:

🔧 Тестирование архитектуры. Позволяет задавать архитектурные правила для кода, например, обязательное использование строгого режима.
📸 Снапшоты. Удобны для проверки неизменности данных.
🚀 Стресс-тестирование. Полезно для проверки производительности приложений.
🛠️ Плагины. Pest активно поддерживает расширяемость, что позволяет добавлять новые функции через сторонние модули.

Эволюция Pest связана с его глубокой интеграцией в Laravel-сообщество. Многие популярные проекты, такие как Spatie, Livewire и Filament, перешли на Pest, что сделало его стандартом де-факто в экосистеме Laravel. Благодаря обратной совместимости с PHPUnit, переход на Pest не требует кардинального изменения существующих тестов, что облегчает его внедрение.

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

Привет!

Мы хотели бы поближе с вами познакомиться! Будем очень признательны за ваши ответы на следующие вопросы!