Сегодня — последний день, когда вы можете пройти открытый урок:
⚙️ Интеграции по REST, GraphQL и WebSocket
⏳ Доступ до 23:59 (Мск)
Если узнали о нём только сейчас — подключайтесь!
Уже регистрировались? Дублировали ссылку с доступом на почту вчера 🙂
👉 Отзывы аналитиков, кто уже прошёл обучение по этому бесплатному уроку:
Ирина:
Мне кажется, что я скоро стану с вашими вебинарами senior еще не начав работать джуном. Огромное спасибо за ценнейшую информацию ❤️
Анастасия:
Столкнулась с API-интеграцией на работе, очень много встало на свои места в голове, стало гораздо понятнее пользоваться Postman и тестировать в нем методы. Огромная благодарность за интенсив!
Кристина:
Я новичок и только погружаюсь в тему интеграции и %80 пробелов закрыл ваш вебинар. Спасибо за подробное занятие
Алексей:
Очень приятное повествование, позволяет увидеть весь путь работы с интеграциями
Татьяна:
Очень понравилось занятие. Жаль, что не удалось присутствовать онлайн. Екатерина все подробно и понятно объясняет. Сравнивая с курсами, которые я проходила ранее, очень высокое качество подачи материала. Я в восторге! Большое спасибо за возможность смотреть подобные занятия в записи.
----------
👩🎓👨🎓 Этот урок - вводное занятие к практической программе Интеграции систем, которая начинается 8 октября.
А уже 15 октября мы встретимся на первой онлайн-встрече, где вы сможете:
+ познакомиться с проектом,
+ разобрать задание по интеграционным User Stories и Use Cases,
+ получить обратную связь и сразу применить знания.
----------
Смотрите открытый урок сейчас, чтобы уже сегодня получить новый опыт и структурировать имеющиеся знания! 🙌🎓
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍4
👷♂️ Воркер (worker) - что это, зачем, примеры, требования 👷♀️
Когда вы слышите от разработчиков слово "воркер", они имеют в виду фонового исполнителя задач, работающего отдельно от “основной” логики приложения.
👉 Воркер (worker) — это автономный процесс или механизм, который:
✔️ слушает очередь или получает задачи от планировщика / API / БД
✔️выполняет логику (обработка данных, интеграции и т.д.)
✔️может записывать статус в БД, отправлять обратный callback / сообщение, логировать ошибки, или перемещать задачу в DLQ
Главная идея - отделить тяжёлые, длительные или отложенные задачи от потока, который обслуживает пользователя, интерфейс или запросы, и положить в очередь, чтобы воркер обработал их позже, в фоне.
👉 Воркер может быть масштабируемым, запущенным в нескольких копиях, и работать независимо от основного приложения.
🧩 Как “воркер” вписывается в контекст отложенных задач:
▫️ В сценариях таймера / delay часто используется очередь + воркер: задача помещается с задержкой, воркер забирает её, когда пора, и исполняет.
▫️ В сценариях cron / шедулер — шедулер может генерировать задания (например, “надо что-то выполнить сейчас”) и отправлять их в очередь, воркер их обрабатывает.
▫️ В архитектуре, где много однотипных задач (например, массовые уведомления, аналитика, интеграции) воркеры — ключевой компонент, чтобы распределить нагрузку.
👉 Что важно учесть аналитику в требованиях:
1. Сколько воркеров может работать параллельно, можно ли масштабировать
2. Источник задач: из очереди, из таблицы БД, от планировщика
3. Идемпотентность, чтобы избежать дублирования выполнения задач
4. Обработка ошибок / retry / DLQ если задача "упала" — как её повторить или куда положить, чтобы выполнить попозже
5. Тайм-аут - сколько времени воркер может “висеть” на задаче
6. Изоляция - воркеры не должны мешать API (CPU, память, I/O)
7. Мониторинг и метрики
8. Как воркер запускается, перезапускается, обновляется. Важно, чтобы падения или деплой не остались без внимания
#ИнтеграцииGA #АрхитектураGA
Когда вы слышите от разработчиков слово "воркер", они имеют в виду фонового исполнителя задач, работающего отдельно от “основной” логики приложения.
👉 Воркер (worker) — это автономный процесс или механизм, который:
✔️ слушает очередь или получает задачи от планировщика / API / БД
✔️выполняет логику (обработка данных, интеграции и т.д.)
✔️может записывать статус в БД, отправлять обратный callback / сообщение, логировать ошибки, или перемещать задачу в DLQ
Главная идея - отделить тяжёлые, длительные или отложенные задачи от потока, который обслуживает пользователя, интерфейс или запросы, и положить в очередь, чтобы воркер обработал их позже, в фоне.
👉 Воркер может быть масштабируемым, запущенным в нескольких копиях, и работать независимо от основного приложения.
🧩 Как “воркер” вписывается в контекст отложенных задач:
▫️ В сценариях таймера / delay часто используется очередь + воркер: задача помещается с задержкой, воркер забирает её, когда пора, и исполняет.
▫️ В сценариях cron / шедулер — шедулер может генерировать задания (например, “надо что-то выполнить сейчас”) и отправлять их в очередь, воркер их обрабатывает.
▫️ В архитектуре, где много однотипных задач (например, массовые уведомления, аналитика, интеграции) воркеры — ключевой компонент, чтобы распределить нагрузку.
👉 Что важно учесть аналитику в требованиях:
1. Сколько воркеров может работать параллельно, можно ли масштабировать
2. Источник задач: из очереди, из таблицы БД, от планировщика
3. Идемпотентность, чтобы избежать дублирования выполнения задач
4. Обработка ошибок / retry / DLQ если задача "упала" — как её повторить или куда положить, чтобы выполнить попозже
5. Тайм-аут - сколько времени воркер может “висеть” на задаче
6. Изоляция - воркеры не должны мешать API (CPU, память, I/O)
7. Мониторинг и метрики
8. Как воркер запускается, перезапускается, обновляется. Важно, чтобы падения или деплой не остались без внимания
#ИнтеграцииGA #АрхитектураGA
❤27🔥6👍1
[GetAnalyst] Интеграционный API-метод.pdf
930.5 KB
Работая с задачами на интеграцию, важно помнить, что в процесс вовлечены сразу несколько частей системы:
▫️Frontend – пользовательский интерфейс. Он не всегда есть в интеграционных задачах, но если присутствует, то выполняет роль инициатора запросов.
▫️Backend – серверное приложение, которое отвечает за логику обработки данных, их проверку и взаимодействие с внешними системами.
▫️Внешняя система – источник или получатель данных, с которым взаимодействует наш Backend.
❗️ Для обеспечения безопасности, большинство интеграций реализуется через Backend.
Для этого создают интеграционные API-методы.
👉 Интеграционный API-метод – это метод на стороне нашего Backend, который:
+ принимает запросы от Frontend-приложения;
+ взаимодействует с внешней системой для получения или записи данных;
+ реализует логику сопоставления (маппинга) и обработку данных.
Почему используется интеграционный API-метод, а не прямое обращение к внешней системе с Frontend?
✅ Централизованное хранение данных:
Backend является центром хранения актуальных данных. Все изменения, включая удаление задач, должны проходить через него, чтобы данные оставались актуальными.
✅ Безопасность:
Хранить секретные ключи на стороне Frontend небезопасно – они могут быть скомпрометированы (например, перехвачены через консоль браузера). Размещение ключей на Backend исключает этот риск.
Пример алгоритма работы интеграционного API-метода разобрала в мини-книге к посту 🤝
#ИнтеграцииGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18🔥7❤🔥4
GetAnalyst_Воркер_для_рассылки_email_о_событиях_через_DashaMail.pdf
1.5 MB
📚 Заполненные шаблоны требований из Confluence к интеграции с участием крона, воркера, брокера Kafka 📚
В сентябре мы проектировали интеграцию для сценария авторассылок для пользователей о мероприятиях в #CityGA:
▫️ мероприятия - из KudaGo
▫️ email-рассылки - через DahaMail
Что получилось:
👉 Вводный пост о проекте
1. Описали архитектуру в C4 — зафиксировали компоненты и точки интеграции для сценария
2. Исследовали API KudaGo
3. Исследовали API DashaMail
4. Провели исследовательское тестирование API KudaGo и DashaMail - оформили пошаговый гайд с примерами
5. Сделали верхнеуровневый интеграционный Use Case
6. Разработали UML-Sequence диаграмму для описанного Use Case
🎁 Тут бесплатный AI-бот + руководство по UML
7. Сделали постановку задачи в Confluence: запуск по cron (scheduler) → выгрузка из KudaGo API → формирование сообщения в Kafka.
8. Сделали маппинг данных (API ↔︎ БД ↔︎ сообщения)
9. Уточнили термины: крон, шедулер, воркер
И между делом публиковали много дополнительных материалов и книг, чтобы вы лучше разобрались с интеграциями 🤝
👉 В этом посте делимся финальными постановками задач из Confluence:
✅📑 Срабатывание крона и авто-выгрузка мероприятий из KudaGo API
✅📑 Рассылка уведомлений через DashaMail API
❗️ Сохраняйте этот сводный пост по проекту #CityGA с готовыми аналитикой и шаблонами требований на интеграции.
Пригодится, когда встретите похожую задачу.
Проект #CityGA на текущей стадии завершён 🥳
Материалы разработаны в поддержку практической программы Интеграции систем для СА и БА 🧩
#ИнтеграцииGA
В сентябре мы проектировали интеграцию для сценария авторассылок для пользователей о мероприятиях в #CityGA:
▫️ мероприятия - из KudaGo
▫️ email-рассылки - через DahaMail
Что получилось:
👉 Вводный пост о проекте
1. Описали архитектуру в C4 — зафиксировали компоненты и точки интеграции для сценария
2. Исследовали API KudaGo
3. Исследовали API DashaMail
4. Провели исследовательское тестирование API KudaGo и DashaMail - оформили пошаговый гайд с примерами
5. Сделали верхнеуровневый интеграционный Use Case
6. Разработали UML-Sequence диаграмму для описанного Use Case
🎁 Тут бесплатный AI-бот + руководство по UML
7. Сделали постановку задачи в Confluence: запуск по cron (scheduler) → выгрузка из KudaGo API → формирование сообщения в Kafka.
8. Сделали маппинг данных (API ↔︎ БД ↔︎ сообщения)
9. Уточнили термины: крон, шедулер, воркер
И между делом публиковали много дополнительных материалов и книг, чтобы вы лучше разобрались с интеграциями 🤝
👉 В этом посте делимся финальными постановками задач из Confluence:
✅📑 Срабатывание крона и авто-выгрузка мероприятий из KudaGo API
✅📑 Рассылка уведомлений через DashaMail API
❗️ Сохраняйте этот сводный пост по проекту #CityGA с готовыми аналитикой и шаблонами требований на интеграции.
Пригодится, когда встретите похожую задачу.
Проект #CityGA на текущей стадии завершён 🥳
Материалы разработаны в поддержку практической программы Интеграции систем для СА и БА 🧩
#ИнтеграцииGA
🔥24👍8❤7❤🔥1🤔1
🤖 5 AI-инструментов, которые рекомендуем знать аналитикам к 2026 году, чтобы ускорять свою работу и быть востребованными на рынке 🤖
👉 ChatGPT
Работа с требованиями, ТЗ, ФТ, БТ, НФТ, Use Cases и тд. Ответы на сообщения и email.
В общем любые тексты, которые делает аналитик. Нейросеть идеальна для их создания и улучшения.
Рекомендуется использовать режим GPT-5 Thinking.
👉 Gemini
+ написание SQL-запросов,
+ код для plantUML, чтобы делать UML-диаграммы,
+ проектирование БД через код, например код для dbdiagram.io или SQL-скрипты,
+ проектирование API методов (json/xml/и тд).
Всё, что касается "кода" от аналитиков - сюда.
👉 Claude
Работа с большими контекстами, обработка длинных документов и получение сути из них, анализ логов.
Пример: сжать 30-страничный документ до 1 страницы.
👉 Cursor AI
Разработка собственного кода для приложений, создание прототипов.
Рекомендуемый язык программирования: Python.
Инструмент для продвинутых аналитиков, кто хочет больше, чем просто писать требования.
Полезно для личных проектов за пределами работы.
👉 DeepSeek
Инструмент для всего.
Умеет всё, что и интрументы выше, но на среднем уровне.
Эти 5 инструментов помогают со стандартными задачами, которые ежедневно решают системные и бизнес-аналитики.
Если пока знакомы не со всеми, то рекомендуем попробовать каждый, сравнить результаты и выбрать наиболее удобный и подходящий под ваши задачи.
❗️ Важно:
+ Проверяйте результаты за AI, он не всегда прав.
+ AI не может вас заменить, но может сделать вас эффективнее.
Хотите закрывать свои задачи быстрее?
Делайте шаги в сторону AI сегодня и уже в 2026 вместе с GetAnalyst сможете выполнять свою работу быстрее 🙌
👉 ChatGPT
Работа с требованиями, ТЗ, ФТ, БТ, НФТ, Use Cases и тд. Ответы на сообщения и email.
В общем любые тексты, которые делает аналитик. Нейросеть идеальна для их создания и улучшения.
Рекомендуется использовать режим GPT-5 Thinking.
👉 Gemini
+ написание SQL-запросов,
+ код для plantUML, чтобы делать UML-диаграммы,
+ проектирование БД через код, например код для dbdiagram.io или SQL-скрипты,
+ проектирование API методов (json/xml/и тд).
Всё, что касается "кода" от аналитиков - сюда.
👉 Claude
Работа с большими контекстами, обработка длинных документов и получение сути из них, анализ логов.
Пример: сжать 30-страничный документ до 1 страницы.
👉 Cursor AI
Разработка собственного кода для приложений, создание прототипов.
Рекомендуемый язык программирования: Python.
Инструмент для продвинутых аналитиков, кто хочет больше, чем просто писать требования.
Полезно для личных проектов за пределами работы.
👉 DeepSeek
Инструмент для всего.
Умеет всё, что и интрументы выше, но на среднем уровне.
Эти 5 инструментов помогают со стандартными задачами, которые ежедневно решают системные и бизнес-аналитики.
Если пока знакомы не со всеми, то рекомендуем попробовать каждый, сравнить результаты и выбрать наиболее удобный и подходящий под ваши задачи.
❗️ Важно:
+ Проверяйте результаты за AI, он не всегда прав.
+ AI не может вас заменить, но может сделать вас эффективнее.
Хотите закрывать свои задачи быстрее?
Делайте шаги в сторону AI сегодня и уже в 2026 вместе с GetAnalyst сможете выполнять свою работу быстрее 🙌
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥41❤🔥8❤4🤩3🤯1🦄1
Forwarded from 👩🏻💻 Подкаст Системных Аналитиков | GetAnalyst
Надоели бесконечные созвоны и непонятные встречи? Или вы только начинаете карьеру аналитика и хотите разобраться, какие мероприятия вообще есть в Scrum и зачем они нужны?
В этом эпизоде мы разбираем все ключевые события Scrum — планирование, дейли, обзоры, ретроспективы и груминг. Делимся своим опытом, ошибками и лучшими практиками, чтобы вы могли увидеть, как это работает в реальных командах и применить полезное в своей работе.
Подойдёт и новичкам, которые хотят погрузиться в атмосферу IT-разработки, и опытным аналитикам, которые ищут свежий взгляд и инсайты для улучшения своих процессов.
Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video
Переходите в GetAnalyst и получайте опыт в системном анализе и архитектуре каждый день! 🙌
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18❤5
👩🎓 Меня зачислили в Университет Джонса Хопкинса (JHU) на Applied Generative AI 🥳
Часть знаний по внедрению AI я уже получила в Гарварде. Но мне этого не хватило. Хочется ещё больше в глубину, понимать техническую часть и уметь делать всё самой, без разработчиков. Так как специалистов в AI пока очень мало.
Итог:
💥 снова студентка на ближайшие 6 месяцев
💥 буду прокачивать программирование на Python
💥 к концу обучения — AI Engineer
Учёба уже началась. Минус ~10-12 часов отдыха в неделю.
Объём новой информации ошеломляет: сразу и код, и сложная терминология, и архитектура AI-систем, много-много нового.
Это радостно и страшно одновременно 😄
Но это именно то, что я искала. Чувствую себя тупой))
На занятиях, задаю вопросы и разбираюсь с основами работы AI, делаем первые крутые практики, и я кайфую 🤗
P.S.
Вместе с этой новостью уже хочется приоткрыть завесу. Я создаю новую программу - AI акселлератор для СА и БА.
Пока можно только записться в лист ожидания.
Собираю лучший опыт работы с AI как системный аналитик. Также буду немного погружать и вас в разработку на Python. Оказывается полезно))
Коллеги, буду делиться с вами своим прогрессом и идеями. И конечно, новыми инструментами! 🔥 А если у вас уже есть вопросы по AI - пишите в комментарии))
Часть знаний по внедрению AI я уже получила в Гарварде. Но мне этого не хватило. Хочется ещё больше в глубину, понимать техническую часть и уметь делать всё самой, без разработчиков. Так как специалистов в AI пока очень мало.
Итог:
💥 снова студентка на ближайшие 6 месяцев
💥 буду прокачивать программирование на Python
💥 к концу обучения — AI Engineer
Учёба уже началась. Минус ~10-12 часов отдыха в неделю.
Объём новой информации ошеломляет: сразу и код, и сложная терминология, и архитектура AI-систем, много-много нового.
Это радостно и страшно одновременно 😄
Но это именно то, что я искала. Чувствую себя тупой))
На занятиях, задаю вопросы и разбираюсь с основами работы AI, делаем первые крутые практики, и я кайфую 🤗
P.S.
Вместе с этой новостью уже хочется приоткрыть завесу. Я создаю новую программу - AI акселлератор для СА и БА.
Пока можно только записться в лист ожидания.
Собираю лучший опыт работы с AI как системный аналитик. Также буду немного погружать и вас в разработку на Python. Оказывается полезно))
Коллеги, буду делиться с вами своим прогрессом и идеями. И конечно, новыми инструментами! 🔥 А если у вас уже есть вопросы по AI - пишите в комментарии))
❤🔥99🔥69❤16👍7🎉5👏3🤩2🤯1👌1🤣1
На каждом собеседовании для системных аналитиков звучат вопросы про REST API. От джуна до сеньора 🙌
Но ответить на него невозможно, если не понимать, как работает протокол HTTP.
REST API — это архитектурный стиль, использующий HTTP в качестве протокола передачи данных (или: основанный на протоколе HTTP).
HTTP
— это протокол прикладного уровня, используемый для передачи данных между клиентом и сервером в Интернете.
И чтобы вы действительно поняли значение слов “архитектурный стиль”, когда мы в следующих постах будем подробнее разбирать определение REST API, я хочу рассказать про протокол HTTP.
Всё самое важное на картинках к посту ☝️
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥27❤8👍6❤🔥4👎1🤣1
💻 Когда Системный Аналитик работает с 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" в вакансиях Системных Аналитиков, полезно понимать, что может за этим скрываться.
Предлагаю чек-лист, который вы всегда можете применить, чтобы оценить свой текущий круг обязанностей и то, что может ожидать вас в будущих проектах
👉 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
Please open Telegram to view this post
VIEW IN TELEGRAM
❤29👍11❤🔥2🔥2
🎯 [13.10 в 19Мск] Практика SQL-запросов в реальной БД через DBeaver 🎯
В следующий понедельник проводим продвинутый онлайн-практикум по БД и SQL:
🎯 Инструмент DBeaver. Практика SQL-запросов
🗓 13 Октября 2025 (пн)
🕖 19:00 Мск
👉 Подробности и регистрация
🤝 Доступ к записи
на следующий день, для всех подключенных участников.
🎁 Актуальный бонус
доступ к записи занятия "Оптимизация БД. Работа с индексами в БД".
План:
1*. Знакомство с инструментом DBeaver. Подключение тестовой БД
2*. О применении SQL аналитиками. Ключевые операторы SQL-запросов.
3. Практика SQL-запросов на получение данных в DBeaver.
4. Использование AI (искусственного интеллекта) в качестве помощника в работе с SQL
* - самостоятельная подготовка по видео-уроку в платформе, на занятии максимально практикуемся с SQL
Практикум подойдёт, если вы:
✔️ умеете читать ER-диаграммы,
✔️ хотите освоить SQL с нуля, на практике,
✔️ и хотите упрощать свою жизнь с использованием AI при работе с SQL.
👉 Материалы по БД для знакомства и подготовки к онлайн-практикуму по DBeaver + SQL:
🔗 Обучающее видео "Проектирование БД - логический уровень"
🔗 Статья "зачем БД аналитику"
🔗 Статья о возможностях DBeaver
До встречи! 😉
Вопросы по практикуму можно написать @getanalyst (или на почту info@getanalyst.ru)
В следующий понедельник проводим продвинутый онлайн-практикум по БД и SQL:
🎯 Инструмент DBeaver. Практика SQL-запросов
🕖 19:00 Мск
👉 Подробности и регистрация
🤝 Доступ к записи
на следующий день, для всех подключенных участников.
🎁 Актуальный бонус
доступ к записи занятия "Оптимизация БД. Работа с индексами в БД".
План:
1*. Знакомство с инструментом DBeaver. Подключение тестовой БД
2*. О применении SQL аналитиками. Ключевые операторы SQL-запросов.
3. Практика SQL-запросов на получение данных в DBeaver.
4. Использование AI (искусственного интеллекта) в качестве помощника в работе с SQL
* - самостоятельная подготовка по видео-уроку в платформе, на занятии максимально практикуемся с SQL
Практикум подойдёт, если вы:
✔️ умеете читать ER-диаграммы,
✔️ хотите освоить SQL с нуля, на практике,
✔️ и хотите упрощать свою жизнь с использованием AI при работе с SQL.
👉 Материалы по БД для знакомства и подготовки к онлайн-практикуму по DBeaver + SQL:
До встречи! 😉
Вопросы по практикуму можно написать @getanalyst (или на почту info@getanalyst.ru)
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13❤🔥1
🔐 Разница между HTTP и HTTPS 🔐
Это один из наиболее частых вопросов, которые я встречаю на занятиях про API от наших студентов. Его же спрашивают на собеседованиях. Поэтому давайте разберёмся, в чём же отличия.
HTTP - это протокол прикладного уровня.
Он включает в себя варианты использования:
👉 HTTP — данные идут «в открытом виде»
Любой, кто перехватил трафик, увидит весь запрос и ответ как текст.
Если трафик в HTTP (незащищённый), то перехватчик сможет видеть:
🔺 Полный URL (включая query-параметры)
🔺 Все HTTP-заголовки (включая Authorization, Cookie, User-Agent)
🔺 Тело запроса/ответа — JSON, формы, файлы.
❗️ То есть любые передаваемые пароли, токены, номера карт, персональные данные будут перехвачены.
👉 HTTPS — тот же HTTP поверх шифрованного канала TLS
Перехватчик трафика не увидит содержимого запросов и ответов - оно зашифровано, он увидит только:
🔺 линию связи: IP-адрес сервера, порт (обычно 443), объём и тайминги пакетов.
🔺 может увидеть SNI (Server Name Indication) - имя хоста, переданное открыто в TLS ClientHello (в большинстве реализаций)
🔺 НЕ видит содержимое заголовков и тела запросов - они зашифрованы. Токены/пароли/JSON недоступны.
❗️ При перехвате трафика все персональные данные будут защищены.
👉 Как перехватывают трафик?
⚪ Открытая Wi-Fi сеть (public hotspot)
Пользователь подключается к общему Wi-Fi, злоумышленник в той же сети запускает сниффер.
Без HTTPS — все данные видно.
С HTTPS — трафик зашифрован.
⚪ Компрометация роутера / провайдера
Подменённый DNS или перенаправление на прокси. Может потребоваться поддельный сертификат.
⚪ Браузерные расширения / вредоносное ПО
Может читать/перехватывать запросы на клиенте до шифрования (например, JS-обработчики, extensions).
⚪ Атакующий выдает себя за шлюз в локальной сети (ARP poisoning) и проксирует (перенаправляет) трафик через себя.
⚪ И другие способы атак.
Без них HTTPS просто не сможет работать и будет просто HTTP.
#RestApiGA #АрхитектураGA
Это один из наиболее частых вопросов, которые я встречаю на занятиях про API от наших студентов. Его же спрашивают на собеседованиях. Поэтому давайте разберёмся, в чём же отличия.
HTTP - это протокол прикладного уровня.
Он включает в себя варианты использования:
👉 HTTP — данные идут «в открытом виде»
Любой, кто перехватил трафик, увидит весь запрос и ответ как текст.
Если трафик в HTTP (незащищённый), то перехватчик сможет видеть:
🔺 Полный URL (включая query-параметры)
🔺 Все HTTP-заголовки (включая Authorization, Cookie, User-Agent)
🔺 Тело запроса/ответа — JSON, формы, файлы.
❗️ То есть любые передаваемые пароли, токены, номера карт, персональные данные будут перехвачены.
👉 HTTPS — тот же HTTP поверх шифрованного канала TLS
Перехватчик трафика не увидит содержимого запросов и ответов - оно зашифровано, он увидит только:
🔺 линию связи: IP-адрес сервера, порт (обычно 443), объём и тайминги пакетов.
🔺 может увидеть SNI (Server Name Indication) - имя хоста, переданное открыто в TLS ClientHello (в большинстве реализаций)
🔺 НЕ видит содержимое заголовков и тела запросов - они зашифрованы. Токены/пароли/JSON недоступны.
❗️ При перехвате трафика все персональные данные будут защищены.
👉 Как перехватывают трафик?
⚪ Открытая Wi-Fi сеть (public hotspot)
Пользователь подключается к общему Wi-Fi, злоумышленник в той же сети запускает сниффер.
Без HTTPS — все данные видно.
С HTTPS — трафик зашифрован.
⚪ Компрометация роутера / провайдера
Подменённый DNS или перенаправление на прокси. Может потребоваться поддельный сертификат.
⚪ Браузерные расширения / вредоносное ПО
Может читать/перехватывать запросы на клиенте до шифрования (например, JS-обработчики, extensions).
⚪ Атакующий выдает себя за шлюз в локальной сети (ARP poisoning) и проксирует (перенаправляет) трафик через себя.
⚪ И другие способы атак.
Чтобы обеспечить работу HTTPS, на сервер должны установить сертификаты SSL/TLS
Без них HTTPS просто не сможет работать и будет просто HTTP.
#RestApiGA #АрхитектураGA
👍34❤20🔥10❤🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
🔐 SSL/TLS-сертификаты для обеспечения HTTPS 🔐
Чтобы обеспечить безопасное HTTPS соединение и защититься от перехвата трафика, на сервере должны быть установлены SSL/TLS-сертификаты.
👉 SSL/TLS-сертификат - это цифровой документ, который:
▫️ подтверждает подлинность сервера (что api.company.com это действительно ваш сервер, а не подделка),
▫️ содержит публичный ключ для шифрования данных при установлении TLS-соединения.
Когда клиент заходит по https://.., он получает этот сертификат и проверяет его подлинность через цепочку доверенных центров сертификации (CA — Certificate Authority)
👉 Центр сертификации - это доверенная организация, которая подтверждает подлинность домена или компании и выдаёт цифровые сертификаты (SSL/TLS).
Каждая операционная система (Windows, macOS, Android и др) и каждый браузер имеет внутри себя список доверенных корневых сертификатов (Root CA).
Это десятки (иногда сотни) организаций:
+ DigiCert
+ GlobalSign
+ Let’s Encrypt
+ GoDaddy
и др.
📦 Этот список устанавливается вместе с системой и регулярно обновляется вместе с обновлением браузера или ОС.
👉 Что происходит, когда ты заходишь на HTTPS://getanalyst.ru, у которого есть SSL/TLS?
1️⃣ Клиент (Postman, браузер, моб. приложение) устанавливает TCP-соединение с сервером (порт 443)
2️⃣ Сервер отправляет свой сертификат (в нём: имя домена, срок действия, кто выдал и т.д.)
3️⃣ Клиент проверяет подпись этого сертификата
👉 Что происходит, когда ты заходишь на HTTP://getanalysts.com?
Браузер сообщает, что соединение небезопасно
📌 Что можно написать в ТЗ про проверку HTTPS (SSL/TLS), в задачах на интеграции по API:
✅ Все внешние и внутренние интеграции - только по HTTPS (TLS ≥ 1.2, желательно TLS 1.3)
✅ Валидировать сертификаты на стороне клиента; логировать certificate errors
✅ Использовать mTLS для сервер-серверных вызовов критичных API (для повышенной безопасности)
✅ Не передавать секреты или CVV в query-параметрах (в URL) - только в теле по HTTPS
✅ Логировать подозрительную активность авторизаций
#RestApiGA #АрхитектураGA
Чтобы обеспечить безопасное HTTPS соединение и защититься от перехвата трафика, на сервере должны быть установлены SSL/TLS-сертификаты.
👉 SSL/TLS-сертификат - это цифровой документ, который:
▫️ подтверждает подлинность сервера (что api.company.com это действительно ваш сервер, а не подделка),
▫️ содержит публичный ключ для шифрования данных при установлении TLS-соединения.
Когда клиент заходит по https://.., он получает этот сертификат и проверяет его подлинность через цепочку доверенных центров сертификации (CA — Certificate Authority)
👉 Центр сертификации - это доверенная организация, которая подтверждает подлинность домена или компании и выдаёт цифровые сертификаты (SSL/TLS).
Каждая операционная система (Windows, macOS, Android и др) и каждый браузер имеет внутри себя список доверенных корневых сертификатов (Root CA).
Это десятки (иногда сотни) организаций:
+ DigiCert
+ GlobalSign
+ Let’s Encrypt
+ GoDaddy
и др.
📦 Этот список устанавливается вместе с системой и регулярно обновляется вместе с обновлением браузера или ОС.
👉 Что происходит, когда ты заходишь на HTTPS://getanalyst.ru, у которого есть SSL/TLS?
1️⃣ Клиент (Postman, браузер, моб. приложение) устанавливает TCP-соединение с сервером (порт 443)
2️⃣ Сервер отправляет свой сертификат (в нём: имя домена, срок действия, кто выдал и т.д.)
3️⃣ Клиент проверяет подпись этого сертификата
👉 Что происходит, когда ты заходишь на HTTP://getanalysts.com?
Браузер сообщает, что соединение небезопасно
📌 Что можно написать в ТЗ про проверку HTTPS (SSL/TLS), в задачах на интеграции по API:
✅ Все внешние и внутренние интеграции - только по HTTPS (TLS ≥ 1.2, желательно TLS 1.3)
✅ Валидировать сертификаты на стороне клиента; логировать certificate errors
✅ Использовать mTLS для сервер-серверных вызовов критичных API (для повышенной безопасности)
✅ Не передавать секреты или CVV в query-параметрах (в URL) - только в теле по HTTPS
✅ Логировать подозрительную активность авторизаций
#RestApiGA #АрхитектураGA
🔥21❤🔥5❤4👍4🤩1