Konstantin

на американской раскладке - под клавишей esc
на европейской раскладке - правее левого shift

Нет юридической силы. Чтобы была юридическая сила - необходимо соблюсти условия изложенные в законе об эцп. (Как минимум)
Не более чем картинка в картинке.

Нет юридической силы. Точнее, не больше, чем у переписки по электронной почте или у скана документа.

На основе ответа Konstantin получилось собрать вот такой вот запросик

$query
                ->innerJoin('histories' , 'users.id = histories.user_id')
                ->select('users.*, histories.user_id, avg(timestampdiff(minute,`histories`.`time_in`,`histories`.`time_out`)) as avgtime')
                ->groupBy('user_id')
                ->having('avgtime > ' . $this->wash_middle_time_more);

Самое простое - nginx отдаёт статику. На больших объёмах делать это через Ноду неэффективно.
Посложнее - nginx позволяет управлять ходом запроса. Например, редиректить на https.
Ещё сложнее - можно настроить nginx, чтобы он умно балансировал запросы между несколькими бэкендами и автоматом блокировал слишком частые попытки подключения.

Nginx очень хорошо в промышленных масштабах делает определённую часть работы, связанной с http-запросом, поэтому ему эту часть работы и делегируют.

в .env файле пропиши правильные логин и пароль к базе

Вот хороший доклад на эту тему https://youtu.be/gDEFVplbB4Q

А я пользуюсь spatie/DTO и доволен. Тоже очень сильно сомневался как и вы вначале, но потом (как правильно заметил vism ) успокоился. Решаем же бизнес задачу, а не пишем академическую учебную работу.

Основной пакет spatie/DTO он не для Ларавеля. Он "общий". Для Лары есть отдельно, на его основе.
В ноябре выйдет 8.1 пых, там будут readonly для свойств.
В паре случаев, я переопределял конструктор, чтобы предвалидировать по-своему параметры перед кастингом.

Придется парсить ключи в обработчике submit:

const re = /(.+)\[(.+)\]\[(.+)\]/;
const formData = new FormData(drawingForm);
const result = {};
for (const [key, value] of Object.entries(formData)) {
    const matches = key.match(re);
    if (!matches) { continue }
    const [, k1, k2, k3] = matches;
    ((result[k1] ??= {})[k2] ??= {})[k3] = value;
}
console.log(result); // тут валидация

Неявное сравнение, т.е. сравнивается только содержимое (0 и 00 приводится к int)

https://www.php.net/manual/ru/types.comparisons.php
https://www.php.net/manual/ru/language.operators.c...

В случае, если оба операнда являются строками, содержащими числа или один операнд является числом, а другой - строкой, содержащей числа, то сравнение выполняется численно

Правы оба.
Лучше раньше упасть, чем обработать кривые данные так, как будто они нормальные. Но и просто бездумно падать в самую базовую ошибку неправильно - потом задолбаетесь выяснять при каких обстоятельствах код упал. Лучше провалидировать и кинуть осмысленное исключение, которое поможет отловить проблему.

иногда такие проверки бессмысленны. Допустим, Вы обращаетесь к функции, которая возвращает список, каждый элемент которого - массив определённой структуры, например ['id'=> ..., 'name' => ..., 'timestamp'=> ...,]
Понятно, что не надо у каждого элемента проверять, есть ли там эти ключи - функция-источник гарантирует это.

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

но опасаемся, что Laravel будет работать очень медленно в случае такой посещаемости.

А вдруг не будет такой посещаемости?
Я б выбрал laravel, потому что преждевременная оптимизация — корень всех зол.

В сессию какой-нибудь флажок добавляйте, что данные уже обработаны. А вообще, после обработки данных делайте редирект на тот же самый скрипт с каким-нибудь случайным параметром. Тогда при обновлении страницы не будет POST-запроса, будет GET

В upload.php в самом конце сделайте редирект на эту же страницу:

//определяем протокол - HTTP/HTTPS
$proto = (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] != 'off')? 'https': 'http';
//шлем заголовок для "обновления" страницы без пересылки формы.
//все последующие "ручные" обновления страницы будут происходить без отправки формы
header('Location: ' . $proto . '://' . $_SERVER['HTTP_HOST'] . '/' . $_SERVER['REQUEST_URI']);
exit;

Вообще, это "best practice", перебрасывать редиректом после обработки формы, если не было ошибок при сохранении формы.
Exit в конце прерывает выполнение остального кода.