🧲 Что общего у сильных аналитиков? 🧲

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

Но есть нечто общее у тех, кто ставит цели и быстро выходит на качественно новый уровень в своей карьере. Они выделяются среди остальных.
⠀
И это не про хард-скиллы. Это про особенности личности.


Черты, которые я вижу снова и снова у всех специалистов, кто у нас примерно в середине или к завершению обучения получают офферы:

💎 Они вникают в детали.
Не потому что надо. А потому что им реально интересно, как всё устроено.
Они могут завалить меня вопросами, попросить разобрать ещё пару примеров, докинуть теории, чтобы прям понять до конца.
Они не проходят мимо непонятного — им важно разобраться.
Это всегда видно.
Я это очень ценю и всегда помогаю!

💎 Желание понять.
Не просто «услышал — записал».
А: «погоди, а почему именно так? а если вот так?».
Они мыслят, задают вопросы, цепляются за нюансы.

💎 Терпение.
Когда не получается с первого раза — не психуют.
Не сдаются. Просто садятся и разбираются.
Переделываю работу по моим "100 комментариям" в Confluence.
Иногда молча, иногда с вопросами.
Но всегда с уважением к процессу.


Это как настройка на уровне личности.
Внутреннее спокойное упрямство.
Сильная мотивация. Настрой на рост.

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

Потому что с таким подходом всегда получается.
Не обязательно быстро. Не всегда гладко.
Но обязательно 🚀🚀🚀


Сама такая, видимо сила притяжения работает 🧲

👀 Сколько API-методов ты видишь на картинке? 😅

В среду дала задание на определение количества API-методов, которые нужны на экран просмотра информации о рецепте для нашего проекта 🙂 Дизайн в Figma тут.

Важно:
Методы авторизации и из "шапки" приложения не учитывать.

Правильный ответ: 2 или 3
(3 тоже верно, если мы подумали об одном и том же 😅)


1. Получение информации о рецепте по его id
GET .../v1/recipes/{recipeId}

2. Получить список комментариев рецепта
GET .../v1/recipes/{recipeId}/comments


➕ 3. Метод, которого на этом экране нет в состоянии, когда пользователь не авторизован, но он появляется, когда пользователь войдёт в систему.
И это... Возможность оставить комментарий:
POST .../v1/recipes/{recipeId}/comments


Были ли у вас какие-то ещё предложения или идеи? Делитесь в комментариях 😊


#RecipeGA #RestApiGA

Я хочу начать этот пост с огромной благодарности каждому, кто был вчера со мной в прямом эфире на практическом вебинаре по ошибкам в REST API ❤️

Спасибо вам за это время и вовлеченность!
Спасибо, что инвестируете время в своё развитие вместе со мной и GetAnalyst.
Спасибо за тёплую обратную связь, которую я получила 🫶


Мои занятия — это не про «пройтись по верхам».
Я всегда иду в глубину.
И это требует времени.

Я про то, чтобы вы действительно разобрались в теме и получили максимум пользы, проведя своё время со мной. Чтобы вы не просто узнали что-то новое, а получили реальный опыт и глубокое понимание.


Вот, что мы вчера успели:
🔹 Разобрали особенности REST API на примере реального API
🔹 Исследовали его работу через Postman
🔹 На практике определили более 5 распространенных ошибок проектирования, которые делают даже опытные специалисты
🔹 Зафиксировали что нужно в качественной постановке задачи на разработчика - передала шаблоны
🔹 Изучили как работать с промптами в современных AI
🔹 Поделилась промптом и AI-ботом GetAnalyst для проектирования REST API

Это много и вы молодцы!

Вы задавали вопросы, делали задания, получали обратную связь.
Всё на одном дыхании!
Ваааау! 😍


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

🔥 5 ошибок в дизайне REST API
🗓 Доступ к записи с 26 до 28 апреля (сб-пн)
👉 Получить доступ

Если уже регистрировались на основной эфир, то ПОВТОРНО РЕГИСТРИРОВАТЬСЯ НЕ НАДО!
Письмо с доступом придёт в субботу утром.


👉 Эта встреча была вводным занятием к практической программе Дизайн REST API, которая стартует уже 6 мая.

Следующий онлайн-поток будет только в октябре.
Так что, если чувствуете, что сейчас — ваше время, чтобы двигаться вперёд в карьере, буду рада видеть вас на следующем онлайн-занятии после майских выходных 🙌


Спасибо вам. За доверие. За рост. За энергию.
За то, что выбираете расти в карьере с GetAnalyst ❤️‍🔥


Искренне ваша,
Екатерина Ананьева

😂👍👍❤️👌😅😊😊😍😘

❗️До начала 15 минут❗️

📹 5 ошибок в дизайне REST API: примеры реальных задач с проектов и собеседований
⏰ 19:00 - 21:30 Мск

➡️ Переходите по ссылке
https://pruffme.com/webinar/?id=cc4603de6512bdef41c893948ac68601

❗️Встречаемся онлайн через 3 часа❗️

📹 5 ошибок в дизайне REST API: примеры реальных задач с проектов и собеседований
⏰ 19:00 - 21:30 Мск

[ ЗАРЕГИСТРИРОВАТЬСЯ ]


-----------------------------------
Подготовка к практике:

Перед эфиром установите Postman и зарегистрируйте аккаунт в нём!

Всё остальное покажем онлайн.

Инструкция по Postman с нуля

-----------------------------------

👉 Запись эфира будет доступна только для зарегистрировавшихся участников

🔔 Сегодня в 19:00 мск | Открытый вебинар по REST API с практикой в Postman + фишками AI 🔔

Встречаемся сегодня, чтобы:
+ познакомиться с теорией REST API на практике, через Postman
+ получить новый опыт в проектировании REST API методов с нуля,
+ узнать основные ошибки, которые допускают IT-специалисты,
+ получить набор инструментов для работы!


🔥 5 ошибок в дизайне REST API
🗓 24 апреля (чт), 19:00 - 22:00 Мск
🔗 Подробности и регистрация

👉 Запись будет доступна только для зарегистрированных участников.


Инструменты к освоению:
✅ Postman
✅ Консоль браузера
✅ Figma с дизайном UI/UX
✅ dbdiagram со схемой БД (ER-диаграмма)
✅ ChatGPT для ускорения работы


-----------
Подготовка:
Перед эфиром установите Postman, попробуйте сделать Workspace и первую коллекцию по инструкции. Всё остальное покажем онлайн.
Инструкция по Postman с нуля
-----------


Реальная работа и серьёзная аналитика.
Будем погружаться в сложную теорию через разбор конкретных примеров.

До встречи в прямом эфире! 😉

🧑‍💻 Создаем API-методы для проекта #RecipeGA | Практика 🧑‍💻

В кулинарном проекте RecipeGA, REST API нужен для веб- и мобильных приложений.

Поэтому, чтобы начать работу с проектированием:

1. Смотрим дизайн в Figma → отсюда берём
+ экраны и определям методы под них,
+ поля, которые нужно поддержать для выбранных методов.
🔗 Ссылка на Figma проекта

2. Заглядываем "под капот" — в Базу Данных
🔗 БД проекта RecipeGA


👉 В дизайне Figma вы найдёте 3 экрана:
+ список рецептов,
+ просмотр рецепта,
+ создание рецепта.

Коллеги, завтра будем использовать эти материалы на открытом вебинаре, так что рекомендую с ними познакомиться заранее 🤝


👉 И у меня к вам вопрос на оценку опыта в REST API:

Сколько REST API методов рекомендуется сделать для экрана просмотра рецепта?
Методы под кнопки "Отправить рецепт", поиск рецептов и вход в аккаунт в "шапке" страницы не учитываем, "Вход в аккаунт" внизу страницы - аналогично.

К посту для удобства прикрепила 4 скрина экрана с рецептом, который анализируем (это один экран).

Варианты ответов:
1 метод - 👍
2 метода - ❤️
3 метода - 🔥
4 метода - 🦄

Голосуем реакцией и предлагаем варианты в комментариях 🙂📝

Ответ подробно разберу и обосную в конце этой недели.

#RestApiGA

📌 Пошаговый план проектирования REST API метода 📌

Для тех, кто хочет не просто читать чужую API-документацию, а уметь проектировать REST API методы с нуля — как Backend-разработчики и архитекторы 😎

План 👇

1. Определить клиента API - для кого мы делаем метод, и выбрать конкретный метод к проектированию

2. Заглянуть "под капот" — в Базу Данных
Часто именно тут выясняется, что:
— каких-то данных нет в БД
— или дизайнер не учёл важные поля
— или мы забыли про данные из интеграции
На этом этапе системный аналитик часто ставит доп. задачи на доработку БД или уточняет макеты с дизайнером, так как тот что-то не учёл или наоборот, переборщил.
👉 Здесь важно уметь объяснить команде и заказчикам, что возможно реализовать, а что технически нереализуемо.

3. Определить тип метода и его URL
🔗 Здесь подробно

4. Прописать требования к безопасности
+ вид авторизации,
+ приложения и роли,
+ ограничения по числу запросов,
+ другие ограничения.

5. Сделать требования к заголовкам (headers)
🔗 Здесь подробно

6. Спроектировать тело запроса (если нужно)
Обычно в формате JSON, но может быть XML, HTML, JavaScript, файлы.

7. Спроектировать тело ответа и выбирать успешный статус-код.
Формат сообщения такой же, как в запросе.
Возможные статус-коды:
+ 200 OK,
+ 201 Created (если что-то создано в БД)
и другие.

8. Описать требования к обработке ошибок
Что вернётся, если что-то пошло не так?
Статус-коды + тело JSON + заголовки

9. Продумать алгоритм работы метода
Что делает метод внутри?
Обращается ли к БД?
Интегрируется с внешней системой по API ("под капотом" может быть SOAP, gRPC и любой другой API)?

