Remap – гидрация результатов sql запросов с преобразованием
#пост

Довольно часто мне приходилось делать raw sql запросы в БД для получения данных. Причин тому было несколько:

- Так быстрее
- Не нужно писать длинные билдеры
- Запрос часто менялся, проще всего переносить as-is из требований в код
- Подсветка синтаксиса в IDE
- Удобная отладка: скопировал в DB Viewer и запускаешь
- И многое другое

Зачастую в проекте уже была какая-нибудь ORM или Active Record, где всегда результат запроса был объектом с необходимыми свойствами и типами.

Однако работа с raw sql обычно заканчивалась перегоном массивом из одного метода в другой.

Это неудобно:

- Нет типизации параметров функции – array $data
- Нет типизации свойств – $data['user_id'] – int/string?
- Нет понятия наличия свойства в массиве вообще – $data['unknown_prop'] – ошибка, которую найдешь только при выполнении кода

Как-то давно общаясь в чате про Active Record в Yii3 ко мне пришло озарение, что AR – это всё еще сложно – нужно наследоваться от базового класса или подключать trait, где-то доставать фабрики и самое главное, всё равно raw sql не смапить в модельку.

К тому моменту hydrator из Yii3 был почти готов и я решил сделать Proof Of Concept обычного data-mapper, с использовать db и hydrator.

Вот что из этого вышло:

Remap

Библиотека содержит лишь 1 класс и делегирует работу по исполнению запроса в yiisoft/db. Создание объекта и его наполнение библиотека делегирует в yiisoft/hydrator.

Таким образом, логика выглядит линейной и понятной:

1. Выполняет raw sql запрос
2. Проходим построчно по результату запроса
3. Создаем DTO и наполняем его нужными полями

Всё это скрыто в методе Remap::map()

Пример работы с библиотекой:

final class Todo
{
    public int $id;
    public string $noscript;
    public int $status;
    public int $created_at;
}

$sql = 'SELECT id, noscript, status, created_at FROM todo WHERE id = :id LIMIT 1';
$params = ['id' => 1];

$remap->map(Todo::class, $sql, $params);

Remap::map()

Метод принимает первым аргументов класс, который нужно будет создать и наполнить.

Второй и третий аргументы – сам запрос и параметры для подстановки. Можно передать во второй параметр string $sql , а в третий array $params , а можно сразу во второй передать [$sql, $params]

Метод возвращает \Generator объектов. Это позволит обрабатывать большие объемы результатов запроса и не падать с нехваткой памяти.

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

$remap->map(Todo::class, Todo::selectOne($id));
$remap->map(Todo::class, Todo::selectAll());

Использовать можно по-разному, поэтому для еще большего упрощения записи можно написать следующее:

$remap->map(...Todo::selectAll());

Статические методы в Todo в текущих примерах будут возвращать массив из нужных значений:

- [$sql, $params] в первом примере
- [self::class, $sql, $params] во втором примере

А использование yiisoft/hydrator позволило использовать Attributes для произведения дополнительных трансформаций. Например:

final class TodoModelHydrator
{
    #[Data('id')] // В свойство $identifier запишется то, что лежит в id свойстве
    public string $identifier; // дополнительно cast from int -> to string
    #[Data('noscript')] // noscript -> text
    public string $text;
    public string $status; // int -> string
    #[Data('created_at')] // created_at -> date_created
    public string $date_created; // int -> string
}

Таким образом, результат запроса можно преобразовать под нужные конвенции объектов и не зависеть от устройства внешнего хранилища.

Причесал библиотеку, написал тесты, подкрутил Psalm на 1 уровень, тегнул 1.0.

Надеюсь эта библиотека поможет и вам. Буду рад любым предложениям по улучшению.

——

Полезные ссылки:

Remap
Использование атрибутов yiisoft/hydrator

@handle_topic

#оффтоп

Хороший кейс, почему нужно писать свои программы быстро :)

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

