Forem: Anna

BFF: Секретное оружие фронтенда в мире микросервисов

Anna — Wed, 01 Oct 2025 10:08:07 +0000

Представим себе такую ситуацию, что backend часть проекта разбросана по разным микросервисам, например, нам необходимо загрузить страницу, на которой отображается информация пользователя с его уведомлениями, а также таблица с необходимой информацией, все эти данные разбросаны по разным микросервисам, то есть, чтобы получить данную информацию нам необходимо "стучаться" по разным URL, при этом следить чтобы запросы отправлялись в правильной последовательности.
Данный процесс довольно трудоемкий, но что если есть способ решения данной проблемы?

Именно здесь появляется BFF (Backend For Frontend) - это архитектурный паттерн, основная идея которого - это создание отдельного серверного слоя, который представляет из себя прокси сервер, то есть он занимается отправкой запроса на нужный сервис и преобразует ответ в вид, который необходим фронтенду.

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

В данной статье мы разберем BFF и его тонкости.

Что такое BFF? Основные концепции

Мы уже сделали вывод, что BFF - это персональный backend для нашего frontend.

Основная идея данного паттерна заключается в том, что каждый клиент, будь то веб-приложение, мобильное приложение и тд имеет свой "сервер-компаньон", который:
1) Знает его специфические требования (например, нам необходимо отправлять на мобильное приложение ответ с меньшим кол-вом полей, чем на веб-приложение)
2) Оптимизирует работу с серверной частью приложения
3) Предоставляет специализированный API для конкретного UI

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

Ключевый характеристики BFF:

Индивидуальность
BFF создается для конкретного клиента и "заточен" на:
1) Особенности отображения данных на клиенте.
2) Особенности сетевого взаимодействия.
3) Специфические требования к формату данных.
4) Оптимальные стратегии кэширования данных.
"Тонкий" сетевой слой
BFF не должно содержать бизнес логики, является крайне важно. Основные функции BFF:
1) Агрегация данных - получение необходимых данных из разных сервисов в единую модель.
2) Трансформация данных под клиентские нужны.
3) Маршрутизация запросов к необходимым сервисам.
4) Обработка ошибок.

Использование данного паттерна в настоящее время становится частой практикой среди frontend сообщества, это связано стем, что:
1) Микросервисная архитектура все чаще и чаще используется на проектах.
2) Большое разнообразие клиентских устройств.

Архитектура BFF в деталях

Рассмотрим общую схему работы BFF:

Как запросы проходят через BFF:
1) Запрос с клиента - frontend отправляет один запрос к BFF.
2) Данные попадают в прослойку и начинается работа BFF архитектуры.
3) Аутентификация - проверка токенов и параметров.
4) Параллельные запросы - обращение к микросервисам, которые необходимы.
5) Агрегация данных - объединение результатов по запросам к микросервисам.
6) Трансформация данных - преобразование данных в необходимый для клиента вид.
7) Ответ на клиент - передача сформированного ответа на сторону frontend.

BFF состоит из нескольких логических компонентов:

Маршрутизатор, который определяет, какой обработчик должен выполнить запрос и провалидировать данные.

// Пример маршрутизации с Express.js
app.get('/web/products/:id', productPageHandler);
app.get('/web/user-profile', userProfileHandler);

Агрегатор данных (Data aggregator), который управляет параллельными запросами и объединяет их результаты.

class DataAggregator {
    async aggregateProductPageData(productId) {
        const [product, reviews, recommendations, stock] = await Promise.all([
            this.catalogService.getProduct(productId),
            this.reviewService.getReviews(productId),
            this.recommendationService.getSimilar(productId),
            this.inventoryService.getStockInfo(productId)
        ]);

        return { product, reviews, recommendations, stock };
    }
}

Трансформеры (Transformers), которые преобразуют данные в формат необходимый клиенту.

class ProductTransformer {
    static transformForWeb(productData) {
        const { product, reviews, recommendations, stock } = productData;

        return {
            productInfo: {
                id: product.id,
                name: product.title,
            },
            reviews: {
                items: reviews.slice(0, 10),
            },
            recommendations: recommendations.map(rec => ({
                id: rec.product_id,
                name: rec.product_name,
            })),
            availability: {
                quantity: stock.quantity,
            }
        };
    }
}

Клиенты микросервисов (Service Clients), которые специализируются на работе с каждым микросервисом, они формируют HTTP-запросы, обрабатывают ошибки и timeout.

BFF и Микрофронтенды

Когда мы работаем с микрофронтендами, то мы разбиваем монолитное приложение на части. Каждый отдельный микрофронтенд (MFE) разрабатывается и деплоится независимо, но должны работать вместе, как единое целое. Тут возникает несколько проблем: каждый MFE делает запросы напрямую к микросервисам, данная логика может дублироваться в разных MFE, что может привести к сложностям реализации MFE или же нарушению принципа независимости.

Когда мы используем BFF совместно с микрофронтендами, то существует несколько подходов:
1) Специализированный BFF для каждого MFE - каждый микрофронтенд имеет собственный BFF, они вместе разрабатывается и деплоятся.
2) Единый BFF с модульной структурой - единый BFF-сервер с четким разделением на модули для каждого MFE.

BFF + микрофрентенды имеют следующие преимущества:

Полная независимость.
Оптимизированная загрузка данных.
Устойчивость к изменениям.
Единая точка управления.

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

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

Время стоить архитектуру, которая работает на вас, а не наоборот.

this не магия: практическое руководство по контексту выполнения в JavaScript

