⏺Grafana: Обзор и возможности

Grafana — инструмент для визуализации и анализа данных.
Позволяет создавать интерактивные графики, диаграммы и дашборды на основе различных источников данных.

Возможности

Подключение к различным источникам данных
〰️поддерживает широкий спектр источников данных: Prometheus, InfluxDB, Graphite, Elasticsearch, MySQL, PostgreSQL и другие
〰️возможность работы с несколькими источниками данных одновременно.

Создание интерактивных дашбордов
〰️интуитивный интерфейс для создания и настройки дашбордов
〰️поддержка множества типов графиков и визуализаций: линии, гистограммы, тепловые карты и др.
〰️добавление пользовательских панелей с метриками и виджетами

Алертинг
〰️настройка оповещений на основе заданных условий и метрик
〰️поддержка различных каналов уведомлений: Email, Slack, PagerDuty и др.
〰️создание сложных правил для оповещений с использованием логических выражений

Управление пользователями и ролями
〰️поддержка многопользовательского режима с разграничением прав доступа
〰️интеграция с системами аутентификации: LDAP, OAuth и др.
〰️настройка ролей и разрешений для управления доступом к данным

Плагины и расширения
〰️установка и использование плагинов для расширения функциональности
〰️плагины для дополнительных источников данных, новых типов визуализаций и интеграции с внешними системами

Основные термины
🟣дашборд: Основной элемент интерфейса, состоит из одного / нескольких виджетов (панелей), отображающих данные из подключенных источников
🟣панель: отдельный виджет на панели мониторинга, может быть представлен в виде графика, таблицы, гистограммы и др. визуализаций
🟣запрос: определяет, какие данные и как будут отображаться в панели.
Может быть написан на языках запросов, поддерживаемых источником данных (SQL для БД)

Примеры применения
🔘мониторинг серверов и приложений: визуализация и анализ метрик производительности серверов, сетевых устройств и облачных ресурсов
🔘DevOps и CI/CD: отслеживание и анализ процессов CI/CD, включая скорость сборки, качество кода, успешность и время выполнения тестов.
🔘мониторинг производительности приложений, включая задержки, количество запросов, использование ресурсов и другие метрики.
🔘 бизнес-анализ: создание дашбордов с отчетами по ключевым бизнес-метрикам (продажи, конверсия, пользовательская активность)
🔘 интернет вещей (IoT): визуализация и мониторинг данных с IoT-устройств (температура, влажность, уровень заполнения и другие показатели)

Недостатки
🟣Некоторые расширенные возможности доступны только в платных версиях (Grafana Cloud или Grafana Enterprise)
*🟣Эффективность работы зависит от качества и производительности источников данных
🟣***Для максимальной эффективности требуется правильная настройка и регулярное обновление

Экосистема Grafana
*😥Grafana Loki*: система для управления логами
😥Grafana Tempo: для распределенного трейсинга
*😥Grafana Cloud*: услуга для облачного хостинга и управления всей экосистемой Grafana
*😥Grafana Agent*: агент для сбора метрик и логов

#инструменты

🛡 Изолированность транзакций в БД: MVCC, блокировки
Изолированность транзакций в БД гарантирует, что параллельные транзакции не влияют друг на друга. Предотвращает видимость промежуточных результатов транзакции для других до её завершения, сохраняя целостность данных
Это одно из свойств ACID
Как обеспечить изолированность*🟣 *MVCC (multiversion concurrency control) — создание отдельной версии данных для каждой транзакции*🟠 *Блокировка — ограничение доступа к данным

MVCC
Принцип работы

Во время транзакции создается копия данных, в которой происходят изменения
➖Если транзакция завершилась успешно, копия становится основным источником, старая версия — удаляется
➖Если во время транзакции произошла ошибка, старая версия остается основной, а копия удаляется

ПримерДва пользователя одновременно меняют карточку товара⚪️ Они открывают карточку товара, создается две копии записи о товаре
⚪️ Одновременно меняют поля товара. Обе копии могут стать основной записью
⚪️ Перед сохранением БД пытается слить две записи в одну
▫️ Если конфликтов нет (менялись разные поля), транзакции завершаются успешно
▫️ Если появились конфликты, обе транзакции откатываются **Блокировки

Примеры видов блокировок**

*️⃣ Централизованная
*️⃣ Распределенная
*️⃣ Независимая

