Sync vs Async: синхронное и асинхронное взаимодействие

1️⃣ В синхронном взаимодействии клиентский микросервис ожидает ответа от вызываемого микросервиса перед продолжением своей работы.

Плюсы синхрона:

1. Простота. Проще в реализации и отладке.
2. Прозрачность. Позволяет легко отслеживать и управлять последовательностью выполнения операций.

Минусы синхрона:

1. Зависимость от доступности. Если вызываемый микросервис недоступен или работает медленно, это может привести к задержкам и блокировкам в клиентском микросервисе.
2. Узкое место. Если синхронные вызовы выполняются последовательно, это может стать узким местом производительности.


2️⃣ В асинхронном взаимодействии клиентский микросервис отправляет запрос вызываемому микросервису и продолжает свою работу без ожидания ответа. Ответ может быть получен позже, например, через сообщения или коллбэки.

Плюсы асинхрона:

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

Минусы асинхрона:

1. Сложность. Требует более сложной реализации, так как необходимо обрабатывать асинхронные ответы и управлять состоянием запросов.
2. Усложнение отладки. Отслеживание и отладка может быть сложнее из-за распределения запросов и ответов во времени.

Что выбрать?

Правильный выбор подхода зависит от следующих факторов:

1. Время отклика. Если требуется мгновенный отклик и задержки недопустимы, синхронное взаимодействие может быть предпочтительным.
2. Надежность. Если надежность и отказоустойчивость важны, асинхронное взаимодействие может быть предпочтительным, так как избегает блокировок и позволяет более гибко обрабатывать ошибки и отказы.
3. Производительность. Если система требует высокой производительности и параллельной обработки запросов, асинхронное взаимодействие может быть более эффективным.

Развернутая статья здесь

#api #интеграции #архитектура

🗣Webhook. Что это такое и когда используется

Вебхук — это способ оповещения клиента о произошедшем в системе событии с помощью пользовательских обратных вызовов по HTTP.

Вебхук запускается, когда в системе происходит какое-то событие. Например, человек написал комментарий на сайте. Когда происходит такое событие, сервер создает HTTP-вызов и отправляет его на адрес, который клиент указал для получения вебхуков.

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

❕Чем Webhook отличается от API?

Большинство API работает по принципу «Спроси меня и я отвечу». То есть для получения свежих данных, программному клиенту нужно постоянно отправлять запросы на сервер.

Вебхуки работают иначе. Они как бы говорят: «Дружище, больше не нужно названивать. Если произойдет что-то для тебя важное, я сам сообщу».
Если простыми словами, вебхук — как бы подписка на обновления для определенных событий. Сервер будет оповещать клиента только о тех изменениях, которые ему по-настоящему важны. Он сам сообщит об этих событиях при настройке вебхука.

❓Когда использовать API, когда вебхуки?

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

⛔️ Когда НЕ следует использовать вебхуки?

Когда нужна гарантированная доставка. У вебхуков такого нет Это значит, что если по каким-то причинам мы не успели обработать запрос, то данные будут потеряны. Поэтому привязывать к вебхукам критичные события не стоит — лучше поискать другой механизм мониторинга.

Ещё бывает так, что проблемы могут быть на самом сервере. Например, если зависнет сервис, который рассылает вебхуки, то мы об этом не узнаем и не получим новых данных.

📎 Материалы по теме
1. Вебхук
2. Вебхук — простой способ получить уведомление с сайта
3. Что такое вебхук, как и зачем его использовать
4. Реализация вебхуков на примере взаимодействия сторонних сервисов с онлайн-кассами
5. Попробовать поэксперементировать онлайн — webhook.site

#интеграции

📌 Список бесплатных онлайн-курсов по базам данных и SQL

▪️ Курс от Stepik: Интерактивный тренажер по SQL - практические задания на создание SQL-запросов.

▪️ Курс от Stepik: Введение в базы данных - Знакомство с методами структурированного хранения данных, основами SQL, принципами использования баз данных в приложениях

