С МобХ согласен в части аргументации выбора, но с другой стороны можно налепить ошибок при проектировании присущих либо чересчур активному применению ООП-паттернов, когда система станет не понятной, либо неправильное их применение и как следствие архитектура нифига не SOLID )
На php я не встречал решений, и вряд-ли они есть без браузера не обойдетесь, могу предложить переехать на VPS и реализовать задачу с помощью первой ссылки которую я дал.
Вот еще вариант https://davidtang.io/2015/04/30/taking-screenshots...
В общем, нужен браузерный движок на бэкенде
truejunya, а что есть?
Боюсь если у вас шаред хостинг, то варианта 2:
1. Рендерить на клиенте на canvas и отправлять на сервер или сразу клиенту отдавать картинку
например так html2canvas.hertzen.com
2. Использовать сторонний сервис, и через API получать от него картинку: https://pdfcrowd.com/doc/api/
Я подробно не исследовал причины,
но приложение написанное на Qt использующее обертку над libpq успешно использует эти функции под тем же пользователем.
Не понимаю, почему проблемы с этим у расширения PostgreSQL для PHP, которое использует тоже libpq.
Если другие научились, почему ты ВОЗМОЖНО не научишься?
С самолетом явно гипертрофированный пример, давай еще про пилотирование союзов поговорим, вдруг у нас задача срочная полететь на луну? Это такие вещи, в отдельных случаях, практически неэластичного спроса, ты если даже и научишься пилотировать самолет, тебе нужна будет своя компания, чтобы беспрепятственно самому собраться куда то и полететь, тем более срочно.
Да и если ты имеешь возможность купить самолет, нафига тебе все это? )
Если говорить о самокате, велосипеде, автомобиле, ну даже об автобусе, то все возможно.
Отвлекитесь немного.
Есть самокат, используется для быстрого перемещения по городу, на относительно небольшие расстояния, ветер в харю, весело, но для серьезных расстояний.
Есть велосипед, тоже ветер в харю, но перемещаться на нем можно быстрее, дальше и с большим комфортом, хоть он и менее мобилен (в метро например не айс с ним), но опять же в дождь будешь мокрым.
Есть автомобиль, еще больше комфорта, климат-контроль, ехать можно на весьма дальние расстояния, дольше, чем на самолете, нужно заправлять, проходить ТО итд.
Можно дальше продолжать про автобусы, самолеты, Falcon и т.п., но, пожалуй, хватит )
Каждый инструмент (а это инструменты, для решения вашей задачи по перемещению из пункта А в пункт Б) имеет свои характеристики.
Если Вам понадобилось поехать в другой город, можно это сделать и на самокате и на велосипеде и на автомобиле, выбор зависит только от того, насколько Вы романтик )
Ну или мазохист, кому как.
Представьте реляционную модель данных, некий граф. Структура данных очень похожа.
Но все это хранится в памяти, например, имеем несколько таблиц в памяти.
Таблицы могут быть связаны между собой по паре полей.
Допустим, есть 3 таблицы. Т1(100 строк), Т2 (1000 строк), Т3(10000 строк).
Эти три таблицы связаны между собой слева направо, один ко многим Т1 -> Т2 -> Т3.
Каждой записи из Т1 соответствует несколько записей из Т2 и еще больше из Т3 (через Т2).
Теперь мне нужно посчитать для каждой строки из Т1 по такой формуле: SUM(Т3.F2)/AVG(Т2.F1), где Fn - имя колонки из которой брать данные, а данные передаваемые в функции это числовые массивы полученные из этих полей соотв-щих таблиц.
Для поиска связанных данных использовать переборы плохо, всегда будет N1*N2*...*Nx переборов, где Nn количество записей в таблицах, которые участвуют в выборке данных.
Строить индексы можно, либо один раз пройтись по всем связям и для каждой записи сохранить ссылки на соотв-щие связанные строки в связанных таблицах, что и сделано, работает быстро. Получить связанные строки из соседней таблицы можно просто вернув уже заранее сформированный массив этих строк, по сути указателей, который хранится в каждой строке текущей таблицы.
На вопрос "Почему не использовать субд?", отвечу, что субд так же быстро не будет работать, так как данные вытаскиваться сложными запросами, которые и без того работают не так быстро как хочется, а так же данные могут выбираться из разных источников, не только субд, это может быть сторонний микросервис.
На вопрос "Какого хрена вы храните данные в браузере?" )) ответ - данных в итоге не так много, чтобы не помещалось в браузере с 2-4 ГБ оперативки, но достаточно, чтобы ощутить тормоза при большом количестве переборов, или же хранить мутации в Redux.
То есть по сути задачу модуль свою решает, но это только часть системы, которую нужно переписать с использованием современных инструментов, react/vue, остальная часть системы это набор каталогов/списков/форм редактирования итп.
