trycontrolmymind Не вводите людей в заблуждение. Node всегда был однопоточный, так как работает на одном ядре процессора. Для многопоточности всегда запускали несколько процессов ноды согласовывая друг с другом.
Касательно вопроса, в метеоре есть `Meteor.user` и другая информация зависимая от ситуации. Однако в плоскости вычислений контекст это не вопрос места в коде, а вопрос времени выполнения. То есть в перемешанных цепочках выполнения может делаться работа для разных юзеров вперемешку и нужно каждый раз переходя от синхронности к синхронности в очереди выполнения на ядре (или можно воспринимать как при возвращении к асинхронности) иметь тот же контекст юзера и ddp что был до асинхронности.
|-1(a)-@ |-2-| @-1(b)-@ |-3-| @-1(c)-|
На 1a мы изначально внутри синхронности настроенным контекстом юзера и ddp. Допустим там мы хотим дождаться ответа из кастомной базы и что бы передать в ту будущую синхронность контекст отсюда, здесь генерируем функцию-callback вызвав `bindEnvironment`, которая будет выполнена потом.
Пока отвечает база делается какая-то другая работа 2 для другого юзера.
Когда база ответит наша синхронность начнется уже обёрнутой. Если мы её не обернули бы на том этапе, то сейчас не могли бы обернуть следующую, и отсюда обращаться к метеоровым переменным контекста и ddp.