Aqua Den / Блог автотестировщика

Вкладка Network. Фронт обменивается данными с бэком. Логично, что эти самые данные должны где-то отображаться. Напомню, что при первом переходе на страницу и по мере её обработки происходит отправка запросов на получение конкретных данных (картинок, стилей и т.п.). Так вот, все эти данные отображаются в хронологическом (по умолчанию) порядке именно здесь. Здесь же отображаются и запросы к конкретным ручкам, которые выполняет фронт, когда с ним взаимодействует пользователь. Вот на этом мы и остановимся подробнее! Исследовать мы будем какой-нибудь рандомный сайт...

Попробуем представить, как же может быть устроен обмен данными между фронтом и сервисами. И начнём мы с каталога товаров. Чтобы представить всю картину целиком, начнём с самого начала: ты, как покупатель, заходишь в интернет-магазин через свой любимый браузер Амиго. Загружаются картиночки, скрипты, HTML-код; рисуются элементы... В этот момент начинает выполняться загруженный скрипт, который обращается к сервису каталога, чтобы получить список товаров (которые, между прочим, на текущий момент ещё не отрисованы). Допустим, у сервиса каталога будет всего одна ручка, назовём её products. Принимать она будет GET запрос, в теле которого мы будем задавать значение фильтра для товаров...

Здравствуй, мой юный автотестировщик! В прошлых частях нашего короткого чтива мы начали говорить про микросервисную архитектуру приложения на примере простого интернет-магазина. Кратко напомню суть: есть интернет-магазин с очень ограниченным функционалом - фронт, каталог товаров и оформление заказа. Каждый кусок функционала - сильный и независимый сервис со своей базой данных, который может работать автономно. Каждый сервис разрабатывает своя команда. Каждый сервис (на минуточку!) может быть написан на разных языках программирования. Взаимодействие с сервисами осуществляет фронт путём отправки HTTP-запросов...

Для успешного взаимодействия сервисов друг с другом важно, чтобы команды, которые их делают, имели прозрачную коммуникацию. Они пишут документацию (спецификации, спеки, доки, FS, эфэски), которой могут воспользоваться в другой команде для понимания как работать с конкретным сервисом. А ещё (в идеальном мире) они качественно описывают взаимодействие со своим API. Делается это с помощью специальных комментариев в исходном коде сервиса, которые потом хитрым образом обрабатываются сторонним ПО и выдают удобную...

Кратко резюмирую итоги предыдущей части: мы рассматриваем пример обрезанного простого интернет-магазина, построенного на микросервисной архитектуре, где каждый сервис может взаимодействовать с другими сервисами по протоколу HTTP. Давай поподробнее рассмотрим какой-нибудь сервис (не важно какой, пусть будет абстрактный). Как у тебя для взаимодействия с окружающим миром есть глаза, уши, рот и другие части тела (гусары, молчать!), так и у сервиса должны быть какие-то способы общения. Чаще всего для организации такого взаимодействия используется REST-архитектура. Такая архитектура предполагает наличие у сервера определённого API, по которому с ним можно взаимодействовать...