Михаил Р.

1. Зачем парсить, если существует куча сервисов с API?
2. По geoip или как-нибудь ещё узнаешь локацию пользователя, и сопоставляешь со страницами на сайте.
Например если пользователь в Алматы, то парсишь https://www.gismeteo.kz/weather-almaty-5205/
А если в Астане, то парсишь https://www.gismeteo.kz/weather-astana-5164/

Все уровни выше users_on_lessons называются денормализацией - хранить эти данные необязательно, их можно вычислить из других по цепочке связей.
"Правильно" в данном случае не существует, вы выбираете на каждом конкретном проекте между скоростью и консистентностью. Храните денормализованные данные? Тогда придётся обеспечивать их связность, чтобы не оказалось, что в users_on_lessons пользователь привязан к одному топику, а в users_on_topics к другому. Храните только "жёсткие" данные? Тогда будьте готовы считать нужное.

Я в данном случае не вижу необходимости в денормализации в том виде, в котором вы её реализовали. Курсов относительно немного (а пользователь всегда работает только с одним из них в момент времени), в каждом курсе относительно немного глав, в главе немного топиков, в топике немного уроков. Посчитать по уроку где там пользователь в этом дереве совсем не сложно прямо на клиенте, а ведь ещё у нас есть возможность кешировать данные.

Получаем все возможные ключи; под каждый создаём пустой массив; при обработке объекта из исходного массива бежим по массиву ключей, добавляем в соответствующий массив значение из объекта или дефолтное - в зависимости от наличия ключа в объекте:

function groupValues(arr, defaultValue = null) {
  const keys = [...new Set(arr.flatMap(Object.keys))];
  return arr.reduce((acc, n) => {
    keys.forEach(k => acc[k].push(Object.hasOwn(n, k) ? n[k] : defaultValue));
    return acc;
  }, Object.fromEntries(keys.map(k => [ k, [] ])));
}


const result = groupValues(arr);

Или, результирующий объект изначально пуст; при обработке объекта из исходного массива перебираем его ключи; если ключ отсутствует в результирующем объекте, создаём массив с длиной как у исходного, заполняем его дефолтным значением; записываем в массив в результирующем объекте значение под тем же индексом, который имеет обрабатываемый объект в исходном массиве:

const groupValues = (arr, defaultValue = null) =>
  arr.reduce((acc, n, i, a) => (
    Object.keys(n).forEach(k =>
      (acc[k] ??= Array(a.length).fill(defaultValue))[i] = n[k]
    ),
    acc
  ), {});

const items = document.querySelectorAll('.item');
const sorted = [... items].map(item => item.dataset.id);
console.log(sorted);

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

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

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

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

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

Вливайтесь в сам проект по развитию Python-а. Там же много работы: Перевод, документация, библиотеки, CPython и др. Да. Сразу будет жесть как тяжело, но зато потом, потом будет такая визитная карточка, что достаточно быстро будете находить новую работу.

1) Выбираешь проект (для начала небольшой), которым пользуешься сам.
2) Смотришь список issues
3) Выбираешь ту, которую сможешь сделать сам (для начала лучше поправить небольшую багу)
4) Форкаешь проект
5) Реализуешь issue
6) Гоняешь тесты
7) Если всё ок, делаешь пулл-реквест автору
8) Повторить

Ну и главное, надо следовать общему стилю всего проекта и про pep-8 помнить.

Используйте pm2 на продакшене
Он запустит Ваше приложение в кластере (настраивается конкретное количество процессов или по числу потоков cpu)
Будет следить за потребляемой памятью и загрузкой процессора
Сделает рестарт упавшего процесса
Будет собирать логи (console.log, console.error), с плагинами можно настроить ротацию
С плагинами можно прикрутить CI для пересборки и перезапуска проекта по webhook в git
Ну и много чего еще

https://nodejs.org/api/cluster.html

Если кратко - то в Ubuntu делают pg_dump а в Windows - pg_restore.
Все остальное - это просто детализация этой инструкции.

Один порт = одно приложение. Всегда. Обычно не бывает проблем из-за того что приложения работают на разных портах - это признак того, что возможно ты не ту проблему решаешь или не тем способом.

Ты можешь поднять nginx (ну или caddy, раз уже определился) на 80-м порту и настроить его на раздачу статики и проксирование запросов.
MongoDB останется как есть.

Оправдано ли будет использование NodeJS в качестве бэкенда крупного приложения?

Если крупного - по нагрузкам и маленького по коду, вполне возможно. Если же предполагается крупная кодовая база, нода - это не лучшая идея.

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

Приведу несколько примеров.

Валидация аргументов, да можно заюзать typescript, как базу для этого, но есть момент: по хорошему, если вы вызвали некий метод с неправильными данными - его штатная работа не возможна, не плохо бы бросить исключение, но не все так просто, если ваш даже синхронный метод вызовется асинхронно - вы обязаны, либо сделать его сразу асинхронным и передавать ошибку, либо всюду хреначить try-catch, чего оптимизатор v8 не любит.

С тестами асинхронного кода все очень плохо, вам придется обмазываться всякими proxyquire, sinon и т.д. При этом очень внимательно следить за очисткой состояния. Да, я понимаю, что моки и в других языках нужно юзать, но тот же proxyquire можно сравнить с php-шным runkit, что как бы вообще по хорошему трогать не надо, а придется. Примите также за исходную, что вы будете много времени тратить на то, что бы понять какой из тестов асинхронщины у вас сфейлился.

Рано, или поздно у вас возникнет потребность в неком DI контейнере, привычный require 'myService' уже не прокатит. Пробросы зависимостей станут источником ошибок. Если вы не будете это дело покрывать функциональными тестами много ошибок обнаружите уже на stage сервере.

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

Лука Никитин
Не проводили тест, когда по 2 сервера и на ноду и на php?

Paypal и Netflix используют Node.js. У обоих нагрузки очень даже приличные.
В плане масштабируемости думайте об архитектуре. Можно и на perl написать приложение, которое за секунду будет обслуживать миллион клиентов.
Node.js будет прекрасно работать в качестве движка для типичного веб-приложения вроде магазина, чата или CRM. Если у вас очень много компонентов, например тысячи, логичнее приложение разбить на модули и сделать вместо одного приложения несколько, которые можно запускать по-отдельности (здесь уместно упоминание микросервисной архитектуры). Разумеется запросы нужно распределять с помощью балансировщика.
Есть еще такая вот штука https://serverless.com/ - ее можно масштабировать практически до бесконечности. Были бы деньги.
Node.js будет плохо работать в области процессинга данных, например генерация картинок, потоковая обработка видео, нейронные сети и т.д. Здесь лидеры C, C++, Go, Rust, Java.
Можно даже создать гибридное приложение - большую часть выполнить на Node.js, а критичную по производительности на другом языке. Например генерация миллиона прайсов в сутки в старый xls или векторный pdf, упаковка в архив и рассылка - не самая лучшая идея для Node..JS. То же C++ здесь будет вне конкуренции.

Лучше всего fontello, особенно если в дизайне есть svg иконки, их можно загрузить fontello и использовать как шрифт, при этом можно давать свои названия и префиксы, можно взять svg иконку с того же FontAwesome и подгрузить в fontello. И по итогу ничего лишнего, только то что нужно для конкретного проекта.