▪️ LearnDB- интерактивные онлайн-курсы по SQL СУБД PostgreSQL.

▪️ Базовый курс SQL для аналитиков и менеджеров — 24 видеоурока по SQL для начинающих, автор Максим Кухарь

▪️ Основы SQL  - базовый курс на платформе Интуит, теоретические материалы + тесты для самопроверки.

▪️ Видеокурс по SQL от IT Proger - изучение SQL и работа с базами данных на примере MySQL.

▪️ SQL для начинающих - курс по основам SQL от Академии IT

Онлайн-тренажёры по SQL
🔹 SQL Academy - онлайн тренажер с упражнениями по SQL;
🔹SQL-EX упражнения и Интерактивный учебник по SQL;
🔹 SQLBolt - пошаговый интерактивный учебник (уроки + упражнения);
🔹 Solve SQL | HackerRank - платформа для практики и изучения языков программирования;
🔹 SQL Fiddle  - эмулятор написания SQL-запросов, позволяет практиковаться на разных типах СУБД (MySQL, PostgreSQL, SQLite, MS SQL Server);
🔹 SQL Tutorial - справочник с множеством примеров и упражнений.

Источник: @notes_analyst

#sql #бд

🔥 Книги для системного аналитика бесплатно без регистрации и СМС 📚

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

Пересылайте коллегам, пусть тоже развиваются, хотя бы чуть-чуть 😉

Требования
📖 Вигерс Карл, Битти Джой. Разработка требований к программному обеспечению
📖 Алистер Коберн. Современные методы описания функциональных требований к системам
📖 Дин Леффингуэлл. Принципы работы с требованиями к программному обеспечению
📖 Джефф Паттон. Пользовательские истории. Искусство гибкой разработки ПО

Архитектура
📕 Роберт Мартин. Чистая архитектура. Искусство разработки программного обеспечения
📕 Эрик Эванс. Предметно-ориентированное проектирование (DDD)
📕 Вон Вернон. Реализация методов предметно ориентированного проектирования
📕 Крис Ричардсон. Микросервисы. Паттерны разработки и рефакторинга
📕 Сэм Ньюмен. Создание микросервисов
📕 Александр Швец. Погружение в Паттерны Проектирования

Интеграции
📗 Грегор Хоп и Бобби Вульф. Шаблоны интеграции корпоративных приложений
📗 Арно Лоре. Проектирование веб-API
📗 Сергей Константинов. API

Своды знаний
📔 BABOK v3
📔 INCOSE Guide for Writing Requirements

Навыки
📓 Алан Купер. Психбольница в руках пациентов
📓 Карл Андерсон. Аналитическая культура
📓 Вера Иванова. Путь аналитика. Практическое руководство
📓 Максим Ильяхов и Людмила Сарычева. Пиши, сокращай: Как создавать сильный текст
📓 Роберт Фитцпатрик. Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?

Библиотека будет пополняться в канале Библиотека Системного Аналитика

#подборка

Интерактивная карта навыков системного аналитика

Вариант 1
Вариант 2
Вариант 3 (здесь просто перечисление)
Вариант 4 — BA & SA Roadmap от TestEngineer

#развитие

Это я завтра утром

Задачник для системных аналитиков от Тинькофф. В задачнике 29 вопросов с нарастающим уровнем сложности.

Очень интересное чтиво, советуем ознакомиться

#развитие

〽️ Нефункциональные требования и зачем они нужны

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

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

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

А НФТ для той же системы могут быть такими:
🔹Система должна быть доступна 99,999% времени.
🔹Время отклика Системы не должно превышать 1 сек (для 90% запросов).
🔹Система должна защищать личные данные и платежную информацию пользователей от несанкционированного доступа.

Какие виды нефункциональных требований существуют

Есть много видов НФТ, разные источники классифицируют их по-разному, например, Карл Вигерс, BABOK, ISO/IEC 25000.
Для примера, рассмотрим классификацию по FURPS+.

➖ Functionality (Функциональность) — это классические функциональные требования. Пример: Система должна иметь возможность выбора способа доставки на этапе оформления заказа.