😀 Централизованная
Приложение-координатор дает доступ к БД или отклоняет запрос, если БД занята.

Алгоритмы выбора координатора

⏩ Забияка
🟡 рассылается сообщение о выборе координатора
🟡 отвечают все неупавшие приложения
🟡 инициатор выбирает приложение с наибольшим ID

⏩ Выбор в кольце
🟡процессы образуют кольцо, передавая сообщение о выборе координатора, пропуская неотвечающие узлы
🟡по завершению инициатору приходит список "живых" приложений
🟡инициатор выбирает приложение с наибольшим ID

📍Проблемы: координатор становится бутылочным горлышком системы, может ограничивать производительность

😀 Распределенная
Каждый процесс отправляет запросы на доступ к ресурсу всем другим (и себе)

Действия получателя:
🟠ОК: если другое приложение не имеет доступа и не запрашивает его
🟠В очередь: если получатель уже использует ресурс
🟠Сравнение времени: если получатель планирует использовать ресурс, он
сравнивает время запроса со времени своего запроса
— ОК: если у входящего сообщения время меньше
— В очередь: если время больше
После отправки запросов приложение останавливается, ждет подтверждения от остальных.
Далее отправляет OK всем в своей очереди и чистит ее

📍Проблемы: при сбое одного из процессов могут возникнуть задержки, блокирующие
доступ к ресурсу

😀  Независимая
Минимизация блокировок за счет работы с копиями данных.
*️⃣Каждая транзакция работает изолированно со своей копией данных
*️⃣Перед фиксацией изменений, проводится проверка на наличие конфликтов.
  — если не обнаружено, изменения транзакции применяются к основной БД
  — если обнаружено (например, другой транзакцией изменены те же данные), текущая транзакция откатывается и, возможно, повторяется

*📍*Проблемы: частые откаты при высокой конкуренции, сложность управления копиями данных
Пример блокировки в БД

Две транзакции (T1 и T2) работают с таблицей accounts (информация о балансах пользователей)

🟡T1: Начинает транзакцию, читает баланс аккаунта
🟡T1: Запрашивает блокировку на аккаунт для обновления баланса
🟡T2: Начинает транзакцию и пытается прочитать баланс аккаунта
⏩ Блокировка: т.к.T1 удерживает блокировку, T2 ждет, пока T1 завершит свою транзакцию
🟡T1: обновляет баланс и фиксирует транзакцию, освобождая блокировку
🟡T2: читает обновленный баланс

Что выбрать для обеспечения изолированности?
*🟣 *MVCC
▫️если важен параллельный доступ
▫️скорость обработки транзакции
▫️когда важно, чтобы чтения не блокировали записи
*🟠*Блокировки
🟡если нельзя допустить любую рассогласованность данных
🟡важна строгая последовательность данных
🟡недостаточно памяти для хранения копий

#бд

✔️SQA: обеспечение качества ПО

SQA (Software Quality Assurance) — процесс для обеспечения соответствия ПО установленным стандартам и требованиям.
Это система подходов, которая интегрирована в процесс разработки, чтобы гарантировать качество на всех этапах.

Почему важно SQA?
💛 Обеспечение соответствия ПО требованиям и ожиданиям пользователей
💛 Раннее выявление и устранение дефектов
💛 Снижение затрат на исправление ошибок на поздних стадиях разработки
💛 Повышение доверия и лояльности пользователей

Основные аспекты SQA

*🟢*Планирование и анализ требований: определение требований к качеству и разработка плана его обеспечения

🟢 Процессы и методологии разработки: внедрение практик разработки (Agile, Scrum, DevOps)

🟢 Документирование и стандарты: создание и поддержка документации, стандартизация процессов и методов тестирования.

🟢 Тестирование ПО: проверка соответствия ПО требованиям, поиск и устранение дефектов.

🟢Контроль качества (QC): мониторинг и проверка соответствия результатов требованиям и стандартам.

🟢Анализ и улучшение процессов

Примеры применения

➡️ внедрение методологии Agile для улучшения взаимодействия между командами разработки и тестирования
➡️ создание стандартов кодирования и тестирования для поддержания качества на всех этапах разработки
➡️ проведение аудитов процессов разработки и тестирования, автоматизация тестирования

Примеры атрибутов качества