10. Описать маппинг данных
Таблица, в которой сопоставляем параметры БД, JSON и, если есть интеграция, то также параметры API внешней системы.

11. Дозаполнить шаблон требований
➕ Общее описание
➕ Логирование и мониторинг
➕ Другие доп. требования


Структуру постановки задачи для Confluence с пояснениями можно найти здесь:
🔗 Шаблон требований


#RestApiGA

🔥 Открытый практикум 24 апреля: знакомимся с REST API через Postman + фишки AI + разбор ошибок проектирования 🔥

Лучше всего изучать теорию через практику. Особенно это касается REST API!
Ведь именно благодаря его глубокому пониманию все остальные API, такие как GraphQL и gRPC, даваться будут гораздо легче 🙌


Поэтому готовлю новый практикум, и уже в этот четверг, буду погружать вас в REST API на примерах реальных задачах с проектов и собеседований:

🔥 5 ошибок в дизайне REST API
🗓 24 апреля (чт), 19:00 Мск
👉 Подробности и регистрация

План:
1. Знакомство с REST API на практике - через Postman
2. Разбор 5 ошибок проектирования REST API
3. Шаблон постановки задачи на разработчиков

Инструменты:
✅ Postman
✅ Консоль браузера
✅ Figma с дизайном UI/UX
✅ dbdiagram.io со схемой БД (ER-диаграмма)
✅ ChatGPT для ускорения работы


Подготовка:
Перед эфиром установите Postman, попробуйте сделать Workspace и первую коллекцию по инструкции. Всё остальное покажем онлайн.
Инструкция по Postman с нуля

Реальная работа и серьёзная аналитика.
Будем погружаться в сложную теорию через разбор конкретных примеров.


До встречи онлайн, в этот четверг! 😊

📚 Всё про JSON в одной картинке 📚

JSON - основной формат сообщений, который используется для обмена данными в разработке ПО:

✔️ REST API (запросы и ответы)
✔️ GraphQL (ответы)
✔️ Сообщения для брокеров Kafka / RabbitMQ
✔️ и в других случаях.


Инструменты, которые помогут в работе и на собеседованиях, когда вас спрашивают о JSON:

🔗 jsoneditoronline
🔗 postman
🔗 chatgpt / deepseek и другие нейросети


А всё остальное, включая подробный разбор структуры JSON, типичные ошибки и рекомендации по проектированию, собрала для вас в практическом руководстве, прикрепленном к посту 📚

#RestApiGA #RecipeGA

⚡ Заканчивается предзапись на REST API с 6 мая ⚡

Актуально добавить знания и опыт по REST API в резюме и портфолио? Хотите с легкостью осваивать другие API за счет глубокого понимания работы протокола HTTP? Тогда рекомендую посмотреть нашу практическую программу:

💻 Дизайн REST API
🗓 Старт: 6 мая 2025
👥 Первая встреча: 13 мая 2025

Вас ждёт:
⚡️ 9 онлайн-встреч
⚡️ 6 месяцев доступа к материалам
⚡️ Telegram-чат с индивидуальной обратной связью для всех участников
⚡️ QA-сессия для разбора вопросов по вашим проектам (ДЗ)

Результат - личный проект портфолио:
✅ Постановки задач и документация в Confluence
✅ Postman-коллекции и интерактивная API-документация
✅ Swagger-документация
✅ Работающие на загрушках ваши API-методы (mock api)

✅ Возможность развиваться, чтобы работать в Backend-командах, на проектах с мобильными приложениями и интеграциями, где аналитики глубоко погружаются в техническое проектирование и создают контракты REST API

🔗 Узнать подробнее и оставить заявку


⌛️ Только до 22 апреля:
Дополнительное обучение по БД+SQL в подарок и запись на самых выгодных условиях.


Есть вопросы? Пишите в @getanalyst или заполняйте анкету на сайте.
Поможем оценить ваш текущий уровень и подскажем, подойдёт ли вам программа 🤝

🌱 Что бы я сказала себе, если бы только начинала карьеру Системного Аналитика? 🌱
А если честно, я это и сейчас себе постоянно напоминаю...

📍 Не бойся задавать вопросы — особенно «глупые».
Ты не обязана знать всё.
Но если стесняешься спросить, то будешь делать вид, что поняла, а потом зависнешь одна, сделаешь ошибки или по 100 раз будешь перепроверять информацию.

📍 Ты не обязана делать всё идеально с первого раза.
Ты учишься. И будешь учиться всегда. Даже через 10 лет, когда уже будешь сама вести проекты, руководить компанией, менторить других и объяснять архитектуру клиенту — всё равно будут моменты «погоди, а как это вообще работает?»

📍 Структура — это суперсила.
В хаосе требований, встреч, срочных задач и непонятных ролей умение выделить главное, собрать картину целиком и объяснить другим — бесценно!
И этому можно научиться. Не сразу. Но можно.

📍 Не сравнивай себя с синьорами, сравнивай себя с собой вчерашней.
Ты уже делаешь больше, чем думаешь.
Просто остановись и посмотри назад.
Это и есть рост.

📍 Окружение решает.
Рядом с людьми, которые не боятся спрашивать, не стыдно учиться.
С теми, кто делится опытом, — расти быстрее.
В среде, где нормально чего-то не знать, но хотеть разобраться — формируется уверенность.


✨ Сегодня я стараюсь создать именно такую среду в GetAnalyst — международном сообществе системных и бизнес-аналитиков.

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


💚 На каком бы этапе в карьере вы ни были, помните, вы не одни на этом пути.

Я прошла этот путь — с сомнениями, с радостями, с трудными моментами.
🌱 И продолжаю идти дальше, потому что рост не заканчивается.

Моя миссия — помогать вам уверенно развиваться в нашей одновременно и технической, и творческой профессии. С уверенностью, опорой и пониманием, зачем и куда двигаться.

Искренне ваша,
Екатерина Ананьева 💚

⚡️🐇 RabbitMQ и его отличия от Kafka: что важно знать системным аналитикам 🐇⚡️

Знакомимся с брокером RabbitMQ: как он работает, когда применяется, и чем принципиально отличается от Kafka, чтобы вы могли уверенно выбирать решение под задачи проекта.

🔗 Презентация и шаблон постановки задачи

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

Видео эпизода доступно в:
⏯ RuTube
⏯ YouTube
⏯ VK Video
⏯ Telegram

Аудио-эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Castbox
⏯ Spotify

Подписывайтесь на GetAnalyst, чтобы каждый день получать новый опыт в системном анализе! ⚡️

📍 5 ошибок в дизайне REST API | Открытый вебинар 24 апреля 📍

Аналитики встречаются с REST API постоянно.

И если говорить о создании API-методов "с нуля", то вроде бы всё понятно:
выбирай правильные HTTP методы, делай URL по аналогии, описывай запросы и ответы в JSON.

Но на практике — сплошные нюансы.

Даже опытные аналитики делают ошибки:
➖ добавляют глаголы в URL,
➖ путают уровни иерархии,
➖ описывают JSON, на которые "ворчат" разработчики,
➖ не думают о поддержке и обратной совместимости.
И на собеседованиях — те же грабли 😔


Чтобы познакомить вас с проектированием REST API и одновременно прокачать в понимании всех "подводных камней" работы, мы готовим для вас новый практический вебинар:


🐞 5 ошибок в дизайне REST API:
👉 примеры реальных задач с проектов и собеседований
🗓 24 апреля (чт), 19:00 Мск

🔗 Подробности и регистрация


В результате практики:
+ Получите опыт работы с инструментом Postman.
+ Сделаете рабочую Postman-коллекцию запросов к реальному API для личного портфолио.
+ Будете знать типичные ошибки при дизайне REST API и как их избежать.
+ Получите примеры корректных постановок задач на API-методы.


Этот урок даст вам не только знания, но и рабочие инструменты 💡

Присоединяйтесь онлайн и получайте новый опыт! 🙌

☑️ Проверьте свои знания: как строить эндпоинты для REST API методов ✅

Разобрали:
🔗HTTP-методы
🔗Структура URL
🔗Пагинация

Попробуйте ответить на вопросы, а затем сравнить результаты с предложенными ответами 👇

1. Какой метод и URL использовать для добавления нового продукта с КБЖУ?
❌ POST /createProduct
→ В URL дублируется действие, хотя оно уже обозначено методом POST
✅ POST /products
→ Метод POST = создание, /products — имя сущности (ресурса), которым управляем


2. Какой эндпоинт нужен для создания рецепта конкретным пользователем?
❌ POST /recipes/{userId}
→ Ресурс recipes не вложен внутрь userId, иерархия нарушена
▫️ POST /recipes?userId={userId}
→ Можно, но есть вариант лучше
▫️ POST /users/{userId}/recipes
→ Аналогично
✅ POST /recipes
с авторизацией пользователя в заголовке header запроса
→ Кто автор — понятно из токена, userId не нужен в URL. В двух вариантах выше не лучшее решение, т.к. по факту получается, что есть дублирование id пользователя в запросе


3. Как изменить обложку (фото) рецепта с id = 45?
❌ PUT /recipes/45/changeCover
→ Избыточный глагол в URL, лучше обозначить действие через PATCH
✅ PATCH /recipes/45/cover
→ PATCH подходит для частичного изменения (только обложки). Это конкретный эндпоинт для загрузки нового изображения
✅ PATCH /recipes/45
с телом { "coverUrl": "..." }
→ Если есть отдельный метод POST /images на загрузку изображений в файловое хранилище, из которого можно получить url для подстановки в "coverUrl"


4. Как удалить продукт из справочника?
❌ PATCH /deleteProduct/15
→ Действие должно быть в глаголе HTTP - DELETE
▫️ DELETE /products?productId=15
→ Есть вариант лучше
✅ DELETE /products/15
→ Лучший вариант
✅ PATCH /products/15/archive
→ Если хотим архивировать - удалить с возможностью восстановления


