Ну сохранит он там в замыкании. Все равно из кэша ведь будет брать для всех модулей эти буфферы

Запустил проект на ноде локально. Пытаюсь сделать fetch POST запрос с клиента на сервер, но почему-то не работает. Сам запрос проходит, но payload на сервере показывает отсутствие данных в запросе.
При этом через Postman я делаю тот же самый запрос и все работает отлично.

Вот мой код fetch POST запроса, что не работает:

javascript
    (async () => {
      const response = await fetch('http://localhost:5000/auth/', {
        method: 'POST',
        mode: 'no-cors',
        headers: {
          'Accept': 'application/json',
          'Content-Type': 'application/json'
        },
        body: JSON.stringify({pass: '123'}),
      });

      const result = await response.json();
    })();

Если же делаю запрос к http://localhost:5000/auth/ через Postman, то все работает отлично.

Также на реальном сервере работает нормально, только в локальном запуске проблема.

https://www.youtube.com/watch?v=STyocIjskBE пройшло 5 років, ця вада вирішена?

А можна дізнатися що за недолік не переглядаючи відео?

наскільки я зрозумів, це коли відбувається uncaughtExeption під час реквестів, не можливо відстежити, на якому іменно реквесті це відбулося

если не ошибаюсь нужно алиас создать в hosts главное чтобы не было localhost в строке

127.0.0.1       testlocals.com

Я могу и сюда делать запросы: http://127.0.0.1:5000/ если не нужно, чтобы localhost был в строке, но это ничего не меняет.

це схоже на проблему асинхронного програмування в цілому, а не на проблему конкретно nodejs
є async_hooks - модуль який може допомогти, але він ще не стабільний

зрозумів

можно еще добавить  "proxy": "http://localhost:5000" в package.json

тогда в адресе запроса нужно указывать относительный путь fetch('/api/todos')

Может проблема в gulp еще. Я клиент запускаю через gulp на localhost:3010 и gulp запускает сервер на localhost:5000 ну и соответственно с одного я делаю запросы на другой, запросы проходят, но сервер не видит payload запроса, хотя он есть.

это не проблема обычно так и работают на разных портах

ок, спс, сейчас попробую твои варианты

В Метархии все было решено с этим в 2013 году еще

Это про краш процессов или состояния гонки после которых нужно перезагрузить процесс

всем привет.
вопрос по типизированным массивам.
допустим, у нас ситуация когда два типизированных массива с числами разного типа, и оба этих массива ссылаются на один буфер:

const buffer = new ArrayBuffer(16);
const int8view = new Int8Array(buffer);
const int16view = new Int16Array(buffer);

for (let i = 0; i < int8view.length; i++) {
  int8view[i] = i;
}

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

так уж устроено, да нужно принять как данное

Порядок от младшего к старшему

Порядок от младшего к старшему (англ. little-endian — с малого конца): A 0 , … , A n − 1 {\displaystyle A_{0},\dots ,A_{n-1}} {\displaystyle A_{0},\dots ,A_{n-1}}

Это обратный привычному порядку записи чисел арабскими цифрами, например, число сто двадцать три было бы записано при таком порядке как 321. Иными словами этот порядок подобен правилу записи «справа-налево».

Этот порядок записи принят в памяти персональных компьютеров с процессорами архитектуры x86, в связи с чем иногда его называют интеловским порядком байтов (по названию компании-создателя архитектуры x86). Современные процессоры x86 позволяют работать с одно-, двух-, четырёх- и восьмибайтовыми операндами. В таком порядке следования байтов очень удобно то, что при увеличении размера (количества байтов) операнда, значение его первого байта неизменно: 3210 → 3210’0000. При порядке от старшего к младшему значение изменилось бы, например: 0123 → 0000’0123;

Кроме x86, такой порядок байтов применяется в архитектурах VAX (отсюда ещё одно название англ. VAX byte order[1]), DEC Alpha и многих других.

Также порядок «от младшего к старшему» применяется в USB, PCI, таблице разделов GUID, он рекомендован FidoNet. Но в целом соглашение little-endian поддерживают меньше кросс-платформенных протоколов и форматов данных, чем big-endian.

Привет. Как выше и написали, какой байт будет считаться старшим, первый(левый) или последний(правый) зависит от big endian и little endian. Когда мы работаем с типизированным массивом, то порядок зависит от нашей машины.
Но если мы обернем буфер в DataView, то мы можем даже этим управлять.
Как например в этих примерах
https://github.com/HowProgrammingWorks/TypedArrays/blob/master/JavaScript/2-DataView.js

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

const buffer = new ArrayBuffer(16);
const view = new DataView(buffer);
for (let i = 0; i < 16; i++) {
  view.setUint8(i, i * 2);  
}

И дальше мы можем получать это число в разных представлениях, типа

const int16 = view.getInt16(0);
console.log(int16);

Мне было интересно как это работает под капотом. в данном случае берутся значения двух первых байтов в их двоичном представлении и просто склеиваются, и полученное двоичное число конвертируется в десятичное представление. И в случае с DataView порядок байтов прямой, я проверял