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

Короче, забудь про абсолюты как про страшный сон. Очень редко, только когда другое ну никак нельзя.
Сделать можно разными способами, например на флексах

'localhost', 'mysql' - это всего лишь указание на хост для коннекта.
В самом простом случае, можете на своей машине прописать что , mysql -> 127.0.0.1

Перезаписываете в цикле
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, поэтому и нужны доп пакеты, которые закрывают конкретные цели.
Если у вас целевое приложение, то незачем его корневую бизнес логику куда-то выводить.