Anna — Tue, 16 Sep 2025 17:58:18 +0000

Если бы у JavaScript был конкурс на самую запутанную концепцию, то первое место уверенно заняло ключевое слово this, его поведение на первый взгляд кажется непредсказуемым, но на самом деле это не так.

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

Самая лучшая аналогия про this - это аналогия со словом "я". Значение этого слова полностью зависит от того, кто его произносит. Если скажете вы, то "я" - это вы, если ваш друг, то это он и так далее. Также и с контекстом, this - это слово "я" внутри функции.

Основные проблемы, возникающие с this

Один и тот же код, но разные результаты
Возможность возникновения потери контекста
Кажущаяся сложность

Цель данной статьи - разобрать правила определения this и убрать страх перед использованием контекста.

Что такое this?

this - это ключевое слово, которое пришло в JavaScript для того, чтобы помочь в реализации объектно-ориентированного программирования. Если говорить проще, то this - это ссылка на некий объект, к свойствам которого можно обратиться внутри вызова функции. this также называют контекстом выполнения.
Это специальная переменная, которая автоматически создается внутри каждой функции(за некоторым исключением, о котором мы поговорим позже) в момент её выполнения.

Ключевая характеристика контекста вызова - это её динамичность, то есть значение this определяется в момент вызова функции, а не в момент создания. Это является фундаментальным отличием между контекстом вызова и переменными, которые имеют область видимости

Режим исполнения и глобальный объект

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

Разберемся что такого глобальный объект.
Глобальный объект в JavaScript - это корневой объект, переменные и функции которого доступны в любом месте программы. Данный объект представляет из себя глобальную область видимости, если мы говорим про frontend разработку, то в браузере глобальный объект - это window.

Мы разобрались, что такое глобальный объект, теперь разберемся, для чего нам это нужно. Когда скрипт выполняется, он может быть вызван в одном из двух режимов:

Нестрогий(режим по умолчанию)
Строгий(use strict)
Данные режимы определяют поведение контекста при вызове функций.
Если функция вызывается, как независимая функция и выполняется в нестрогом режиме, то this будет ссылаться на глобальный объект:

function checkThis() {
  console.log(this);
}

checkThis();// В браузере будет выведен глобальный объект window

Если мы захотим изменить свойства объекта через this, то это может привести к ошибкам и мы можем изменить свойства глобального объекта, поэтому чаще всего используют строгий режим.

Если функция будет вызвана, как независимая функция, но в строгом режиме, то ответ будет отличаться, значение this в данной функции будет становиться undefined:

'use strict'; // Включение строгого режима

function checkThisStrict() {
  console.log(this);
}

checkThisStrict();// В результате будет undefined

Это более безопасное поведение, обращение к полям такого объекта вызовет ошибку, которую будет легко обнаружить.

Данное поведение является базовым, все остальные правила - это способ переопределить поведение и явно указать функции, на что должно ссылаться ключевое слово this.

Основных правила определения this

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

Правило 1: Простой вызов (Default Binding)
Функция, которая вызывается сама по себе, без каких-либо дополнений. Данное поведение мы рассмотрели выше, поведение в строгом и нестрогом режимах.

Важно: это правило срабатывает чаще всего там, где мы не ожидаем, особенно при работе с callback.

Рассмотрим пример с использованием "голых" функций:

function foo(){
    var bar = "local";
    console.log(this.bar);
} 
var bar = "global";

foo();  // global

Разберемся, почему конечный вывод именно такой. Как известно, переменная, объявленная с помощью var попадает в глобальную область видимости, именно поэтому, когда мы вызываем независимую функцию в нестрогом режиме, то в нее попадает значение, хранящееся в глобальной области видимости (window.bar).

Пример с callback мы разберем позже, чтобы лучше понять материал.

Правило 2: Вызов как метода объекта (Implicit Binding)
Функция, которая вызывается как метод объекта, то есть через точку или квадратные скобки. В данном случае this будет ссылаться на сам объект, который стоит перед точкой в момент вызова.
Рассмотрим пример:

const user = {
  name: 'Анна',
  logName() {
    console.log(this.name);
  }
};

user.logName(); // Выведет "Анна"

Мы создали объект, внутри которого прописали функцию вывода имени пользователя. Как мы уже сказали выше, контекст вызова будет ссылаться на объект перед точкой, как мы видим из строчки user.logName();, объект перед точкой - это user, значит this = user.

Важно: this определяется в момент вызова, а не в момент создания.

На основе этой информации рассмотрим еще несколько примеров:

Пример №1

const user = {
  name: 'Анна',
  logName() {
    console.log(this.name);
  }
};

// Создаем новую переменную, которая ссылается на функцию logName
const logNameFunction = user.logName;

// Вызываем функцию без объекта перед точкой.
logNameFunction(); // undefined или ''

В результате мы получим не совсем тот результат, который мы ожидали, разберемся, почему это происходит.
Мы создали объект точно также, как и в предыдущем примере, но при этом результат получило совершенно иной. Это связано с тем, как мы вызываем метод объекта, в данном случае, мы функцию кладем в переменную logNameFunction, это действие эквивалентно следующему коду:

function logNameFunction () {
    console.log(this.name);
}

Поэтому, когда мы вызываем данную функцию, она действует по правилу 1, то есть ссылается на глобальный объект.

Пример №2

const user = {
  name: 'Анна',
  logName() {
    console.log(this.name);
  }
};

// Правило 2: вызов как метода объекта. Сработает.
user.logName(); // Анна

// А теперь передадим метод как колбэк
setTimeout(user.logName, 1000); // undefined или ''

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

