smilingcheater

Вообще это очень нерационально гонять mysql почем зря каждую секунду.
Более целесообразно при выборке вместо поля suc проверять разницу текущего времени с полем date.

Call to a member function bind_param() on boolean

Где вызывается bind_param()?

$stmt->bind_param("ssisss", $plaintiffs_json, $respondents_json, $type, $reason, $petition, $video);

Где stmt получает значение?

$stmt = $conn->prepare("INSERT INTO `cases`(`nickname`, `respondent`, `type`, `reason`, `petition`, `video`) VALUES (?, ?, ?, ?, ?, ?)");

В каком случае prepare может вернуть значение типа boolean?

mysqli_prepare() returns a statement object or false if an error occurred.

Вывод - при вызове prepare возникает ошибка.
Как найти ошибку? Либо проверить $conn->error после вызова prepare, либо, что правильнее, сразу настроить mysqli на выброс исключений при ошибке, добавив перед соединением с базой вызов

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

Смотри. Уже прошло время когда все пилили монолиты на микросервисы. Щас пошло переосмысление.
Объективно есть 2 причины пилить. Первое - организационная. Команда по какой-то причине не хочет
или не может поддерживать приложение. Или там что-то с бизнесом. Слияние. Поглощение. Передача
проекта другой команде в поддержку. Тогда берут и ставят задачу раздела отвественностей.
Конвей про это писал еще.

И второе - это баланс нагрузки и децентрализация. Про failover тут еще даже речи нет. Это
тяжелая тема и распилить монолит так чтобы его части были отказоустойчивы очень трудно. Более
того в случае синхронных взаимодействий между частями микросервисов может быть даже падение
перформанса. Да. Теоретики которые там пишут восторженные отзывы - совершенно игнорируют
накладные на RPC. И не упоминают что в монолите цена RPC была равна нулю. Иногда RPC заменяют
на MQ - но это новая архитектура и это надо полностью переделывать бизнес.

И что делать с базой данных? Это тот еще вопрос. Я почти готов спорить что вы базу пилить не будете.
И что в результате будет? Иммитация микро-сервисов? Где слабая связность?

Тоесть если у вас нет таких кричащих ситуаций что оргазниация требует или нужно баланс
нагрузки как-то разнести - то тебе вообще-вообще нет смысла ходить ни в какие микросервисы.

Но имеет смысл сделать модуляризацию монолита. Например что там...

application
- sales
- hiring
- userprofiles

Тоже очень полезно для управления сложностью. И пускай себе будет монолит зато будет сильный
контроль за изменениями.

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

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
$conn = new mysqli("зачем", "вам", "это", "знать?");

$name = $_POST["name"];
$login = $_POST["login"];
$pass = $_POST["password"];

$sql = "INSERT INTO admins (login, pass, name) VALUES (?,?,?)";
$stmt = $conn->prepare($sql);
$stmt->bind_param("sss", $login, $pass, $name);
$stmt->execute();

$id = $conn->insert_id;
header("Location: profile.php?id=$id");

Пара замечаний

• отдельная таблица админов обычно не делается, достаточно общей таблицы пользователей
  
• id вставлять не надо, его должна генерировать БД
  
• после успешной обработки прямого POST запроса обязательно должен быть редирект. Обычно это либо созданная учетка, или страница входа или список пользователей или что-то ещё
  
• при обработке прямого запроса никаких echo в коде быть не должно
  

У проца TDP меньше 100 Вт. Подойдет любая жижа сомнительного происхождения.

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

когда лучше реляционную и нереляционную использовать?

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

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

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

Проще всего рут комментарию давать парент_ид равный своему ид, тогда все становится элементарным - ордер по парент_ид, креатед_эт. При выводе просто проверять если парент = ид. А все коментарии которые ответы на ответы все равно писать как ответ на рут коментарий, так как они будут тупо по дате строиться, и разницы в принципе нет. Разве что вы хотите чтобы ветвление было бесконечным, тогда проще ввести рут_ид.

поэтому использую ajax. Как я понял, в контроллере нельзя получить сведения о пользователе, если данные передаются таким споссобом

Дайте угадаю. Конфигурация по умолчанию, и вы делаете запрос на роут /api/blabla
Только вот /api по умолчанию предлагается использовать для stateless запросов.
Можете использовать другой роут, например /ajax/bla, тогда все запросы будут проходить через группу миддлвэров web и стартовать сессию.
Или исправить RouteServiceProvider

Route::prefix('api')
    // ->middleware('api')
    ->middleware('web')
    ->group(base_path('routes/api.php'));

B тогда у вас в контроллере, вызываемом через аякс, будет текущая сессия, а значит и Auth::user() будет содержать текущего пользователя.

PS Passport и Sanctum тут совершенно не нужны.