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

С этого года я провожу дополнительное обучение по БД и 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

Когда ты уже не джун 😀

Всем отличного начала рабочей недели, друзья! Давайте сделаем 💪🏼

#GAhahaha

🔺Use Case: ОБЫЧНЫЕ vs ИНТЕГРАЦИИ 🔺

Расскажу про отличия по пунктам шаблона Use Case.

-----------------------
ℹ️ Предусловие:
Отличий нет. Просто описываем что инициирует запуск сценария.


ℹ️ Роли пользователей:
Здесь могут отсутствовать пользователи, т.к. сценарий может запускаться автоматически, например, по расписанию. Но и в обычных сценариях это тоже допустимо.


ℹ️ Приложения и сервисы:
Здесь перечисляются наши приложения, системы и подсистемы, а также внешние системы, с которыми выполняется интеграция. Для внешних систем рекомендуется дать ссылку на их API-документацию.


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


ℹ️ Результат:
Отличий нет, кроме того, что итоговые данные могут быть получены из внешней системы.


ℹ️ Основной сценарий:

1. В шагах сценария указываются конкретные системы и API методы, которые отвечают за его выполнение.
При работе с интеграциями важно четко понимать, какие данные и функции доступны через API. От этого зависит, какие функции мы можем реализовать внутри Use Case.
2. Важно различать синхронное и асинхронное выполнение задач.

3. Аналитик должен понимать, как последовательно происходит исполнение задачи подсистемами (сервисами / микросервисами) проекта и внешними системами.
Описание “выполняется получение самой выгодной цены внешними сервисами” не подойдёт - слишком открытая формулировка, за которой нет конкретного решения.

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

ℹ️ Обработка ошибок и альтернативные сценарии:

1A. Нужно учитывать что в любой момент любая внешняя система может оказаться недоступна.

1B. Обрабатывать потерю технической авторизации с внешней системой, которая не видна пользователю и восстанавливается автоматически стандартным методом ре-авторизации.

2A. Обрабатывать задержки в ответах на запросы и ошибки по тайм-ауту.

...
-----------------------

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

Интеграции — это не просто "еще одна задача". Это серьезная работа по анализу взаимосвязей БД + Функций + UI/UX + API нашей и внешних систем, который требует нашего опыта, внимания и профессионализма 🙌 Поэтому важно уметь определять и разрабатывать требования к интеграционным Use Case.

Предлагаю разобрать примеры интеграционных Use Case для TravelPoints 🙂

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

🧩 Интеграционный Use Case - Просмотр списка стран 🧩

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

Казалось бы, что можно всего лишь написать 2 шага:
1. Пользователь открывает приложение.
2. Приложение отображает список стран.

Но когда мы работаем с интеграциями, то нужна детализация.

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

Обратить внимание:
1. В идеале делить задачу на части для frontend (мобильное приложение) и backend (сервер-приложение) разработчиков.
2. Посмотрите на прикрепленную картинку - на ней мини-схема архитектуры.


🧩 Use Case: Просмотр списка стран в приложении travelPoints

🔸 Пользователи:
- Пользователь МП TravelPoints


🔸 Приложения:
- МП TravelPoints
- Backend TravelPoints
- countries.trevorblades

🔸 Предусловие:
- Пользователь должен быть зарегистрирован и авторизован в приложении.
- Пользователь имеет доступ к интернету.

🔸 Цель:
Показать пользователю список полный список стран. Выделить в списке те страны, которые он посетил, если такие есть.

🔸 Основной сценарий
👇👇👇

🧩 Интеграционный Use Case - Просмотр списка стран 🧩

🔸 Основной сценарий

1. Пользователь выбирает опцию просмотра списка стран: переходит на главный экран приложения.

2. Мобильное приложение выполняет запрос по REST API на Backend TravelPoints

GET /countries

для получения списка стран.


3. Backend TravelPoints выполняет запрос по GraphQL API в сервис countries.trevorblades

query { countries {} }

для получения полного справочника стран.
В БД TravelPoints он не хранится, так как предполагаем, что часть параметров о странах постоянно актуализируется в countries.trevorblades и нам нужно иметь доступ к актуальной информации.