setTimeout(function() {user.greet()}, 1000);// Анна

При такой записи мы не теряем контекст за счет того, что вызов происходит сразу, когда this ссылается на объект user. Есть и другие способы решения этой проблемы, рассмотрим их позже.

В рассмотренных выше примерах показывается самая частая проблема при работе с контекстом - потеря контекста, когда this не указывает на объект, откуда функция была взята.

Правило 3: Явное указание контекста (Explicit Binding)
В JavaScript мы можем явно указать какой объект должен использоваться в качестве контекста вызова. Для этих целей методы call, apply, bind.

Методы call и apply очень похожи, их разница в том, как мы передаем аргументы в функцию, поэтому рассмотрим их в связке.
Данные методы позволяют вызывать функции в контексте других объектов, иными словами, мы явно указываем контекст вызова this. Особенностью данных методов является то, что они немедленно вызывают функцию.
Синтаксис:
func.call(this, arg1, arg2, ...)
func.apply(this, [arg1, arg2, ...])
Как можно заметить, разница данных методов в синтаксе, а именно в том, как передаются аргументы в функцию.

Метод bind очень похож на предшественников, но его отличие в том, что данный метод НЕ вызывает функцию сразу, он возвращает новую функцию, которая будет привязана к необходимому контексту.
Синтаксис:
func.bind(this, arg1, arg2, ...)

Теперь мы можем дать еще одно решение для проблемы потери контекста из примера №2.

setTimeout(user.logName.bind(user), 1000); // Анна

В данном случае, мы привязали объект, поэтому в момент вызова функции, контекст вызова будет равен объекту user, что решает нашу проблему.

Правило 4: Вызов с оператором new (New Binding)
В JavaScript можно создавать функции-конструктор с помощью оператора new.
Функция-конструктор - это специальная функция, предназначенная для создания объектов. Чаще всего функции-конструкторы применяют для создания объектов по шаблону. Внутри такой функции this будет ссылаться на новосозданный пустой объект.

Рассмотрим пример создания функции-конструктора:

function User(name, age) {
  // В данный момент this = {}
  this.name = name;
  this.age = age;
  this.isAdmin = false;
}

const userAnna= new User('Анна', 25);
console.log(userAnna.name); // 'Анна'
console.log(userAnna.age); // 25

При этом, в случае, если мы неправильно создадим объект, то есть без оператора new, то поведение будет совсем иное, тогда контекст вызова будет работать по правилу 1 и ссылаться на глобальный объект.

Важно: всегда использовать new с функциями-конструкторами.

Приоритет правил
Может случиться так, что к this подходят сразу несколько правил, на этот случай в JavaScript есть приоритет правил, рассмотрим от высшего приоритета к низшему.

new (Правило 4) имеет самый высокий приоритет, в функции-конструкторе this - это всегда новый объект.
Явная привязка (Правило 3), когда привязываем контекст с помощью call, apply, bind.
Неявная привязка (Правило 2), вызов функции через метод объекта.
Простой вызов (Правило 1) имеет самый низкий приоритет, контекст ссылается на глобальный объект, зависит от строгого или нестрогого режима.

Рассмотрим пример:

const obj = { 
  name: 'Анна',
  getName() {
    console.log(this.name)
  }
};
function foo() {
  console.log( this.name);
}
// Правило 1
foo(); // undefined

// Правило 2
obj.getName(); // "Анна"

// Правило 3
const boundFoo = foo.bind(obj);
boundFoo(); // "Анна"

// Правило 4
const newObj = new boundFoo(); // undefined

На данном примере хорошо видна приоритезация между правилами 3 и 4. Почему в последней строке выводится undefined, хотя контекст явно привязан через метод bind? Как и говорилось выше, при использовании new контекст вызова - это пустой массив, то есть this = {}, внутри этого объекта нет свойства name, именно поэтому мы и получаем такой ответ.

Мы рассмотрели все правила и их приоритет, теперь определять, чему равен this намного проще.

Особое поведение: Стрелочные функции

Стрелочные функции ведут себя иначе с точки зрения контекста вызова по сравнению с обычными функциями. Главное правило стрелочной функции - это то, что у нее нет своего this.

Внутри стрелочной функции контекст берется извне, то есть она не создает свой контекст исполнения, а ссылает на объект ближайший по иерархии. Это называется "лексический this".

Если говорить проще, то this внутри стрелочной функции равно this снаружи её.

Рассмотрим пример использования контекста со стрелочной функцией и когда это будет полезно:

const user = {
  name: 'Анна',
  greet: function() { 
    setTimeout(function() {
      console.log('Обычная функция:', this.name); // undefined или ''
    }, 100);

    setTimeout(() => {
      console.log('Стрелочная функция:', this.name); // 'Анна'
    }, 200);
  }
};

user.greet();

При вызове через обычную функцию, у нас произойдет потеря контекста, так как функция вызывается сама по себе позже и подчиняется правилу 1, обращаясь к глобальному объекту. Вызов через стрелочную функцию решит данную проблему, потому что у нее нет своего контекста, и она обращается к внешнему this из функции greet, а внутри нее по правилу 2 контекст равен user, стрелочная функция "запомнила" это значение и использует его всегда, когда бы не вызвали.

Важно: к стрелочным функциям нельзя применять методы call, apply и bind, this внутри таких функций зафиксирован и не меняется.

Важно: стрелочные функции не могут быть конструкторами, вызов функции с new выбросит ошибку.

Использовать стрелочных функций с контекстом вызова лучше всего в callback функциях, так как это уберегает от потери контекста.

