Григорий Васильков

Попытка не пытка.

1. Пагинация (постраничная навигация) НЕ НАСЛЕДУЕТ соединение, а ИСПОЛЬЗУЕТ его. наследовать = быть КОПИЕЙ С ИЗМЕНЕНИЯМИ, использовать = требовать в коде (ЗАВИСЕТЬ). В ООП можно писать "extends" (наследовать), а можно пробрасывать через конструктор (зависимости). То что вы сделали - это использование "наследования" для "зависимости", оно к вам завтра вернется, когда что-то захотите ещё сюда всунуть, как будете второе наследование делать?

2. Размышляйте так. Чтобы сделать навигацию вам нужно:
1 - имя таблицы
2 - число страниц
3 - отступ, чтобы переходить на вторую страницу
4 - (необязательно) SELECT COUNT результатов, чтобы показать сколько всего страниц
5 - фильтр, чтобы скрыть ненужные результаты (самый прикол в том, что фильтр универсальный сделать не выйдет, т.к. придется написать SQL заново, он весь про фильтры)
6 - сортировка, чтобы выдать в нужном порядке (бывает несколько-ступенчатая сортировка "сначала-по-подгруппе-потом-по-цене", но её никто никогда не делает, лень правит мир)

Вы здесь крышей упадете писать одну функцию, которая делает это всё.

К человекам здесь пришло понимание, что нужно передавать "недоделанный" запрос из функции в функцию, дописывая в него кусочек. Для удобства запрос оборачивают в объект, которые называют Query.

Если вы пытаетесь сделать на чистом SQL запросы - вам придется очень многое изучить. Поэтому как решение я предлагаю такую последовательность действий:
1 - Изучаете, что такое composer, ставите в ваш проект какой-нибудь пакет (пока любой, например, symfony/var-dumper), добиваетесь что работает функция dd() (этот пакет её содержит, вам не нужно функцию создавать) в вашем коде. На самом деле там один консольный вызов и одна строка в коде, там нет "методики на 40 действий"
2 - ставите пакет illuminate/database
3 - гуглите статью "eloquent without laravel"
4 - создаете модельку под вашу таблицу
5 - на модельке вызываете метод ->paginate(), где его для вас заботливо написали
6 - и только здесь начинаете изучать детали, которые хотели выучить сразу, чтобы сделать не просто пагинацию, а фильтруемую и сортируемую пагинацию (если оно надо). Скорее всего у вас появятся классы FilterBuilder, SorterBuilder, PaginationBuilder и Pagination, в которой будет метод вроде ->paginate($query, $paginationBuilder)
7 - что такое паттерн "строитель" (Builder) читать на https://refactoring.guru

У вас долгий путь впереди. Если вы делаете задачу впервые, возможно, вы ушатаете неделю или полторы.

3. Кое-что о запросах. Пагинация с OFFSET имеет смысл только в очень простых запросах. На практике запросы имеют UNION, JOIN и "subquery", чтобы собирать данные, и кое-где работать не будет. Рекомендуется либо сразу оттолкнуться от (id > ?) вместо OFFSET (а заодно охренеть от того, что "айди больше" + "сортировка" опять не пашут, то есть вам по сути надо сделать "rowNum > ?", но почти все СУБД не дают такого параметра и придется КЕШИРОВАТЬ сделав запрос первый раз тяжелый, а следующий раз выбирать номер результата в кеше), либо делать велосипед с выгрузкой результатов в файл, например, и потом с помощью условного $splFileObject->fseek() выбирать прямым указанием номер первой строки и число результатов после (сложнее, веселая задачка потренироваться, на практике - создает больше гемора, чем пользы)

Попробуйте proc_open() вместо shell_exec(), и не забывайте прокидывать в него $env и $cwd. У вас хоть поток stderr будет, откуда можно почитать что там сломалось.

Посмотрите, как реализовано, но я там пока с логгерами натупил, выключить нельзя, так что скопируйте код.
https://github.com/6562680/support/blob/main/src/X...
https://github.com/6562680/support/blob/main/src/X...

Вопрос все еще открыт.

Из того к чему пришел опрашивая несколько человек (среди них два архитектора, два сисадмина и два программиста):

- в идеи нет никакой магии. простейшая реализация - закидываем код проекта в github, запускаем его на двух машинах вместо одной, просто вместо http-роутера мы используем message-брокер + eventbus, и соотственно каждая из машин обслуживает свои роуты. придумывать "ивенты" которые продвигают рабочий процесс, где один ивент является началом другого рабочего процесса - сулит головняк, такой же как если бы мы в пхп не использовали классы-сервисы, а вообще всё и всегда делали на ивентах. задолбались бы и запутались кто начало кто конец.

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