5. Как удалить продукт из рецепта (ингредиент)?
❌ DELETE /products/15
→ Это удалит сам продукт, а не его использование в рецепте
✅ DELETE /recipes/8/ingredients/15
→ Соблюдена иерархия


Какие ещё варианты у вас получились? Есть вопросы? Пишите комментарии 📝👍

#RestApiGA #RecipeGA

💎 Headers в REST API: что это и зачем 💎

Headers – заголовки запроса и ответа в протоколе HTTP.

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

Помогают:
✔️ Определять, как обрабатывать запрос.
✔️ Передавать метаинформацию о данных (системную).
✔️ Настраивать взаимодействие между клиентом и сервером.


Проще всего разобраться с Headers, познакомившись с набором стандартных значений, которые можно нагло копировать в требования к вашим методам REST API 🙂


📌 Request Headers - для запросов

◽️ Authorization
Используется для передачи токенов доступа, ключей API или других данных для авторизации. Используется для проверки доступа к API-методам.
Authorization: Bearer

◽️ Content-Type
Сообщает серверу, в каком формате отправлены данные.
Если сервер не знает в каком формате переданы данные, то он не сможет обработать запрос.
Если его нет в API, то сервер обычно ждёт JSON, если в документации не указано иное.
Content-Type: application/json
Content-Type: application/xml

◽️ Cache-Control
Управляет кэшированием данных на клиенте.
Полезно для работы с экономией трафика.
Cache-Control: no-cache

◽️ Ключи идемпотентности - название придумываете сами
Это уникальный идентификатор для запросов, который помогает избежать дублирования. Например, при повторной отправке платежного запроса сервер проверяет ключ и не создаёт дубль.
Подробнее в подкасте
Idempotency-Key:

◽️ Часовые пояса
Когда система работает в разных регионах, важно учитывать часовые пояса и их можно передавать как обязательные заголовки во всех запросах.
Стандартные названия из моего опыта:
Time-Zone: UTC+3
X-Time-Zone: UTC+3


📌 + помним про Response Headers (заголовки ответов)


Полные подборки стандартных Headers:
🔗 Wikipedia
🔗 MDN


Правильно выбранные Headers помогают удобно передавать все системные параметры для обмена данными, которые не важны для бизнес-логики и алгоритмов работы API-методов.

#RestApiGA

📑 Элементы пагинации в REST API: что это, когда нужно, примеры 📑

Когда мы работаем со списками в REST API, почти всегда рекомендуется использовать элементы пагинации (pagination).

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

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

Ключевые параметры пагинации (допустимы другие названия):

◽️ limit — максимальное количество записей, которые хотим получить в ответе. Query-параметр.
Альт. названия: size.
◽️ offset — смещение, с которого начинается выборка данных. Query-параметр.
Альт. названия: page, cursor.
◽️ count — общее количество записей по запросу. Возвращается в ответе, в body (JSON), вместе со списком, в запросе не передаётся.
Альт. названия: total.


Пример получения списка рецептов в #RecipeGA:

GET https://recipe-ga.com/api/users-app/2.1/recipes
Этот запрос вернет список всех рецептов.

Но что, если в БД сохранено 10 000 рецептов? Получать все за раз?
Кажется, это перебор. Никакой пользователь не будет реально читать весь этот объем данных.
Поэтому лучше получать список по частям.
👉 Вот здесь и пригодятся limit и offset!

Допустим, нужно получать по 12 рецептов за запрос:

🔸 1-й запрос: получить первые 12 рецептов
GET https://recipe-ga.com/api/users-app/2.1/recipes?limit=12&offset=0

🔸 2-й запрос: еще 12 рецептов
GET https://recipe-ga.com/api/users-app/2.1/recipes?limit=12&offset=12

🔸3-й запрос: еще 12 рецептов
GET https://recipe-ga.com/api/users-app/2.1/recipes?limit=12&offset=24

Так мы можем получать данные частями, что значительно упрощает работу с большим количеством записей.


👉 Зачем это нужно?
1. Удобство отображения: Не все данные нужно отображать сразу, особенно если их очень много.
2. Оптимизация: Запросы с меньшим количеством данных обрабатываются быстрее и требуют меньше ресурсов.


Запоминаем и пользуемся, почти по всех API есть пагинация 🙂

#RestApiGA

🤖 Нейросети для проектирования БД и SQL-запросов | Четверг, 19:00 Мск 🤖

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


🟢 Использование ChatGPT (и не только) для проектирования БД
🗓 17 апреля, чт
🕘 19:00 - 21:30 МСК
🔗 Подробности и запись


В результате практикума:
✔️ Научитесь грамотно формулировать промпты для AI.
✔️ Получите связки инструментов, которые необходимы аналитикам для работы с базами данных.
✔️ Создадите свою СУБД через DBeaver и выполните SQL-запросы в ней.


✅ Запись будет доступна после занятия.
✅ Для всех участников сейчас доступно занятие в записи по SQL-запросам с практикой в реальной БД 😎

По вопросам можно писать через сайт или @getanalyst 💬


👇👇👇
А если вам уже сейчас хочется узнать больше про использование нейросетей для работы, то рекомендую послушать новый подкаст
🎧 Полный гид по AI для системных аналитиков

🥑 Как строить URL для REST API методов: разбираем на практике 🥑


Рекомендуемая маска:
<Вид метода HTTP> <Протокол> :// <Доменное имя> / api / <имя API> / <версия> / <путь: названия сущностей и path-параметры> ?


✅ Метод HTTP
Не относится к URL, но тесно связан с ним. Правила выбора в этом посте.

✅ Протокол
В начале любого URL указывается протокол HTTP(s).

✅ Доменное имя
Основной адрес, по которому можно обращаться к серверу.

✅ Путь (Path)
Включает в себя один или несколько сегментов, разделённых слешами (/):

▫️“api” - указатель на каталог API сервера, может быть название вида api.
▫️имя API - указывает на конкретный интерфейс API, предназначенный для разных пользователей системы.
▫️v1 - версия API, важна для поддержки совместимости с предыдущими версиями.

В этой части может быть организована иерархия связанная с вложенными сущностями или действиями над объектами:
▫️recipes - это ресурс, к которому осуществляется доступ. В данном случае “рейепт”. Может быть в единственном числе (recipe).
▫️{recipeId} - это параметр в пути URL (path-параметр), указывающий на конкретный рецепт по его id в БД системы. Фигурные скобки {} обозначают переменную часть URL, значение которой должно быть предоставлено клиентом (например, идентификатор 18290).



✅ Query-параметры (Query-parameters)
Дополнительные параметры запроса после ?, необязательны. Если их несколько, то перечисление через символ &.
Обычно используются для фильтров, сортировок и пагинации при получении списков методом GET, но могут быть и в других методах.

В примере:
GET …/recipes?offset=0&limit=20&name=пирог&authorId=777
👉 ?offset=0&limit=20 - запрос результатов с 0-го, ограниченный 20-ю на страницу. Это два отдельных query-параметра - элементы пагинации (постраничного получения данных).
👉 name и authorId - фильтры по названию и id автора рецепта.


Больше примеров на картинках 🖼


Благодаря такой структуре всегда понятно, каким ресурсом (сущностью) управляет REST API метод ✅

#RestApiGA #RecipeGA

📌🥗 Новый проект по REST API — Кулинарная платформа #RecipeGA 🥧📌

Мы продолжаем изучение навыков системных аналитиков на практике. В этом месяце погружаемся в тему проектирования REST API для кулинарного проекта 🥧


RecipeGA — это веб- и мобильные приложения, в которых пользователи создают и делятся рецептами с фотографиями и составом блюд на основе заранее добавленных продуктов с КБЖУ (калории, белки, жиры, углеводы).


Возможности пользователей платформы:
1. Регистрация в системе
2. Создание продуктов с указанием КБЖУ
3. Добавление рецептов, включающих:
+ название блюда,
+ описание блюда,
+ ингредиенты,
+ рецепт / инструкция по приготовлению,
+ основная и дополнительные фотографии.
Продукты для рецептов они могут как создавать сами, так и брать уже готовые, из справочника, ранее созданные другими пользователями.


👉 Основной контекст для работы: управление продуктами и рецептами.


👉 Наши задачи по проектированию REST API методов, которые будут использоваться в мобильных и веб-приложениях:
▫️ Сделать с нуля методы GET, POST, PATCH, DELETE для продуктов и рецептов
▫️ Проработать структуру JSON для запросов и ответов
▫️ Разобрать пример постановки задачи на разработчиков
▫️ Сформировать корпоративный стандарт по дизайну REST API для проекта
▫️ Разобраться с документированием API через Postman и Swagger (OpenAPI)


Каждый участник получит навыки, которые нужны в реальной работе системного аналитика.


Проект объявляю открытым! 🎉

Чтобы участвовать, включайте уведомления, следите за публикациями в канале с тегом #RecipeGA, и задавайте вопросы в комментариях к постам! Разбирайтесь, изучайте и получайте новый опыт!

Будет вкусно и полезно! 😉🥙

#RestApiGA

💡 Иногда просто не хватает одного действия… и немного вдохновения 💡

Хочу поделиться историями входа в профессию аналитиков.
Они из реальной жизни моих знакомых и очень вдохновляют.

🤝 А ещё они показывают, насколько важно быть открытым к переменам и ценить силу хорошего нетворкинга.


#1. Иногда, чтобы изменить свою жизнь, нужно просто помнить чей-то заказ

Девушка работала бариста: делала смузи в баре при дорогом спортзале. Не училась в колледже, просто работала.