this в обработчиках событий DOM

Ключевая задача frontend разработчика - это работа с DOM деревом, в JavaScript также есть правила работы с контекстом в обработчиках событий.

Стандартное поведение - обычные функции обработчики
Когда мы создаем прослушиватель событий и назначает обычную функцию обработчик, то в данном случае this ссылается на DOM-элемент, на котором событие было вызвано.
При вызове addEventListener он неявно привязывает контекст вызова к элементу, на котором случилось событие.

Рассмотрим пример:

const button = document.getElementById('myBtn');

button.addEventListener('click', function() {
  // this внутри этой обычной функции будет указывать на элемент button
  console.log(this); // Выведет: <button id="myBtn">Нажми меня</button>
  console.log(this.id); // Выведет: 'myBtn'
  console.log(this.textContent); // Выведет: 'Нажми меня'

  this.style.backgroundColor = 'red'; // Можно напрямую менять стили элемента
});

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

Исключение - стрелочные функции обработчики
Если использовать стрелочную функцию в качестве обработчика, то поведение с this меняется. Внутри стрелочной функции-обработчика контекст this будет равен контексту той функции, внутри которой она была вызвана.

Пример с кнопкой и стрелочной функцией:

const button = document.getElementById('myBtn');

button.addEventListener('click', () => {
  console.log(this); // window или undefined

  this.style.backgroundColor = 'red';// строка вызовет ошибку в строгом режиме
});

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

Специальные случаи и тонкости

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

this в методах массива (forEach, map, filter и т.д.)
У методов массивов, которые принимают callback функции, например: forEach, map, filter, some, every и прочие, есть второй параметр, который является необязательным. Это объект, который будет использоваться в качестве this, то есть можно сказать, что это аналог явной привязки с помощью call, apply, bind.
Синтаксис:

array.method(callback, thisArg)

Рассмотрим пример с методом map:

const validator = {
  min: 10,
  max: 20,
  validate(value) {
    return value >= this.min && value <= this.max;
  }
};

const numbers = [5, 15, 25, 35];

const resultBad = numbers.map(validator.validate);
console.log(resultBad); // [false, false, false, false] 

const resultGood = numbers.map(validator.validate, validator);// [false, true, false, false] 
console.log(resultGood);

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

Альтернативным способом является переписать callback функцию внутри метода, чтобы this ссылалось на верные данные. Пример реализации:

const resultBad = numbers.map((item) => (validator.validate(item)));

this в конструкторах встроенных объектов
Многие встроенные в JavaScript конструкторы, например, такие как Promise, Set, Map, Date имеют особенности при работе с контекстом вызова, они сами управляют контекстом и внутри них он обычно равен undefined(в строгом режиме).

Итог: Алгоритм определения this для любой функции

Подведем итог и выявим алгоритм для определения контекста.

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

Функция вызвана с помощью оператора new?

ДА --> Значит this ссылается на пустой только что созданный объект.
НЕТ --> Переходим к следующему шагу

Функция вызвана с помощью методов call, apply, bind?

ДА --> Значит this ссылается на объект переданный в метод.
НЕТ --> Переходим к следующему шагу

Функция вызвана как метод объекта?

ДА --> Значит this ссылается на объект перед точкой.
НЕТ --> Переходим к следующему шагу

Это стрелочная функция?

ДА --> Значит this ссылается на контекст, который находится выше по иерархии на момент ее объявления.
НЕТ --> Переходим к следующему шагу

В иных случаях - это простой вызов функции

Значит this ссылается на глобальный объект, если это нестрогий режим и undefined, если строгий режим.
Простая блок схема для определения значения this.

Заключение

Тема контекста this в JavaScript является одной из самых сложных, но после изучения всех тонкостей поведение контекста становится предсказуемым.

Ключевые выводы, которые можно сделать по этой теме:

Контекст определяется в момент вызова функции, а не в момент объявления.
Существует два координально разных типа функций с точки зрения контекста: обычные и стрелочные функции.
Необходимо подбирать инструменты под определенные задачи.
Существует проблема потери контекста, бороться с ней можно, при этом важно понимать причину.

this понятен. Можно идти дальше :)

Promise полный гид для понятного кода

Anna — Tue, 09 Sep 2025 19:26:54 +0000

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

Callback функция в JavaScript - функция, которая передается в другую функцию в качестве аргумента.

Приведем пример функции callback:

function first ( callback ) {
   callback();
   console.log("1");
}

function second () {
   console.log("2");
}

first(second)

В ответе мы получим следующий результат:

1
2

Кажется, что может быть проще, но данный паттерн имеет проблемы при масштабировании сложных приложений. Данная ситуация называется callback hell.

Callback Hell в JavaScript возникает при выполнении слишком большого кол-ва функций обратного вызова.

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

Рассмотрим наглядный пример:

function asyncFirst(callback) {
  setTimeout(() => {
    console.log("1");
    callback();
  }, 1000);
}

function asyncSecond(callback) {
  setTimeout(() => {
    console.log("2");
    callback();
  }, 1000);
}

function asyncThird(callback) {
  setTimeout(() => {
    console.log("3");
    callback();
  }, 1000);
}

asyncFirst(function() {
  asyncSecond(function() {
    asyncThird(function() {
      console.log("Done");
    });
  });
});

Мы рассмотрели вариант callback hell, но в данном случае мы видим, что у пирамиды высота равна трем, представим, как громоздко будет выглядеть код с большей высотой пирамиды.

