Александр Талалаев

Насчёт конкретно подхода о котором вы говорите не скажу, скорее всего это плохая идея. Видел пару примеров несколько лет назад, бОльшая часть этих модульных подходов было нечто среднее между недомикросервисного подохода, с примесью разработки composer пакетов и элементами (концептуальными) плагинов wordpress.
Или другой подход где "модули" laravel разделялись пространством имен и особой структурой, с некоторыми костылями для поддержки разделения кода. Этот подход формально лучше, но по факту обычное не нужное усложнение проекта. Но если вам интересно, можете изучить https://github.com/nWidart/laravel-modules
Но как по мне, если уж и заморачиваться в подобном плане, то скорее наоборот отвязкой максимальной ядра приложения от любого фреймворка framework-agnostic подход.
А так... Главный принцип, в целом кстати во многом пересекается с принципами микро сервисной архитектуры:
есть определенная часть/логика приложения, которая может выполнять свою функцию независимо, которую могут писать разработчики независимо, можно выделить в отдельный пакет. Например, вы придумали свой крутой прокси изображений, и он как-то явно выходит за рамки вашей бизнес-логики приложения, более того возможно он пригодится в ваших других приложениях (или вы хотите поделиться с миром) делайте отдельный пакет.
Ну и конечно у таких пакетов, могут быть зависимости в виде других пакетов.
А вот прям делать декомпозицию приложения на пакеты, ради декомпозиции не стоит. Только если есть конкретный смысл что-то выделить.
Примеры вот хорошие у Spatie https://spatie.be/open-source?search=&sort=-downloads .
Там же можно посмотреть, как пакеты зависят друг от друга, например image от image-optimizer.
Все их, достаточно популярные, пакеты вышли из практики разработки приложений для клиентов.
Ближе к вашему примеру это проект Nova https://nova.laravel.com/ и тоже имеет кучу пакетов https://novapackages.com/ .
Но здесь тоже нужно учитывать, цели самой Nova и почему такая организация. Сама Nova это как бы расширяемый прототип панели управления для CRUD приложений, она универсальная by design, поэтому и нужны доп пакеты, которые закрывают конкретные цели.
Если у вас целевое приложение, то незачем его корневую бизнес логику куда-то выводить.

//Получаем коллекцию всех элементов с классом Text
const elementsTextClass = document.getElementsByClassName('Text');

//Проходим по всем элементам
for (const element of elementsTextClass) {
//Проверяем текстовое содержимое текущего элемента
  if (element.textContent === 'Bye, Wrld!') {
   //Выводим id родителя
    console.log(element.parentElement.id)
  //Дальше нам не нужно перебирать элементы выходим из цикла
    break;
  }
}

Проверьте верно ли вы сделали настройки вашего веб сервера. Потому как в момент использование приложения, там url строка в браузере динамически подменяется и лишних запросов к вебсерверу (помимо запроса данных ) особо нет. А вот при обновлении, либо прямом заходе по url идёт прямое обращение к нему. И если у вас не верно настроен Apache или nginx (или что там у вас), то не найдя страницу/правила/логику для example.com/login (а у вас там что-то вроде index.html и дальше только папки с асетами и тп) он и вернёт соответствующий результат что ничего не наёдено.

Вы забыли указать параметры при вызове
let multiply = getMultiply(1, 2, 3);
Кстати, неплохо бы сделать проверку на это внутри вашей функции. Либо сделать параметры по умолчанию

Зачем что-то парсить лишний раз. У вас приходят даты в UTC (Z в конце говорит об этом).
Карбон отлично всё создаёт из этой строки

$tm = Illuminate\Support\Carbon::create('2022-05-01T07:00:00.000Z');
/*
Illuminate\Support\Carbon @1651388400 {#4888
     date: 2022-05-01 07:00:00.0 +00:00,
   }
*/
В базе мы тоже(надеюсь) храним в UTC
<code lang="php">
$tm->setTimeZone('Europe/Moscow');
/*
=> Illuminate\Support\Carbon @1651388400 {#4887
     date: 2022-05-01 10:00:00.0 Europe/Moscow (+03:00),
   }
*/
$tm->setTimeZone('Europe/London');
/*
=> Illuminate\Support\Carbon @1651388400 {#4887
     date: 2022-05-01 08:00:00.0 Europe/London (+01:00),
   }
*/
</code>

0. В целом на уровне БД редко есть смысл запрещать пустой пароль.
1. Инициируем создание объекта пользователя, заполняем поля, которые возможны (Имя, имейл если сетка отдает и тп)
2. Сохраняем его куда-нить(ну допустим в локалсторе), создаем кукис, запоминаем что он незавершил регистрацию
3. Пользователю показываем блокирующее любые другие штуки окошко/страницу с просьбой завершить регистрацию и ввести пароль.

