⚙️ В чем разница между балансировщиками нагрузки, обратными прокси и API-шлюзами?

1️⃣ Балансировщик нагрузки

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

Он получает запрос, перенаправляет его на сервер, принимает ответ и отправляет его обратно клиенту.

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

2️⃣ Обратные прокси

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

Они обеспечивают контроль за сетевым трафиком, снижая риски атак и угроз.

Дополнительно, они могут кэшировать контент для уменьшения нагрузки на сервер, сжимать данные для ускорения передачи и управлять SSL/TLS-шифрованием, разгружая веб-серверы.

3️⃣ API-шлюзы

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

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

Идеально подходят для работы с микросервисной архитектурой.

🖥 Laravel → NestJS: карта соответствий для тех, кто и так всё знает

Вы годами живёте в Service Container, пишете Form Requests на автомате и знаете, где у Laravel «магия». Вопрос не в том, умеете ли вы, — а в том, как быстро вы смапите привычные концепции на чужой стек, когда прилетит проект на NestJS.

Deva Jayantha сделал именно это: не туториал «с нуля», а таблицу перевода Laravel → NestJS по девяти осям:

— Service Container vs явная регистрация провайдеров в модулях;
— Form Request vs связка DTO + class-validator + Pipe;
— Middleware vs Guards/Pipes/Interceptors (и почему middleware в Nest только про логирование и CORS);
— Eloquent (Active Record) vs TypeORM (Data Mapper);
— Exception handler vs Exception Filters.

Главный сдвиг парадигмы: «convention over configuration» против «explicit over implicit». Всё, что Laravel делает за вас неявно, Nest требует объявить руками и это не хуже, это другая философия с другими trade-offs для больших модульных кодовых баз.

Ничего революционного там не найти, но за 15 минут можно получить готовую ментальную модель, которая сэкономит день онбординга на TypeScript-проекте. Полезно и как аргументация в спорах «а почему у нас Laravel».

🔗 Читать статью

⌨️ Топ-вакансий по PHP за неделю

Middle Fullstack Developer (PHP/Laravel + React) — от 2000 до 2700 $ — удалёнка

Fullstack-разработчик (PHP, JS) — удалёнка/гибрид (Казань) — Danaflex

Senior Backend разработчик (PHP) — удалёнка — MPSTATS

➡️ Еще больше топовых вакансий — в нашем канале PHP Jobs

🏗 Fat controller, fat model, fat service — выбери, где тебе будет больно

Бизнес-логику нужно куда-то положить. Вечный спор не про «как правильно», а про то, какую боль ты выбираешь осознанно.

🔹 В контроллере.

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

🔹 В модели (Active Record).

Логика рядом с данными, удобно. Но модель начинает знать про отправку писем, платёжные шлюзы и очереди. God-object, который тащит за собой полприложения в каждый тест. Боль: связность.

🔹 В сервисах / Action-классах.

Логика отделена от транспорта и от хранилища, тестируется на чистых данных. Цена — больше файлов и дисциплина, чтобы сервис не превратился в свалку из 30 методов. Боль: дисциплина.

Практичная середина, которая выживает дольше всего: тонкий контроллер (валидация + вызов), модель хранит данные и простые инварианты, Action/сервис держит сценарий. Один use-case — один класс с одним публичным методом. Растёт линейно, читается за минуту, тестируется без фреймворка.

💬 Какие проекты на каком варианте пишете?

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

✔️ PHP-тест: один запрос кладёт воркеры

CPU одного ядра — в полку на несколько секунд. PHP-FPM воркеры заканчиваются, сайт встаёт. И всё из-за одного поля формы 👇

📦 Задание

Форма регистрации компании. Поле «теги деятельности» — строка вида php, backend, api. Сделали «надёжную» валидацию регуляркой. Работало месяцами. Потом сайт начал периодически зависать на 5–10 секунд, мониторинг показывает 100% CPU на одном ядре, а APM — что время уходит внутри preg_match. Воспроизводится только на определённых вводах от пользователей.

// src/Validation/TagsValidator.php
class TagsValidator
{
    private const PATTERN = '/^([a-zA-Z0-9]+\s*,?\s*)+$/';

    public function validate(string $tags): bool
    {
        return (bool) preg_match(self::PATTERN, $tags);
    }
}

🔹 Задачи

— Объяснить механизм катастрофического бэктрекинга на этом паттерне
— Привести пример строки, которая «вешает» движок регулярных выражений
— Переписать проверку

Ставьте → 🔥 если нравится формат. Если нет → 🌚

💬 Решения пишите в комменты под спойлер — сравним подходы.

🐳 Работа с Docker CLI

Собрали образ и он весит 2 ГБ, а вы не понимаете, откуда столько? docker history покажет размер каждого слоя — сразу видно, какая инструкция в Dockerfile раздула образ.

🔹 Зачем это нужно

— Каждая инструкция в Dockerfile создаёт слой, и docker history показывает размер каждого.
— Сразу видно, если COPY затянул 800 МБ зависимостей.
— Помогает оптимизировать порядок слоёв для лучшего кэширования.

🔹 Как использовать

— Посмотреть слои: docker history my-image
— Без обрезки команд: docker history --no-trunc my-image
— Только размеры в human-readable: docker history --format "{{.Size}}\t{{.CreatedBy}}" my-image
— Сравнить два образа: запустите history для обоих и сравните слои.

💡 Если видите большой слой от COPY . . — значит, в контекст сборки попали модули, .git или логи. Проверьте dockerignore, это обычно экономит сотни мегабайт.