FanatPHP

Или же я вообще пишу глупость

В целом да. Но

вся эта логика прекрасно будет в index.php лежать?

- это гораздо большая глупость.
Ну то есть лежать-то будет, но к MVC уже никакого отношения не будет иметь.

По пунктам

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

Что такое AuthPage вообще непонятно. Модель, контроллер? По базе проверяет модель, куки пишет контроллер. А здесь какой-то кадавр.

Перед тем как писать авторизацию "в стиле MVC", надо сначала разобраться, что такое модель, что такое контроллер, и что такое вью.

Модель - это вся логика приложения.
Контроллер - это интерфейс для общения модели с браузером. Делает всё, связанное с обработкой НТТР запросов.
Вью - отображение.

Как правильно.

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

Для регистрации делается еще один экшен, который
- проверяет, если был запрос методом ПОСТ, то берет из него данные для регистрации,
- валидирует их, если валидация не прошла, то создает ошибку, которую надо показать юзеру
- если прошла, то то заполняет класс User данными и выполняет метод save() и делает редирект куда-нибудь
- вызывает вью с формой для регистрации

Для личного кабинета делается третий экшен, который берет из сессии ид юзера, обращается к методу read() модели User и через View показывает личный кабинет

Варианты реализации

Самый простой вариант реализации контроллера - это папочка с отдельными файлами-экшенами. Ничего плохого в такой архитектуре нет, этот этап надо пройти, если раньше так не делали.

То есть папка user в которой есть, скажем, файл index.php который является экшеном личного кабинета.
Он проверяет юзера в сессии, и если нету, то перекидывает на auth.php
в auth.php есть форма и ссылочка на register.php
Все три файла инклюдят в себя файл user.php из папки model, в котором есть функции auth(), register() и profile()

Но в более классическом варианта к трем буквам MVC добавляется ещё одна - R, роутер. Специальный сервис, который разбирает адресную строку, и видя, например, что к сайту обратились по адресу /user/register, создаёт экземпляр класса UserController и вызывает его метод register()

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

А мычит он не про сам шелл, а про используемый в нем скриптовый язык.
И ответ получается очень простой - для некоторых задач Bash scripting language тупо подходит лучше. Не говоря уже про интеграцию скриптового языка баш в командную оболочку баш, какой никогда не добиться с помощью "обёрток".

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

Так что да - или легаси, или тупо адекватность задаче.

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

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

1. Получение значения из адресной строки

Чтобы получить значение переменной, которую передали в строке запроса (это то что после знака вопроса), надо обратиться к переменной $_GET

То есть в данном случае можно написать $id = $_GET['id']. Имя получаемой переменной ($id) может быть любым и не обязательно совпадать с переданным значением. А вот в индекс массива $_GET разумеется надо писать именно то имя, которое в адресной строке. То есть если site.com/?id=1 то в $_GET['id'] будет значение 1.

2. Валидация данных

Далее очень желательно проверить, что мы в переменной получили то что хотели, а так же что мы вообще хоть что-то получили.

Сначала надо проверить наличие в массиве $_GET нужного ключа. В данном случае это можно сделать с помощью оператора isset() (хотя вообще она для проверки наличия ключей в массивах не рекомендуется)
Если для показа информации используем отдельную, специальную страницу, которая только занимается показом данных по айди, то после проверки на существование надо выдать ошибку.

Затем, поскольку id может быть только целым числом больше нуля, то лучше проверить и это тоже и тоже выдать ошибку.

3. Соединение с БД.

в "config.php" должно быть написано не то что там сейчас а вот это (со своими параметрами подключения разумеется)

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
$link = mysqli_connect($host, $user, $pass, $db_name);
$link->set_charset("utf8mb4");

4. SQL

Запрос, который нам нужен, выглядит так:
SELECT * FROM `product` WHERE id=1

5. Выполнение запроса в РНР

Но разумеется вместо 1 надо подставить значение переменной.
Это самое сложное. Но надо один раз выучить и потом везде применять

Важно, чтобы данные в БД всегда попадали отдельно от самого запроса. Это непреложное правило, которое надо соблюдать всегда.
Для этого надо

1. Заменить все переменные в запросе на специальные маркеры, которые называются плейсхолдеры или параметры, а по сути - просто знаки вопроса
   
2. Подготовить запрос к исполнению с помощью функции prepare(). Эта функция принимает строку запроса и возвращает экземпляр специального класса stmt, с которым в дальнейшем и производятся все манипуляции
   
3. Привязать переменные к запросу.
   
4. Выполнить подготовленный ранее запрос с помощью с помощью execute()
   
5. Получить результат запроса через get_result()
   
6. и дальше конкретную строку из БД с помощью уже знакомой fetch_assoc
   
   

В коде это будет так

$sql = "SELECT * FROM `product` WHERE id=?";
$stmt = $link->prepare($sql);
$stmt->bind_param("s", $id);
$stmt->execute();
$result = $stmt->get_result();
$row = $result->fetch_assoc();

bind_param() принимает в качестве параметров все переменные, которые должны попасть в запрос, в том же самом порядке, в котором стоят плейсхолдеры в запросе. Но кроме того, сначала в этой функции должны быть указаны типы для всех переменных, в виде строки, где тип переменной обозначается одной буквой. То есть букв в этой строке должно быть ровно столько, сколько дальше будет переменных. К счастью, можно особо не париться с типами и для всех переменных указывать тип "s".

6. Вывод данных.

Важно понимать, что в момент вывода данных никакой работы с БД уже быть не должно!
Должны быть только переменные РНР с уже полученными данными.

Взламывают точно так же как и мелкие.
В статье описана обычная SQL инъекция, когда данные подставляются прямо в SQL запрос.