Запускать нужно в веб сервере с соответствующими настройками.
Когда вы разрабатывали приложение и запускали локальный сервер, который брал всё на себя.
А так, допустим вы используете Apache там свои настройки, Nginx свои. Во множестве облачных сервисах нередко всё оптимизировано и почти ничего делать не нужно. Для условного Github Pages нужны свои небольшие манипуляции.
Поэтому.
1. Определитесь с веб сервером/площадкой где вы будете размещать проект
2. Гуглите "Сервер/площадка react router settings" "Сервер/площадка react router deploymnet" и тп.
Для локального у вас на компьютере нужно скачать какой-нибудь веб сервер(условный wamp или альтернативы), создать сайт там и тестировать.

Сама запись просто укороченный способ записать функцию которая возвращает функцию, которая возвращает функцию.

function logger(store) {
  return function wrapDispatchToAddLogging(next) {
    return function dispatchAndLog(action) {
      console.log('action', action)     
      console.log('next', next)
      console.log('store', store)
      return next
    }
  }
}

Легче читается так

const logger = store => next => action => {      
      console.log('action', action)     
      console.log('next', next)
      console.log('store', store)
      return next       
}

И вызвав logger(1)(2)(3); вы получете:

action 3
next 2
store 1

Далее, сама applyMiddleware уже умеет(с проверками и парочкой хитростей и ограничениями) прокидывать нужные параметры, запуская каждый middlware, на каждом этапе добавляя параметр.
Условный пример, не про реальность, а так чтобы понятно:

//Наш миддлвар
const logger = store => next => action => {      
      console.log('action', action)     
      console.log('next', next)
      console.log('store', store)
      return next       
}
//другой наш миддлвар
const logger2 = store => next => action => {      
      console.log('action2', action)     
      console.log('next2', next)
      console.log('store2', store)
      return next       
}

//Наша функция применялка, которая берет все миддлвары и будет с ними что-то мутить
function applyMiddleware(...middlewares) {
  const param1 = 1;
  const param2 = 2;
  const param3 = 3;
  const do1 = middlewares.map(middleware => middleware(param1))
  const do2 = do1.map(middleware => middleware(param2))
  const do3 = do2.map(middleware => middleware(param3))
 //Возвращаем условно 
 return 1
}

//Где-то в коде мы вызываем applyMiddleware
applyMiddleware(logger, logger2 )

//В консоле получим
//action 3
//next 2
//store 1
//action2 3
//next2 2
//store2 1

Сразу отмечу: писать свой велосипед, кроме как для получения личной практики - не советую. Будет бесконечное число подводных камней, костылей и тп, которые разработчики различных БД уже прошли.
А так, если нужно простое решение советую обратить внимание на SQLite. Там не требуется отдельный сервис/демон у вас должна быть реализация под ваш язык/фреймворк/среду и она будет работать.
Достаточно надёжное решение.
PS отдельно отмечу, возможно, вы имели ввиду совсем другое.

Laravel Sail всего лишь обёртка с командами чтобы быстро развернуть удобное докер окружение вокруг Ларавел.
Поэтому запускаете Docker Desktop и там можно посмотреть какие контейнеры и тп есть в системе. Там же можно быстро удалить.

Начни с базовых штук, но усилить можешь любимым языком программирования.
В вашем случае это JS. TypeScript - это тот же JS но обернут некоторыми фичами, а React использует JS(и/или TypeScript) вы будете на нём писать, соответственно не зная языка, делать что-то больше простых реактивных кнопочек будет сложно.
Советую глянуть сюда
https://ru.hexlet.io/webinars (там проскролить чуть ниже к "Бесплатные курсы"), там годные указания и начало базового пути.
Ну и конечно же сюда: https://roadmap.sh/frontend
Крайне не советую тупо учить React, вы быстро упретесь в стеклянный потолок условного "скриптокидди", и ничего толкового в любой продуктовой или крупной компании сделать не сможете, да и не возьмут (впрочем такие встречаются чаще чем хотелось бы, так что как-то пролазят хех).
Не бойтесь объёма, идит шажками.

Тут прямая зависимость от системы что у них на сервере. Есть те, кто относится к внезапной смене ip лояльно, есть кто не приемлет вообще. Ну и куча градаций, к примеру менять можно, если это не известный ip из серверных(не домашних) и тп и тп.
Таким образом они видимо сохраняют на сервере ip с которого были установлены эти куки и отклоняют если не совпадает.
Вывод - вы ничего не сделаете.
Можно только с владельцами сервиса договориться, чтобы сделали для вас исключения и тп