Иван Григорьев

нет никакой ошибки: это особенность ивент-лупа - не должно быть долгих операций ибо они блокируют весь поток.

конвертируйте отдельно от основного потока.

Вот смотри, собралась команда, и придумывает какую-то новую штуку.
Сначала только они сами о ней что-то знают.

Затем они решают, что пора ее показать миру. Ну или к ним проникает шпион, и подглядывает.

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

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

IT-журналисты специально подписываются на твиттер гугла и эппла, и на их корпоративные блоги и пресс-рассылки, ездят на конференции и смотрят трансляции тех конференций, куда не могут доехать. Читают десятки новостный сайтов вроде хабра, медиума и реддита, и много всего еще.

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

В таком подходе есть одна проблема: новостей будет столько, что не будешь успевать их читать. И не все из них будут интересными.

Конечно вам нужно нанять бэкенд-разработчика, а фронт сделать своими силами в виде заглушек (т.е. максимально упрощенно, без дизайна, адаптива и т.д.) Когда логика будет готова, нанимаете фронтендера и он делает красиво и удобно. Сами подумайте, какой смысл делать обертку для несуществующего приложения? Мало ли что там и как будет в итоге.

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

www.chartjs.org/samples/latest

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

Курсы, книги, менторы и т д - это, конечно, хорошо.
Но самая реальная польза - сверстайте из psd 3-5-10 макетов pixel perfect. И без всяких бутстрапов. После энного макета постигните дзен и все поймете. И чем макеты будут разнообразнее, чем больше в них адаптивности и хитрых элементов - тем лучше. По непонятным моментам спрашивайте на тостере. А так, судя по опыту коллег, иметь "некоторые представления о css" и подгугливать можно до бесконечности.

100,000 Stars

Код, который написан и читается, словно он вовсе не асинхронный (все вызовы друг за другом).

пример из js

const parseAdminsData = async ()=>{
  const token = await getToken();
  const users = await getUsers(token);
  const admins = users.filter(({isAdmin})=>isAdmin);
  return admins;
}

вот тут два асинхронных запроса, но в коде они выглядят просто как вызовы функций. (без колбэков)

Есть ли смысл

Ну да, главное это оформить в виде красивого кейса с непонятными графиками.

Как вариант Javascript:

• Для pc Electron
  
• Сервис (back end) node.js, express
  
• Фронт angular, react или vue
  
• Для мобилок react native , ionic
  

Аналогично для .NET

• Для pc WPF клиент
  
• Сервис (back end) WEB API (ASP.NET)
  
• Фронт angular, react или vue
  
• Для мобилок xamarin