- брокеры сообщений. краткий обзор их такой - они работают всегда в одном из трех режимов. первый - сообщение:
1) "точка-точка" - "я отослал, ты придешь - получишь".
2) "трансляция" - я вещаю, кто хочет слушает, кто не пришел - пропустил
3) "трансляция-точка" - я вещаю, все слушают, кто не пришел - получит когда подключится.
Команды работают в режиме "трансляция-точка", ивенты "трансляция", уведомления "точка-точка".
Если бы мы делали хранение истории транзакций - то здесь ивенты должны работать в "трансляция-точка", ведь нам нельзя потерять ни один из них, их надо в постоянный ящик сохранить. Ещё в брокерах есть понятие "подтверждение". Это про надежность. После получения сообщения если выставить режим работы "нужно подтверждать" - непрочитанное удаляется только тогда, когда его подтвердили, иначе запихивается обратно в канал, причем не "следующим", а по временной марке на свое место. Это нужно там где есть "входящая точка", и да, если команда вернула "готово" или "невозможно" - сообщение подтверждается, если команда вернула "перебой связи" и "что-то пошло не так" - сообщение не подтверждается.

- параллелизация. пока не понятно, какие проблемы вызовет параллель всего, попробую методом тыка. Когда мы использовали роутер - параллелизацией занимался nginx/fpm запуская десяток процессов. И если "обновить заказ" запускалось раньше чем "создать его", мы справедливо получали ошибку мол "невозможно" или "заказ не существует". Когда у нас есть брокер - то параллельно будут созданы "джобы" на первой машине, и их нужно резолвить на второй. Если мы дальше синхронно будем выполнять команды - это будет дольше, чем раньше, пользователей много, а поток всего один. Нам нужно их выполнять точно так же параллельно, только без nginx, а вручную, используя "ext-pcntl" для unix или "composer require react/async" для windows.

- не путать event-sourcing и event-driven-design (что я и сделал в начале топика). ивент сорсинг в широких кругах известен как "история транзакций". Что получается, когда мы все приложение делаем в режиме "история транзакций" - получается биткоин. Кто-то миллионер, а вся планета тратит электричество на расчет его данных и мощностей все равно не хватает. у вас есть своя планета с людьми и компьютерами? думаю, пока нет.

- в ивент-драйвен-дизайне очень легко посчитать, что весь бизнес процесс должен состоять из цепочки ивентов, которые запускают маленькие скрипты, и контроллирующей системы, которая знает в каком порядке команда ждет эти ивенты. но в этот самый момент мы уничтожили преимущества ивент-драйвен - мы создали точку, которая "знает", узкое место, сломав которое - всё ляжет. мы начинали EDD потому что одна машина была точкой, которая лагает и всё лежит. создав полный ивент драйвен - мы снова сделаем такую точку, и тут же себя зароем. ивенты стоит использовать как уведомление, а не как двигатель прогресса. а прогресс двигают все те же обычные скрипты, которые висят. идея только в том, что они висят уже не на машине-фронтенде, а на одном из бекендов, в виде воркеров, а фронтенд летает быстро, только не умеет выполнять задачи, но умеет сказать "задача сейчас выполняется или нет". Точно так же как работает компьютер - северный мост работает с видеокартой, южный - с задачами, просто потому что видео должно обновляться так часто как возможно.

Поправляйте кто знает.

Если SOAP запрос не удастся сделать через Curl, сделав все заголовки ручками, то установите "composer require react/async".

<?php

$loop = Loop::get();

$limitThreads = 3;

$soaps = [
  // ...
];

$tasks = [];

$limit = $limitThreads;
while ($limit--) {
   $soap = array_shift($soaps);

   $tasks[] = function () use ($soap) {
     // do soap request...
     return $result = doSoapRequest($soap);
   };
}

if ($tasks) {
  $results = await(parallel($tasks));

  foreach ($results as $result) {
    var_dump($result);
  }
}

$loop->run();

Позвольте поправить.

Это не "правильно", это "возможно".

Использование API уменьшает число данных в одном запросе, но заставляет вас делать авторизацию, делать всевозможные защиты. Если у вас есть фронтенд, который так и так делает запросы асинхронные (fetch/$.ajax), то разумнее конечно возвращать данные.

С другой стороны, если ваш фронтенд не умеет в виртуальное дом-дерево (у вас не фреймворк, а нативный яваскрипт) - то при первой отдаче страницы в конце html вы можете отправить

<template id="mytemplate"><div>{{data}}</div></template>

, чтобы его схватить яваскриптом и генерировать верстку на основе него.