Из-за роста сложности приложений на JavaScript паттерн использования функций обратного вызова себя исчерпал, поэтому была придумана новая и более мощная абстракция, которая была сформирована в спецификации ES6 и носила название Promise.

Promise в JavaScript - специализированный объект, который предоставляет удобный способ организации асинхронного кода.

В данной статье будет проведен детальный анализ объекта Promise, чтобы предоставить понимание данного механизма, необходимого для современной разработки на JavaScript.

Жизненный цикл Promise

Promise может находиться в 3 состояниях:

pending(ожидание) - начальное состояние объекта, после его создания, на данном этапе promise не исполнен и не отклонен.
fulfilled(исполнено) - состояние объекта после успешного завершения операции. Переход в данное состояние происходит в момент вызова функции resolve внутри promise.
rejected(отклонено) - состояние объекта после завершения операции с ошибкой. Переход в данное состояние происходит в момент вызова функции rejected внутри promise.

_Важно запомнить, что переход promise из состояния pending в fulfilled или rejected является необратимым, то есть, мы можем получить только успешное завершение операции или завершение с ошибкой, изменить это состояние не получится. Это гарантирует предсказуемость операции. _

Завершенный promise - это тот, который перешел в состояние fulfilled или rejected(данный термин мы еще будем использовать).

Создание Promise

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

Функция исполнитель вызывается синхронно, когда создается Promise. Она принимает два аргумент:

resolve - функция, которую необходимо вызвать, чтобы promise успешно завершился. Аргументом данной функции является значение выполняемого promise, то есть то, что мы получили в ходе выполнения асинхронной операции.
reject - функция, которую необходимо вызвать, чтобы promise завершился с ошибкой. В качестве аргумента передать значение, которое станет причиной отклонения данной операции.

Приведем пример:

const getData = new Promise((resolve, reject) => {
  console.log('Start');

  // Имитируем асинхронную операцию
  setTimeout(() => {
    const data = { id: 1, name: 'John Doe' }; 
    // Успешное завершение
    if (data) {
       resolve(data);
    }

    // Завершение с ошибкой
    reject(new Error('Error'));// или throw new Error("Error");
  }, 1000);
});

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

Если внутри Promise не вызвать resolve или reject, она так и останется в состоянии pending и никогда не будет завершена.

Методы .then(), .catch(), .finally()

Мы написали Promise, теперь нам необходимо извлечь и обработать данные, которые мы отправили через resolve или reject. Для того, чтобы это сделать существуют методы then(), .catch(), .finally(). Эти методы регистрируют функции-обработчики, которые будут вызваны автоматически, когда Promise перейдет в соответствующее состояние.

then() - метод, который является основным для обработки результата, он подходит как для обработки успешного выполнения, так и для завершения с ошибкой. Принимает два аргумента:

onFulfilled - функция, которая будет вызвана, когда Promise завершится с успехом.
onRejected - функция, которая будет вызвана, когда Promise завершится с ошибкой.

Рассмотрим пример обработки функции, которую мы писали выше:

getData.then(
   (data) => {
      console.log('Полученные данные по пользователю:', data);
   },
   (error) => {
      console.log('Ошибка:', error);
   },
);

Чаще всего в функцию передается первый аргумент, а ошибка обрабатывается в методе catch()

catch() - метод для обработки ошибок, имеет один аргумент - функция для обработки ошибок, такая же, как если бы мы передавали второй аргумент в метод then(). Только в данном случае catch() - это упрощенный и более читаемый синтаксис для регистрации обработчика ошибок.

Рассмотрим пример обработки ошибок функции getData:

getData.catch(
   (error) => {
      console.log('Ошибка:', error);
   },
);

//Или второй вариант написания
getData.then(null ,
   (error) => {
      console.log('Ошибка:', error);
   },
);

finally() - метод, который выполняется в любом случае, независимо от того завершился Promise успешно или с ошибкой. Этот метод позволяет избежать дублирования в методах then() и catch(). Данный метод не принимает никаких аргументов, а также не возвращает никакие значения.

Рассмотрим пример:

getData.then((data) => {
      console.log('Успех');
   }).catch((error) => {
      console.log('Ошибка');
   }).finally(()=>{
      console.log("Завершено");
   })

Так в случае успешного завершения Promise мы увидим:

Успех
Завершено

А в случае завершения с ошибкой:

Ошибка
Завершено

Но и это еще не все, каждый из методов then(), catch(), finally() возращает тоже Promise, а это значит, что мы можем реализовать так называемые цепочки вызовов. Благодаря этому можно обработать несколько асинхронных операций одна за другой.

Разберемся, как это работает. Как говорилось выше, методы возвращают Promise, а значит можно продолжить цепочку дальше, в качестве их аргументов будут выступать результаты предыдущих методов. Легче разобраться на практике.

const getData = new Promise((resolve, reject) => {
  resolve("Успех")
})

getData
  .then((data) => {
    console.log(data);
    return data + " 2";
  })
  .then((data) => {
    console.log(data);
    return data + " 3";
  })
  .then((data) => {
    console.log(data);
  });

В результате мы получим:

Успех
Успех 2
Успех 2 3

Рассмотрим выполнение кода поэтапно:

Мы создали Promise getData, который с помощью resolve переводит состояние Promise в fulfilled со значением "Успех".
Обрабатываем с помощью then(), в качестве аргумента в функцию будет передаваться значение "Успех".
При обработке снова возвращаем значение, которое переходит в следующий метод then()
Далее алгоритм повторяется.

То же самое происходит с методами catch() и finally().

