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

Перезаписываете в цикле
contactList.appendChild(template)
Вынести нужно его за цикл

for(let valueKey in contact.contact_value) {
//***
}
contactList.appendChild(template)

Построение маршрутов нетривальная задача и для неё нужно огрмное число данных, так здесь вам придётся использовать API от владельцев этих данных(яндекс карты и тп).
Трекинг легче. Просто раз в какое-то время сохраняете координаты в базу данных. Расстояние считаете кусочками по формуле геверсинуса, пример с кодом www.movable-type.co.uk/scripts/latlong.html
Насчет лимитов. Сразу говорю вам не хватит, бесплатные лимиты чисто потестить с друзьями/тестерами. Ну и бюджет зависит от количество запросов, фич что вы используюете. Здесь тоже есть место для автоматизации и кеширования(в ущерб конечно интерактивность и удобства).
Можете начать с openStreetmaps и для интерфейса. У них даже есть краудсорсевые маршутрные сервисы https://wiki.openstreetmap.org/wiki/Routing https://wiki.openstreetmap.org/wiki/Routing/online...

У вас есть два пути, у которых есть общая часть это данные о языке оригинале (правда не без подводных камней, есть двуязычные, но пока опустим).
Первый вариант, вы в Song храните id песни, язык оригинала(пусть сейчас условно строка, 'en' или 'ru', но возможно id языка и связь с другой таблицей), ну и другие мета данные, айди автора, группы и прочее.
а в отдельной таблице SongTranslations вы храните уже id, id песни, язык(или его id), название, текст.
Второй вариант, мне он немного больше нравится в самой таблице Song сделать больше текстовое/json поле где мы будем хранить переводы песни в виде json (снова таки возможно он будет сложнее)

{
[
{'en': { 
title: 'название на английском',
lyric: 'текст на английском'
}
},
{'ru': { 
title: 'название на русском,
lyric: 'текст на русском'
}
}
]
}

Ну идею вы поняли

Если очень кратко - фреймворк и это Laravel.
А если чуть подробней, то важнее показать, что решаешь конкретную проблему, можно даже взять какую-либо среднею проблему из популярных с задач/запросов на фриланс биржах.
Показать, что понимаешь построение базовой структуры проекта, основные принципы проектирования (условные SOLID) и решаешь определенную задачу приносящую понятную очевидную пользу.
Последнее тоже важно. Иногда пишут запудренные, оверинжиниринг штуки, но что она решает и зачем нужно ещё разобраться. А тут и понятная проблема, понятное решение, относительно красивый и понятный код.

Да, код нужно чтобы загружался и срабатывал на каждой странице, которую вы хотите отслеживать и видеть статистику использования.
Насчёт index.php - обратитесь к вашему разработчику, тут зависит слишком от многих вещей.
Я советую вам добавить google tag manager(его так же нужно установить на каждой странице), а уже в дашборде google tag manager добавлять аналитику и другие скрипты. С google tag manager вам не нужно будет лишний раз трогать разработчика, бОльшую часть задач по добавлению аналитики, метрики и других подобных штук нужных маркетологу(и около) можно добавлять самому. В интернете полно уроков на этому инструменту, советую изучить.

Насчёт конкретно подхода о котором вы говорите не скажу, скорее всего это плохая идея. Видел пару примеров несколько лет назад, бОльшая часть этих модульных подходов было нечто среднее между недомикросервисного подохода, с примесью разработки 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. Пользователю показываем блокирующее любые другие штуки окошко/страницу с просьбой завершить регистрацию и ввести пароль.