Однажды зашёл яркий мужчина и заказал крайне сложный, кастомный смузи — из серии “вот это, но без этого, и добавьте щепотку вот этого, но только если...”.
Необычный рецепт она запомнила, да и самого мужчину тоже.

Когда он пришёл в следующий раз, она повторила заказ по памяти прежде чем он успел что-то сказать.
Он был в шоке и спросил “Кто ты?!” 😂
Завязался разговор.

Чуть позже он представил её своей жене, которая занимается в том же зале, и предложил с ней побеседовать.

Через пару недель она получила неожиданный оффер на аналитика, без какого-либо формального собеседования 😱
Оказалось, у них стартап в IT.

Она — вообще ни разу не айтишник. Просто быстро схватывает.

Сначала она думала: "Зачем мне это, я же просто делаю смузи, что я там буду делать без знаний?".
Но в итоге согласилась.

Сейчас она системный аналитик. Обожает свою работу. Обсуждали с ней подходы к написанию требований и процессы работы её команды. Толковый специалист.

И да, всё это началось с одного нестандартного заказа 🍹


#2. Бухгалтерия устала

Больше 8 лет она считала чужие налоги. Гибридная работа: в офисе и дома. Но постоянный стресс. Сроки. Отчетность. Куча нудных цифр.

Все повышения получены. Драйва в работе больше нет. Неинтересно, некуда расти.

Можно было сменить фирму и вырасти в деньгах. Но что изменилось бы? Радости к работе это бы не добавило.

Она решила попробовать себя в IT.
Только начала учебу, но что-то пошло не по плану.
Почти сразу после начала обучения она получила оффер в IT-компанию 🙃

Не магия, а совпадение. Её знакомый работает в ТОП-овой компании, которая делает ПО для ведения бухгалтерии. Им как раз был нужен кто-то из отрасли, кто понимает боль клиентов и может помочь им развивать продукт.

Когда он узнал, что она хочет в IT, то… На собеседование она попала быстро.

Теперь она бизнес-аналитик — часть продуктовой команды.
Полгода в новой должности. Радость от новых знаний.
Кайф от жизни и уверенность, что рост есть.


А ещё …
# Из отвечающего за бумажки в гос конторе до БА, с возможностью роста в СА.

# Из учителя в школе до СА.


Разные истории.
Разные люди, разные старты, разные решения.

👉 А суть такова: перемены — это не страшно, а вселенная всегда помогает нам.

Иногда всё, что нужно — вдохновение и первый шаг.
А дальше начнёт складываться.


👉 Если вам нужен знак, что всё возможно — вот он.
Главное быть смелым и открытым миру.

🐞 Виды HTTP-методов: не повторяйте эти ошибки 🐞

GET, POST, PUT, PATCH и DELETE - виды методов, часть протокола HTTP.
Нужны, чтобы стандартизировать взаимодействие между клиентом и сервером.

Каждый метод выполняет определённое действие и соответствует логике CRUD-модели (Create, Read, Update, Delete).


Основные HTTP-методы, которые нужно знать при проектировании REST API 👇


✅ POST: создание нового ресурса
Добавить новый товар в Интернет-магазин
Зарегистрировать пользователя
Создать заказ товаров
👉 Иногда POST может использоваться для получения данных:
+ асинхронные запросы
+ слишком много query-параметров (фильтров) для списков


✅ GET: получение ресурсов
Посмотреть список товаров
Получить информацию о выбранном товаре
Проверить статус заказа


✅ PUT: обновление ресурса целиком или создание нового
для полной замены данных ресурса

Вызываем PUT (изменить/создать) для товара со штрихкодом 0123456789, на вход передаём все-все данные о нём:
👉 если товар с таким штрихкодом уже был создан, то обновить данные по нему в БД целиком, даже если какие-то параметры, как название или стоимость менять сейчас не нужно
👉 если товар с таким штрихкодом еще не создан, то создать новый

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



✅ PATCH: частичное обновление ресурса
для обновления только некоторых полей ресурса - частичное редактирование.
Изменить описание товара и передать на вход методу только его.
При этом действии в БД поменяется только описание товара, и не будет полной перезаписи всех полей, как это происходит при использовании PUT.


✅ DELETE — удаление ресурса
Удалить выбранный товар из магазина
Удалить выбранный товар из заказа


🐞 Распространенные ошибки при выборе HTTP-методов для REST API на картинке к посту


Правильное использование HTTP-методов в REST API упрощает взаимодействие с вашей системой, так как делает API предсказуемым и удобным для разработчиков.

#RestApiGA

Не инженер, не менеджер, не архитектор. Как найти себя системному или бизнес-аналитику?

Ответ — на конференции Flow, 26 апреля в онлайне. Спикеры и участники встретятся , чтобы отрефлексировать профессиональную деятельность, честно поговорить о трудностях и найти решения неочевидных проблем.

Кому будет полезна конференция:

→ Опытным аналитикам и лидам. Узнайте, как развиваться и не перегореть, когда вы уже лид. Найдите решения сложных кейсов.

→ Начинающим аналитикам. Найдите вдохновение для профессионального роста. Учитесь на ошибках опытных коллег.

Готовы искать смыслы и преодолевать неудачи? Тогда регистрируйтесь — участие в новой Flow бесплатное 🔥

💥 12 важных терминов по API,
которые нужно знать системным аналитикам 💥

1. API (Application Programming Interface)
2. REST API (Representational State Transfer)
3. HTTP-методы запросов
4. Эндпоинты
5. Коды ответов
6. Ограничение частоты запросов (Rate Limiting)
7. Полезная нагрузка (Payload)
8. Заголовки (Headers)
9. Аутентификация
10. Авторизация
11. Пагинация
12. Кэширование


Дополнительно:
1. OAuth
2. JWT Token
3. API Gateway
4. API Keys
5. Basic Authentication
6. Bearer Tokens
7. CORS
8. Webhooks
9. OpenAPI
10. API Versioning (Версионирование API)
11. Content Negotiation
12. Query Parameters
13. Path Parameters
14. API Documentation
15. API Monitoring
16. Throttling
17. Circuit Breaker
18. Idempotency (Идемпотентность)
19. API Proxy
20. Retry Logic (Логика ретраев / повторов)
21. Batch Processing (Пакетная обработка)
22. API Security
23. Health Checks
24. API Testing
25. Mock APIs
26. API Marketplace
27. API Schema
28. Semantic Versioning (Семантическое версионирование)
29. Hypermedia
30. API Deprecation (Устаревание API)

Вроде бы всё самое важное и нужное на месте 😎

#RestApiGA

🤖 Полный гид по AI для системных аналитиков: как выбирать нейросети и для каких задач использовать 🤖

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

Ключевые нейросети в обзоре:
🤖 ChatGPT
🤖 DeepSeek
🤖 Gemini
🤖 YandexGPT

Также расскажем про дополнительные инструменты со встроенными AI-возможностями и про вспомогательное ПО, которое помогает системным аналитикам использовать нейросети с максимальной пользой.


Здесь мы даём готовые инструкции, как системный аналитик может применять нейросети на практике, чтобы оставаться конкурентоспособным в быстро меняющемся мире IT.

🔗 Статья к эпизоду с дополнительными материалами


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

👉 Реальные кейсы, примеры и личный опыт.

Подкаст, который точно стоит послушать сегодня!


Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video


Получай самые актуальные знания с GetAnalyst — сообществом, где системные аналитики растут каждый день 📈

✨ Дизайн REST API с 6 мая - открыта запись в новый поток практической программы ✨

Если вы недавно интересовались актуальными требованиями к Системным аналитикам, то наверняка видели:

+ Знание REST API / JSON
+ Опыт проектирования и документирования API
+ Понимание принципов работы мобильных приложений
+ Знание OpenAPI / Swagger для создания REST API документации
+ Навык тестирования API Backend (Postman)

Все эти навыки, в разных формулировках, ожидают от Middle и Senior Системных аналитиков, которым предстоит работать с Backend- или мобильными командами, в проектах с интеграциями.


Мы осваиваем их в рамках одного большого проекта, на практической программе:

💻 Дизайн REST API
🗓 Старт 6 мая 2025
✅ Первая онлайн-встреча: 13 мая

🔗 Узнать подробности и записаться

В ходе работы учимся проектировать методы REST API с нуля, глядя на требования, архитектуру, БД и дизайн UI/UX системы.

Проект с подвохами и сложностями, на котором “набиваем шишки”, учимся писать с нуля и структурировать API-документацию, осваиваем ключевые инструменты СА 🛠



В результате вы создаете свой проект API-документации в Postman и умеете запустить работающие REST API методы Backend на заглушках, даже без навыков программирования! 🤩

👉 Это самая весомая и “программистская” часть вашего профессионального портфолио.



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


Есть вопросы?
Пишите @getanalyst,
на почту info@getanalyst.ru
или заполняйте анкету предзаписи на сайте.
Мы поможем оценить ваши текущие навыки, пришлем дополнительную информацию и ответим на все вопросы 🤝

💻 Когда Системный Аналитик работает с REST API 💻

Глядя в вакансиях Системных Аналитиков на ключевые слова "REST API", полезно понимать, что может за этим скрываться.

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


👉 1. При создании новой функциональности
У вас в команде Frontend + Backend разрабатываются отдельно - разные кодовые базы.
Frontend / Мобильные приложения взаимодействуют с Backend по REST API.

Когда в системе нужно добавить новую функциональность, то от аналитика ожидают, что он может:

+ со стороны Backend - проектировать REST API:
▫️ Определить REST API методы, которые нужно разработать для работы Frontend.
▫️ Описать алгоритмы их работы, которые будут программировать разработчики.
▫️ Продумать требования к обработке ошибок.
▫️ Сделать ролевую модель доступов к REST API методам.
▫️ Спроектировать структуру API-методов:
+ на естественном языке описать входные параметры запроса и параметры ответа на запрос.
+ продумывать техническую реализацию и описывать сразу тип метода (GET, POST, ...), endpoint (URL), query-параметры, headers запроса и ответа, тело JSON запроса и ответа, статус-код ответа.
▫️ Описывать маппинги (сопоставление) данных между БД и параметрами API-методов (в URL, JSON).
▫️ Формировать техническую API-документацию, которую в дальнейшем будут использовать разработчики: в Postman, Confluence или Swagger (OpenAPI).