Рассмотрим и разберем более сложные примеры, чтобы лучше понять принцип действия.

Задача 1

Promise.resolve(5)
  .then(x => x * 2)
  .then(x => x + 3)
  .then(x => { throw new Error(x) })
  .catch(e => parseInt(e.message))
  .then(x => console.log(x))
  .finally(() => console.log('Done'));

Первый then возвращает значение 10.
Второй then возвращает значение 13.
Третий then возвращает ошибку, которая переходит в catch.
В методе catch возвращается значение 13, так как метод закончился без ошибки, то переходит дальше к then.
Выводится значение 13
Выводится 'Done' Вот как выглядит точный ответ:

13
Done

Задача 2

Promise.reject(new Error('Boom!'))
  .finally(() => console.log('Cleanup 1'))
  .catch(e => { 
    console.log(e.message); 
    throw new Error('Again!'); 
  })
  .finally(() => console.log('Cleanup 2'))
  .catch(e => {
    console.log(e.message);
    return "Good!!!" 
  })
  .catch(e => console.log(e.message));

Как уже говорилось ранее, finally также возвращает Promise, поэтому цепочка продолжается, а конечный результат будет иметь следующий вид:

Cleanup 1
Boom!
Cleanup 2

Мы не попадаем в последний catch, так как метод перед ним закончился успешно.

Задача 3

Promise.reject('A')
  .catch((a) => {
    console.log('Catch 1:', a);
    return 'B';
  })
  .finally(() => {
    console.log('Finally 1');
    return 'C';
  })
  .then((b) => {
    console.log('Then 1:', b);
    throw new Error('D');
  })
  .catch((d) => {
    console.log('Catch 2:', d.message);
    return 'E';
  })
  .finally(() => {
    console.log('Finally 2');
    return 'F';
  })
  .then((e) => {
    console.log('Then 2:', e);
  });

Вспомним, что метод finally не возвращает никакие значения, поэтому данные строки можно убрать, при этом в then попадает значение из предыдущих методов then или catch

Думаю, что после пояснения результат стал вполне ожидаемым:

Catch 1: A
Finally 1
Then 1: B
Catch 2: D
Finally 2
Then 2: E

А вот с ошибками результат будет другой, рассмотрим такой пример:

Promise.reject('First Error')
  .catch((err) => {
    console.log('Catch 1:', err); //First Error
    return 'Success';
  })
  .finally(() => {
    console.log('Finally 1');

    //Возникает ошибка, которая обрабатывается в catch
    throw new Error('Error in Finally'); 
  })
  .then((value) => {
    //Так как возникла ошибка, то then пропускается
    console.log('Then 1:', value);
  })
  .catch((err) => {
    console.log('Catch 2:', err.message); //Error in Finally
    return 'Final Recovery';
  })
  .then((value) => {
    console.log('Then 2:', value); //Final Recovery
  });

Таким образом, finally не возвращает значение, которое может попасть в then, но при этом, может вызвать ошибку, которая в дальнейшем будет обработана.
Конечный результат:

Catch 1: First Error
Finally 1
Catch 2: Error in Finally
Then 2: Final Recovery

Думаю, на этих примерах принцип действия стал понятнее.

Статические методы класса Promise

Статические методы предназначены для работы с коллекциями Promises. С их помощью мы можем организовать параллельное выполнение асинхронных операций. Данные методы возвращают новый промис, состояние которых зависит от переданных Promises.

all() - принимает на вход массив с Promises, а возвращаемый Promise выполняется, когда все Promises из входных данных выполнятся, отклоняется, когда любой из переданных Promise завершается с ошибкой, при этом причина отклонения поступает с первого Promise, который неудачно завершился.

Рассмотрим два примера:

const promiseFirst = Promise.all([1, 2, 3, Promise.resolve(4)]);
console.log(promiseFirst)

Данный пример вернет следующий результат:

Promise { <state>: "fulfilled", <value>: Array[4]}

То есть, все Promises, которые передавались во входные параметры закончились успешно, поэтому конечный Promise закончился с успехом и мы может увидеть результаты каждого выполненного Promise.

Теперь рассмотрим следующую ситуацию:

const promiseSecond = Promise.all([Promise.reject('bad 1'), 2, 3, Promise.reject('bad 2')]);
console.log(promiseSecond)

Данный пример вернет следующий результат:

Promise { <state>: "rejected", <reason>: Error: bad 1 }

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

allSettled() - метод, который принимает на вход массив из Promise и возвращает один, как и в случае с методом all, но их отличие в том, что он ждем выполнения всех Promises, неважно, успешны они или нет.

_Метод allSettled() никогда не отклоняется _

Данный метод возвращает массив объектов, который имеет следующий вид:

{
   status // "fulfilled" или "rejected"
   value? // Значение, когда status = "fulfilled", хранит данные по успешной операции
   reason? // Значение, когда status = "rejected", хранит данные по ошибке
}

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

Рассмотрим пример выполнения данного метода, который заканчивается неудачей:

const promise = Promise.any([
  Promise.reject('bad 1'),
  Promise.reject('bad 2'),
  Promise.reject('bad 3')
]);

promise.then(result => {
  console.log('Успех! Result:', result);
}).catch(error => {
  console.log('Ошибка! Error name:', error.name); // AggregateError
  console.log('Ошибка! Error errors:', error.errors); // Массив ошибок
});

Результат будет иметь следующий вид:

Ошибка! Error name: AggregateError
Ошибка! Error errors: [ 'bad 1', 'bad 2', 'bad 3' ]

