Дмитрий Беляев

https://ru.wikipedia.org/wiki/Расстояние_Левенштейна

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

Итак, мы пишем на нашем высокоуровневом любимом языке, неважно JS/Rust/C#/Scala/Python или любой другой. В современном мире у нас скорее всего есть какая либо абстракция для работы с асинхронными апи, предоставляемая или стандартной библиотекой языка или сторонними библиотеками. Она может быть примитивной и основанной на колбэках или более продвинутой, вроде Future/Promise/Task или чем-то подобным. Иногда наш язык предоставляет синтаксис наподобие async/await для более простой работы с этими абстракциями, а иногда асинхронная работа может вообще быть скрыта от нас в рантайме языка, например как с горутинами в Go. Но в любом случае где-то под капотом у нас будет event-loop, а иногда и не один, так как никто не запрещает нам писать многопоточку в то же время используя асинхронные вызовы.

Сам event-loop - это не более чем обычный while(true) или любой другой бесконечный цикл. И внутри этого цикла наша программа имеет доступ на извлечение к некоторой очереди (если не знаете, что это за структура данных, то погуглите), которая содержит в себе результаты уже обработанных задач. Программа берет очередной результат, находит ожидающий ее колбэк/Promise/Future/Task и запускает выполнение ожидающего кода. Очередей опять же может быть несколько и обрабатываться они могут по разному, но это не важно. Важно то, что наш основной поток (или потоки) ничего не знают, о том как выполняются асинхронные задачи. Он лишь смотрит, есть ли в очереди результат, и если есть - обрабатывает его, а если нет, то принимает решение или выйти из цикла (и завершить поток, а иногда и весь процесс) или уснуть пока новых результатов не появится.

Но откуда же в очереди берутся результаты? Надо понимать, что асинхронная программа почти всегда многопоточная и результат операций попадает в очередь из фоновых потоков, которые просто блокируются в ожидании нужного ресурса (или сразу многих ресурсов, если используют системные апи вроде epoll или kqueue). Как правило такие фоновые потоки большую часть времени находятся в состоянии ожидания, а значит не потребляют ресурсы CPU и не попадают в планировщик ОС. Такая простая модель действительно позволяет сильно экономить ресурсы по сравнению с моделью, где множество потоков выполняют по 1 задаче и самостоятельно ожидают свои запросы.

Важно отметить, что в современном мире даже на среднеуровневых языках, вроде C или C++, не говоря уже о высокоуровневых, не реализуют асинхронность сами. Во-первых, на разных ОС для этого используются разные апи. Во-вторых, эти апи на разных ОС умеют обрабатывать разные типы ресурсов (с сетью вроде как умеют работать все основные ОС, но помимо сети асинхронно можно работать с пользовательским вводом, диском и периферийными устройствами, вроде сканеров, вебкамер и прочего цепляемого в usb). Наибольшую популярность (ИМХО) имеет кроссплатформенная библиотека libuv, хотя в Rust принято использовать mio (или даже абстракции над ней, вроде tokio), в C# подобные механизмы есть в .NET Core, а в Go оно уже зашито

Ок. С прикладным кодом вроде разобрались. А что же происходит в ядре ОС? Ведь, как писалось выше, у нас даже есть апи, чтоб ждать запросы пачкой. Все просто. Ядра ОС стали асинхронными еще до того, как это стало мейнстримом, если мы конечно имеем дело не с ОС реального времени (но у нас же винда/линь/мак/фряха, а не ОС для бортового компа боинга, где это критично). Смотрите, когда что-то происходит на внешней периферии (ну например диск запрошенные данные прочитал или по сети данные пришли, или юзер мышкой дернул), то формируется прерывание. CPU реально прерывает свою текущую работу и бежит смотреть что случилось, точнее вызывает обработчик предоставленный ОС. Но у ОС то есть основная работа, поэтому она скорее старается освободить обработчик и просто скидывает все данные в оперативку, а разбираться будет потом, когда очередь дойдет. Ничего не напоминает? Очень похоже, на то что происходило в event-loop, только вместо фоновых потоков "результаты" попадают в очередь из прерываний. А уже когда-то потом ОС отдаст данные в драйвер устройства, ну и т.д., пока они не дойдут до нашего прикладного приложения. Вот и все, никакой магии.

