Будь ласка.
Тоді вже можна і на мій Medium підписатись також.

Раджу знайти на Medium блог Deepal Jayasekara. Там багато цікавих речей дуже гарно описано.

я би порівняв це з службою таскі і власним авто

1. служба таксі визначає вартість поїздки. щось не подобається — можеш шукати іншу служба на півдорозі.
2. на таксі не поставиш спойлер і вініли, про які завжди мріяв. ну чи це буде коштувати досить дорого.
3. якщо не сподобався стиль водіння таксиста — служба підтримки буде розглядати твою скаргу в залежності від тарифного плана.

своя ж машина — це відовідальність. не пить, не спать, техогляд робить. зате як захочеш — так і тюнінгуєш, їздить — куди скеруєш

Дякую за статтю.
Використовую Firebase для пет-проєктів за замовчуванням.
Простий, весь мінімум (auth, db, messaging, analytics) є + хостинг, якого вистачає.

Величезне дякую. Дійсно виявили цікавий баг. Міна вважалась знешкодженою тільки після завершення анімації встановлення прапорця, а за цей час можна було зробити подвійний клік/тап. Все завдяки вашим відео — www.loom.com/...​b83d047438f072168a9131344 (0:08-0:09) та www.loom.com/...​6022f496bb1a78b14b5a7382e (1:02-1:03). Фікс вже залито, можна грати далі. Ща раз дякую, буду вважати це першим оглядом геймплею)

Доброго дня. Дякую за відгук. Круто, що дійшли вже до 4го рівня. Щойно перевірили — все працює коректно. Скоріш за все ведмідь «затоптав» прапорці на вже знайдених мінах. Спробуйте ще раз та слідкуйте за міні-картою — червоні точки (прапорці) будуть в таких випадках зникати.

+

Дякую.

З основним тезами згоден.
Використання синхронної функції мінімально вплинуло на результат замірів (перевірив).
Щодо воркерів — так, була думка порівняти багатопоточності, але в даній статті таких цілей не ставив.

Дякую за відгук.

Так задача дійсно цікава. Відповіді наразі не маю.

Дякую за відгук.

Саме ця теза і є одним з висновків до даної статті.

Дякую за інтерес до статті.

Golang в рамках даного дослідження використовувався як мікросервіс, на який йшов запит від умовного Node.js (core) застосунку. Відповідно сам Node.js та WebAssembly були частиною цього застосунку. Тому мережева затримка була присутня лише у випадку з Golang.

Так, в даних конкретних випадках використання WebAssembly не мало значного сенсу, так як Node.js (а точніше С-шна його частина) справляється навіть краще.

Щодо WebAssembly, то імовірно виграш буде у випадках великих проектів/бібліотек по типу tensorflow.js або Google Earth. Але таке дослідження, на жаль, точно не могло увійти в рамки статті.

Дякую.

Дякую.

Мені здається в такому випадку проблемою є сам факт парсингу тіла запиту (json) в декілька мегабайт. Маю на увазі саме в основному потоці, саме працюючого backend застосунку. Якщо такий монстр прилітає з frontend — щось явно йде не так і потрібно переглядати контракти та домовлятись. Найчастіше з моєї практики такі запити — це якісь сторонні сервіси (статистика, списки геолокацій і тд), які можна обробляти не у окремих потоках і процесах, а взагалі в окремих сервісах і на окремих машинах (ресурсах). Після цього отримані дані вже у обробленому вигляді можуть бути доступні скажімо так «основному застосунку». Якщо все ж з якоїсь причини необхідно парсити huge json саме під час запиту, то знову ж реалізація як на мене залежить від багатьох умов: наявні ресурси — кількість ядер, який має бути результат — можливо необхідно і розпарсити і одразу провести якісь розрахунки/шифрування/ще щось CPU-bound. Можна запускати такі завдання як не в основному потоці/процесі, так і в окремому (мікро)сервісі, враховуючи мережеву затримку.

Залежить від реалізації аддона та способу його використання (може бути запущений, як у основному потоці, так і в окремому процесі/потоці). Заміна CPU-bound завдання на I/O-bound («перетворення» обрахунків на запит до зовнішнього сервіса) може мати профіт в деяких умовах (наприклад при великих об’ємах цих обрахунків та відносно невеликому кінцевому результаті), але звучить скоріше як виключення. Для таких речей в більшості випадків уже є готові рішення (а у цих рішені готові API). Щодо JSON.stringify/parse важко уявляю собі задачу, яку довелось би виносити в окремий сервіс для працюючого застосунку, хіба що використати ті ж worker threads або child processes.
PS. До речі підходи до вирішення CPU-bound завдань у тому числі з винесенням в окремий сервіс будуть розглянуті в моїй наступній статті.
Тому підписуйтесь тут та на Medium.

JSON — це власне клас v8 (C++), тому додатково застосовувати аддони в цьому випадку не має сенсу

Навіщо щось кудись додатково передавати, якщо і так
v8docs.nodesource.com/...​2540fb630ed37d3ee3ffe4504
v8docs.nodesource.com/...​4949a8dd3c09f63f5cb93ddff

Дякую за відгук.
Така вже тяжка доля у С/С++ в Node.js. — «працювать, працювать, працювати, В праці сконать!»

Дякую.

Дякую за відгук.
Можливо був недоствтньо точним у формулюванні.
Мав на увазі, что цей модуль «Compiled from heavily optimized algorithms written in C».
Порівняння з WASM (та реалізацією на Golang) буде в наступній статті, яку буде опубліковано до кінця року (вірогідніше за тиждень-два).
Тому підписуйтесь тут та на Medium.