johnymkp

Здесь можно даже и не заподозрить, что then что-то возвращает.

Все функции в js что-то возвращают. Если явного return нет или в нём не указано значение, то возвращается undefined.

Но поскольку там null, можно подумать, что исходный промис просто как-то передается дальше.

Так и есть - вы не передали никакой callback и весь этот вызов как бы игнорируется. Этот сценарий аналогичен предыдущему.

Еще интереснее - then возвращает простое значение, которое моментально попадает в следующий then.

Это ваш callback возвращает простое значение, которое then оборачивает в отрезолвленный промис.

Можете рассказать в общих чертах, если then возвращает промис, то как он его формирует?

Ну берёт и формирует... Примерно так:

then = (onFulfilledCallback, onRejectedCallback) => {
  try {
    let newValue;

    if (this.previousValue instanceof Error) {
      newValue = onRejectedCallback(this.previousValue);
    } else {
      newValue = onFulfilledCallback(this.previousValue);
    }

    if (newValue instanceof Promise) {
      return newValue;
    } else {
      return Promise.resolve(newValue);
    }
  } catch (error) {
    return Promise.reject(error);    
  }
}

Это псеводокод но общий смысл такой.

bind кэширует текущее значение своего this в момент своего вызова, т.е. он привязывает именно функцию, а не объект, в котором находится функция. Иначе нельзя было бы вызывать bind на просто функции по типу foo.bind(abc). В мануале, кстати, описано что именно она кэширует - там полный список есть: https://developer.mozilla.org/ru/docs/Web/JavaScri...

Упрощенный пример реализации bind для понимания механизма:

function binder(that) { 
    let targetFunction = this; // кэш целевой функции
    return function() { targetFunction.call(that) } // В возвращаемой функции используем кэш
}

let user = {
  name: "Tom",
  intro() {
    console.log("I am " + this.name);
  }
}

user.intro.binder = binder 
let f = user.intro.binder(user);

setTimeout(f, 1000);

user.name = "Sid";
user.intro = function() {
  console.log("Вообще другая функция. name: " + this.name);
}

Я хочу уточнить - блокируется микросервис (мс) вообще целиком или все-таки только поток, из которого сделан вызов?

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

Я себе представляю работу так: пусть у нас 2 мс, А и В, сделаны на Spring Web или любом другом веб-фреймворке. Каждого мс по одному экземпляру.
* Пользователь что-то щелкает.
* запрос уходит в А.
* в А создается новый поток (или берется из пула - не важно) для обслуживания пришедшего запроса.
* А вызывает В и ждет от него ответа.
* при этом блокируется не весь А, а только поток, который обслуживает запрос.

Условно так, но на практике даже поток не будет блокироваться - только обработка запроса от пользователя (пользователь не получит ответ, пока B не вернёт ответ)

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

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