Я просто сомневаюсь, что valve может нанять таких людей в backend

Не надо сомневаться.
Нету никаких "особенных способов взлома".
А есть такое явление как "эффективные менеджеры". У которых размер премии зависит от того, сколько денег они сэкономили акционерам.

Если бы там были подготовленные выражения, то и взлома бы не было.
Но вместо подготовленных выражений в больших компаниях есть эффективные менеджеры. Которые экономят на нормальных программистах, и заказывают разработку в Индии, в штате Бангалор. Где живет какой-нибудь Хамишь Кумар, который родился в касте вычерпывателей говна из сортиров. И вот у него только один шанс не черпать говно всю жизнь - всеми правдами и неправдами научиться программировать, путь даже за еду. Сравниваем с силиконовым программером с запросами $250k в месяц. Экономия налицо!

На всякий случай напомню, для стопроцентной защиты от инъекций необходимо всегда следовать двум простым правилам:

1. данные подставляем в запрос только через плейсхолдеры
   
2. идентификаторы и ключевые слова подставляем только из белого списка, прописанного в нашем коде.
   

Ключевое слово здесь - "всегда". Как только начинаются рассуждения вида "ну эти данные и так безопасные, их защищать не надо", то в этот момент мы добавляем инъекцию к себе на сайт. Следует понимать, что защищаем мы не данные, а запрос. Данные нас вообще не интересуют - какие они, откуда пришли, являются "безопасными" или нет. Важно не то откуда они пришли, а то, куда они идут. В SQL запрос? Используем подготовленные выражения, точка.

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

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

Эффективность здесь вообще не при чем.
Генератор - это синтаксический сахар
То есть вопрос вообще не про эффективность

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

Но на самом деле бывают и другие критерии.
У генератора есть одно однозначно полезное применение - возможность создания унифицированных интерфейсов.
Любой потоковый источник он может превратить в перебираемый.
То есть можно наплодить интерфейсов и скармливать их какому-нибудь форичу, и он будет с ними работать, не зная, поток внутри, или массив. Файл, результат запроса из БД, раскодированный джейсон - если в каждого из этих источников будет перебираемый интерфейс, то все их можно будет перебирать в одном и том же цикле.
И вот ради такой унификации и используется генератор

Вопрос очень хороший. И код в целом неплохой. А ошибки совершенно стандартные, их делают все.

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

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

Соответственно, сначала надо сделать код универсальным, и вынести в абстрактный класс.
Заодно исправив в нём одну критическую ошибку (с безопасностью) и одну логическую.
Что будет, если значения двух последних элементов массива совпадут? Тогда уж надо ключи сравнивать, а не значения.
И зачем вообще такие ухищрения с поиском последнего элемента, если у тебя есть переменная $fields? Если она пустая - значит это первый оборот цикла. Всё, этого достаточно

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

abstract class AbstractTableGateway
{
    protected $db;
    protected $table;
    protected $fields;
    protected $primary = 'id';

    public function __construct(DB $db)
    {
        $this->db = $db;
    }
    public function update(array $params): void
    {
        $this->validate($params);

        $set = "";
        foreach($params as $key => $value)
        {
            if ($key !== $this->primary)
                $set .= ($set ? "," : "") . "`$key` = :$key";
            }
        }
        $sql = "UPDATE `$this->table` SET $set WHERE `$this->primary`=:$this->primary";
        $this->db->query($sql, $params);
    }
    protected function validate($data)
    {
        $diff = array_diff(array_keys($data), $this->fields);
        if ($diff) {
            throw new \InvalidArgumentException("Unknown field(s): ". implode(",",$diff));
        }
    }
}

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

После этого уже можно создавать класс юзер (и не повторять, как попугай, user user по 10 раз)

class UserGateway extends AbstractTableGateway {
    protected $table = 'users';
    protected $fields = ['email', 'password', 'name', 'birthday'];
    protected $primary = 'user_id';
}

И спокойно к нему обращаться в коде

$user = new UserGateway();
$user->update($params);

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

(new class {
    public function log($msg)
    {
        echo $msg;
    }
})->log("hello");

You need to make your mind first, whether you want to "scale up" which means to split the processing between different servers, or you are not even sure yet, whether adding different instances is a good thing at all.

Generally scaling up a web application indeed means providing dedicated hardware for the every major service involved. For your setup I'd make it four different servers
- PHP/Nginx instance
- database backend dedicated for Postgres
- column database backend to host Clickhouse
- processing backend to host rabbitmq and Golang microsevices

The good thing, each of those can be easily scaled up in turn by simply adding more instances of the kind (I am not sure how it's done for Clickhouse tho).

But I have a feeling that you are probably confusing the scaling up with just performance optimization. And you need to start from the latter. Simply checking the CPU load is tоo rough a measurement. You need a full qualified profiling to pinpoint certain bottlenecks.

From such incomplete data I can only guess that Laravel configuration is not quite optimal. 75 rps shouldn't be a problem for such a hardware. Make sure you have all production environment settings configured properly - all caching is turned on, etc. Also, switching to 7.4 and preloading could also help.

А вся проблема в том, что ты не понимаешь, что делает "твой" код.
И следовательно, не можешь его отлаживать.

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

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

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

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

что такое array_filter? Это реализация примитивного цикла,

foreach ($array as $key => $value) {
    if (!условие фильтра) {
        unset($array[$key]);
    }
}

что такое array_diff? Это реализация чуть более сложного алгоритма, когда мы перебираем первый массив, и смотрим, есть ли такой же элемент во втором. Если нет - то записываем это значение в третий.
И так далее.

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

error_reporting(E_ALL);

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