💫 ПРОБЛЕМЫ В РАБОТЕ С ЗАДАЧАМИ НА ИНТЕГРАЦИИ 💫

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

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

1:18 - Что такое интеграции?
4:25 - Роль системного аналитика в процессе работы с задачами на интеграции.
11:41 - Как изменилась работа с задачами на интеграции за последние годы?
16:49 - Написал требования в соответствии с API-документацией внешней системы, а потом оказалось, что работает не так.
19:40 - Интеграция работала в продакшн и всё было хорошо, а потом всё внезапно сломалось.
22:57 - Что делать если предстоит интегрироваться с системой у которой еще нет API, а сроки горят?
26:18 - Разработчик системы, с которой предстоит интегрироваться, не предоставляет API и доступы, а задачу нужно реализовать, потому что сроки (P.S. Влиять через заказчика на внешнюю команду при возможности).
28:07 - Что, если вы тот самый разработчик, у которого просят API, но вам пока не до этого?
29:21 - Платные подписки и использование внешних систем. Примеры: DaData.ru, сервисы SMS-рассылок с поштучной оплатой со счета заказчика и другие.
31:58 - Разные структуры данных в разных системах: как собрать всё в нашей системе воедино? Про агрегаторы.
36:07 - Высокие нагрузки и длительное ожидание ответов. Асинхронные запросы и вебхуки.
39:37 - Не работал с видом API, по которому предстоит интеграция (REST API, GraphQL, gRPC, SOAP API и WebSocket - основные, посмотрите на них).
42:02 - Заключение и рекомендации


Эпизод доступен в:

⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Apple Podcast
⏯ Castbox
⏯ Spotify
⏯ Amazon Music


Подписывайтесь на подкаст и делитесь с коллегами, начинающими и опытными системными аналитиками!

Привет! Возвращаюсь к вам с новыми проектами на интеграции! 😌

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

В этот раз выбор нового проекта дался мне не просто. Хотелось показать:
1. Любой API с авторизацией, с которым можно сделать интеграцию, чтобы рассказать о том, как писать требования и в чём могут быть сложности.
2. Нестандартный API, чтобы все в канале узнали для себя что-то новое.
3. Постановку задачи на интеграцию на все 100%: фронтенд, бэкенд, БД, маппинги и остальное.

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

Я хожу к вендорам (разработчикам внешних систем, с которыми интегрироваться) и запрашиваю у них доступы к тестовым площадкам. В открытую разбираю их API и документацию. Это возможно не с любой системой - увы. Не у всех открытая документация и доступы.

А ещё и запас известных API кончается 😀 Я уже много показала в рамках обучающих программ, открытых вебинаров и здесь в канале. И хочу новое каждый раз.

Путём исследований, напряжений памяти и фантазии нашла 3 проекта, которые можем сделать, с новыми API! Ура! 🎉

📌 Начнём с нестандартного API - интеграция через GraphQL.

Делаем мини-проект “Чеклист путешественника” или “Travel Points” - полный разбор с нуля: с постановкой задач на UI, БД, маппинги и интеграционные REST API бэкенда.

Начнём проект сегодня! ❤️

⭐️ Онлайн-практикум по миграциям БД в этот четверг ⭐️

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

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

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

📚 Разработка требований к миграциям БД
🗓 14 марта в 19:00 Мск

📌 План:
1. Определение понятия миграции данных. Примеры.
2. Требования к обратной совместимости данных. Распространенные ошибки.
3. Влияние нефункциональных требований на миграции в БД.
4. Практика проектирования миграций внутри одной БД.
5. Обзор проблем миграций данных между разными СУБД. Практика.
6. Обзор шаблона постановки задачи на разработчиков по миграции данных.

Практикум проводится в рамках программы по дополнительному обучению БД и SQL.

Участие полезно для тех, кто уже знаком с проектированием БД и хочет погружаться глубже в детали 👀

До встречи онлайн!