В мире компьютерной безопасности сегодня интересный день. Точнее, он начался вчера вечером, когда немецкий разработчик Андрес Фройнд опубликовал отчет о тайной лазейке (бэкдор), которую он обнаружил в новых версиях широко используемой библиотеки для сжатия liblzma (часть архиватора xz). Лазейка позволяет взломщикам заходить через SSH на системы, в которых установлены эти новые версии - к счастью, похоже, что это всего несколько дистрибутивов Линукса в их до-релизовых версиях.

Всех очень впечатлило, насколько эта лазейка была сделана хитро, и как взломщик или взломщики серьезно поработали над тем, чтобы замести следы:

- взломщик под именем/псевдонимом Jia Tan почти два года (!) участвовал в разработке опенсорсного пакета xz, завоевал доверие его мейнтейнеров и получил доступ к прямому коммиту в его репозиторию. Он сделал больше 700 коммитов, лишь малая часть которых медленно подготовила код для лазейки

- основной код лазейки спрятан в тестовых файлах проекта (примеры "плохих" и "хороших" архивов)

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

- эта добавка прячется в конфигурационной магии autoconf, которую все ненавидят лютой ненавистью и никто никогда не заглядывает внутрь

- она проверяет, когда исходники конфигурируют именно для постройки дебиан-пакета или RPM-пакета (т.е. то, что будут делать мейтейнеры дистрибутивов), и только в этом случае вынимает из тестовых файлов определенные куски и добавляет в код библиотеки

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

- интересно, что openssh, стандартный SSH-сервер под линуксом, не использует библиотеку liblzma, в которую вставили эту лазейку, но несколько популярных дистрибутивов добавляют в него поддержку уведомлений системы, systemd, а библиотека libsystemd уже в свою очередь использует liblzma.

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

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

Если бы все происходило быстро и не было задержки в полсекунды, очень может быть, что это не заметили бы месяцы и годы, и этот код попал бы в основные дистрибутивы, в версии Линукса, которые запускаются у основных облачных провайдеров итд. Они реально очень, ОЧЕНЬ хорошо замели следы.

Теперь все думают, что надо было/надо теперь делать по-другому, и как обнаружить следующую лазейку такого типа - или предыдущую, если она уже есть и никто не знает! - не опираясь на удачу и героическую занудливость Андреаса Фройнда.

SSE или стримы на PHP
#пост

SSE – Server-sent events. Стрим – потоковая передача данных в рамках одной сессии.

SSE – протокол общения сервера и клиента, когда сервер отдает информацию частично, при этом не обрывая и не завершая соединение.

Для простой реализации такого протокола потребуется:

- Добавить в HTTP Headers Content-Type: text/event-stream
- В HTTP Body писать следующее:
- Передача сообщения начинается с data:
- Заканчивается сообщение с \n\n на конце строки
- Таких сообщений может быть неограниченное количество
- Задержка между сообщения может быть любая: секунда, минута, 30 минут, прочее

Рассмотрим несколько примеров с возможностями SSE:

- Так пишутся комментарии, с двоеточием вначале

: comment
: another comment
data: ...

- Кастомное имя события. Если не указать event, то событие будет типа message. В моем примере тип события = question с телом в виде JSON

event: question
data: {"tg_channel":"@handle_topic"}

- Событие с id. Не вижу в этом id какой-то полезности для себя.

data: text message
id: 55

- Длинные строки. Это всё еще одно событие.

data: looooooooooooooooong text
data: looooooooooooooooong text
data: looooooooooooooooong text

- А это уже два разных сообщения:

data: payload1

data: payload2

- Еще можно указать retry в milliseconds. Будет учтено при обрыве соединения и попытке восстановления. Например, 1 секунда (1000 миллисекунд).

data: ok
retry: 1000

Это довольно удобная штука, когда нужно что-то недолго* постримить пользователю:

- Прогресс бар для загрузки файлов
- Какое-то реалтайм действие
- Асинхронная операция и прочее

Реализация

Реализовать на чистом PHP довольно просто: посмотреть пример можно здесь.