+ со стороны Frontend - подключение разработанного на Backend REST API метода:
▫️ Читать техническую REST API-документацию.
▫️ Проверять работу готовых REST API методов через Postman, чтобы убедиться, что все работает так, как описано в документации.
▫️ Описывать маппинги (сопоставление) данных между UI и параметрами API-методов (в URL, JSON).


👉 2. Интеграции внешние - подключение сторонних систем по REST API
Состав подзадач аналогичен подключению API на Frontend.
Отличия:
1. Работа ведется не с внутренней API-документацией, а с чужой - на внешние системы.
2. Интеграции - это обычно про взаимодействие Backend-ов. Алгоритм работы может включать одновременно несколько компонентов: наш Frontend, наш Backend (+БД), внешний Backend.
3. Всвязи с этим больше таблиц маппингов данных в постановках задач:
✔️ Маппинг 1: UI + наш REST API,
✔️ Маппинг 2: наш REST API + внешний REST API + наша БД.


👉2.1. Интеграции - создание интеграционных REST API-методов (дополнительно к п. 2)
Нужно сделать REST API-метод на Backend, который будет вызывать любой API внешней системы (хоть REST, хоть SOAP, хоть GraphQL).
Состав подзадач аналогичен проектированию API-методов на Backend.

Маппиг данных теперь будет не только для БД и параметрами нашего API-метода (в URL, JSON). К нему добавятся еще и параметры внешней системы, которые могут быть в любом формате в зависимости от вида API.


👉 3. Интеграции внутренние - обмен данными между сервисами и микросервисами по REST API
Состав подзадач аналогичен подключению API на Frontend, но больше компонентов в описании алгоритмов и таблиц маппингов.


👉 4. Для анализа ошибок работы ПО
Что-то пошло не так при работе Frontend (или мобильного приложения)?
Открываем консоль.
Анализируем запросы и ответы REST API методов.
Тестируем сложные ситуации через Postman, смотрим на результаты и ищем причины ошибок.



Рекомендация:
Для Системного аналитика важно понимать REST API не только с точки зрения возможностей, но и с точки зрения ограничений, типовых проблем и ошибок в проектировании.
Чем лучше вы их понимаете, тем качественнее будет работать ПО разработанное по вашим требованиям.


#RestApiGA

💙 Всё про REST API методы в одной картинке 💙

Публикую для вас картинку-шпаргалку, которую можно использовать при проектировании методов REST API и постановке задач на Backend-разработчиков 🙌

Проектирование REST API актуально для старших системных аналитиков, которые работают с Backend-командами, с мобильной разработкой, в проектах с микросервисной архитектурой или в других проектах, где нужно проектировать и описывать процесс обмена данными между системами.


👉 А чтобы вы наглядно могли сопоставить структуру методов на картинке с реальными REST API, предлагаю вам посмотреть примеры открытой API-документации для интеграции с крупными сервисами:

ТБанк - Кредитные продукты
Jira - работа с задачами

Проверьте себя!
Это отличная практика по изучению структуры методов REST API.
Сможете ли найти все описанные на картинке параметры в документации?


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

#RestApiGA

👩‍💻 6 главных принципов REST API, про которые спрашивают на собеседованиях 👩‍💻

REST API — архитектурный стиль для создания веб-сервисов, основанный на протоколе HTTP.


REST API основан на протоколе HTTP:
это означает, что все принципы работы HTTP методов, их структура запросов и ответов, будут также применимы и для REST API.

Пример:
+ в HTTP есть виды методов: GET, POST, PUT, PATCH и т.д.
+ в REST API методы абсолютно те же.


Архитектурный стиль REST добавляет к HTTP дополнительные правила и принципы, по которым должен происходить обмен данными👇

Главные принципы REST:
1. Строгое разделение клиента и сервера
2. Единый интерфейс
3. Без сохранения состояния (Stateless)
4. Многоуровневая система
5. Кэширование
6. Выполнение кода по запросу

В картинках к посту просто и с примерами разобрала эти принципы.

Это не самая ценная в работе информация, но перечень этих принципов и их понимание могут спрашивать на собеседованиях 👌

#RestApiGA

🤖 Как эффективно использовать ChatGPT для проектирования БД и SQL-запросов | 17 Апреля, 19:00 Мск 🤖

Использование ChatGPT и аналогичных нейросетей для работы аналитика всё еще может вызывать вопросы. Где-то это помогает, а где-то наоборот - отнимает время 📉

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

Но в то же время, если вы используете нейросеть:
✔️ Умея решать задачи самостоятельно
✔️ Зная алгоритмы работы и последовательности команд
✔️ Используя правильные связки инструментов
то она может стать вашим помощником! 🤝


👉 Если вы умеете проектировать БД на логическом уровне, ищите возможность развиваться в темах БД и SQL, и хотите ускорять свою работу с использованием нейросетей, то приглашаю вас на онлайн-практику:

🤖 Использование ChatGPT для проектирования БД
🗓 17 апреля, чт
🕘 19:00 - 21:30 МСК
👉 Подробности и запись

План:
1. Знакомство с ChatGPT (и не только)
2. Проектирование физической модели БД PostgreSQL
3. Автоматическая отрисовка ER-модели с использованием ChatGPT и дополнительных инструментов
4. Создание реальной БД и SQL-запросы в DBeaver

✅ Запись будет доступна после занятия.
✅ Для всех участников сейчас доступно занятие в записи по SQL-запросам с практикой в реальной БД 😎


По вопросам можно писать через сайт или @getanalyst 💬

Бывают моменты, когда теряешь ориентиры в карьере.

Не понимаешь, куда расти, в каком направлении двигаться. Вроде всё умеешь — но хочется большего, хочется развиваться и в навыках, и в деньгах. Но как и куда?

⭐️ В такие моменты помогает одна простая, но мощная практика — написать "резюме мечты".

Не текущее.
А такое, где ты — тот, кем хочешь стать.

Почти как в детстве про "я хочу стать космонавтом", но уже с позиции взрослого человека 🙃


Садишься и честно придумываешь себе будущий опыт работы (наконец-то можно!) 😊

✅ Навыки:
+ проектирование архитектуры
+ нотация С4
+ проектирование REST API
+ интеграции
+ микросервисы
+ Kafka
+ RabbitMQ
+ Postman на продвинутом уровне
+ ...

✅ Опыт работы:
+ Убрал хаос в компании по работе с REST API и ввёл корпоративные стандарты проектирования
+ Работал с высоконагруженной системой и проектировал внутренний обмен данными
+ Продумывал сложные цепочки интеграций микросервисов с участием брокеров, gRPC, REST API
+ Проектировал архитектуру для переезда с монолита на микросервисы
+ Управлял командой из 12 аналитиков распределенных по командам продукта
+ Работал в Германии на позиции ведущего системного аналитика более 3-х лет
+ ...

✅ ЗП:
от 100 000 $ /год


Пишем всё, что когда-то и где-то слышали от более опытных коллег. Мечтаем. Ищем вдохновение в статьях на хабре, в цифрах ЗП в вакансиях на LinkedIn. Для вдохновения еще полезно посещать митапы, конференции и обучения))


Это может показаться странным. Как будто ты приписываешь себе несуществующий опыт. Кто-то это ради "лишь бы взяли" делает 😅
Но у вас другая история. Вы к этому опыту планируете прийти.

Магия в том, что такой практикой ты даёшь себе чёткий вектор: куда я хочу расти 📈🔮

Появляется фокус. А вместе с ним — план.
После этой практики ты даже неосознанно начинаешь движение к цели 🙌 (а если опубликовать, так вообще можно случайно "сесть на ракету" и ускориться...😅)


У меня вообще всё, что записано на бумаге, обычно через время сбывается. Такой вот ритуал исполнения желаний 🪄

Попробуйте 😉
Это работает!

📌 Подборка полезных материалов по Интеграциям от GetAnalyst 📚


Послушать и посмотреть:

🎧 Postman: навык тестирования REST API за вечер

🎧 Опасные интеграции - про альтернативные сценарии и обработку типовых ошибок

🎧 Подкаст "Проблемы в работе с задачами на интеграции"

🎧 Доставить и не потерять: синхронизация данных в распределенных системах - основы очередей сообщений

🎧 Подкаст "Идемпотентность и коммутативность API: что это и как применяют на практике"

🎧 Подкаст "Kafka: что нужно знать Системному аналитику" - глубже в понимание очередей и брокером


Познакомиться с теорией:

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

📝 Отличия между обычными и интеграционными Use Case

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

📝 Работа Kafka - что надо знать для работы СА



Практические руководства по Postman:

📚 Практическое руководство по Postman - тестирование API DaData (с нуля до результатов)

📚 Практическое руководство по Postman - тестирование API ChatGPT

📚 Практическое руководство по Postman - тестирование API Unisender


Шаблоны постановок задач:

💎 Полный интеграционный Use Case - рассылка email через Unisender (с брокерами и микросервисами)

💎 Полный интеграционный Use Case - автоматическое создание задач во внутренней системе ToDoist для сотрудников компании после оплаты заказов

💎 Интеграционный REST API-метод - поиск структурированных адресов



Ещё больше про интеграции:

🎓 Практический курс Интеграции Систем - работа онлайн с Екатериной Ананьевой и экспертами программы

🎓 Материалы для самообучения по Интеграциям (пакеты вебинаров)