Делать апи запрос, который возвращает html - это возможно, но это не то что "неправильно", это вы соединяете две задачи, каждая из которых может в будущем быть дополнена, в одну - и усложняете доработку в итоге. Если они по отдельности - доделать это проще. Апи запрос может быть использован где-то еще, если с версткой - то нет. Верстка же может быть изменена под новую тему оформления, если вместе - то сложнее.

Считается, что доделывать должно быть легко, поэтому это "неправильно".

Но вернуть верстку первым запросом когда человек только на сайт вошел - это нормальная практика и так было, пока было мало фронтенд фреймворков, в которых верстка вшивается в код самого фронтенда. Пока люди использовали handlebars/jquery это было нормально и вполне работало, а главное - не требовался специалист, который знает конкретный фреймворк, т.к. верстку знает большинство.

Коллекция это про пачку.

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

Иногда это имеет смысл, но это такие редкие случаи, что так не надо делать. "независимость" модели это про другое, это про то что контакты являются частью одной задачи из ТЗ, а компании - другой. Но это не мешает одним иметь другое в подчинении, если в тз написано что компания имеет контакты.

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

Да, только оно будет читаться наоборот.

"Если /id2 (или начинается на /id\d+) то перейти на страницу /profile.php?id=2 либо /profile/id/2"

которая уже будет разбираться скриптом, как будто было profile.php?id=2

Как сказал Ипатьев, в php всё делается с помощью цикла foreach (да, здесь не только for и while), а чтобы получать курсор - у каждого списка или хешмапа (здесь для удобства массив это и то и другое, что закинешь внутрь тем и будет) - есть внутренний указатель который можно двигать функциями current()/prev()/next()/reset()/end().

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

ArrayIterator() применяется почти никогда, если применяется то разве что для сведения нескольких "итерабельных" типов к единому способу обхода (чрезвычайно редкая задача), особенно когда в php появились интерфейсы \Traversable и проверка is_iterable(), позволяющая тупо передать что-угодно в foreach() чтобы его обойти.

floor() - округление "отбрасывает дробную часть" при положительном аргументе, и округляет в меньшую сторону при отрицательном. То есть [ floor(-1.65/0.55) = -3 ], а [ floor(1.65/0.55) = 2 ]
round() - округляет по математическим правилам
ceil() - округляет в большую сторону

Вы когда на работу устраиваетесь - заключаете контракт. Контракт описывает что вы должны уметь. Это вот интерфейс "на вас".
Тогда как вы сами - это "класс", который что-то уже умеет.

Если ваши классы ничего ЧТО ТРЕБУЕТСЯ ДРУГИМ не делают - интерфейс на них не обязателен.

Интерфейс выполняет две задачи. Даёт классу назначение (имя в рамках задачи) и контроллирует, что класс что-то умеет.

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

Назначение чаще всего применяется в контейнерах зависимостей (см. Psr\ContainerInterface), там два интерфейса можно (и нужно) использовать, чтобы два одинаковых объекта положить в разные "коробки" и достать одну в одном классе, а другую - в другом.

Вторая функция применяется для проверки входных данных, когда вы в функции указываете тип данных для параметра, и программа упадет в ошибку, если тип данных неверный. Этот же принцип используется для организации ПОДМЕНЫ одного класса на другой. Если смотреть на вашу задачу (хотя здесь интерфейс не нужен) , то вместо того, чтобы на входе писать RurMoney вы сможете написать MoneyInterface, если вам не важно, какая валюта придет в функцию, но они все умеют в ваш ->getName()

В некоторых программах есть классы-данные, в которых нет методов (либо есть только геттеры и сеттеры - это вот ваш случай). Эти классы называют ValueObject. Для них интерфейс писать не надо. Чаще всего для них даже несколько классов делать не надо, просто один класс с разными свойствами. Но вот если методы есть - то нужно сделать АБСТРАКТНЫЙ КЛАСС, от него наследовать конкретные классы, тогда на входе проверять не интерфейс, а абстрактный класс. Абстрактный класс объединяет в себе "действия по-умолчанию" и "проверку умения" (через абстрактные методы). Они похожи на те, что в вашей задаче - getName() есть у всех - отличный способ положить этот метод в абстракцию, и не писать интерфейс, т.к. у вас уже есть абстрактный класс.

К чему мы приходим.
Интерфейсы чаще всего применяются, когда мы делаем класс умеющий несколько разных действий, класс-сервис, и мы подразумеваем, что когда класс кому-то не понравится, он возможно захочет удалить ваш и написать свой. Поэтому мы на входе пишем интерфейс и пусть свой туда подсовывает изменив настройки контейнера.

