Зачем ты пилишь велосипед, есть уже готовое решение!

Есть внешний API сервис.
Структуру нужно как то проверить перед тем как начать с ней работать - это факт.
Наш сервис написан на базе фреймворка Laravel и хорошо что у него есть фасад Validator, плохо тем что когда мы попытались его натравить на большой массив, он с дулся.
По времени было все печально, весь сервис начал жутко тормозить.
Он мог по минуте или двум проверять только ответ от внешнего API сервиса.
На этом этапе было принято решение сделать свой проверщик, который просто проверит структуру без изысков.
По началу не было даже мечтаний что идея стоит свеч, и будет хоть какой-то эффект.
Но эффект шокировал.

Вот результат теста.

Validator Время выполнения: 84.0274 сек. 
ApiCheck Время выполнения: 0.1269 сек. 

В телеге сильно ограничены посты.
Подробнее здесь https://reptily.ru/bash/bystraia-proverka-struktury-vnesnenego-api-servisa

Готовим фабрику по производство DTO

https://reptily.ru/bash/gotovim-fabriku-po-proizvodstvo-dto

<?php
  
$dto = DTOFactory::makeDTO(
    className: UserDTO::class,
    id: 222,
    name: 'Jon'
);

ПССС парень! PHP 8.3 подъехало!

Докер сборка уже готова и ждет тебя!
https://github.com/reptily/openserver

git clone сделал? звезду поставил!

Дубликат кода - может быть хорошо!

Расскажу вам дивную историю с продакшена.
Было две доменных модели, похожие как две капли воды, с одним отличием, это название.
В коде появились общие объекты а в базе общие таблице. Потому что дубликаты кода это же плохо!

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

Как следствие появилось куча ветвлений и куча проверок в объектах.
Код и данные стали на столько сложно поддерживать что проще было все переписать.

Как можно было избежать?
Если мы понимаем что домены разные, то лучше сделать дубликат кода, что бы в дальнейшим было это проще поддерживать.

С новым годом друзья!!!!

Показалось прикольной идеей зарегистрировать домен https://255255255.ru/

Вчера нашел у себя интересный кейс.
Какая-то редиска прописала свой домен на по ip, вопрос нахера, сложный!
Ладно был бы у меня там трафик, а там две с половины колике.

Собственно сам кейс с nginx, если прописать дефолтный конфиг.
```

server {
    listen 80;
    listen 443 ssl;
    server_name example.com;
}

```
Вроде как мы обслуживаем только

example.com

, остальные идут лесом, но на практике это не так, по всем доменным именам идут обращения к

example.com

.
Что немного похоже на магию.

Что я сделал, что бы все запросы по левым именам отклонялись.
В первичном файле default.conf прописал

server {
    listen 80 default_server;
    listen 443 ssl default_server;
    server_name _;

    ssl_certificate /etc/nginx/conf.d/ssl/_/fullchain1.pem; # левый сертификат
    ssl_certificate_key /etc/nginx/conf.d/ssl/_/privkey1.pem; # левый ключ

    return 418; # я — чайник
}

include /etc/nginx/conf.d/sites/*.conf; # остальные доменные имена

Теперь по левым доменам запросы вылетают с 418 статусом.

Проблема N + 1 в Laravel Eloquent

Что может быть плохое в этих строчках?

User::query()->where('status', '1')->exists();

Может быть плохая магия!

Дело в том что, Eloquent делает следующие этапы
1. Формирует сам запрос

SELECT * FROM `users` WHERE `status` = '1'

2. Его оборачивает

SELECT EXISTS(SELECT * FROM `users` WHERE `status` = '1');

https://github.com/illuminate/database/blob/master/Query/Grammars/Grammar.php:compileExists
Вот и проблема, запрос ради запроса


Мы бы хотели конечно видеть запрос вида

SELECT 1 FROM `users` WHERE `status` = '1' LIMIT 1

И как это сделать?!

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

public function scopeExists(Builder $query): bool
{
    return $query
        ->limit(1)
        ->select(DB::raw(1))
        ->get()
        ->isNotEmpty();
}

class Page
{
    public function getByUserId(int $userId): DTO
    //или
    public function getByUser(User $user): DTO
}

Как вы думаете, какая функция будет более оптимальна, запрос по id или использования целой модели.
С первого взгляда использовать целую модель это избыточно, она тянет много полей да и памяти это требует намного больше, чем передать простой integer.

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

SELECT * FROM table WHERE id = ?

Самое печальное что начинается цепная реакция по передачи этого id и последующих дополнительных запросов к базе.

Друзья, с праздником!
С днем программиста!!!!

Если у вас большая таблица, более 1 000 000 записей в ней. То при массовом обновление данных, есть вероятность заблокировать все таблицу. Это становится весьма критично если таблица очень большая. Но можно написать процедуру которая будет обновлять точечно по каждому первичному ключу, тем самым мы не будет блокировать все таблицу или ее часть. Пример процедуры выглядит примерно так.

https://255255255.ru/bash/massovoe-obnovlenie-v-mysql-bez-blokirovki-tablicy

https://github.com/reptily/openserver/releases/tag/1.15.0
Ну вот! и в нашу репу пришло PHP 8.4

Вдруг кому нужно, ключи для jetbrains
https://255255255.ru/bash/polnyi-dostup-k-jetbrains-besplatno

Axios был скомпрометирован

Вредоносные изменения были интегрированы в выпуски Axios 1.14.1 и 0.30.4 через подстановку фиктивной зависимости plain-crypto-js 4.2.1, содержащей код для загрузки компонентов, принимающих команды с управляющего сервера злоумышленников. Вредоносные выпуски предлагались для загрузки 31 марта в течение почти 3 часов - с 03:21 по 6:15 (MSK).

Статьи здесь
https://www.opennet.ru/opennews/art.shtml?num=65109
https://www.huntress.com/blog/supply-chain-compromise-axios-npm-package