Всё по интеграциям от GetAnalyst вы всегда можете найти в канале по хэштегу #ИнтеграцииGA 🙌


Прекрасных выходных!

💎 Заполненный шаблон реального интеграционного Use Case 💎

Готов итоговый файл Confluence с примером интеграционного Use Case:
👉 Авторассылка email по расписанию через интеграцию с Unisender

Внутри:
✅ микросервисная архитектура
✅ есть брокер Kafka
✅ задача запускается по cron (автоматически, по расписанию).

Всё на уровне системы, без участия пользователей.
Максимально подробный и детальный пример.


👉 Шаги для его создания:

1️⃣ Анализ API-документации внешней системы Unisender.

2️⃣ Тестирование API через Postman (можно другой инструмент),
чтобы понять, как API Unisender реально работает и его "подводные камни".

3️⃣* Обсудили алгоритмы авторизации запросов во внешние системы.
В случае Unisender можно отправить все настройки подключения в конфигурационный файл, а API-ключ туда же или в Key Store (хранилище ключей).

4️⃣ Встроили новую функциональность в архитектуру проекта
и показали это на схеме архитектуры C4/Container:
+ какие сервисы / микросервисы задействованы (если это не монолит)
+ какие БД используются
+ нужны ли брокеры в процессе
+ и другие детали

5️⃣ Знаем, что нужны задачи на доработку БД в МС Уведомлений,
чтобы хранить информацию о:
+ соответствии городов и их list_id в Unisender
+ какие пользователи (email) и на какие города подписаны для рассылки

6️⃣ Описали интеграционный Use Case (вер1),
используя полученный опыт работы с API, понимание архитектуры: зафиксировали, как будут перетекать данные между микросервисами системы.

7️⃣ Дополнили его UML Sequence диаграммой
и узнали, как её строить (в статье оставила ссылку на специальный AI-бот от GetAnalyst по генерации идеального кода PlantUML 😎).

8️⃣ Узнали что такое маппинг данных.
Добавила несколько таблиц маппинга в статью.

9️⃣ Зафиналила список задач на разработку.
В идеале ещё доделать предложенный список вложенных статей, но уже в этом виде разработчики могут начинать работу над задачей и остатки важной документации формировать сами!


Полезный образец для развития насмотренности и получения опыта 💎

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

🏆 Маппинг данных - что это и зачем? 🏆

Маппинг - это процесс сопоставления полей (данных) из одной системы с соответствующими полями в другой системе.
Это нужно, так как разные системы могут описывать один и тот же объект данных по-разному.

Этот процесс всегда необходим в задачах на интеграции.

Маппинг описывают в виде таблицы.
Допустимо делать и в виде структурированного списка, но по опыту - таблицы удобнее.


➡️ В таблице с маппингом делают несколько основных колонок:

- название параметра на разговорном языке;
- описание, требования к валидации, ФЛК (форматно-логический контроль) и преобразованиям, если это необходимо;
- названия параметра в API каждой системы (например, поле из JSON, поле из xml или другого формата сообщения, query из URL и др);
- название параметра в БД системы, если она есть в описании Use Case.
- типы данных в каждой системе / БД.

Допустима вариативность с колонками.
Их может быть больше, а может быть и меньше.


Если говорить про задачу на интеграцию системы #BookingGA с Unisender для подписки пользователей на рассылку, то 👉 таблица маппинга под часть задачи "чтение сообщения из топика Kаfka и добавление пользователя в лист контактов Unisender" 👉 будет содержать колонки:

- название поля на русском
- название поля в сообщении Kafka (JSON)
- название поля в БД Сервиса Уведомлений BookingGA, т.к. туда будет сохранена информация о подписке пользователя на город
- название параметра в API системы Unisender, куда будем отправлять данные о новом пользователе для листа контактов
- общее описание поля, требования к его обработке и проверкам
- типы данных в сообщении Kafka (JSON), API Unisender и БД. Я бы добавила только отдельную колонку “Тип данных в БД Уведомлений”. Все остальные типы данных не так важны или очевидны.


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

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

🤖 UML-диаграмма для интеграционного Use Case за 3 минуты: ChatGPT + PlantUML 🤖


🔗 Статья с инструкцией - пошаговый гайд с картинками и примерами


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

ChatGPT / DeepSeek - Искусственный Интеллект
PlantUML - Инструмент для создания любых UML-диаграмм через код


Инструкция по созданию UML Sequence:

1️⃣ Открой ChatGPT / DepSeek и войди аккаунт
Вход в аккаунт нужен, чтобы использовать улучшенную модель ИИ.

2️⃣ Выполни команду
Работай как опытный системный аналитик.
Сделай код для plantUML, чтобы создать UML Sequence диаграмму.
Не показывай альтернативные сценарии.

Сценарий:
<название сценария>

Пользователи и системы:
<участники сценария>

Описание сценария:
<описание Use Case>

Заполни название сценария и список участников (пользователи, фронтенды, бэкенды, внешние системы, БД).

Скопируй и вставь на место <описание Use Case> детализированный Use Case с описанием сценария интеграции.
Пример Use Case.

Отправь запрос к ChatGPT.

3️⃣ ChatGPT вернет в ответ код диаграммы для PlantUML

4️⃣ Вставь полученный код в PlantUML

5️⃣ Обязательно проверь и скорректируй результат:
5.1. Вручную поправь код по аналогии - это быстрее
5.2. Проси уточнения кода у ChatGPT дополнительными запросами


➕ Плюсы:
1. Диаграмма за 3+15 минут, с учетом проверки результатов.
2. Не надо писать код самому
3. Легко делать правки, т.к. диаграмма через код, и при любых правках всё двигается автоматически

➖ Минусы:
1. Use Case должен быть описан идеально. Без него диаграмму не сделать, либо будет много правок в придуманном ИИ варианте
2. ChatGPT / DeepSeek делает ошибки и за ними надо вносить правки
3. Лучше работает DeepSeek. Но и ChatGPT можно натренировать


🔗 Статья с инструкцией


❗️ Рекомендую использовать этот лайфхак только при знании и понимании нотации.
Для тех, кто только изучает UML, рекомендую использовать ИИ для проверок, но помните - он ошибается.


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

💥 UML-диаграммы для интеграций: Sequутce b 💥

Интеграционный UseCase написан.
Но возможно в нем много текста. Слишком много текста 😁
А разработчики много читать не любят.

Для быстрого понимания “о чем тут вообще” помогают картинки и схемы. Особенно, когда речь идет о сложных интеграционных сценариях.


➡️ UML Sequence
Прекрасным дополнением к интеграционному Use Case служит UML диаграмма последовательности.
UML-Sequence – это тип диаграммы, который показывает, как компоненты в системе взаимодействуют друг с другом в хронологическом порядке.
Диаграмма помогает быстрее разобраться не только в последовательности шагов, но и во взаимосвязях между компонентами системы, что особенно ценно при разработке и тестировании интеграций.

➡️ UML Activity
UML-Activity помогает визуализировать последовательность действий в процессе работы системы, показывая не только шаги, но и ветвления, условия, циклы. Может показывать системы и роли пользователей.
Визуально похожа на блок-схему.
Помогает показывать алгоритм работы системы.
Но используется реже, чем UML Sequence.


Диаграммы могут являться как дополнением, так и заменой текстового описания.
👍 Но текст алгоритмов всё же лучше держать рядом с диаграммами, как показазывает опыт.


Основные инструменты для построения UML-диаграмм:

Графические редакторы
🔸 Draw.io
🔸 Lucidchart
🔸 Miro
🔸 Microsoft Visio

Для создания диаграмм через код
🔸 PlantUML
🔸 MermaidChart



🖼 На картинках к посту показала обе диаграммы — UML Sequence и UML Activity.


Пример для процесса сброса пароля:
1. пользователь на переходит к экрану "Забыли пароль?",
2. вводит свой email,
3. получает письмо со ссылкой для сброса пароля на email.

👉 Обе созданы через код в PlantUML и описывают один и тот же процесс.

👉 Как читать:
+ UML Sequence: читайте строки по порядку, сверху-вниз, даже если следующая строка находится правее или левее.
+ UML Activity: двигайтесь сверху вниз, а при разветвлении (ромбы/многоугольники) сначала завершите читать одну ветку, затем другую.

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

В каждой шутке есть доля шутки 😱

С 1 апреля! Пусть ваше утро начнётся с хорошего настроения 🙃

#GAhahaha

📚 Пример реального интеграционного Use Case: с микросервисами, cron и kafka 📚

Интеграционный Use Case - это постановка задачи на разработчиков, которая содержит технические детали, такие как вызовы API методов, обращения к БД, взаимодействия с брокерами и другие.


👉 Основные шаги, чтобы написать интеграционный Use Case:

1️⃣ Понять отличия между обычными и интеграционными Use Case, да и вообще что это и зачем.

2️⃣ Декомпозировать интеграционную User Story (или бизнес-требования к интеграции) проекта на отдельные Use Case и выбрать тот, с которым будем работать.

3️⃣ Сделать анализ API-документации внешней системы.

4️⃣ Протестировать API внешней системы через Postman или другой инструмент, чтобы понять как она реально работает.

4️⃣* Сразу же продумать алгоритм авторизации запросов во внешнюю систему, где и как хранить ключи, как их использовать.

5️⃣ Понять, как будет встроена новая функциональность в архитектуру проекта и показать это на схеме:
+ какие сервисы / микросервисы задействованы (если это не монолит)
+ какие БД используются
+ нужны ли брокеры в процессе
+ и другие детали

6️⃣ Сделать задачи на доработку БД, если необходимо.

7️⃣ Описать интеграционный Use Case для разработчиков, используя:
+ полученный опыт работы с API