Внешние
⏪ Удобство установки / удаления
⏪ Целостность (насколько хорошо система защищает от неточности)
⏪ Совместимость (взаимодействие и обмен данными с другими системами и компонентами)
⏪ Производительность
⏪ Надежность
⏪ Устойчивость
⏪ Безопасность
⏪ Удобство использования

Внутренние
⏩ Эффективность использования ресурсов системой
⏩ Возможность модификации
⏩ Переносимость (насколько легко заставить систему работать в другой
операционной среде)
⏩ Возможность повторного использования
⏩ Масштабируемость
⏩ Проверяемость и тестируемость (как быстро можно протестировать систему

Инструменты и методы

🟢для управления тестированием: Jira, TestRail
🟢для авто-тестирования: Selenium, TestComplete
🟢системы контроля версий и CI/CD: Git, Jenkins
🟢для статического анализа кода: SonarQube Отличие от нефункциональных требований

🔵QA охватывает весь процесс разработки и контроля качества ПО, обеспечивая соответствие всем требованиям (функциональным и нефункциональным).
🟢 Нефункциональные требования определяют конкретные критерии, которым должна соответствовать система для обеспечения качественного функционирования, не затрагивая процесс их обеспечения  (производительность, безопасность, масштабируемость, надежность и удобство использования)

#требования

Kanban vs Scrum: сравнение методологийKanban и Scrum — методологии гибкого управления проектами, используемые для реализации принципов Agile и DevOps при разработке.

Kanban — подход к управлению процессом разработки, который включает следующие практики:

?Визуализация задач и прогресса с помощью канбан-доски, установление приоритетов задачам
?Ограничение количества задач со статусом "В работе", или WIP (work in progress). Если лимит превышен, то команда не может взять новую задачу в работу, пока не будет завершена одна из текущих
?Управление потоком: отслеживание метрик, таких как скорость движения задач между статусами, для устранения «бутылочных горлышек», где процесс замедляется
?Проведение каденций — встреч членов команды по процессу разработки. Всего выделяют 7 видов встреч. Главная цель — объяснение правил для всех участников команды и сбор обратной связи
?Непрерывное улучшение процесса на основе обратной связи и анализа метрик
Что общего между Kanban и Scrum
➖Обе методологии относятся к Agile➖Важна визуализация работы для прозрачности и оценки текущего состояния задач.
➖Имеют итерационный подход к работе, даже если длительность итераций различается.
➖Имеют механизмы для определения и управления приоритетами задач.
➖Акцентируют внимание на командной работе и взаимодействии между участниками

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

*✅ Когда лучше применять*

Kanban:*?в проектах с типовыми повторяющимися задачами, например, техническая поддержка, где задачи обрабатываются по мере поступления и приоритеты могут меняться в зависимости от срочности
?команда не является кросс-функциональной
? в проектах с высокой степенью неопределенности, где требования часто меняются или неизвестны заранее. Kanban позволяет вносить изменения в любое время без нарушения цикла работы
*Scrum:
*? важен строгий контроль сроков и структура
? требуется четкое определение целей и результатов
?команда является кросс-функциональной
*Пример: Разработка новой версии продукта с фиксированным релизным циклом, например, каждые 3 месяца.

❌ Когда не подойдет
Kanban*?в проектах, где необходимо строго соблюдать сроки
?в кросс-функциональных командах
?когда требуется постоянная обратная связь от клиентов
*Scrum
*? продукт нужен целиком, итерации невозможны
? когда нет сплочённой, самоорганизованной и кросс-функциональной команды
?*** для слишком маленьких групп из 1–2 человек, или, наоборот, больших лучше заменить другими методами — SAFe, LeSS.

*☯️ Гибрид ScrumBan*

Используется в средах, где необходимо управление проектом в условиях неопределенности и частых изменений. ScrumBan легче внедрить, чем Scrum
*?*от Scrum: сохраняет ключевые элементы Scrum: спринты, роли (Product Owner, Scrum Master, и команда разработки) и основные события (планирование, ревью, ретроспектива).
?от Kanban: заимствует концепцию визуализации процесса на доске, ограничения рабочего объема, адаптацию к изменениям в реальном времени и фокус на поток задач.

⭐️ Подборки материалов по этой и другим темам доступны взакрытом канале

#управление_проектами

✨ Денормализация в БД и не только

Ранее мы рассказывали про нормализацию в БД, рассмотрим обратный процесс.

Денормализация — внесение избыточности в БД путём объединения таблиц, чтобы упростить структуру и ускорить чтения данных

Отличие от нормализации

Нормализация нужна для устранения избыточности данных; для разделения информации по отдельным таблицам, чтобы обеспечать целостность и упростить обслуживания БД
?Увеличивает количество джойнов при выполнении запросов и может замедлять чтение данных
Денормализация, наоборот, вводит избыточность обратно в БД, объединяя таблицы и дублируя информацию
?Запросы становятся проще, операции чтения быстрее. Но могут возникнуть трудности с поддержкой и обновлением из-за риска несогласованности

*✨ *Когда применяется

?для ускорения чтения данных за счет сокращения количества джойнов
?в системах с большим объемом операций чтения и минимальным количеством обновлений, где производительность чтения критична
?для ускорения разработки и оптимизации работы приложений

*✨ *Методы

*? *Добавление избыточных данных: дублирование данных в нескольких таблицах для сокращения соединений при запросах
*? *Добавление производных или агрегированных столбцов: включение полей с предварительно вычисленными значениями, например, общей суммы заказа.
*? *Объединение таблиц: слияние смежных таблиц в одну для уменьшения операций соединения
*? *Денормализация иерархических структур: дублирование информации о верхних уровнях иерархии на нижних для упрощения запросов
*? *Использование материализованных представлений: хранение результатов сложных запросов в виде отдельной таблицы для быстрого доступа
? Введение таблиц сумм и счётчиков: создание отдельных таблиц для хранения суммарной информации, например, общее количество товаров, проданных за день, или общее количество посетителей сайта. Позволяет избежать необходимости агрегации больших объёмов данных при каждом запросе

✨ Примеры

*?*Агрегация данных: в таблице заказов хранится не только идентификатор клиента, но и агрегированная информация о клиенте, например, общая сумма покупок. Это избавляет от необходимости соединять таблицы заказов и клиентов для расчета общих покупок клиента
*?*Кэширование результатов запросов: в таблице с продуктами может храниться не только информация о продукте, но и предварительно рассчитанное количество продуктов на складе. Это снижает нагрузку на СУБД за счет уменьшения количества вычислений при каждом запросе

*✨ *Недостатки

— избыточность данных может привести к проблемам с их согласованностью, когда изменение информации в одном месте потребует её обновления и во всех остальных денормализованных таблицах. Это увеличивает сложность поддержки и может привести к ошибкам
— увеличивается объём хранимых данных
— замедление других операций, может замедлить процессы вставки, изменения и удаления данных
*✨ *Совет

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

*✨ *Денормализация в других областях

?Data Warehouse: улучшает производительность аналитических запросов через агрегированные структуры данных для быстрого выполнения запросов OLAP
?NoSQL базы данных: для оптимизации горизонтального масштабирования и ускорения доступа к данным, храня связанные данные вместе
*?*Frontend-разработка: при проектировании состояния приложений, например в Redux для React, для упрощения доступа к данным и улучшения производительности
?Микросервисы: улучшает независимость и отказоустойчивость сервисов, храня данные, необходимые каждому микросервису в его собственной базе

⭐️ Подборки материалов по этой и другим темам доступны взакрытом канале

#бд

Хранимые процедуры и пользовательские функции в БД

*?*Кратко
Хранимые процедуры предназначены для выполнения действий, а пользовательские функции - для вычислений и возврата значений.

✔️ Хранимые процедуры
Это набор инструкций, которые выполняют любые операции с данными, сложную логику или задачи на стороне сервера БД
?компилируются один раз и хранятся на сервере
?могут содержать циклы, условные операторы
?как в обычном коде в языках программирования, можно реализовать логику работы с данными
?могут принимать параметры и возвращать результаты, но могут и не возвращать

Как используются?

?выполнение сложных операций (сортировка, фильтрация и агрегация), сложной бизнес-логики
?могут включать несколько операций, которые выполняются как одна транзакция
?последовательное выполнение нескольких SQL-команд
?регулярно выполняющихся операций, требующих быстрого повторного исполнения
?обеспечивают защиту, выполняясь на стороне сервера БД, а также контролируют доступ и выполнение операций. С помощью процедур можно реализовать логику доступа, проверки прав и аутентификации пользователей

Примеры ⏩процедура принимает ID сотрудника в качестве входного параметра и возвращает его имя из таблицы Employees
⏩процедура принимает данные о новом заказе (например, клиент, товары, количество) и добавляет соответствующую запись в базу данных.
⏩входной параметр -- ID заказа, процедура извлекает информацию о товарах в заказе и вычисляет стоимость всех товаров.

*〰️ *Минусы? когда сложны, тяжело поддерживаемы, возникают проблемы с рефакторингом
?могут создавать зависимость от конкретной СУБД — затрудняет масштабирование
?хранение бизнес-логики в PLSQL ведет к созданию монолита. Его дальнейшее разбиение затрудняется
? отладка не всегда удобна, логирование и обработка ошибок выполняется вручную

*✅ *Пользовательские функции

Это фрагменты кода, предназначенные для выполнения конкретных операций или вычислений над данными
?принимают входные параметры, выполняют определенные вычисления и всегда возвращают результат
?не предназначены для изменения данных или выполнения транзакций

Как используются?

? для сложных логических или арифметических операций
?возвращаемые значения используются в др. запросах / выражениях
?для использования операторах SQL (SELECT, WHERE и тд) для вычисления значений
?фильтрации данных, поиска определенных значений или обработки данных по заданными условиями
?для работы с текстовыми данными (разбиение строк, поиск подстрок, замена символов и тд)

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

〰️ Минусы
?не эффективны в сложных запросах
?на больших объемах данных могут привести к низкой производительности
?отладка может быть трудной из-за изоляции от основного кода
?могут зависеть от контекста сессии или окружения, что может привести к неожиданным результатам

*✔️ *Основные различия

Назначение
?процедуры -- для выполнения последовательности операций и изменения данных в БД
?функции -- для выполнения вычислений и возвращения результата

Возвращаемые значения
?процедуры могут возвращать 0 или более значений или изменять состояние БД
?функции возвращают только одно значение

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

ХП и пользовательские функции могут использоваться не только в БД, а еще в:
?приложениях на стороне сервера: могут быть частью серверных приложений, написанных на Java, C#, Python и др. Используются для обработки данных на сервере перед отправкой их клиенту.
?интеграциях в веб
?интеграциях с внешними системами, такими как API, сервисы и внешние БД, чтобы обрабатывать данные и для взаимодействия между приложениями и платформами.

⭐️ Подборки материалов по этой и другим темам доступны взакрытом канале

#бд

Технологии проектирования баз данных

✍️ Авторы: Дмитрий Осипов
? Год издания: 2019
? Язык: русский
? Объём: 498 стр.

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

Рассматривается жизненный цикл баз данных, технология проекти-рования реляционных баз данных на концептуальном, логическом и физическом этапах, базовые конструкции, используемые в SQL-ориентированных СУБД.

Излагаются обязанности особенности проектирования пользовательского интерфейса клиентских прило-жений, возможности интерактивной аналитической обработки данных OLAP, безопасность данных и способы противодействия угрозам, требования ГОСТ к документации БД.
Большое внимание уделяется перспективам развития баз данных, переход от централизованных к распределенным способам хранения данных, обсуждаются объектно-ориентированная и доку-мент-ориентированная модели данных. Излагаются возможности языка XML для работы с слабоструктурированными данными.

#бд

?Методы трассировки требований

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

Трассировка требований позволяет:
1️⃣ Обеспечить соответствие функциональности системы исходным бизнес-требованиям
2️⃣ Отслеживать изменения требований на протяжении всего жизненного цикла разработки
3️⃣ Управлять изменениями: позволяет оценить влияние изменений требований на другие артефакты и всю систему в целом
4️⃣ Упрощает тестирование: позволяет покрыть бизнес-требования тест-кейсами и не упустить важное

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

Помимо ID, требования могут иметь следующие атрибуты:
?статус
?дата создания
?версия
?автор
?владелец
?приоритет
?источник
?обоснование
?релиз
?контактное лицо или ответственный за принятие решений по внесению изменений в требование
?критерии приёмки

Виды трассировки

*↕️Вертикальная—связи между высокоуровневыми элементами проекта ( бизнес-требованиями) и низкоуровневыми (техническими требованиями или кодом)
*↔️Горизонтальная**—связи между элементами одного уровня. Например, трассировка между функциональными требованиями или между разными компонентами архитектуры системы.

✏️ Методы трассировки требований

*? *Матрица трассировки (Requirements Traceability Matrix)

Это таблица для документирования связей между  требованиями и другими элементами системы: тест-кейсами, функциями, документацией, исходный код и т. д. Также может трассироваться история изменений требований.

Примеры возможных связей
—Один к одному: один элемент дизайна реализуется в одном модуле кода;
—Один ко многим: одно функциональное требование (ФТ) проверяется множеством тест-кейсов;
—Многие ко многим:  общие или повторяющиеся элементы дизайна могут удовлетворять нескольким ФТ. На практике данным видом трассировки сложно и трудно управлять

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

Структурированное дерево, показывающее иерархию требований от общих к более детальным.

Пример
Техническое требование
—> Архитектурное требование
——>Требование к БД
——>Требование к интерфейсу

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

Плюсы и минусы трассировки
*➕Четкое представление о требованиях к системе и их взаимосвязях
➕***Отслеживание изменений требований

*➖Ресурсо-затратно: некоторые методы требуют времени на подготовку, ведение требований и обновление
➖***Есть риск недооценки сложных взаимосвязей между требованиями и элементами проекта.

#требования

*▶ *Способы асинхронного взаимодействия в API
Обзор посвящён асинхрону в API. Асинхрон в брокерах сообщений смотрите в этом посте. А здесь можно найти вводный пост по асинхронным интеграциям.

Асинхрон в API позволяет клиентским приложениям отправлять запросы на сервер и продолжать работу без ожидания ответа.

Зачем это нужно
?‍?Клиент не блокируется в ожидании ответа. Важно для операций, требующих значительного времени на обработку
?‍?Сервер может обрабатывать больше запросов за счет асинхронной обработки
?‍?Уменьшается количество необходимых запросов для получения обновленных данных, снижая нагрузку на сервер

Способы асинхронного взаимодействия в API
*1⃣Webhooks
1. Клиент отправляет запрос серверу, указывая сallback URL
2. Сервер принимает запрос и отвечает клиенту, что запрос принят в обработку (например, 202 Accepted)
3. Сервер обрабатывает запрос и отправляет клиенту запрос с результатами на сallback URL
➡ Пример: GitHub Webhooks отправляют автоматические уведомления о событиях в репозитории (например, push или pull request) на конфигурированный внешний сервис
2⃣ *Polling
Клиент отправляет запрос на сервер, а затем раз в Т миллисекунд отправляет запросы к серверу, чтобы проверить статус операции
➡  Пример:
1. Пользователь заполняет анкету и загружает скан паспорта
2. Фронт отправляет файл на сервер, получает 202 Accepted и позволяет пользователю заполнять анкету дальше
3. Сервер начинает процесс распознавания паспортных данных, который в среднем занимает 5-7 секунд.
4. Приложение запускает фоновый процесс поллинга: раз в 1 секунду отправляет запрос для получения статуса обработки запроса

*3⃣ *Long Polling
Сервер получает запрос, но держит его открытым до момента появления новых данных. Это уменьшает количество запросов по сравнению с обычным поллингом. Работает на протоколе HTTP. После получения данных от сервера соединение закрывается.
➡  Пример: чат-приложения, где сервер держит соединение открытым до появления новых сообщений, и только после этого отправляет ответ

4⃣ Server-Sent Events (SSE)
Однонаправленный канал связи от сервера к клиенту, позволяющий серверу посылать события клиенту через открытое соединение. В отличие от Long Polling клиент может получать несколько событий и данных от сервера без необходимости устанавливать соединение заново.
➡ Торговые платформы в реальном времени, где клиенты получают обновления цен акций без необходимости постоянного запроса к серверу
*5⃣WebSocket API
Протокол, обеспечивающий двустороннее постоянное соединение между клиентом и сервером, позволяя обмениваться данными в реальном времени. Это именно отдельный протокол (не НTTP), клиент и сервер могут без задержек обмениваться данными в обе стороны, без необходимости устанавливать и закрывать соединения по несколько раз.
➡*** Онлайн-игры, интерактивные приложения, где требуется немедленная реакция сервера на действия пользователя и наоборот

⭐️ Подборка материалов доступна взакрытом канале

#интеграции #async

Тестирование веб-API

✍️ Авторы: Марк Винтерингем
? Год издания: 2024
? Язык: русский
? Объём: 304 стр.

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

Обзор книги на Хабре

За книгу спасибо нашей подписчице Анне ?

#тестирование