Однако, мало кто пишет на чистом пхп свои бекенды. Скорее всего на бекенде используется какой-то фреймворк с ответами в виде класса Response. Либо сразу в контроллере, либо под капотом происходит трансформация возвращаемого значения в строковый ответ.

Если разбирать PSR ResponseInterface , то HTTP Body формируется через метод withBody, который принимает объект StreamInterface. Ага, вот и стримы обещанные.

Стримы

Так как задать несколько ответов с задержкой?

Раз уж наш ответ является стримом, то стрим не обязан возвращать все данные “за одно чтение”.

Поэтому можно сделать некий буфер, который будет вычитываться в методе read() . Если данных больше не будет, то достаточно поменять флаг eof и вернуть его в соответствующем методе объекта стрима.

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

- Бекенд будет думать, что клиент всё принял и обработал
- Клиент получит часть, что-то сломается, и получить остальную часть он уже не сможет
- Дополнительные затраты на память

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

Ограничения

Разберем еще несколько ограничений SSE:

- Можно стримить только body
- Хедеры нельзя менять после начала стрима
- Кодировка всегда UTF-8

Emitter фреймворка должен уметь в стримы, чтобы не выдать первый результат и закрыть стрим, либо объект стрима должен сам уметь блокироваться и чанковать данные.

Проблемы

- Сложная реализация
- Реализовывать стримминг событий на PHP при помощи SSE еще и в PSR обёртках?
- Проще подключить Mercure и настроить его.
- Протокол – пустышка
- Ни авторизации, ни разделения на каналы, ни бродкастинга
- Всё делать либо в HTTP, либо самому
- По сути в нем можно перегонять лишь текст и всё
- Это как HTTP внутри HTTP. Шутка про монитор в мониторе
- Свободные воркеры
- Свободные воркеры веб-сервера превращаются в зомби за мгновение
- Поэтому таймауты обязательны
- Либо Non-blocking I/O. Кстати, надо бы попробовать.

---

Полезные ссылки:

MDN Server-sent events
StreamInterface
HTML Standard

@handle_topic

#мем

Концовка топ😂

С днем космонавтики!

День космонавтики — отмечаемая сначала в СССР, а после в России и других странах постсоветского пространства 12 апреля дата, установленная в ознаменование первого полёта человека в космос.

Куда пропал?
#оффтоп

С середины Апреля ничего не писал, но много разного произошло.
Если перестал писать статьи и заметки, то чем дольше этого не делаешь, тем дольше будешь это откладывать. Кто занимается подобным то скорее всего меня понимает. При этом у меня в черновиках есть несколько "продакшен-реди" статей, даже это откладывалось.
Решил не делать новогодних резолюций, а взять и написать сегодня.

Буду наверстывать, вкидывать уже что-то из прошлого и делиться своими мыслями, и уже совсем скоро будет приятный бонус всем кто использует PHPStorm для разработки на PHP. Нет, не лицензия и не прокси сервер, вы уж там сами 😁

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

Всех с наступающим 🎄❄️☃️

Видео обзор плагина MetaStorm для PHPStorm 🚀

Покажу, как работает MetaStorm и как он упрощает работу с автокомплитом в PHPStorm! Так и не дождался поддержки MoonShine в Laravel Idea, но получилось всё что хотел реализовать в MetaStorm! Сразу скажу, скорость работы с MoonShine повышает максимально!

Вы увидите:
- Примеры конфигураций MetaStorm и принцип работы
- Возможности автокомплита для иконок, полей, методов и моделей
+ Интервью с автором плагина - Дмитрием Дерепко, планы на развитие и взгляд на Open Source

https://youtu.be/pUhnl03ckEM

📌 Полезные ссылки:
MetaStorm на jetbrains - https://plugins.jetbrains.com/plugin/26121-metastorm
Обзоры от автора на Хабре:
https://habr.com/ru/articles/868898/
https://habr.com/ru/articles/872000/
GitHub репозиторий - https://github.com/xepozz/meta-storm-idea-plugin
Телеграмм канал MetaStorm @meta_storm