К посту прикрепила выгруженный из Confluence пример интеграционного Use Case для
Авторассылки email по расписанию через интеграцию с Unisender
в котором:
✅ микросервисная архитектура
✅ есть брокер Kafka
✅ задача запускается по cron (по расписанию, автоматически).
Т.е. всё на уровне системы, без участия пользователей.

Максимально подробный, детальный и реалистичный пример.
Остается добавить в него UML-диаграмму, маппинги данных и отсылки на дополнительные тех. задачи 😊

Сохраняем файл в личную библиотеку!
💯% пригодится!

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

⏳ Последний день доступа к записи обучения по интеграциям ⏳

📌Задача на Интеграцию: от Postman до требований в Confluence
🗓 доступ до 31 марта (пн), 23:59 Мск

Продлим до конца дня 1 апреля для всех, кто зарегистрировался до дня закрытия, и это не шутка 😏

👉 Получить доступ к записи

Ключевое, что выделили участники:
✅ Структурировали знания и восполнили пробелы в порядке работы с задачами на интеграцию
✅ Работа с GraphQL и WebSocket
✅ Предоставленные материалы
✅ Реальная практика


👉 Также напоминаем про старт практической программы для СА и БА по Проектированию Интеграций 2 апреля.


💬Обратная связь к занятию за выходные:

✍️ Анастасия
Прекрасная подача материала! Доходчиво в теории и подкрепляется практикой. Нигде не встречала подобного вебинара. Полезность 100 из 10.
Каждый раз актуальная информация и другие примеры для разбора, т.к. была уже не одном вебинаре и курсе от getanalyst, поэтому есть с чем сравнивать

✍️ Ксения
Это лучший вебинары по интеграциям!! Знаний больше, чем в платных курсах! Спасибо


✍️ Diana
Это был очень информативный вебинар, включая как теоретические так и практические аспекты. Особенно круто углублённое погружение непосредственно в практику, взаимодействие с чатом, ответы на вопросы. После вебинара остались только положительные впечатления, обнаружены пробелы и пути дальнейшего развития, спасибо!

✍️ Алексей
Подача материала динамичная пошагово просто о сложном

✍️ Анастасия
Отличная практика, здорово что углубились в websocket и graphQL

✍️ Александр
Крутой урок и материалы, буду использовать в работе, спасибо!

Большое количество благодарностей! 😊


В выходные продолжали подключать новых учеников к программе Проектирование Интеграций 👩‍💻

Им уже доступен модуль "Предобучение". А в эту среду откроем первый основной модуль, дадим ДЗ к первому занятию и доступ в Confluence.

Рады приветствовать всех участников!
Готовимся к продуктивной работе, коллеги! 🤝

💬 По вопросам о программе можно написать @getanalyst, на почту info@getanalyst.ru или заполнить заявку на сайте

Мы не обязаны всё знать.
Не обязаны быть самыми умными в комнате.
Не обязаны сразу разбираться в сложных задачах.

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

Когда ты среди таких людей — ты тоже растёшь.
Незаметно. Постепенно. Потому что мотивация в людях.

Там, где развитие — это норма, а незнание = повод двигаться вперёд, ты становишься лучшей версией себя каждый день.
Сопротивляться невозможно 🙌

💥 Виды API: GraphQL, gRPC, WebSocket 💥

⚡ GraphQL
Позволяет клиенту запрашивать только те данные, которые ему необходимы, с помощью декларативного языка запросов.

Удобен для сложных приложений с изменяемыми потребностями в данных, для мобильных приложений и микросервисов с целью оптимизации трафика между клиентом и сервером, который реализует API.

Пример документации:
Contentful


⚡ gRPC
Использует Protocol Buffers для сериализации данных и поддерживает как синхронные, так и асинхронные вызовы.

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

Пример документации:
Dropbox от Google


⚡ WebSocket
Обеспечивает двухстороннюю связь между клиентом и сервером в режиме реального времени.

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

Пример документации:
Binance Биржа


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

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

💥 Виды API: когда и какой выбрать 💥

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

Другими словами, если для взаимодействия пользователя и программы как правило используется пользовательский интерфейс (UI - User Interface), то для взаимодействия программы с другой программой используется программный интерфейс (API - Application Programming Interface).


Основные виды API:
⚡ REST
⚡ SOAP
⚡ GraphQL
⚡ gRPC
⚡ WebSocket


В деталях 👇

⚡ REST API (Representational State Transfer)
Использует HTTP-протокол и основывается на концепциях ресурсов и методов (GET, POST, PUT, PATCH, DELETE и другие).

Широко используется для веб-, мобильных приложений и микросервисной архитектуры.

Пример документации:
Wildberries


⚡ SOAP API (Simple Object Access Protocol)
Использует XML для обмена сообщениями и поддерживает сложные операции и стандарты безопасности.

Считается, что в основном применяется в корпоративных системах, требующих высокого уровня надежности и безопасности. Устаревает.

Современные средства безопасности на уровне инфраструктуры делают REST более приятным и менее тяжеловесным в использованию по сравнению с SOAP.

Пример документации:
PayPal (обратите внимание, что устаревший)


Самые интересные API с примерами документации чуть позже 👇

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

Таким важным вещам вообще блин не учат!
Этот отзыв после онлайн-практики получен вчера, после открытого урока в GetAnalyst. И это была только база. Ещё есть куда копать!


Благодарю вас за участие и работу на онлайн-практике Задача на Интеграцию: от Postman до требований в Confluence ❤️‍🔥


Эфир был проведен в качестве открытого урока практической программы
Интеграции систем
(следующий поток в сентябре 2025)


📈 Статистика:
+ 4 часа реальной работы
+ 2 000 сообщений в чате
+ больше 70% участников были от начала до конца! (о записи объявили сразу)
+ обратная связь 😍


Вот, что мы успели:

1️⃣ Познакомились с задачей и провели детальное исследование API-документации. Обсудили проблемы этого этапа и способы их решения.

2️⃣ Протестировали API в Postman:
👉 HTTP API, REST API, GraphQL и WebSocket.

3️⃣ Вместе восхищались особенностям, которые есть в GraphQL и WebSocket по сравнению с обычным REST.

4️⃣ Обсудили, почему аналитикам важно уметь работать с Postman: задачи интеграции часто содержат скрытые нюансы, а документация далеко не всегда охватывает все детали. Поэтому тестируем через него.

5️⃣ Показала как работать с шаблоном постановки задачи в Confluence.

6️⃣ Разобрали детальный интеграционный Use Case с:
+ API Gateway
+ Kafka для асинхронной работы
+ со всеми прелестями микросервисной архитектуры.
Теперь у участников есть
👉 заполненный образец сложной постановки задачи на интеграцию для Confluence.

7️⃣ Работали со сложными схемами архитектуры в C4 и строили UML через AI.


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


-----------------

‼️ Для тех, кто не был онлайн, либо отключился раньше:
+ пришлём запись в субботу утром всем, кто был зарегистрирован
+ доступ с 29 до 31 марта

+ тем, кто был зарегистрирован на основной эфир, ПОВТОРНО регистрироваться НЕ НАДО

👉 Регистрация тут

-----------------

Спасибо вам за яркие впечатления и проделанную работу! ❤️🔥❤️‍🔥

😂👍👍❤️👌😅😊😊😍😘

📹 Задача на Интеграцию: от Postman до требований в Confluence:

Вход в эфир:
🔗 https://pruffme.com/webinar/?id=19c886b9048d3a71662974fb0a88b909

Переходите по ссылке и начинаем!

❗️Встречаемся онлайн через 3 часа❗️

📹 Задача на Интеграцию: от Postman до требований в Confluence
⏰ 19:00 - 21:30 Мск

[ ЗАРЕГИСТРИРОВАТЬСЯ ]


-----------------------------------
Подготовка к практике:

Перед эфиром установите Postman и зарегистрируйте аккаунт в нём!
Попробуйте сделать Workspace и первую коллекцию.
Всё остальное покажем онлайн.

Инструкция по Postman с нуля
-----------------------------------

👉 Запись эфира будет доступна только для зарегистрировавшихся участников

📚 Виды Интеграций: полный справочник 📚

1. Синхронные по API (REST, SOAP, GraphQL и другие)
2. Асинхронные по API (Webhook, Polling)
3. Режим реального времени (WebSocket, SSE и другие)
4. Брокеры и очереди сообщений
5. Общая БД
6. Обмен файлами

Полезно иметь под рукой перед подготовкой к собеседованиям 🤝

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

⚡️ Уже завтра - в 19 Мск! Практический вебинар по Интеграциям ⚡️

💥 Задача на Интеграцию: от Postman до требований в Confluence
🗓 26 Марта, в 19:00 Мск (ср)
🔗 ЗАРЕГИСТРИРОВАТЬСЯ

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

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

👉 За один вечер:
✔️ Разберётесь в процессе работы с интеграциями.
✔️ Освоите на практике в Postman принципы работы с REST API, GraphQL и WebSocket.
✔️ Научитесь анализировать JSON-сообщения.
✔️ Узнаете какие диаграммы и зачем нужны в требованиях.
✔️ Проанализируете схему архитектуры в C4.
✔️ Построите UML Sequence с помощью AI-инструментов.
✔️ Получите шаблон постановки задачи для Confluence.
✔️ Узнаете, как избегать типичных ошибок в проектировании.

-----------------------------------
👉 Подготовка к практике:
Перед эфиром установите Postman и зарегистрируйте аккаунт в нём!
Попробуйте сделать Workspace и первую коллекцию.
Всё остальное покажем онлайн.
Инструкция по Postman с нуля
-----------------------------------

👉 Будет практика, разбор ошибок и ответы на вопросы. Не пропустите!

Предзапись на практическую программу Интеграции завершается сегодня

🗓 Старт: 2 апреля 2025
🎁 До 24 марта скидка + доп. обучение по БД в подарок

🔗 Подробности и регистрация

