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

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

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

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

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

Но в общем случае это невозможно.

Ну конечно можно. Звоните владельцу сайта, говорите "алло, дайте мне доступ к вашему серверу". Он вам отвечает - "Да, конечно!" и высылает root ssh доступ. Заходите на сервак и всё скачиваете. А потом еще раз перезваниваете и просите к трубке админа, что бы он вам объяснил как это всё установить, что бы заработало. Profit! :)

А если серьёзно, то есть в вебе два ключевых значения -- "frontend" и "backend". Вот "frontend" это всё то, к чему имеет доступ, непосредственно, ваш браузер. Это html код, картинки, скрипты(на разных языках) и css стили(про всякие xml и прочее говорить не буду даже). А всё то, что работает с базами данных, делает всякие хитрые операции на СЕРВЕРНОЙ стороне, то есть на БЭКЕ, всегда скрыто от браузера, т.е. от вашего непосредственного доступа. Браузер отображает лишь результат, который БЭК посылает на ФРОНТ, т.е. в ваш браузер с сервера. Поэтому никакими программами (если это не супер-мега-хакерская прилага из для взлома особо слабозащищенных и плохо написанных сайтов) вы бэкенд не скачаете.

"нет возможности из процесса, поднятого в докере запускать под-процессы"

Это неправда. Те же самые nginx и php-fpm запускают мастер процесс и стартуют кучу своих воркеров как отдельные процессы.

Простейший способ сделать то что вы хотите - запустить скрипт внутри контейнера

docker run -d -v /home/project:/var/www php:8.1-cli php /var/www/worker.php

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

public function delete(User $user, Menu $menu) {
        // dd($menu->project->id, $menu->project_id);
        return $this->projectPolicy->isAdmin($user, $menu->project);
    }

Зачем вы так? Ну у вас уже есть пользователь. Есть модель Project. Нахрена вы тащите руками Policy. Ну определите разрешение на модификацию элементов меню в ProjectPolicy и используйте на здоровье.

public function delete(User $user, Menu $menu) {
        return $user->can('delete-menu', $menu->project);
}

Сделать несколько своих пакетов либо написать самому. Кэш, хранилище, работа с картинками. Под разные проекты и задачи (разные наборы модулей) пишем адаптеры, наверное ещё какой то конфиг свой не помешал бы, тут можно ни одного пакета не писать самому. Взять кучу подобных и на собирать. Точно бы не стал писать сам intervention/image, хотя писал, задач всяких разных много, а всего сразу не предусмотреть. Зависимость от модели или бд тут лишнее, это можно получить в методе модели из хранилища например

Какие известны хитрости, чтобы передавать меньше данных, не рискуя рассинхроном?

Чем меньше тик рейт сервера, тем меньше данных. Одно дело динамичный шутер(батла на 130 человек), а другое дело кооп игра на 4 человек. В одних случая критичен высокий тик рейт в других нет. Хотя... умереть в батле через секунду после того как ты забежал за стену благое дело...

Какие рассинхроны не критичны?

Опять зависит от игры.

В каком порядке происходит проигрывание на сервере того, что на клиенте было сделано, и как клиенты-друзья воспроизводят действия?

Ну почитайте какие нибудь статьи вот например на хабре
Мультиплеер в быстрых играх (части I, II)
Мультиплеер в быстрых играх (Часть III: появление ...
Мультиплеер в быстрых играх (Часть IV: Хэдшот! Пут...

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

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

Сервер принимает сообщения от игроков. Некоторые тут же форвардит остальным подключённым к нему. Некоторые вызывают серверное событие, и уже оно рассылает всем какое-то сообщение.

Т.к. один серв держит ограниченное число подключений (около 30 тыс в нашем случае), серверов несколько. Каждый напрямую отвечает за подключённых к нему игроков. И идёт меж-нодовая коммуникация: каждая нода шлёт остальным, например, сообщение для всех подключённых игроков. Или в конце консолидируется счёт и рейтинг.

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

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

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

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

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

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

Подобных решений масса причем под любой фреймворк, например, один из пакетов для yii2 + примеры работы с файлами В общем packagist/github в помощь.

Если url уникальный то его можно вынести в ключ массива, и дальше использовать array_diff_key или array_intersect_key

Видел однажды такую реализацию.

При успешном прохождении авторизации кидает на страницу, где через тег img подключается "картинка" с каждого домена, участвующего в sso тусовке.

<h2>Вы успешно вошли</h2>
<img src="https://example.com/auth.php?key=1hB7fa014bbXCDg920">
<img src="https://example.net/auth.php?key=hVVFD41looas8730MM">
<img src="https://example.org/auth.php?key=QnaVBhj7mqwaBK9xq6">

При авторизации создаётся и записывается в базу пачка одноразовых временных токенов, привязанных к только что авторизованному пользователю. При загрузке auth.php проверяется этот токен (передается через key в примере выше) и если токен ещё не просрочился, то выдаётся однопиксельный прозрачный gif с авторизационным кукисом. Этот кукис привязывается к домену, с которого загружается картинка.

Если я использую функцию комбинаторики для всех 4 букв, на выходе будут в том числе пересечения ыЫ йЙ и подобные.
Т.к. важно условие что сочетаться могут только разные буквы, но не заглавная и маленькая одной и той же буквы, имхо можно делать признак b, m (большая, маленькая или 1,0) для N-столбцов.

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

upd:
это называется декартово произведение списка элементов самого на себя (product позволяет перемножать несколько списков) с заданным числом повторов

list(itertools.product('mB',repeat=3))
Out[9]: 
[('m', 'm', 'm'),
 ('m', 'm', 'B'),
 ('m', 'B', 'm'),
 ('m', 'B', 'B'),
 ('B', 'm', 'm'),
 ('B', 'm', 'B'),
 ('B', 'B', 'm'),
 ('B', 'B', 'B')]

А дальше обработать список и на основе номера позиции и значения поставить нужную буквы большую или малую