Сергей Горностаев

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

Ну и server side rendering для фронта, написанного на каком-нибудь реакте, ангуляре, вью, свелте не просто организовать без ноды на сервере.

Refresh-токены хранят для проверки на повторное использование. При первом использовании ставится пометка, при попытке повторного использования блокируются все refresh-токены пользователя. При следующем обновлении с любого клиента данного пользователя потребуется полная аутентификация. Можно хранить не весь токен, а только uid токена и id пользователя.

Подыскиваю сейчас курс, да такой, чтобы можно было за какой-то срок полностью въехать в дело.

Хотелось бы работать с бакендами, сайтами. Что-то в этом направлении.

• Любой учебник по Python;
  
• Учебник по СУБД (проектирование и sql);
  
• Документация/учебник по фреймворку;
  

Только так.

Цикл while?
Не, серьёзно. Это основы языка. Открой учебник и читай.

Почему не переписать вместо этого
add ebx,dword ptr [rbp+ECX*4+10h]

Буквально так написать нельзя, потому что нет такого режима адресации в котором можно было бы использовать вместе Rbp (64-битный) и Ecx (32-битный). Можно было бы написать add ebx,dword ptr [rbp+rcx*4+10h], но для этого счётчик цикла должен был бы быть 64-битным, а он, как мы видим, 32-битный (int i). Т.е. ответ на вопрос "для чего это": для беззнакового расширения 32-битного счётчика цикла в регистр, который можно использовать для доступа к памяти.

Другое дело, что из исходного кода очевидно, что при обращениях к памяти i не выходит из диапазона 0..9, так что разницы между ecx и rcx нет и не может быть. Возможно я что-то упускаю и у компилятора другое мнение на этот счёт, но может быть он просто туповат и не имеет кода который бы мог использовать эту возможность оптимизации, а может такая оптимизация и есть, но она не была включена во время генерации этого кода.

В общем, чтобы не издеваться над девушкой, объясним на пальцах.

Во-первых, заголовок у вопроса чудовищно некорректный. Это все равно что спросить, "что быстрее - пылесос или стиральная машина?"
Во-вторых, ответ на вопрос "производить ли обработку данных в БД или же запросить все данные в клиентское приложение и обрабатывать там" совершенно очевиден: обработку данных следует производить в общем случае только в БД. Она для этого и придумана. Чтобы обрабатывать значительные объемы данных.

Да, js тоже "может" обрабатывать большие объемы данных.
Но чтобы значительный объем данных обработать, его сначала надо передать, полностью забив канал между сайтом и базой
Чтобы значительный объем данных обработать, его надо сначала проиндексировать. Причем делать это каждый раз, а не использовать уже имеющийся набор индексов
Чтобы значительный объем данных обработать, надо иметь значительный объем памяти или упасть из-за её недостатка
Чтобы значительный объем данных обработать в многопоточном режиме (а сайт как раз является многопоточной системой), все вышеперечисленное надо умножить на количество посетителей сайта - при каждом запросе перегонять весь массив данных, выделять память, индексировать, считать. Если же вы оставляете все данные в памяти приложения, то их тогда надо как-то синхронизировать с БД. То есть вы себе собираете кучу проблем на пустом месте.

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