На проекте удаётся прожить самый настоящий опыт, со всеми “подводными камнями”, которые встречаются в реальной работе

В программе:
◽️ 10 живых онлайн-встреч
◽️ Работа над ОДНИМ проектом в течение всего обучения
◽️ Разбор всех этапов проектирования интеграций от А до Я на его примере
◽️ Возможность задать вопросы и получить обратную связь сразу

Ключевые темы:
🔸 определение точек интеграций в сложной системе,
🔸 REST API, GraphQL, SOAP API и другие способы интеграции систем,
🔸 работа в Postman,
🔸 архитектура систем, нотация C4,
🔸 интеграционные Use Case,
🔸 нотация UML,
🔸 маппинг данных,
🔹 ведение документации в Confluence,
🔹 создание и распределение задач на разработчиков.


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

🧑‍🔬🟠 Пошаговое руководство: как тестировать API Unisender в Postman 🟠🧑‍🔬

Пополняем ваше портфолио в Postman коллекцией API-запросов к открытому API Unisender.

Подготовила пошаговое руководство, которое поможет:
🔹 разобраться, как работает API Unisender на практике, даже если вы никогда не пользовались Postman;
🔹 увидеть, как API-запросы соотносятся с UI личного кабинета Unisender;
🔹 понять, что важно при вызове методов API Unisender, чтобы сделать интеграцию к этой системе.

В руководстве вы найдете:
✅ Начало работы в Postman: регистрация аккаунта и вход
✅ Создание Workspace и Collections для работы
✅ Регистрация аккаунта во внешней системе Unisender для получения доступа к API
✅ Тестирование API Unisender


Актуально как для тех, кто еще ни разу не работал с Postman, так и для тех, кто с ним работает постоянно.


💡❗️Опытным аналитикам обратить внимание:
1. Метод sendEmail поддерживает очень длинный URL — это важно учитывать при интеграции.
2. Хотя в гайде показала только POST-запросы, все методы также работают как GET — попробуйте.


👉 Сохраняйте гайд, пробуйте выполнить практику и делитесь результатами!

Ссылки на ваши Postman-коллекции по итогам выполнения всех шагов руководства буду рада видеть в комментариях 😉

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

Март 🌸🥰❤️‍🔥 Спасибо, что такой теплый, душевный и радостный!

Коллеги, искренне благодарю, что делитесь своими изменениями.

Даже пара строк "Я сделал...", "У меня получилось...", "Внедрил в проекте...", "Оффер 🕺💃" вдохновляют и вызывают чувство радости и гордости!

Всё читаю.
Всё вижу.
Всех помню!

#студентыGetAnalyst

🔥💥 Открытая онлайн-практика 26 марта | Интеграции систем 💥🔥

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

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


💥 Задача на Интеграцию: от Postman до требований в Confluence
🗓 26 Марта, в 19:00 Мск (ср)
🔗 ЗАРЕГИСТРИРОВАТЬСЯ


План:
1. Интеграции: порядок работы над задачами
2. Знакомство с задачей и анализ API-документации
3. Основы REST API: практика в Postman (+ мини-практика с GraphQL и WebSocket 😏)
4. Разработка интеграционного Use Case
5. UML-диаграммы + архитектурные схемы и их роль в требованиях
6. Формирование постановки задачи в Confluence


Эта практика — ваша возможность получить структурированные знания по интеграциям, освоить инструменты работы с API и уверенно двигаться дальше в профессии системного аналитика 💪


Регистрируйтесь, чтобы не пропустить!

🔑 Виды авторизации в API: что нужно знать? 🔑

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


Зачем нужна авторизация?

1️⃣ Защищает данные от утечек данных.

2️⃣ Исключает несанкционированный доступ к API, из-за которого могут украсть данные или записать “грязные” данные в систему.

3️⃣ Разграничивает права доступа (например, чтение данных vs редактирование).

4️⃣ Помогает отслеживать действия каждого клиента API.


Основные виды авторизации разобрала в слайдах к посту:

👍 API Key
👌 Basic Auth
❤️ Bearer Token
🦄 JWT (JSON Web Token)
🔥 OAuth 2.0

А какие способы авторизации используются в ваших проектах и интеграциях?
Делитесь в комментариях и ставьте реакции, соответствующие способу! 😊

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

⭐️ Интеграция с брокером Kafka в Микросервисной архитектуре: зачем СА понимать архитектуру проекта ⭐️

Чтобы сделать четкую и структурированную постановку задачи на интеграцию - технический Use Case (UC), сначала надо изучить архитектуру проекта.

👉 Это помогает:
1. Явно определять участников UC на каждом шаге
2. Понимать где, когда и какой API вызывать
3. Наглядно видеть потоки данных

Из огромной схемы архитектуры проекта #BookingGA, сделанной в рамках этой публикации, я выделила часть, которая связана с задачей:
Подключить Unisender, чтобы пользователи подписывались и получали рассылку по новым и выгодным объектам недвижимости в выбранном городе.


Далее обзорно рассказываю, как будут "ходить" запросы и данные по архитектуре для реализации задачи.


UC 1: Подписка на рассылку

1. Пользователь с Frontend подписывается на рассылку.

2. Frontend отправляет REST API запрос на подписку в Backend (API Gateway).

3. API Gateway перенаправляет запрос на сервис авторизации для проверки валидности токена.
Если успешно, то API Gateway проксирует запрос на сервис Управления Пользователями (УП), чтобы включить настройку.

4. Сервис УП сохраняет изменения настроек в своей БД и отправляет сообщение (JSON) в Kafka о новом подписчике.

Асинхронно, в фоновом режиме, Сервис Уведомлений:
4.1. Читает сообщение о подписке из Kafka.
4.2. Уточняет лист рассылок по БД, в который внести пользователя.
4.3. Отправляет запрос на подписку пользователя в Unisender.
4.4. Сохраняет в БД результат и делает отметку в Kafka об успешной обработке.


5. Сервис УП возвращает ответ об успешном включении подписки на API Gateway.

6. API Gateway возвращает ответ на Frontend, который отражает результат пользователю.



UC 2: Авторассылка новостей подписчикам
Начинается со срабатывания крона (задачи по расписанию), а далее расскажу в детальной постановке задачи 😉


Дополнительно:
🔗 Use Case для уведомлений о бронировании


Только после понимания как "ходят" данные в архитектуре, мы можем переходить к постановке задач на интеграции 🙌

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

🧑‍🔬🟠 Сначала исследовательское тестирование API в Postman, а потом сценарий интеграции 🟠🧑‍🔬

Прежде чем писать детализированный интеграционный Use Case, настоятельно рекомендую протестировать API, чтобы понять, как он работает, и убедиться, что документация соответствует реальности.


👉 Проверять важно только те методы, которые необходимы для работы системы.
Вообще всё по API-документации проверять не нужно.


Исследовательское тестирование API позволяет:
✅ Понять поведение API, особенно момент с работой авторизации запросов.
✅ Выявить расхождения между документацией и фактической реализацией API.
✅ Определить, какие данные реально передаются и принимаются.
✅ Понять, как API обрабатывает ошибки и исключения; найти то, что не задокументировано, чтобы продумать обработки на свои "узкие места" в сценарии.


🟠 Postman — главный инструмент аналитика для работы с API и проведения его исследовательского тестирования. А также один из ключевых навыков в резюме СА.

Если вы хотите работать с Backend-командами и понимать API, то без него никуда.

Он помогает проверять, как работают API-методы, не написав ни одной строчки кода.

С помощью Postman можно проверять:
+ REST API
+ GraphQL
+ gRPC
+ WebSocket
и другие виды API.

Чтобы познакомиться с инструментом в деле, предлагаю поработать с этими практическими руководствами:

🔗 Практическое руководство по Postman - тестирование API DaData (с нуля до результатов)

🔗 Postman: навык тестирования REST API за вечер

🔗 Знакомство с GraphQL на практике через Postman

Знание Postman — это не просто навык, а шаг к карьерному росту!
Он поможет вам разбираться в API на практике, уверенно работать с интеграциями и открыть двери в работу с Backend-командами 🤩

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

👀 Практика: анализ API-документации Unisender для email-рассылок. Часть 2 👀

В задаче для #BookingGA есть особенности, которые делают интеграцию сложной.

Они связаны с подбором методов под Use Cases для:
Еженедельной рассылки новостей о новых объектах недвижимости и выгодных предложениях

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


Часть 1. Подписка пользователей

✅ UC1. Создать лист контактов при создании нового города в справочнике Администратором
createList
Удаление и редактирование поддерживать пока не будем, хотя тоже можно.

✅ UC2. Добавление пользователя в лист контактов по городу при настройке подписки
subscribe
+ в процессе регистрации
+ в настройках уведомлений



Часть 2. Рассылка email

✅ UC3. Создать шаблон письма с новыми актуальными предложениями по городу
Редактировать существующий шаблон сообщения в Unisender:
updateEmailTemplate


✅ UC4. Сделать рассылку обновленного шаблона для выбранного города
+ вручную
+ автоматически, по крону (расписанию)
createEmailMessage - создать сообщение, используя шаблон, но не отправлять
createCampaign - запланировать или немедленно запустить рассылку на основе созданного сообщения



Часть 3. Отписка пользователей

✅ UC5. Отписать пользователя от рассылки на выбранный город
unsubscribe



Дополнительно:

✅ Подготовка стандартного сценария авторизации всех запросов к Unisender и типовой обработки ошибок

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

✅ Первичная настройка шаблонов и сопоставление их с городами в БД


---
UC = Use Case
---


👉 Итого:
+ 5 интеграционных Use Cases
+ 7 API-методов внешней системы
+ 3 тех.задачи

👉 Моменты, на которые стоит обратить внимание: UС4 с двумя API-методами, и сценарий авторизации, который аналитики забывают описывать.

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