Robur

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

Ну так у вас задача именно так и сформулирована - "появилась необходимость завязать два сервиса друг с другом".
Вы не сможете завязать сервис на что-то внешнее если не добавите в него зависимость на это внешнее в том или ином виде.
В такой ситуации завязать на стандартное апи которое абстрагирует один сервис от другого - это хороший и даже правильный вариант.

Как проще реализовать подобные блоки?

Простыми div с заливкой и позиционированием, это ж просто черные и белые прямоугольники. Если хотите красоты в коде - то блоками before, after, тегов меньше, суть та же.

Нет. Но могут быть. Как сделаете.
И мне кажется что вы или тот кто вам это заявил путает асинхронную функцию с асинхронной логикой.

Какое внешнее лексическое окружение у анонимной функции, создаваемой при вызове другой функции в качестве ее аргумента?

такое же как у создаваемой в любых других условиях. например при `const x=() => {}` факт наличия вызова другой функции не играет никакой роли для привязки лексического окружения, в этом его смысл. так как функция стрелочная, this привяжется вместе со всем остальным контекстом.

Во втором примере у вас нет стрелочных функций, поэтому this никуда не привязывается и определяется контекстом вызова sayHello, остальные переменные, если они будут - привязываются по общему принципу замыканий - лексического контекста

const x=1
console.log(this) //некий объект A
doSomething( () => console.log(this, x))// this привязан, равен A, x привязан равен 1

doSomething(function () { console.log(this, x)}) //this не привязан значение зависит от кода doSomething, x все так же привязан, равен 1

Выглядит странно, ранее очень редко встречал такие конструкции,

вполне себе нормально, assertSomething()
даже в ноде в стандартной либе есть https://nodejs.org/api/assert.html#assert_assert_o...

ваш if (cond) throw 'aaa' превращается в assert(cond, 'aaa'). Наглядно, понятно, в одну строчку. Ну или еще как вам будет удобнее.

сейчас получается так что на http свое хранилище, а на https свое. как будто другой сайт.

да, это разный origin со всеми вытекающими. Все равно что разные айпишники.

Непонятно, если у вас уже есть https то в чем проблема его использовать в обоих вариантах?

да, возможно. сразу после строчки if (json.result == "success") {
добавляйте ваш код очистки.

точное время выполнения одного вызова функции получить довольно сложно.

во первых - performance.now возвращает дробное число, поэтому там в принципе может быть наносекундная точность. однако стандарт определяет что точность должна быть 5 микросекунд. Плюс браузеры могут специально занижать точность чтобы бороться с некоторыми атаками.

поэтому правильно вызывать функцию много раз и считать среднее.
так же в ноде есть process.hrtime которая дает наносекунды.

оба этих метода "в лоб" не дадут нормального результата. Почему? потому что в реальности происходит много всего интересного при выполнении кода.

в движке есть неимоверное количество оптимизаций, и функция вызванная 10 раз будет иметь совершенно другой код чем функция вызванная 100 раз. То же касается и типов параметров - например вы можете передавать целые или дробные числа.
На одну вашу написанную js-функцию движок сгенерирует несколько функций которые это реализуют. У этих функций может быть совершенно разный код с разной произодительностью.

Переключение происходит на лету и в общем виде вы не знаете когда это происходит.

поэтому само по себе замерение скорости "функции" имеет мало смысла, так как там их несколько внутри. Если интересны детали - погуглите JIT, AOT и v8 optimizations.
Сейчас важно то что есть "холодные" функции которые работают медленее но надеждее и как правило используются сразу и есть "горячие" варианты, которые компилятор начинает использовать когда видит что код вызван много раз, и условия не меняются. "Горячие" работают быстрее.

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

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

или, как вы сказали, запустить его миллион раз (думаю хватит и десятка тысяч), и первые запуски холодного кода не будут особо влиять. Это можно определить по тому как растет производительность с увеличением итераций, в какой-то момент она перестанет это делать.

И тут самый главный момент - даже если вы замерите эту скорость, что вы будете делать с этим знанием? В реальной программе при выполнении этого кода скорость может быть совсем не такая как вы намеряли. Эти тесты годятся только для своего общего развития

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

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