4. Полученный список стран Backend TravelPoints преобразует в структуру JSON, используемую мобильными приложениями TravelPoints, в соответствии с требованиями маппинга, и возвращает в ответ на запрос GET /countries.

В процессе преобразования Backend TravelPoints дополняет список стран информацией о том, какие страны пользователь уже посетил и сохранил, на основе данных из БД.

При формировании ответа использовать сортировку списка стран по алфавиту. Но если у пользователя есть посещенные, то отображать первые 5 те, которые он отметил как посещенные последними.

5. Мобильное приложение разбирает полученный JSON-ответ и отображает экран со списком стран пользователю.


🔸 Альтернативные сценарии к обработке:

2А. Нет доступа в сеть интернет.
3А. Внешняя система countries.trevorblades недоступна.


Простой Use Case, но именно на его примере захотелось показать детали проектирования интеграций 🙂

И в ответ на вопрос, который возник наверняка:
"А почему бы просто не сходить в countries.trevorblades из мобильного приложения напрямую за данными, или один раз не загрузить справочник?"
Да, так можно, но не всегда.

В нашем случае прямая интеграция недопустима, так как:

1. Считаем, что на стороне countries.trevorblades есть динамическая часть данных.

2. При ответе на мобильное приложение мы дополняем полученные сведения из внешней системы данными о посещенных и сохраненных в закадки странах из нашей БД (посмотрите на макет экрана).

3. И мое любимое: если API countries.trevorblades внезапно поменяется (поменяется формат запроса или ответа), то сможем быстро внести правки на бэкенде, а не страдать из-за того, что куча пользователей скачало наше мобильное приложение TravelPoints и не все обновились, в связи с чем старые версии не работают из-за чужого изменившегося API.
В этом главная суть, почему строят такие конструкции интеграций.


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

Это того стоило 🦄

Этот месяц для меня самый тяжелый по нагрузке за последние два года.

Каждый час расписан по минутам. Можно было заметить, что почти неделю я не вела активность в канале. А все, кто работает со мной, видят меня в работе без остановки. Сегодня ответы в мои 10 вечера, 3 ночи, 5 утра или 12 дня это норма.

Я ощущаю, как на меня давит невероятная нагрузка. Работа по трем огромным направлениям забирает почти все мое время и силы, и порой мне становится до ужаса тяжело.

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

Это не бесконечно и у всего есть дедлайны, к которым надо успеть, чтобы всё получилось. В моём случае это начало апреля, когда я смогу выдохнуть и вернуться хотя бы в нормальный режим сна 🥲

Такой ритм жизни нездоров, но пару спринтов можно пережить. Работает как со спортзалом. Если хочешь получить результат, то собери все силы, напрягись и доделай свои 100 приседаний со штангой или подобное! 😁💪

Мои усилия сегодня – это путь к чему-то большему, к мечтам и целям, которые я стремлюсь достичь 🦄

И я знаю, что уже скоро я смогу оглянуться назад и сказать себе: "Это того стоило".

P.S. Хотя бы по чуть-чуть отдыхать во время спринтов важно. Так что в бонус к перегруженному расписанию есть и приятные моменты, среди которых не только спортзал каждый день 😊 Посмотрела вот на четвертый по значимости в мире турнир по теннису. Оценила работу спортивных мобильных приложений под мероприятия 🔥 Есть новые идеи для GetAnalyst
P.S.S. Я забыла сфоткаться на фоне корта 🙈

🚀 Открыта предзапись на Интеграции систем! 🎓

Интеграции - это одно из самых востребованных направлений для аналитиков. И не удивительно. Каждая третья вакансия на hh.ru требует навыков по интеграциям, особенно в ведущих компаниях интеграторах и в продуктовых компаниях.

В программе Интеграции систем мы на практике разбираем все детали проектирования: от анализа API-документации до создания структуры требований и постановок задач на разработчиков.

🗓 Старт предобучения: 26 марта 2024

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

🎁 Специальное предложение до 24 марта: Дополнительное обучение по БД в подарок.

Хотите узнать больше? Пишите @getanalyst или заполняйте анкету предзаписи на сайте, и мы поможем оценить ваши текущие навыки и ответим на все вопросы!