smilingcheater

Смотри. Уже прошло время когда все пилили монолиты на микросервисы. Щас пошло переосмысление.
Объективно есть 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 тут совершенно не нужны.

Никакую базу, имхо, не нужно использовать с "FTP через FUSE".

С помощью systemd
Создайте файл `myscript.service`

[Unit]
Description=Мой скрипт

[Service]
ExecStart=/путь/к/вашему/скрипту.sh

2. Создайте таймер для запуска скрипта `myscript.timer`

[Unit]
Description=Таймер для моего скрипта

[Timer]
OnCalendar=*-*-* 00:00:00
RandomizedDelaySec=3600

[Install]
WantedBy=timers.target

3. Активируйте и запустите таймер.

sudo systemctl daemon-reload
sudo systemctl enable myscript.timer
sudo systemctl start myscript.timer

Параметр `RandomizedDelaySec` устанавливает случайную задержку в секундах между запусками.

Если обе базы в одной СУБД вы можете это вообще одним запросом делать

SELECT A.*, B.* FROM db1.table1 A LEFT JOIN db2.table1 B ON A.id = B.id

Ну и у меня есть подозрение, что вы путаетесь в терминологии, и на самом деле все проще, и у вас одна база, но разные таблицы.
Просто JOIN это для вас какой-то страшный зверь, а не один из основных инструментов СУБД.

А что за ответ вы услышать хотите? Остальные вопросы это какие? Что не получилось? Конкретной информации по какому вопросы вы не нашли? Вы вопрос без вопроса задали. Напишите ваши "остальные вопросы" и тогда вам смогут подсказать где найти "конкретную информацию".