race() - метод, который также принимает массив в качестве входных параметров, а то, разрешается он или отклоняется, зависит от первого завершённого Promise. То есть race - это, как и any тоже своего рода организатор гонок, только победителем может быть как успешно завершенный Promise, так и отклоненный с ошибкой.
reject() - метод, который возвращает отклоненный Promise по указанной причине. Мы уже использовали его ранее.
resolve() - метод, который возвращает успешный Promise с указанным значением.
try() - метод, чтобы была возможность запустить функцию, которая может быть как синхронной, так и асинхронной, и вернуть Promise.
Если callback функция выполняется синхронно и возвращает значение, то данный метод возвращает успешный Promise с этим значением, который потом можно обработать в then().
Если callback функция выполняется синхронно и возвращает ошибку, то данный метод возвращает отклоненный Promise с этой ошибкой, который потом можно обработать в catch().
Если callback функция возвращает другой Promise, то данный метод вернет этот Promise.

Рассмотрим пример:

const result = Promise.try(() => {
  throw new Error('Error');
});

result.catch(error => console.error(error.message)); // Error

То есть метод try() - это универсальный контейнер, если мы в него что-то положим, то он обязательно вернет Promise, который в дальнейшем можно обработать с помощью then() или catch().

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

Из метода withResolvers() мы можем получить следующие данные:

promise - созданный Promise
resolve - функция для успешного завершения Promise
reject - функция для завершения Promise с ошибкой

Рассмотрим пример:

const { promise, resolve, reject } = Promise.withResolvers();

setTimeout(() => resolve('Успех!'), 1000);

promise.then(data => console.log(data)); // Успех!

Связь с async/await

Ключевые слова async и await не являются полноправной заменой Promise, это так называемый синтаксический сахар, для того, чтобы упростить работу с Promise и сделать код более удобочитаемым. Данный синтаксис позволяет писать асинхронный код, который выглядит как синхронный, при этом нет потери производительности и не блокируется основной поток.

Под капотом async/await работает на основе Promise, а также функций генераторов.

Если перед функцией поставить ключевое слово async, то данная функция автоматически будет возвращать Promise.

Рассмотрим пример:

async function getNumber() {
  return 42;
}

getNumber().then(number => console.log(number)); // 42

При этом, данную функцию можно записать и через Promise, эквивалентное решение будет выглядеть следующим образом:

function getNumber() {
  return Promise.resolve(42);
}

Ключевое слово await можно использовать только внутри функции, перед которой стоит async, то есть внутри async-функции. Оно заставляет интерпретатор приостановить выполнении функции до тех пор, пока Promise не будет завершен.

Алгоритм работы:

Если Promise завершился с успехом, то await возвращает его результат.
Если Promise завершается с ошибкой, то await генерирует ошибку, которую можно обработать через try/catch.

Рассмотрим пример:

async function fetchDataNew() {
  try {
    const response = await fetch('...');
    const data = await response.json();JSON
    console.log(data);
  } catch (error) {
    console.error('Error:', error);
  }
}

Необходимо грамотно подходить к выбору того, что лучше использовать, например, когда нам необходимо выполнить несколько операций параллельно, то лучше использовать Promise, а когда логика требует выполнения последовательных действий, то лучше использовать async/await.

Заключение

Promise - это фундаментальная блок асинхронного кода, который позволил разработчикам уйти от callback hell и сделать код более предсказуемым, удобочитаемым и элегантным.

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

Теперь спокойно можно покорять вершины асинхронности, самое главное не прибегать к callback hell :)

HTTP-методы: GET, POST, PUT, DELETE и другие — полный гид

Anna — Wed, 16 Jul 2025 20:27:36 +0000

В первую очередь стоит начать с того, а что же такое HTTP.

HTTP (Hypertext Transfer Protocol) - это протокол прикладного уровня, который определяет правила обмена данными между клиентом и сервером.

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

Методы разделяются по своим свойствам. Бывают следующие виды методов:

1) Безопасные - это методы, которые не изменяют состояние сервера, то есть методы, которые используются только для чтения и не имеют side effects. К таким методам относятся: GET, HEAD, OPTION, в дальнейшем рассмотрим все эти методы подробнее.

2) Идемпотентные - это методы, которые не имеют никаких побочных эффектов(side-effects). Иными словами, идемпотентные методы - это методы, которые при повторном идентичном запросе не изменяют состояние сервера. Как пример, рассмотрим случай добавления сущности на сервер, у нас есть два варианта решения этой задачи:

Добавление сущности, когда сервер самостоятельно выбирает новый идентификационный номер ресура.(POST)
Добавление сущности, когда клиент задает идентификационный номер ресурса.(PUT)

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

Исходя из описания идемпотентного свойства можно сделать следующий вывод:
Все безопасные методы являются идемпотентными, но не все идемпотентные являются безопасными

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

Методы GET и HEAD могут быть закэшированы, методы POST и PATCH могут закэшированы, если указаны признак "свежести" (заголовок Expires, который указывает дату и время, по истечении которых кэш должен считаться устаревшим), а также установлен заголовок Content-Location. Другие методы считаются некэшируемыми.
Коды ответов, которые приходят с сервера, известны как кэшируемые: 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501.
HTTP заголовок Cache-Control не ограничивает кэширование.

Некоторые запросы, которые не являются кэшированными могут инвалидировать закэшированные данные, в случае, если запрос проходит по одному и тому же URI.
Например, мы сохранили данные с помощью метода GET, а далее совершили PUT запрос по тому же URI, тогда ответ от некэшируемого запроса сделает недействительным предыдущий закэшированный ответ, полученный от GET.