Как по человечески сделать?

никак, nuxt мартышки делали, а не люди...

Нашел один способ - через костыли - прицеплять данные к req.

к сожалению это единственный способ сделать +/- адекватно, не гоняя при этом запросы через axios

Потому что лайки - это не просто int счетчик в таблице статей, это отдельная таблица вида
user_id | article_id | еще какие-то поля, вроде логов или еще что-то надо
Первичным индексом у этой таблицы будет 2 поля - user_id и article_id
И уже сама база не позволит одному юзеру поставить лайк 2 раза на 1 статью

Для начала стоит понять сам термин "побочный эффект".
Вот Вы вызываете функцию, а она что-то делает за своими пределами, например пишет в файл или localStorage, или меняет Ваш DOM на странице, или меняет глобальные объекты. Это и есть побочные эффекты.
Модуль тоже может иметь побочные эффекты. Например Вы можете не просто экспортировать некоторые функции из модуля, но и сразу что-то сделать, вне всяких функций.
Например пусть у нас будет такой модуль:

const div = document.body.appendChild(document.createElement('div'));

export function remove() {
  document.body.removeChild(div);
}

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

Конкретно в контексте вебпака и импортирования стилей, у Вас скорее всего будет включен в обработку или style-loader или MiniExtractCssPlugin.loader. Побочный эффект style-loader - добавление тега style со стилями из импортируемого css в head. А у MiniExtractCssPlugin.loader - побочный эффект - извлечение стилей в отдельный файл.

Никак. LocalStorage не связан с запросами, он управляется чисто скриптами. И он не хранит информацию, о том кто и когда в него писал или читал из него. Все что хранится - это строки: ключ и значение

Правильным ли решением будет использовать redux для обычного веб-ресурса

Почему бы и нет. Redux не имеет никакого отношения к React от слова совсем.

Или есть альтернативы ?

Ну можете взять обычный compose из lodash/ramda (в ramda кстати есть линзы, которые хорошо помогают работать с иммутабельными объектами) и соединить им Ваши "редьюсеры". Положить объект в переменную state в замыкании, и все - свой redux готов.
Можно так же глянуть в сторону mobx или svelte/store если действительно хочется реактивности, а не тупого клонирования объектов

Можно. В том числе и без дополнительных пакетов.
Нодовский require в render процессе есть так же в глобальном объекте (в window) и работает относительно html файла, с которым этот render процесс был запущен.
Для вызова builtin модулей (всяких fs или самого electron) вообще пофиг, относительно чего работает require.
В main процессе при создании render процесса (а так же для всех webview) нужно разрешить nodeintegration

1. scss можно подключать из ts файла просто через import, в webpack скорее всего уже настроен необходимый лоадер. Со scoped конечно сложнее, но ИМХО scoped тормознутое зло, лучше css modules использовать, которые опять таки разруливаются через css-loader
2. для шаблонов можно написать кастомный лоадер, который будет их компилировать, и можно будет просто заимпортить из ts

import {render, staticRenderFns} from './messager.pug';

и вставить как есть в компонент
Сам ts файл и будет делать export default компонента
3. для самого ts нужно будет описать declare module '*.pug' {} иdeclare module '*.scss' в каком нить .d.ts файле в корне проекта

Вот только зачем? Вы лишаетесь HMR (хотя для шаблонов можно сделать в лоадере). Код компонента становится раскиданным по 3 файлам, что делает хуже его поддержку. Ну и другие разработчики явно Вас проклянут за такие костыли.

https://gist.github.com/wuzzabi/9094585b852292058d...
вот здесь Вы потеряли контекст

let rawNews = []; // Массив объектов (Свеженькие новости прямо из БД)
let rawCats = []; // Массив объектов с обработанными новостями
// Промис с массивом результатов
let modifyNews = Promise.all(rawNews.map(async (item, i, arr) => {
    item.autor = await getUserByID(item.autor); // Асинхронная функция которая выставляет имя автора вместо id
    return item;
}));

так?