💥 Самые важные виды API + примеры 💥

API (Application Programming Interface) — это программный интерфейс, через который программы могут обмениваться данными и функциональностью между собой тем способом, который предусмотрели разработчики. Интеграция систем становится более безопасной и стандартизованной за счет использования API.

Есть 5 наиболее популярных видов API:
1. REST API
2. SOAP API
3. GraphQL
4. gRPC
5. WebSocket

Разберёмся с каждым из них на примере с машиной 🚗
Сущность “Машина” - это марка, модель и год выпуска. Также для машин в системе будем хранить уникальные номера - id.

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


🔺REST API (Representational State Transfer) - архитектурный стиль взаимодействия компонентов системы. REST API использует HTTP запросы для создания, чтения, обновления и удаления данных (CRUD операции).

Формат сообщений: JSON, XML, HTML, TEXT, JavaScript. JSON является более популярным из-за его легкости и компактности.

◾️ Создание машины

POST /cars
{
"brand": "Tesla",
"model": "Model 3",
"year": 2021
}

Тело ответа JSON, после того, как запись в БД будет создана и ей будет присвоен уникальный id.
{
"id": "456",
"brand": "Tesla",
"model": "Model 3",
"year": 2021
}

◾️ Получение машины c id=457

GET /cars/457
Тела запроса нет.

Тело ответа JSON:
{
"id": "457",
"brand": "Tesla",
"model": "Model Y",
"year": 2022
}

Методы выбирают по принципу: GET = получать, POST = создать, PATCH = изменить и т.д.
Идея JSON: слева перед двоеточием имя параметра, справа значение.

🔺SOAP API - протокол обмена структурированными сообщениями в реализации веб-сервисов. Считается устаревающим. До сих пор много где используется в банках и государственных учреждениях, в старых системах.
Формат сообщений: XML.

Продолжение 👇

Примеры для SOAP API часто включают SOAP Envelope, который является контейнером для SOAP сообщений.


Запрос на создание машины:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="http://example.com/webservices">
<soapenv:Header/>
<soapenv:Body>
<web:CreateCar>
<web:brand>Tesla</web:brand>
<web:model>Model 3</web:model>
<web:year>2022</web:year>
</web:CreateCar>
</soapenv:Body>
</soapenv:Envelope>

После создания машине присваивается уникальный id=456. Пример ответа:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="http://example.com/webservices">
<soapenv:Header/>
<soapenv:Body>
<web:CreateCarResponse>
<web:carId>456</web:carId>
<web:brand>Tesla</web:brand>
<web:model>Model 3</web:model>
<web:year>2021</web:year>
</web:CreateCarResponse>
</soapenv:Body>
</soapenv:Envelope>

Теперь, как и для REST API, получение машины c id=457

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="http://example.com/webservices">
<soapenv:Header/>
<soapenv:Body>
<web:GetCarRequest>
<web:carId>457</web:carId>
</web:GetCarRequest>
</soapenv:Body>
</soapenv:Envelope>

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

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="http://example.com/webservices">
<soapenv:Header/>
<soapenv:Body>
<web:GetCarResponse>
<web:car>
<web:id>457</web:id>
<web:brand>Tesla</web:brand>
<web:model>Model Y</web:model>
<web:year>2022</web:year>
</web:car>
</web:GetCarResponse>
</soapenv:Body>
</soapenv:Envelope>

Обратите внимание на перегруженность формата xml. Если в JSON всё аккуратно и человекочитаемо, то в XML, конечно, читаемо, но более перегружено. И это еще простой пример. А еще есть XSD-схема и wsdl 🙂

Но об этом в другой серии постов, если наберем 100🦄 и SOAP вам актуален. Пока GraphQL 😀

#ИнтеграцииGA

😍 GraphQL и отличия от REST 😍

GraphQL — это язык запросов для API-интерфейсов и среда, в которой они выполняются. Понятие "язык запросов" в контексте GraphQL относится к систематизированному способу формирования запросов к серверу (Backend).

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

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