Настало время перейти к самим методам.

-GET - метод, который запрашивает ресурс с сервера, то есть извлекает данные с сервера для чтения.
Данный метод является безопасным, идемпотентным и кэшируемым. При этом в данном методе есть тело ответа и можно написать тело запроса, но этого лучше не делать по следующим причинам:
а) Сам метод GET подразумевает под собой операцию чтение, а передача тела запроса нарушает семантику, так как тело запроса необходимо дополнительно обрабатывать на сервере.
б) Многие сервера могут игнорировать или даже отклонять тела запросов в методе GET, что может привести к некорректному вызову метода.
в) Возможность возникновения проблем с кэшированием, так как кэши не будут учитывать тело запроса, поэтому при одинаковом URI, но разных телах запроса данные, приходящие с сервера, могут отличаться, тем самым, закэшированные данные могут быть неверные.
г) Проблемы с безопасностью, поскольку тело запроса в методе GET является специфической, то могут возникнуть такие проблемы, как утечка данных или же CSRF атаки и др.

HEAD - метод, который запрашивает ресурс также, как и метод GET, но без тела ответа. Мы можем использовать данный метод, например, для того, чтобы проверить загрузку большого объема данных, для увеличения пропускной способности.
Метод HEAD может сделать кэширование метода GET по тому же URI недействительным, когда результат запроса HEAD будет показывать, что закэшированные данные устарели
POST - метод для отправки данных на сервер, часто вызывает изменения состояния сервера или side effects. Мы можем использовать данный метод, например, для того, чтобы создавать новые сущности на сервере. Иногда данный метод используется для получения данных, например, когда нам необходимо получить отфильтрованные данные, а размера URI не хватает, чтобы передать все фильтры корректно, а как мы говорили выше, то в методе GET нежелательно использовать тело запроса, и тут на помощь приходит метод POST, в который мы можем передать тело запроса и корректно получить данные, ну и конечно не стоит забывать про то, что метод GET лучше не использовать для передачи чувствительных данных(уж очень легко украсть).
Метод POST не является безопасным и идемпотентным, но он может быть кэшируемым, если будет соблюдено 1 условие для кэшируемых методов.
PUT - метод, который используется для обновления или создания ресурса. Данный метод создает новое или заменяет старое представление ресурса данными, которые приходят в теле запроса.
Разница между PUT и POST заключается в том, что чаще всего PUT используется для редактирования ресурса, в то время, как метод POST отвечает за создание ресурса, именно такое поведение методов является семантически верным. Кроме этого разница этих методов еще и в том, что метод PUT является идемпотентным, а метод POST идемпотентным не является, пример именно с этими методами приведен выше, при пояснении идемпотентности.
PATCH - метод, который используется для частичного редактирования ресурса. Как мы говорили выше, метод PUT также отвечает за изменение данных на сервере, так в чем же разница между методами PUT и PATCH? А разница заключается в том, что метод PUT полностью заменяет ресурс данными, представленными в теле запроса, в то время, как метод PATCH может заменить какие-то конкретные поля у данного ресурса.
Метод PATCH может быть идемпотентным при правильном использовании, а также может быть кэшируемым, но никогда не будет безопасным.
DELETE - метод, который отвечает за удаление данных с сервера. Данный метод не является безопасным и кэшируемым, но является идемпотентным. Например, мы не можем удалить один и тот же ресурс с одинаковым идентификатором дважды.

Настало время приступить к менее известным методам. Итак, приступим.

OPTION - метод, который запрашивает информацию о возможностях и параметрах доступных методов на конкретном ресурсе. Если говорить проще, то метод OPTION задает следующий вопрос: "Что я могу делать с этим ресурсом?". Данный метод может дать информацию о том, какие методы применимы к ресурсы, какие заголовки можно передавать и тд. В случае, если в URI написана *, то данный запрос применяется ко всему методу.
Данный метод является безопасным и идемпотентным, но не является кэшируемым.
CONNECT - метод, используемый для создания "тунеля" к серверу. Данный процесс можно описать следующим образом: отправляется запрос на создания соединения в котором указывается хост и порт, в случае, если прокси сервер одобряет соединение, то устанавливается связь с конечной точкой, после этого все соединение происходит через прокси.
TRACE - метод, который используется для диагностики и отладки. Принцип работы данного метода заключается в том, что отправляется запрос, а в ответ от сервера приходит тот же запрос, который мы отправили. Зачем это нужно? Например, нам необходимо понять, верно ли мы отправляем запрос, все заголовки к нему и тд. Также данный метод иногда используется для мониторинга и ведения логов, но данный метод используется редко, так как это может привести к проблемам с безопасностью, например, злоумышленник может украсть важные данные, например, куки, токены и тд. К слову данный метод является идемпотентным, но не является безопасным и кэшируемым.

Итого, мы разобрали все методы. Какие методы мы делаем?

GET - скромный наблюдатель, может читать, но не может записывать.
POST - создатель, даст данные, а там уже пусть что-то создастся.
DELETE - ликвидатор, безвозвратное удаление, никак иначе.
PUT - перфекционист, знает как должен выглядеть ресурс, если его нет, то нужно создать, а если есть, то нужно отредактировать.
PATCH - хирург, точные изменения, никак иначе
HEAD - это GET-запрос, который стесняется тела ответа.
OPTION - как гид в ресторане: расскажет, какие "блюда" доступны для ресурса, но сам ничего не подаст.

Выбирайте методы с умом, и пусть ваш API никогда не узнает, что такое 500 ошибка!