➖ Usability (Удобство использования) — это характеристики, которые определяют удобство и привлекательность системы для пользователей, такие как эргономика, эстетика, интуитивность, обучаемость и т.д. Пример: Система должна иметь адаптивный дизайн, который подстраивается под разные размеры экранов и устройств.

➖ Reliability (Надежность) - это характеристики, которые определяют способность системы работать без ошибок и сбоев, а также восстанавливаться после них, такие как доступность, непрерывность, отказоустойчивость и т.д. Пример: Система должна иметь резервное копирование данных и автоматическое восстановление в случае сбоя.

➖ Performance (Производительность) — это характеристики, которые определяют скорость и эффективность работы системы, такие как время отклика, пропускная способность, масштабируемость и т.д. Пример: Система должна обрабатывать не менее 1000 запросов в секунду при нагрузке до 10 000 одновременных пользователей.

➖Supportability (Поддерживаемость) — это характеристики, которые определяют легкость сопровождения и модификации системы, такие как тестируемость, документированность, совместимость и т.д. Пример: Система должна быть написана на языке программирования Python с использованием фреймворка Django.

➖ "+" в названии модели означает, что к ней можно добавить другие категории НФТ в зависимости от специфики проекта, такие как экологичность, экономичность, правовые аспекты, ограничения и т.д. Пример: Система должна соответствовать требованиям GDPR по обработке персональных данных.

📎 Статьи по теме
1. Нефункциональные требования к программному обеспечению — Хабр
2. О нефункциональных требованиях — Школа системного аналитика
3. Высокая доступность и удобный интерфейс: разрабатываем нефункциональные требования — BABOK School
4. Нефункциональные требования: как не пустить систему ко дну — Хабр, больше о практике
5. Нефункциональные требования? Нет, модели обеспечения качества — Хабр, предложен интересный подход к проработке НФТ

Вебинары
▶️ Немного о требованиях, которые все меняют — доклад с Analyst Days 2020
▶️ Нефункциональные требования · При чем тут заказчик? Александра Галамага

#требования

🖥 ⇆ 🗄 Как работает клиент-серверная архитектура

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

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

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

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

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

Пример работы клиент-серверной архитектуры

1️⃣ Пользователь вводит данные в форму на клиенте и нажимает кнопку “Отправить”.
2️⃣ Клиент формирует запрос на сервер и отправляет его через сеть.
Сервер получает запрос от клиента и обрабатывает его согласно бизнес-логике.
3️⃣ Сервер формирует запрос на базу данных и отправляет его через сеть или локально.
4️⃣ База данных получает запрос от сервера и выполняет его, возвращая результаты.
5️⃣ Сервер получает результаты от базы данных и формирует ответ на клиент.
6️⃣ Сервер отправляет ответ на клиент через сеть.
7️⃣ Клиент получает ответ от сервера и отображает его пользователю.

Виды клиент-серверной архитектуры

🔹 Двухзвенная — это архитектура, в которой есть только два слоя: клиентский и серверный. К двухуровневой архитектуре «клиент-сервер» следует относить такую, в которой прикладные программы сосредоточены на сервере приложений, например, на сервере CRM, а в рабочих станциях находятся программы-клиенты, которые предоставляют для пользователей интерфейс для работы с приложениями на общем сервере.

🔹 Трехзвенная — сервер баз данных, файловый сервер и другие представляют собой отдельный уровень, результаты работы которого использует сервер приложений. Логика данных и бизнес-логика находятся в сервере приложений.

🔹 Многозвенная — больше трех слоев, которые могут выполнять разные функции, такие как презентация, бизнес-логика, интеграция, хранение и т.д. Клиент обращается к одному или нескольким серверам за услугами, а серверы обращаются к другим серверам или базам данных за данными или услугами.

Преимущества и недостатки клиент-серверной архитектуры

Клиент-серверная архитектура имеет много преимуществ перед другими архитектурами, например, файл-серверная, в которой все файлы хранятся на одном сервере и доступны для всех клиентов:

✅ Экономия ресурсов и денег, так как масштабировать систему легко, добавляя или удаляя клиентов и серверов по мере необходимости.
✅ Упрощение разработки и поддержки кода, так как не нужно дублировать логику на каждом клиенте, а достаточно реализовать ее на сервере.
✅ Обеспечение безопасности и конфиденциальности данных, так как пользователь не имеет прямого доступа к базе данных и другим частям приложения, а только к своему интерфейсу.

Однако клиент-серверная архитектура также имеет некоторые недостатки, такие как:
🔻 Зависимость от сети и доступности сервера, так как если сеть пропадет или сервер упадет, то пользователь не сможет работать с приложением.
🔻 Сложность обеспечения отказоустойчивости, так как если нагрузка на приложение возрастет или произойдет сбой на одном из серверов, то нужно предусмотреть механизмы балансировки и резервирования.

📎 Материалы по теме
1. Клиент-серверная архитектура в картинках: статья на Хабре и видео
2. Клиент - серверная архитектура (Client-Server Architecture)
3. Клиент-серверная архитектура — JavaRush
4. Как работают веб-приложения
5. Грамотная клиент-серверная архитектура: как правильно проектировать и разрабатывать web API

#архитектура

HTTP. Что нужно знать аналитику

HTTP (HyperText Transfer Protocol) — это, если дословно, протокол передачи гипертекста. Простыми словами, гипертекст – это текст + теги. Сегодня HTTP – самый популярный протокол интернета и в целом интеграций через API.

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

Основой HTTP является технология «клиент-сервер», есть две роли: сервер и клиент.
➖ Клиент инициируют соединение и посылает запрос на сервер
➖ Сервер обрабатывает запрос и посылает ответ клиенту.

Структура HTTP-сообщения всегда одинакова:

🔹 Стартовая строка, в которой определяется адрес, по которому отправляется запрос, и тип сообщения. Указывается метод, который определяет действия при получении этого сообщения (GET, POST и т.д.)

🔹 Заголовки (Headers), в которых прописаны определённые параметры сообщения. Например, может быть напрямую задан язык.

🔹 Тело запроса (Request Body), текст сообщения — данные, которые передаются. Например, файлы, отправляемые на сервер.

Пример запроса:

GET /users/octocat HTTP/1.1
Host: api.github.com
User-Agent: curl/7.64.1
Accept: */*

Процесс работы HTTP-протокола

1️⃣ Клиент формирует и отправляет запрос на сервер по адресу (URL), который может быть введен в браузере или сгенерирован автоматически.

2️⃣ Запрос передается по сети с помощью других протоколов, например TCP/IP, которые разбивают его на пакеты данных.

3️⃣ Сервер получает запрос, обрабатывает его и отправляет ответ, который также передается по сети в виде пакетов данных.

4️⃣ Клиент получает ответ и отображает результат, например веб-страницу в формате HTML.

Структура ответа в HTTP состоит всё из тех же частей, что и запрос:

🔸 Cтартовая строка содержит версию протокола, код состояния и текст результата запроса, например, HTTP/1.1 200 OK

🔸 Заголовки содержат дополнительную информацию о ответе, такую как тип и длина контента, дата и время, куки, кэширование и т.д.
Например:

Content-Type: text/html; charset=utf-8
Content-Length: 125829
Date: Mon, 29 Nov 2021 10:24:06 GMT

🔸 Тело содержит данные ответа, например HTML-документ, изображение, JSON-объект и т.д.

Пример ответа

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Content-Length: 29769
Content-Type: text/json

{
    "isFree": false,
    "price": 200
}

📎 Материалы по теме
1. Стандарт HTTP 1.1 — RFC 2616
2. Статья Что такое протокол HTTP и почему на нём работают почти все сайты
3. Статья на сайте Backend interview
4. Обзор протокола HTTP — Mozilla
5. HTTP-запросы: структура, методы, строка статуса и коды состояния — Академия Selectel
6. Самые распространённые HTTP-заголовки

В продолжение к посту кидаем полезные шпаргалки 👇

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

Методы HTTP

Свойства методов HTTP
(картинка, кстати, с англоязычной Википедии 😁)

Фредерик Брукс. Мифический человеко-месяц или как создаются программные системы

Классическая книга про управление проектами в ИТ.

Фактически книга Брукса представляет собой сборник очерков, в которых последовательно обсуждаются узловые проблемы разработки крупных программных проектов: повышение производительности труда программистов, организация коллективной работы, планирование и выполнение графика реализации. Одной из главных тем книги стала идея, получившая впоследствии название «закон Брукса», о том что привнесение в проект новых сил на поздних стадиях разработки лишь отодвигает срок сдачи проекта

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

HTTP. Краткие советы по использованию протокола

📌 URL идентифицирует ресурс. Вызов метода — не ресурс.
Не делайте так:
GET /?method=шарахнуть&to=Луна
Лучше так:
POST /шарахалка/?to=Луна

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

Например, если у вас есть каталог котиков по породам, то породы — часть пути, города доставки — часть запроса, фрагмент – это якорь на странице:

http://nyashnye-kotiki.xxx/breeds/maine-coon/?deliver_to=Moscow#photo

📌 Обращение по HTTP — это применение метода (глагола) к URL. Результат должен соответствовать глаголу. Например, GET возвращает ресурс, DELETE удаляет его.

📌 Методы GET, HEAD, OPTIONS — безопасные. Они не изменяют состояние ресурса. Некоторые сетевые агенты могут вызывать их без вашего согласия.

📌 Методы GET и HEAD кэшируются по умолчанию, остальные — нет. Если вы хотите шарахнуть по Луне методом GET, то можете получить ответ из кэша и не шарахнуть на самом деле.

📌 Методы GET, PUT, DELETE идемпотентны, то есть возвращают один и тот же результат. PUT кладёт ресурс по URL-у, GET возвращает его, DELETE удаляет его. Метод HEAD возвращает только заголовки ресурса.

📌 POST используется, если у вас нет URL для операции. Например, если вы создаёте новое сообщение на форуме и не можете самостоятельно сгенерировать его ID.

POST /threads/php-rulezz/messages

Если вы повторите POST запрос — создастся дубликат сообщения. PUT можно повторять сколько угодно — результат не изменится. Это свойство называется идемпотентностью. Если клиент сам может сгенерировать ID, лучше использовать PUT:

PUT /threads/php-rulezz/messages/100500

📌 PUT может создавать или обновлять ресурсы целиком. PATCH может модифицировать ресурсы частично.

📌 Коды ответа нужны, чтобы клиент мог понять, что ему делать дальше.
3хх говорит, что нужно выполнить дополнительное действие.
4хх говорит, что клиент сделал что-то неправильно. В 4хх крайне рекомендуется включать информацию о том, что конкретно клиент сделал не так.
5хх говорит о том, что клиент всё сделал правильно — проблема на стороне сервера.

📌 Обычно при успешном выполнении операции сервер отвечает на GET — 200, на PUT — 201 Created (если ресурс создан) или 200 (ресурс обновлён), на DELETE — 204 (операция успешна, возвращать нечего), на POST — 200 или 201 (во втором случае в заголовке, обычно Location, указывается URL созданного ресурса).


📌 Работа с HTTP-статусами:

401 Unauthorized обязан сопровождаться заголовком WWW-Authenticate и подходит только для HTTP-аутентификации. Используйте 403 Forbidden для других случаев.

3xx статусы требуют дополнительного действия от клиента. Например, 304 Not Modified означает, что клиент должен взять ресурс из кэша.

404 статус может повторяться, так как ресурс может появиться позже. Если ресурса нет и не будет, используйте 410 Gone или 400.

📎 Материалы по теме
1. 15 тривиальных фактов о правильной работе с протоколом HTTP — Хабр, Яндекс
2. REST API Best Practices / Хабр
3. Best Practices in API Design — блог Swagger