Формат запроса: язык GraphQL.
Формат ответа: традиционный JSON.

Пример про машины:
- В REST API вызывая метод “Получить информацию о машине” GET /cars/457 я получу весь список полей, который заложен в ответ на уровне сервера, т.е. id, марка, модель и год выпуска.

{
"id": "457",
"brand": "Tesla",
"model": "Model Y",
"year": 2022
}

- В GraphQL клиент, например, разработчик мобильного приложения, может оптимизировать свой запрос и получать только нужные данные с сервера. Для машины это может быть только id и марка. Зависит от задачи и экрана, где нужно отображать данные.

{
"id": "457",
"brand": "Tesla",
}

🙃 Отличия от REST API
Одно из ключевых отличий между GraphQL и REST заключается в способе обработки запросов и ответов.

В REST для каждого объекта данных, который вы хотите получить или обновить, обычно требуется отдельный endpoint.
GET /cars/{carId}
POST /cars
PATCH /users/{userId}
и др.

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

Лучше посмотреть примеры 👇 Но сначала на получение данных, т.к. с созданием сложнее.

#ИнтеграцииGA

😍 GraphQL: примеры и создание новых данных через мутации 😍

Продолжим наш пример с машиной, чтобы показать структуру GraphQL, и как он упрощает взаимодействие с данными.
Запрос на получение машины в GraphQL с id=457

>> Вариант 1 - полные данные:

query {
car(id: "457") {
brand
model
year
}
}

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

{
"data": {
"car": {
"brand": "Tesla",
"model": "Model 3",
"year": 2021
}
}
}

>> Вариант 2 - только марка (бренд):

query {
car(id: "457") {
brand
}

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

{
"data": {
"car": {
"brand": "Tesla"
}
}
}

А теперь про создание и изменение данных в GraphQL:

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

А вот любые методы GraphQL, вызывающие изменения данных, должны быть явным образом определены через мутации.

Структура:

mutation {
createObject(input: {...}) {
object {
….
}
}
}

Продолжение скоро 😉

#ИнтеграцииGA

😍 GraphQL: Мутации в GraphQL 😍

Мутации — это способ изменения данных на сервере, аналогично тому, как вы бы использовали методы POST, PUT, PATCH, DELETE в REST API. Мутация позволяет клиенту GraphQL API явно указать, какие действия он хочет выполнить с данными, включая создание новых объектов, обновление существующих и их удаление.

Мутации выполняются явно и должны быть указаны в запросе как таковые через слово mutation. Это отличает их от запросов на получение данных, где используется ключевое слово query.

Давайте рассмотрим пример, где нам нужно добавить новую машину в базу данных через GraphQL. Мы определим мутацию createCar, которая принимает параметры для новой машины Tesla, Model 3, 2021 и возвращает информацию о созданной машине.

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

mutation {
createCar(input: {
brand: "Tesla",
model: "Model 2",
year: 2021
}) {
car {
id
brand
model
year
}
}
}

Обращаем внимание на состав данных в мутации:
🔸 В createCar мы описываем input - входные параметры, которые пользователь передаёт на вход.
🔸 Во второй части мутации мы описываем объект данных car, который будет создан, и какие данные из него мы хотим получить. В данном случае полный набор.

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

{
"data": {
"createCar": {
"car": {
"id": "456",
"brand": "Tesla",
"model": "Model 3",
"year": 2021
}
}
}
}

Ответ содержит данные о новой машине, включая присвоенный ей идентификатор id=456.

Это позволяет клиенту немедленно обновить своё состояние, используя возвращённые данные, без необходимости выполнять дополнительный запрос для получения информации о созданном объекте. Такое можно делать и в REST API, но в GraphQL именно клиент задает каждый раз то, что хочет видеть в ответе на запрос, связанный с изменением данных. В REST ответ фиксированный.

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

#ИнтеграцииGA