Необходимость интерфейса появляется тогда, когда другой класс начинает использовать методы вашего, но при этом вы считаете необходимым сделать возможным подмену вашего на полностью чужой. Если он должен быть не "полностью чужой", а только пару методов, то есть "вы требуете наследования" - можно обойтись абстрактным классом. Интефейс - когда речь заходит о "подмене", а не о "видах одного и того же".

Конкретно вашу задачу лучше решать разобравшись как настраивать вот этот пакет:
https://github.com/moneyphp/money

Думаю, вы правильно мыслите, то есть надо просто добавить пару проверок

Я тоже предпочитаю curl, а не Guzzle и им подобные.
Моя проверка как правило так выглядит:

// двойная инверсия как раз про "если хоть одно не выполнилось"
if (! (! curl_errno($ch)
&& 200 === curl_info($ch, CURLINFO_HTTP_CODE)
&& strlen(curlmulti_get_content($ch)) // для wordpress вместо strlen будет empty() т.к. их апишка ещё цифру 0 возвращает, когда отработало, но плохо
)) {
  // ... retry
}

И я оставил только CURLOPT_CONNECT_TIMEOUT, т.к. CURLOPT_TIMEOUT - это время на выполнение функции полностью (сломало меня, когда я много запросов запустил и поставил тайаут 5, так все курлы не успевали выполнится в мульти), вне зависимости от сети.

Так же у меня тоже была проблема, что курл единожды использованный нельзя просто "запустить еще раз", надо клонировать, а ресурс - не клонируется. Решил её через свою обертку curlBlueprint куда я напихиваю опции, а потом создаю ресурсы при помощи широко-понятных методов get/post/put... в итоге запросить повторно для меня это $chNew = $cbp->{get|post}(curl_getinfo($chUsed, CURLINFO_EFFECTIVE_URL));

https://github.com/6562680/support посмотрите реализацию XCurl.

При этом единственное, что отличает "юзаный курл" от "не юзаного" - это total_time, который у свежего строго 0.0. Ну и да, код ошибки тоже у свежего 0.

www.michurin.net/computer-science/boolean-logic.html

Как я вижу тут два способа.

Способ первый. Дерево есть дерево. Сначала строится дерево всего что может быть, потом контроллеры работают с деревом. Если нету в дереве - 404. Здесь будет работать механизм SubstituteBindings, когда ты на входе пишешь LiteraController::literaAction(Category $model), которая по твоей букве ищет категорию, у которой slug - твоя литера - и т.к. её нет - автоматически выбрасывается 404. Делать труднее, изменять труднее, зато потом получаешь все плюшки работы с деревом и возможностью по нему всячески бегать, подсчитывать суммы элементов в нем и так далее.

Способ второй. Твой. Роут работает с любой литерой, а внутри роута pages.books.litera тянет всё что начинается на букву такую-то, и если ничего не вытянул принудительно кидает 404. Это нормальное абсолютно поведение, когда ты бросаешь 404 вручную, а не автоматически. Делать легче, менять легче, плюшек нет. Зато дешевле. Заказчик захочет изменить - надо ПЕРЕ-делывать и наращивать функционал, доделывать - не прокатит.

Асинхронка - это далеко не всегда фоновые задачи. Хотя если считать любое приложение умеющее в "одновременно" - фоновой задачей - то да. Даже браузер параллельку делает, обращаясь к штуке под названием WebApis в каждом шаге отрисовочного event-loop если хоть что-то висит в ожидании на этом шаге.

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

Это значит вы запрашиваете записи не по одной, а делаете функцию, которая очень любит foreach а данные хранятся не в переменной value, а в $values.

В этом случае ваша логика уже представляет собой не действие от а до я, а сначала циклом сделать для всех А, потом циклом сделать Б, потом циклом сделать В. И вот на каком-то из этих циклов вы втыкаете туда multicurl/guzzle, чтобы самую длительную (но не самую тяжелую) выполнить сразу в 100 потоков и получить 100 ответов.

В принципе авторы выше подсказали решение проще, ибо долго пояснять иное. Они сказали - чем переписывать логику, проще запустить 100 действий А-Я и для этого применить очереди, а знач их настроить, понять, поиграться, столкнуться с приколами и нежданчиками. По мне начать стоит с переписывания слабого места в этом скрипте на циклы, понять что можно "работать с пачками", но в компаниях это как правило не любят - переписывание - это всегда косяки, поэтому легче запустить уже написанное в поточном режиме (и получить серверные косяки, которые вас и добьют :( ), чем попробовать написать действие для "пачки" вместо "действия для одной"