GetAnalyst - Навыки • Системный анализ • Бизнес-анализ

💚 Swagger - Open API - Практическое руководство. Часть 3 💚

Ранее опубликовано:
🔗 Часть 1. Регистрация аккаунта и создание демо-проекта
🔗 Часть 2. Создание собственного проекта и работа с базовыми настройками, первые строки кода

В этом посте:
👉 Часть 3. Описание методов POST и GET по спецификации OpenAPI
файл прикреплен к посту

Что внутри:
✔️ Разберетесь с блоками кода paths и components в OpenAPI
✔️ Получите готовый документ API-документации для личного портфолио с двумя описанными методами
✔️ Получите реальный опыт работы со Swagger / OpenAPI

⏳ Время на изучение и практику:
🕓 60 минут — на работу с заданиями строго по руководству, где есть подсказки по каждому шагу
🕓 +60 минут, если хотите выполнить ДЗ и создать личный демо-проект для портфолио


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

#RestApiGA

🔥 Практическая программа по Архитектуре для СА стартует 4 марта: открыли предзапись 🔥

Погружение в архитектуру, опыт работы в сложных проектах с микросервисами и брокерами - точки роста для опытных системных аналитиков уровня Middle+.

Чтобы помогать вам достигать максимального уровня в карьере, мы создали практическую программу “Архитектура систем”.

В ходе работы на ней мы будем:
✔️ Строить архитектуру проекта с нуля: монолит, сервисная, микросервисная.
✔️ Практиковаться работать с нотацией C4.
✔️ Подбирать API для проекта и учиться работать с ними на практике: REST, GraphQL, WebSocket и другие.
✔️ Ставить задачи на брокеры (Kafka, RabbitMQ), Webhooks, и знакомиться с другими способами асинхронного взаимодействия систем.

Собрали всё, что нужно для проектирования систем на самом глубоком техническом уровне для аналитиков.


Цели, которые ставят и реализуют наши аналитики в процессе обучения:
✅ Повышают грейд внутри компании
✅ Переходят из проектной разработки в продукт
✅ Структурируют знания и проходят аттестации
✅ Получают повышения
✅ Проходят собеседования и выбирают офферы по душе 🩷


Приглашаем и вас достигать новые цели вместе с нами! 🙌

🌟 Проектирование архитектуры
🗓 Старт: 4 марта 2025
👉 Подробности о программе и заявка на участие


🎁 До 25 февраля открыта предзапись на специальных условиях:
скидка + дополнительное обучение по проектированию REST API в подарок.

Вопросы можно задать через сайт, на почту [email protected] или в Telegram @getanalyst.

🏠 Новый проект: микросервисная архитектура для платформы аренды недвижимости #BookingGA 🏠

Теорию надо закреплять на практике. Только так реально разобраться во всей сложной

👉 В этом месяце мы проектируем архитектуру для проекта BookingGA.

Покажу вам три варианта реализации архитектуры:
+ Монолит
+ SOA
+ MSA


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

Основные функции платформы:
✔️ Поиск недвижимости для аренды.
✔️ Бронирование жилья — моментальное подтверждение или с подтверждением владельцем после бронирования.
✔️ Электронный договор аренды — автоматическая генерация сразу после оплаты, электронное подписание обеими сторонами и хранение документов в PDF.
✔️ Безопасные платежи — интеграция с платёжными системами, депозиты, автоматическое списание средств за аренду.
✔️ Верификация владельцев и арендаторов — проверка документов, права собственности.
✔️ Отзывы и рейтинги — оценки арендаторов и хозяев, история аренд.
✔️ Управление объявлениями — возможность владельцев редактировать, деактивировать, продвигать объявления.
✔️ Поддержка пользователей — чат с техподдержкой, система обращений.

Для пользователей будут разработаны приложения на iOS, Android и Web. Владельцы смогут управлять объектами через веб-приложение. Панель администратора поможет тех. поддержке и администраторам модерировать систему.


План работы:
0️⃣ Расскажу про нотацию C4
1️⃣ Покажу архитектуру монолита в нотации C4
2️⃣ Научу выделять сервисы и микросервисы
3️⃣ Покажу архитекту SOA и MSA в нотации C4
4️⃣ Выберем технологии для обмена данными — REST API, gRPC, GraphQL и другие
5️⃣ Посмотрим когда и зачем нужны брокеры Kafka и RabbitMQ, встроим в архитектуру


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

Стартуем отсюда, и следим за постами с хэштегом #BookingGA! 🙂

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

📄 Про собеседования, резюме и вилки ЗП 📄

Проходить собеседования - тоже навык, и его надо оттачивать.

Но эту тему я почти не поднимаю в канале, так как я больше "суровый технарь", который передаёт технические навыки и опыт работы 😁

А чтобы всегда быть в курсе, как пройти через HR на техническое собеседование и самопрезентовать себя, понимать, как менять карьеру и тактично спрашивать о большей ЗП.

Я рекомендую посмотреть подборку материалов, не моего авторства, по резюме, собеседованиям и оценке своей ЗП:

🔴Ключевые лайфхаки по резюме и его ОШИБКИ
🔴Нужны ли сопроводительные и что там писать
🔴Как отвечать на вопрос «Расскажите о себе»
🔴Как вести себя с неадекватом на собесе
🔴Как рассказывать о своем факапе?
🔴Какие книги почитать в т.ч. для успешного прохождения собеседований?
🔴Реальные примеры офферов бизнес и системным аналитиков до 500к

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

✨ Монолит ⚔ Сервисы (SOA) ⚔ Микросервисы (MSA) ✨


👉 Архитектура

◽️ Монолит:
Один большой блок - единая кодовая база Backend.
Вся логика в одном месте.

🟡 SOA:
Отдельные сервисы с независимыми кодовыми базами.
Логика распределена.
В SOA сервисы крупные и многофункциональные, их можно назвать "микромонолитами".

💚 MSA:
Небольшие, автономные сервисы, каждый из которых отвечает за управление одной сущностью, процессом или задачей.
В MSA сервисы более узкоспециализированные по сравнению с SOA.

Сравнение сервисов в SOA и MSA на примерах:

🔹 Каталог товаров
SOA:
+ Сервис "Каталог" – управляет товарами, категориями, характеристиками, поиском и рекомендациями.
MSA:
+ Сервис управления товарами – добавляет, редактирует, удаляет товары
+ Сервис поиска – отвечает только за фильтрацию, поиск и выдачу результатов
+ Сервис рекомендаций – анализирует покупки пользователей и предлагает похожие товары

🔹 Корзина покупок
SOA:
+ Сервис "Корзина" – хранит товары пользователя, управляет ценами и скидками
MSA:
+ Сервис корзины – добавляет и удаляет товары.
+ Сервис расчёта цен – отдельно высчитывает итоговую сумму с учётом акций, налогов и доставки
+ Сервис промокодов и скидок – управляет купонами, скидками, программами лояльности



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

👉 База данных

◽️ Монолит:
Обычно одна на всю систему, но может быть и больше.

🟡 SOA:
Сервисы могут иметь общую БД или отдельные схемы внутри одной БД.

💚 MSA:
У каждого микросервиса своя БД.

Сравнение SOA и MSA:
Например, обновление платежного модуля в интернет-магазине с MSA не затронет каталог товаров, так как у них разные БД. В то время как в SOA архитектуре могут быть проблемы с обновлениями из-за наличия общей БД.



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

👉 Независимость, масштабируемость и отказоустойчивость

◽️ Монолит:
Если отказывает что-то в монолите, то он ломается целиком.
Релиз обновлений приводит к полной недоступности всего Backend.
Сложно масштабировать:
- постоянно надо добавлять новые мощности (память, ядра и другие) к существующему серверу при добавлении новых функций,
- если запущено несколько параллельно работающих копий монолита, то при росте пользователя, надо запускать новую дорогую копию.


🟡 SOA:
Если отказывает что-то в одном сервисе, то ломается только он, а остальная часть системы работает.
Релиз обновлений приводит к недоступности только одного сервиса. Но могут быть сложности с отключением нескольких сервисов, когда выполняются обновления общих БД.
Можно масштабировать каждую БД и сервис по мере необходимости - т.е. если растет нагрузка на каталог товаров, то запустим больше копий только этого сервиса, а не всей системы.


💚 MSA:
Если отказывает что-то в одном сервисе, то ломается только он, а остальная часть системы работает.
Релиз обновлений приводит к недоступности только одного сервиса, за счет собственной БД сложностей нет.
Можно масштабировать каждую БД и сервис по мере необходимости, как в SOA.



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

👉 Взаимодействие

◽️ Монолит:
+ внутреннее, через вызов процедур и функций в одном коде.


🟡💚 SOA и MSA:
+ напрямую по API (REST, gRPC и другие),
+ через шину данных ESB,
+ через API-сервисы, в том числе можно использовать API Gateway,
+ через оркестратор,
+ асинхронно, через брокеры сообщений как Kafka или RabbitMQ.



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

Когда лучше монолит, когда SOA, а когда MSA?

Когда монолит?
✅ Если у вас стартап и ограниченный бюджет.
✅ Нет опытных специалистов и архитекторов, кто работал с MSA.
✅ Нужно сделать быстро и протестировать гипотезу.
✅ Нет высокой нагрузки – мало пользователей.

Когда SOA?
✅ Большая корпоративная система с интеграциями.
✅ Если в компании уже используется ESB.
✅ Не требуется высокая скорость изменений – SOA сложнее менять, так как сервисы могут зависеть от общей БД или централизованных решений.

Когда MSA?
✅ Нужна высокая скорость изменений и независимость команд.
✅ Нагрузка на отдельные функции распределена неравномерно – например, поиск товаров требует больше вычислительных мощностей, чем расчёт скидок.
✅ Отказоустойчивость критически важна.
✅ Частые релизы.


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

🦄 Микросервисная архитектура(MSA): погружение в детали 🦄

Микросервисная архитектура (MSA) – это эволюция сервис-ориентированной архитектуры (SOA), но более гибкая, независимая и масштабируемая.

Если монолит – это один большой блок,
а SOA – это несколько крупных сервисов,
то MSA – это сеть небольших сервисов, работающих как единая система.


Что такое микросервис (МС)?

▫️ Это небольшая, автономная служба, которая:
+ управляет данными одной сущности,
+ обслуживает строго один бизнес-процесс,
+ выполняет только одну простую функцию.
По сравнению с SOA, в MSA сервисы более узкоспециализированные и мЕньшие по размеру.

▫️ У каждого МС своя БД, API, кодовая база.

▫️ Каждый МС развернут на своём сервере, работает и релизится независимо от других.

▫️ МС не используют общую БД – каждая часть системы управляет своими данными.



👉 В МСА сервисы взаимодействуют между собой:
+ напрямую по API (REST, gRPC и другие),
+ через API Gateway,
+ через оркестратор,
+ асинхронно, через брокеры сообщений как Kafka или RabbitMQ.


Набор МС для классического примера с Интернет-магазином:
🔹 Каталог товаров
🔹 Корзина
🔹 Заказы – получает данные из корзины и формирует заказ
🔹 Платежи
🔹 Управление скидками
🔹 Доставка
🔹 Уведомления (sms, email, push)
🔹 ЛК пользователей


👉 Плюсы MSA во многом совпадают с SOA:
✅ Сервисы можно легко добавлять или обновлять без влияния на всю систему, т.к. у них отдельные кодовые базы
✅ Масштабируемость – можно увеличить нагрузку на конкретный сервис, не затрагивая всю систему
✅ Можно обновлять сервисы без даунтайма всей системы. А собственная БД гарантирует, что другие сервисы не будут затронуты
✅ Ошибки в одном сервисе не влияют на работу других
✅ Гибкость технологий


👉 Недостатки MSA:
❌ Сложность управления большим количеством сервисов. Мониторинг и логирование должны быть на высоком уровне, чтобы не терять сбои в отдельных частях системы
❌ Возможны задержки в работе из-за количества звеньев в цепочке обмена данными
❌ Нужна опытная команда


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

🪄 Сервис-ориентированная архитектура (SOA): погружение в детали 🪄

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

👉 Сервис – это маленький монолит.
👉 SOA – это набор маленьких монолитов, которые взаимодействуют друг с другом.


Когда мы думаем о серверной части приложения Backend, то в SOA надо представлять, что это НЕ одно большое приложение, как монолит, НЕ один прямоугольник “Backend” на схеме архитектуры, а много разных прямоугольников - сервисов, каждый из которых может:
+ отвечать за определенную группу функций,
+ иметь собственную БД,
+ иметь собственный API,
+ иметь собственную кодовую базу,
+ устанавливаться на отдельном сервере,
+ обновляться независимо от остальных.

👉 Эти сервисы общаются друг с другом, обычно через API или шину данных (ESB), для выполнения различных бизнес-задач.


Сервисы в SOA обычно выделяют по бизнес-контекстам или процессам, которыми они должны управлять.
В классическом примере с Интернет-магазином можно выделить сервисы:
▫️ товары,
▫️ корзина покупок,
▫️ платежи,
▫️ уведомления (sms, email, push),
▫️ ЛК пользователей.


Особенности SOA:

💪 Backend разбивается на независимые сервисы.

💪 Сервисы можно легко добавлять или обновлять без влияния на всю систему, т.к. у них отдельные кодовые базы. Каждый сервис можно разрабатывать, тестировать, развертывать и масштабировать независимо.

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

💪 Ошибки в одном сервисе обычно не влияют на работу других, что повышает надежность всей системы.

💪 SOA позволяет использовать различные технологии и языки программирования в рамках одного проекта. То есть один сервис может быть на PHP, второй на Python, а все остальные сервисы на Java. Это позволяет программистам пробовать внедрять новые технологии в проекты при разработке новых сервисов.

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

🪲 Проблемы монолита: разбор на примерах 🪲


🔺1. Масштабируемость
Добавление новых функций и рост пользователей требуют больше затрат на серверные мощности (ресурсы): память, ядра процессора и другие.

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

> Планируется повышение нагрузки на приложение в 2 раза из-за новой рекламной акции: надо запустить еще несколько копий ВСЕГО такого же огромного монолита, к уже работающим параллельно копиям, чтобы выдержать нагрузку.

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



🔺2. Сложность поддержки и развертывания
Бывает, что приходится полностью останавливать работу системы в процессе обновлений. Это почти недопустимо в современных реалиях. Важно работать 24/7, чтобы обеспечивать высокий уровень сервиса.

> В существующем API-методе, в платежной части системы, нужно добавить к JSON-ответу дополнительное поле. Маленькая задача.

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

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


🔺3. Сложность масштабирования команды
Приходя в проект, аналитики, разработчики и тестировщики должны узнать очень много обо всех частях системы, чтобы не вредить ей при развитии и знать, как очередная маленькая функция, может задеть 100 существующих...

Для аналитиков полноценное погружение в проект может занимать от 3-х месяцев до года. И к концу испытательного срока вы все еще можете допускать ошибки проектирования и продолжать исследования дальше. Это считается нормой в монолитах.

В условиях архитектуры с сервисами аналитику часто достаточно знать только про свои сервисы и его БД, а также про API связанных сервисов внутри проекта и API внешних систем.



🔺4. Единая точка отказа
Монолит ломается целиком.
Из-за отказа в работе основной и единственной БД, возникает остановка работы всей системы. Напротив, в сервисной архитектуре, остановят работу только те сервисы, которые работают с этой БД.



🔺5. Гибкость и инновации
Затрудняется внедрение новых технологий и подходов в разработке, что делает больно разработчикам.

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

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



Это основные проблемы монолитной архитектуры 😔

Но в ней есть и очень много плюсов:
+ легкость в разработке
+ не нужна супер-опытная команда
+ нет проблем в синхронизации данных, которые распределены по разным БД
+ легче устанавливать проект на сервере
Она идеальна для стартапов! 🚀

Монолит - это не плохо. Его можно сделать архитектурно красивым, и с ним будет интересно и приятно работать 🙌 Но всё зависит от опыта программистов, архитекторов и аналитиков, которые участвуют в разработке.

Вопрос про недостатки монолитов важно знать, если предстоит сотрудничество с архитекторами. А также он есть среди подборок теоретических вопросов для собеседований на СА.

Сохраняем этот пост в памяти, чтобы быть готовыми к развернутым ответам 🙂

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

🛠 Монолитная архитектура: погружение в детали 🛠

Монолитная архитектура – это подход к разработке программного обеспечения, при котором все компоненты приложения объединены в единый и неделимый блок, называемый монолитом.

Можно выделить две основные группы монолитов:

👉 Классический (жесткий) монолит: весь код Frontend и Backend в одном месте.

👉 Современный монолит: код UI (Frontend) выделяют в отдельную кодовую базу, но при этом проект может всё еще остаётся монолитным в части сервера (Backend).

Подробнее рассказала в картинках к посту 📚

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

✨📚 7 шаблонов архитектуры, которые важно понимать СА 📚✨

Системные аналитики описывают внутреннюю логику работы приложений:
+ связи между данными на UI (экраны), в БД и API,
+ интеграции с внешними системами,
+ алгоритмы обработки данных,
+ и другие технические детали.

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

А вот в сложных продуктовых компаниях, таких как банки, маркетплейсы и страховые компании, базовых знаний недостаточно. Здесь чаще встречается сложная сервисная (SOA) или микросервисная (MSA) архитектура.

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

👉 Собрала для вас 7 основных шаблонов проектирования архитектуры, которые важно понимать СА.

Рассказала о каждом с примерами и картинками, про связи между ними, и зачем их нужно знать аналитикам.

1. Монолит
2. Слоистая архитектура
3. Модульная архитектура
4. Клиент-Серверная архитектура
5. Сервис-ориентированная Архитектура (SOA)
6. Микросервисная архитектура (MSA)
7. Событийно-ориентированная архитектура (EDA)

Всю информацию собрала в мини-книгу прикрепленную к посту 📚

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

🔮 Не забывайте высыпаться 🔮

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


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

🔹 Просыпаюсь в 7 утра без страданий, но раньше не встану — организму нравятся его 8+ часов сна.

🔹 Бодрость весь день, желание вздремнуть не появляется.

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

🔹 Неожиданно легко отказалась от кофеина — ромашковый чай и декаф стали лучшими друзьями. Это дало больше спокойствия.


👉 Раньше спала по 5-6 часов и думала, что так нормально и мне так комфортно.

Но разница между 6 и 8 часов сна оказалась колоссальная – усталости стало в разы меньше, энергии больше.


Так что...
Сон – штука важная.


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


Я вдохновлялась и убеждала себя в важности сна книгами:
📚 «Зачем мы спим» – Мэттью Уолкер
📚 «Наука сна» – Дэвида Рэндалла

Берегите себя и не забывайте восстанавливаться 💜


Делитесь в комментариях: сколько часов спите вы? как себя чувствуете в течение дня?

🔐 Авторизация в API: что важно для работы с требованиями и собеседований 🔐

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

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


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


Делитесь с коллегами и подписывайтесь на канал подкаста, чтобы следить за релизами новых эпизодов ⚡

💚 Swagger - Open API - Практическое руководство. Часть 2 💚

Настроим базовую спецификацию OpenAPI! Вот ключевые элементы, которые нужно знать:

🔹 openapi: версия спецификации OpenAPI, определяющая формат описания API.

🔹 servers: список серверов, на которых развернуто API (продакшн, тест, дев).

🔹 info: содержит название, описание, версию API и контактную информацию разработчиков.
📌 Важно! В Swagger версии API хранятся как отдельные документы, между которыми можно переключаться.

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


Что дальше?
Я подготовила для вас следующую часть практического руководства, которая поможет вам разобраться с базовой информацией об API и научиться с ней работать в OpenAPI.

⏳ Время на изучение и практику OpenAPI:
🕓 30 минут — на работу с заданиями строго по руководству, где есть подсказки по каждому шагу,
🕓 +50 минут, если хотите выполнить ДЗ и создать дополнительные личные демо-проекты для портфолио.


Сохраняйте и выполняйте задания по шагам из практического руководства!
Это позволит вам освоить инструмент Swagger (OpenAPI) в реальной работе 🙌

#RestApiGA

💚 Swagger - Open API - Практическое руководство. Часть 1 💚

Меня часто просят показать как работает Swagger.
Поэтому одной из целей последнего проекта по REST API было демо работы с этим инструментом и спецификацией OpenAPI, с использованием которой ведется разработка кода в нём.


Это первая часть практического руководства, по которой вы шаг за шагом научитесь:
✅ Регистрироваться и настраивать аккаунт в Swagger
✅ Ориентироваться в интерфейсе и возможностях инструмента
✅ Создавать демо-проекты в спецификации OpenAPI

🔗 Ваш первый результат будет выглядеть так


Swagger и OpenAPI — это не просто инструменты, а стандарты в REST API.
Их используют разработчики и аналитики для описания, проектирования и тестирования методов API.

Разбираясь в спецификации кода OpenAPI, вы будете лучше понимать, как API устроено изнутри 🙌

Скачиваем руководство и уделяем 15 минут, чтобы освоить новый инструмент!

#RestApiGA

----
P.S. Может потребоваться VPN

💻 Публичная документация API через Postman - пример реализации 💻

Вчера я показала вам заполненный шаблон постановки задачи на REST API и на его основе создала образец документации в 🟠Postman.


Такой формат документации может быть использован в двух случаях:

1. Для внутренней Backend-команды
При описании задач вы можете сразу сохранять всю информацию в Postman, без Confluence.
Ограничения на коллекцию:
+ Доступна только для команды.
+ Не является публичной, так как может содержать приватные данные (например, маппинг с БД и алгоритмы работы).

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


--------------
👉 Пример публичной документации в Postman для проекта #ElibraGA,
где скрыты детали реализации методов:
🔗 ссылка
--------------

На что обратить внимание:
1. Вы можете открыть мою Postman-коллекцию с методами на основе которой сделана эта API-документация.
2. Посмотрите, что я показываю несколько вариантов ответа. Т.е. не только успех, но и ошибки. Это важно для удобства работы с вашим API.


Как сделать аналогичную документацию в Swagger (OpenApi) покажу на этой неделе 🤝

#RestApiGA

Сегодня последний день доступа к занятию "Знакомство с REST API через Postman: с нуля до рабочих методов":
🔗 Подробности и регистрация


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

🎁 В этот раз она запускается в новом уникальном формате, где вы дополнительно получаете:
+ 3 онлайн-занятия
+ 1 проект в портфолио
+ 3 месяца доступа к обучению

Вы получите:
• 25+ часов практических занятий (11 встреч)
• Встреча по разбору индивидуальных проектов
• Теоретические модули в платформе
• Домашние задания для создания индивидуального проекта в портфолио
• Доступ к закрытому Telegram-чату, где мы публикуем уведомления о проходящих вебинарах, полезные ресурсы, ссылки на книги и разбираем ваши вопросы
• Сертификат о повышении квалификации



На занятии "Знакомство с REST API через Postman: с нуля до рабочих методов" мы затронули множество аспектов, необходимых для успешного освоения REST API.


Программа «Дизайн REST API» поможет вам закрепить эти знания, погрузиться в тему глубже, получить больше практики и открыть новые карьерные возможности в системном анализе!

🔗 Узнать подробнее о программе Дизайн REST API


Есть вопросы? Пишите нам на почту [email protected], в Telegram или на сайте. Мы свяжемся с вами, поможем оценить текущие навыки и ответим на вопросы 🙂

💙 Образец постановки задачи на REST API: заполненный шаблон для Confluence 💙

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

Но я искренне понимаю всех, кто еще ни разу не работал с постановками задач на Backend (REST API), и, даже глядя на шаблон, слабо представляет что туда писать 🥲

Поэтому я оформила постановку задачи по проекту #ElibraGA на метод GET /books - получение списка книг.

Теперь у вас есть образец, на который можно подглядывать 🙂


На что обратить внимание:
1. Headers: показала, какие могут быть для запроса, включая авторизацию.
2. Query-parameters: подробно расписала всё про фильтры запроса, их ограничения и связь с БД.
3. API name: уточнила, что метод может использоваться и для админского API, с аналогичной реализацией.
4. Ответы: дала примеры двух успешных ответов, включая пустой список, и описала все ошибки.
5. Требования к реализации: подробно расписала алгоритм для разработчиков, включая исключительную ситуацию с элементами пагинации.


Используемая информация для подготовки:
▫️ шаблон постановки задачи на REST API метод
▫️ БД и дизайн проекта
▫️ пример 9 методов по проекту (сделала улучшение, чтобы сразу был список авторов и список жанров)


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

Сохраняйте и пользуйтесь 💙

#RestApiGA

Друзья, как говорится, «новый год – новая жизнь!»😁
 
Поэтому хотим вам порекомендовать книгу Евы Кац «Жизненный баланс. 82 идеи для управления работой и жизнью, 7 способов мечтать и 6 шагов, чтобы всё реализовать».
 
Это полезное руководство для всех, кто стремится наладить гармонию между работой и личной жизнью.
Автор предлагает практические инструменты и вдохновение для достижения целей.
 
Книга написана в разговорном стиле, с чувством юмора и борьбой со стереотипами✔️
 
#hwGetAnalyst

🔔 Открытый урок по REST API [доступ к записи | 1-3 февраля] 🔔

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

По итогам работы у вас будет собственная коллекция запросов в Postman для портфолио, которой вы сможете поделиться с коллегами и потенциальным работодателем!

Пример такой коллекции можно посмотреть здесь.


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

⭐️ Знакомство с REST API через Postman:
⭐️ с нуля до рабочих методов
🗓 1-3 Февраля
🔗 Подробности и регистрация


Пусть эти выходные пройдут с пользой для вашей карьеры! ⚡️

💥 REST API: спорные вопросы с проектов и собеседований на Системного Аналитика 💥

1. Можно ли использовать метод POST для получения данных?
2. Можно ли сделать в проекте все методы POST?
3. Можно ли в GET передавать тело запроса?
4. Как правильно именовать эндпоинты - ед. число или мн. число (/user или /users)?
5. Как правильно строить URL - нужно ли писать create/update в названии метода?
6. Какой код ответа на метод POST: 200 или 201?
7. Что вернуть в ответ, если получен пустой результат - пустой массив или 404?

Опасная подборка 😄

Подробный разбор ответов в этой статье 🔗

#RestApiGA

💎 Методы REST API: 9 примеров для понимания принципов дизайна REST API 💎

Для проекта #ElibraGA спроектировала методы, которые надо реализовать для обеспечения работы приложения.


На что обращать внимание при знакомстве с документом:


Методы REST API - для приложения читателя

✔️ Получить список книг
Показаны:
+ Работа с Query-параметрами для пагинации и фильтрации.
+ Показан массив - список книг.
+ Структура списка - его всегда лучше держать внутри {}, даже если не будет элементов пагинации limit, offset, count.

✔️ Получить информацию о выбранной книге
Пример URL получения информации о конкретном объекте из списка по его id.

✔️ Получить список избранных книг пользователя
Обратите внимание на структуру URL и уточнение про авторизацию пользователя.

✔️ Получить информацию о пользователе и его текущей подписке
+ Проанализируйте JSON с информацией о пользователе и его связь с БД.
аналогично проанализируйте JSON метода получения информации о книге по id и его связь с БД.
Какие особенности заметили?
+ Также для пользователя и книги проверьте, что есть в JSON, и чего нет на UI.


Методы REST API - для приложения админа

✔️ Загрузить обложку книги + Загрузить файл книги
Помогут понять, как работать с загрузкой файлов при работе с REST API.
Важно:
1. Сначала грузим файлы в хранилище.
2. Потом создаём книги с использованием готовых ссылок.

✔️ Создать книгу
Обратите внимание, что JSON-запроса по структуре отличается от JSON-ответа.
Например, при создании книги не надо передавать всю информацию об авторе, т.к. подразумеваем, что его уже создали в системе до этого запроса. Нужен только id.

✔️ Редактировать книгу
Вариантов JSON-запроса может быть много.
В ответ рекомендуется всегда возвращать полный JSON-объекта при редактировании. Допустимы другие варианты.

✔️ Удалить (архивировать) книгу
Нет JSON-ов.


Документ разработана в Confluence.


👉 Методы этого проекта будут особенно полезны для систем, в которых предусматривается работа с файлами.

Сохраняем в личные архивы 🤝

#RestApiGA

🔥 1-3 февраля | Открытый урок по REST API 🔥

Если бы мне снова пришлось осваивать проектирование REST API самостоятельно и с нуля, мои шаги были бы следующие:

1. Найти 5 публичных REST API-документаций.
2. Зарегистрироваться в Postman.
3. Получить доступ к этим API. Протестировать каждый из них через Postman, глядя одновременно на UI приложений и на структуру API-методов.
4. Найти общее и различия в этих API.
5. Пробовать брать боевые задачи и получать обратную связь от моей опытной команды Backend-разработчиков 💪

👉 Минимум теории, максимум практики.

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

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


📚 Знакомство с REST API через Postman: с нуля до рабочих методов
🗓 Доступ 1-3 февраля
🔗 Узнать подробнее и зарегистрироваться

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


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

Регистрируйтесь, учитесь и получайте новый опыт! 🙌

✨ Завершаем предзапись на REST API | с 4 февраля ✨

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

💻 Дизайн REST API
🗓 Старт 4 февраля 2025

Уникальный поток с новым форматом:
⚡️ +3 месяца доступа к материалам и обратной связи (9 мес)
⚡️ +3 онлайн-встречи
⚡️ +1 проект

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

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


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


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

⭐ Прежде чем сделать JSON: подготовительные шаги ⭐

На прошлой неделе поделилась с вами книгой по JSON (в комментарии добавила версию для печати). В ней я показываю все необходимые примеры, но…

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



👉 От чего зависит вид JSON-объекта:
+ для какого экрана(-ов) мы его делаем,
+ какая БД в проекте,
+ для какого метода REST API мы его делаем.



👉 Знакомлю вас с #ElibraGA:

✅ Макеты приложения в Figma - основные экраны пользовательского МП (моб. прил.)
Ссылка на Figma

+ авторизация и регистрация
+ книги, поиск и фильтры
+ избранное
- экран оплаты подписки не показан, но он есть 🙂


✅ БД проекта (ER диаграмма в Draw.io)
Ссылка на dbdiagram.io

+ ключевые таблицы: user (пользователь), subscription_tariff (тарифы), user_subscription_tariff (история тарифов пользователя, включая текущий), book (книга), user_book_purchase_history (история покупок книг по подписке)

+ ‼️Обратите внимание, БД не просто в draw.io, а интегративная - сделана через код в dbdiagram.io (иногда нужен VPN): все связи можно проверить, каждое поле прокомментировано



👉 Как мы будем это использовать:
1. Выбираем экран и определяем, какое действие для него требуется — это метод REST API: тип и URL.

2. Анализируем данные, отображаемые на экране, и выделяем ключевую сущность.

3. Продумываем, на каких ещё экранах и в каких приложениях системы будут использоваться данные этой сущности.

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

5. Проектируем полный объект JSON, который будет использоваться для ответа метода GET /object/{objectId} с полной информацией о сущности.

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



👉 Подготовительную часть сделали!

Можем переходить к проектированию JSON-ов!

#RestApiGA

Прошедшую неделю официально объявляю неделей офферов, а январь - месяцем активного найма 💪


После того, как я несколько раз написала в канале, что для нас действительно важно и приятно знать, что вы растёте в карьере с GetAnalyst, то нам в ЛС стали чаще приходить новости об офферах 🎉

Только за эту неделю 5 радостных сообщений почти по всем программам ⚡️ включая начинающих СА

👉 Так что если кто-то думает, что в январе "мертвый месяц" для найма и все только-только отходят от праздников - это не так.


А еще я вижу, как команда трудится над оформлением историй студентов за конец прошлого года. Их много!


Душа радуется за всех вас!
И появляется еще больше неугасающего желания делиться и создавать лучших специалистов в IT!
а не умельцев проходить собеседования


Одну историю и несколько ярких сообщений публикую в картинках к посту.

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

Искренне ваши,
Екатерина Ананьева,
и команда GetAnalyst

#студентыGetAnalyst

🟢🟠 Инструменты системного аналитика для работы с API 🟡🟣

Работа с API — важный навык для системного аналитика.


👉 Для работы с интеграциями:
Системному аналитику необходимо убедиться, что API внешней системы будет работать именно так, как описано в документации (если она есть, а если нет - то составить), чтобы затем предоставить информацию разработчикам.

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


👉 Работа с Backend и мобильными командами:
Нужно уметь самому с нуля проектировать и документировать API, желательно с использованием специализированных инструментов как Postman и Swagger, а не только в Confluence-подобных системах.


Список инструментов, которые помогают системным аналитикам в тестировании и документировании API:

🟠 Postman
🟡 SoapUI
🟣 Insomnia
🟢 Swagger

Подробности в картинках к посту ☝️


👉 В конце рекомендую поработать с инструментами

Делюсь своими практическими гайдами, с которыми вы сможете поработать с инструментами сами, с понятными пошаговыми инструкциями:
▫️ Postman: Практическое руководство с примером тестирования открытого API
▫️ GraphQL — знакомство на практике через Postman [пошаговая инструкция]
▫️ Postman: навык тестирования REST API за вечер
+ скоро добавлю для вас Swagger.


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

🙌 Сводка по проектированию эндпоинтов REST API 🙌

🔗 HTTP-методы
🔗 Структура URL
🔗 Ошибки проектирования методов REST API

Проверим, насколько вы хорошо усвоили материал по эндпоинтам REST API.

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


1. Какой метод сделать для регистрации нового пользователя?
❌ POST https://elibraga-online.com/api/public/v1/createUser
В URL дублируется действие (глагол create), которое уже указывает HTTP-метод POST.
✅ POST https://elibraga-online.com/api/public/v1/users
+ Метод POST используется для создания новых ресурсов - регистрация = создание пользователя.
+ users является сущностью, к которой относится запрос.

2. Как получить список авторов с фильтрацией по жанру?
❌ GET .../api/public/v1/authorsByGenre/{genre}
Фильтрация по жанру в данном случае не является частью основного ресурса.
✅ GET .../api/public/v1/authors?genre=fiction
+ Query-параметры позволяют удобно передавать фильтры, такие как genre=fiction. Значение жанра может отличаться, также их можно перечислить через запятую. Это делает запрос гибким и легко расширяемым.

3. Как получить список заказов пользователя?
✅ GET .../api/public/v1/orders
То, что это заказы конкретного пользователя, понимает за счет того, что запрос подписан авторизацией.
✅ GET .../api/admin/v1/users/123/orders
Для админского метода выстроена иерархия от пользователя к заказу для просмотра заказов внутри информации о пользователе.
✅ GET .../api/admin/v1/orders?userId=123
В общем списке заказов в админке можно применить фильтр по пользователю.

4. Как сделать метод отмены заказа пользователем?
◽️DELETE .../api/public/v1/orders/{orderId}
Больше подходит, чтобы показать удаление неоплаченного заказа.
✅ PATCH .../api/public/v1/orders/{orderId}/cancel
Глагол действия на смену статуса вынесен в конец URL, что часто встречается для PATCH (еще бывают archive, pay и подобные).

Сколько правильных ответов получилось?
Задавайте вопросы в комментариях 🙂
Делитесь результатами и доп решениями💡

#RestApiGA #ElibraGA

Кто не успел записаться на Оптимизацию БД и индексы, то еще можно успеть подключиться к нам сегодня в 19:00 Мск.

+ занятие про распределенные БД на неделе посмотреть.


🔗 Подробности и запись тут


До встречи в эфире! 🙂

🐝 Ошибки проектирования методов REST API 🐞

API (программный интерфейс) - это как UI (пользовательский интерфейс).

За нажатием на кнопку “Удалить” может скрываться алгоритм создания 🙈
Да, кнопка называется “Удалить”, но главное то, что запрограммировали разработчики в коде.

Так и с API: за методом POST на создание данных может быть реализован алгоритм получения данных.

Это самое важное, что нужно знать о REST API 🙂


Собрала для вас статью, в которой показала основные ошибки при определении методов REST API - эндпоинтов (метод HTTP + URL):

1. Выбор метода POST, GET, PUT, PATCH, DELETE, который не соответствует действию
2. Все методы POST
3. Глагол действия в URL - названии эндпоинта, который дублирует команду HTTP-метода
4. Опущена важная часть URL
5. Нарушена иерархия в URL
6. Слишком длинный путь в URL
7. Отсутствие элементов пагинации для списка
8. Единственное или множественное число в URL
9. Нарушение корпоративного стиля


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

Рекомендации из этой статьи помогут сделать ваш API интуитивно понятным и соответствующим рекомендациям архитектурного стиля REST API.

#RestApiGA #ElibraGA

🔗 Структура URL для REST API методов на практике 🔗

Разбираем тему на примере методов:
👉 POST /books
👉 GET /books
👉 GET /books/{bookId}
Подробности в документе к посту.


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

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

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

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

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

▫️books - это ресурс, к которому осуществляется доступ. В данном случае “книга”. Может быть в единственном числе (book).
▫️{bookId} - это параметр в пути URL (path-параметр), указывающий на конкретную книгу по её id в БД системы. Фигурные скобки {} обозначают переменную часть URL, значение которой должно быть предоставлено клиентом (например, идентификатор 78679).


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

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



Это основные элементы URL в REST API, которые помогают точно определить, к какому ресурсу (сущности) должен быть осуществлен доступ 💾

#RestApiGA #ElibraGA

✨ Открыта запись на практическую программу REST API ✨

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

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

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




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

💻 Дизайн REST API
🗓 Старт 4 февраля 2025
⚡️ Поток с новым форматом:
⚡️ +3 дополнительных месяца доступа к материалам и обратной связи (9 мес)
⚡️ +3 дополнительных онлайн-встречи

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

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

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




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


🗓 До 27 января
Запись на специальных условиях с дополнительным обучением по БД в подарок, знания которой понадобятся в ходе работы на проекте.


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

✨ HTTP-методы — это действия, которые надо понимать для проектирования REST API ✨

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

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


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


✨ POST: создание нового ресурса
Добавить новую книгу в библиотеку.
Зарегистрировать пользователя.
Создать платеж за подписку.


✨ GET: получение ресурсов
Посмотреть список книг.
Получить информацию о выбранной книге.
Просмотреть информацию о своём профиле.
Проверить статус подписки.



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

Вызываем PUT (изменить/создать) для книги с ISBN 1234567890:
👉 если книга с таким ISBN уже была создана, то обновить данные по ней целиком, даже если какие-то параметры, как название, не редактируются.
👉 если книга с таким ISBN еще не создана, то создать новую.

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



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


✨ DELETE — удаление ресурса
Удалить выбранную книгу
Удалить выбранные книги из списка
Удалить платеж, если он не оплачен.
Удалить книгу из “избранного”.



Распространенные ошибки в REST API:
- Игнорирование назначения методов.
- Использовать все POST вместо рекомендуемых методов.
- Неправильное использование PUT и PATCH.


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

#RestApiGA #ElibraGA

💛 Структура методов REST API в одной картинке 💛

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

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


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

ТБанк - Зарплатный проект
API - Умного дома от Яндекс
ЦИАН - Покупка и продажа недвижимости

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


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

#RestApiGA

📌 Проект по REST API - Электронная Библиотека #ElibraGA 📌

Каждый месяц в канале GetAnalyst мы изучаем навыки для системных аналитиков через разбор проектов.

Этот месяц мы посвятим проектированию методов REST API для приложения электронной библиотеки #ElibraGA.


В ходе разбора темы я буду делать фокус на:
✅ разработку корпоративных стандартов REST API в компании, которые помогают работать над проектом,
✅ документирование REST API в Swagger.


📚 О проекте 👇

Пользователи-читатели:
+ Регистрируются на платформе через веб- или мобильное приложение
+ Оплачивают подписку, которая дает возможность скачивать 1, 3, 5 или 15 книг в месяц.
+ Получают доступ к списку книг
+ Могут скачать книгу

Администраторы платформы:
+ Добавляют новые книги
+ Редактируют или удаляют существующие
+ Просматривают полный список пользователей-читателей
+ Блокируют и активируют аккаунты читателей
+ Смотрят информацию о подписках и платежах


👉 Наши задачи по проектированию REST API методов

▫️ Сделать с нуля методы POST, GET, PUT, PATCH, DELETE
▫️ Научиться описывать JSON
▫️ Создать задачи на разработчиков
▫️ Формировать корпоративный стандарт по дизайну REST API для проекта
▫️ Создать документацию в Swagger (OpenAPI)


Подписаны на канал?
Значит вы участвуете в проекте и получаете новый опыт 🤝


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


#RestApiGA

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

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

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

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

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

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

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

#RestApiGA

💻 Оптимизация БД. Работа с индексами 💻

Каждый месяц в GetAnalyst мы проводим продвинутые практикумы, посвященные проектированию БД и SQL.
Тема этого месяца:

💻 Оптимизация БД. Работа с индексами
🗓 20 ЯНВАРЯ, 19:00 Мск (пн)
🔗 Подробности и запись

План практики:
1. Нефункциональные требования и их связь с БД.
2. Понятие индексов в БД и их назначение. Разбор примеров.
3. Практика: знакомство с БД проекта и определение таблиц с индексами.
4. Проблемы избыточной оптимизации БД.
5. Индексы в постановках задач на разработчиков.

👨‍💻 Этот практикум идеально подходит для системных аналитиков, стремящихся углубить свои знания и навыки в области проектирования баз данных и оптимизации систем.

Присоединяйтесь к нам 🙂

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


Когда затрагивают тему REST API, то полезно знать, что могут требовать от Системного Аналитика.

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


👉 При создании новой функциональности
У вас в команде 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).


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

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


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



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


#RestApiGA

В новогоднюю ночь я написала список из 50 целей на год. А также подвела итоги, что получилось в 2024. Хочу поделиться результатами.

1. Часть целей, которая была в 2024, переехала на 2025. Это нормально.

2. Почти все цели, которые переезжали с 2022 и 2023 были выполнены в 2024.

3. Промежуточный контроль и ежедневное чтение этого списка помогали планомерно достигать и искать мотивацию.


Цели - это не только про карьеру, успех и достигательство. Это самые разные мечты и желания. И про то, что даже невозможное возможно 🙌

У меня одна из целей была «давать себе больше времени на отдых и перезагрузку». Получилось наконец-то! 😄


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


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


Кто тоже писал цели и желания в новогоднюю ночь?
Делитесь в комментариях, как это работает у вас, или просто ставьте 🔥 верю, что я не одна такая))

🔔📚 Полезные материалы перед выходными 📚🔔

В этом году больше всего ДЗ на проверку и вопросов по ходу работы над проектами GetAnalyst я получила 1 января 2025 😁


Поэтому на новогодние каникулы собрала для вас:

📚 Большая подборка материалов по Интеграциям от GetAnalyst

🎁 Доступ к записи вебинара "Интеграции: REST API, GraphQL, gRPC + Postman" - ДО 12 ЯНВАРЯ (ВСК)

📹 Пакеты вебинаров в записи со скидкой 25% - ДО 12 ЯНВАРЯ (ВСК)


Кто еще не успел посмотреть - успеваем!
Особенно посмотреть вебинар по REST+GraphQL+gRPC! 😍


Отличных выходных!

📄💎 Полная постановка задачи на интеграцию - заполненный шаблон требований 💎📄


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


1. Получить требования от бизнеса - ссылка на требования нашего проекта

2. Запросить API-документацию и доступы к API внешней системы - ссылка

3. Исследовать API документацию и найти нужные методы для интеграции - ссылка

4. Понять архитектуру системы - ссылка

5. Описать интеграционный Use Case - теория и пример для проекта

6. Сделать UML-Sequence диаграмму для требований - самому или через ChatGPT за 3 минуты

7. Определить интеграционные API-методы и добавить в сценарий и на UML-диаграмму, если их еще нет - ссылка

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

👉 9. Оформить полную постановку задачи на интеграцию - заполненный шаблон постановки задачи прикреплен к посту 📄

10. Доделать еще две статьи с нашими интеграционными API методами - пример (можно дополнить ими основную статью с полным сценарием интеграции, но тогда есть риск перегрузить общую статью с описанием интеграции, ведь общий сквозной сценарий и так сложный).


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

Сохраняйте и пользуйтесь 🙂

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

Друзья, с началом первой рабочей недели😃
 
Желаем плавно влиться в рабочие будни.
Не забывайте находить время для отдыха и маленьких радостей в течение дня☺️

💡 Более 100 000 лампочек сияют каждую ночь, чтобы радовать людей 💡

Кто-то это придумал, спроектировал и реализовал.

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

Кадр из моего ночного путешествия.
До сих пор не могу поверить, что сделала это фото своими руками.

Сияния вам в ваших сердцах, как в этих огоньках, и даже ярче!
Больше волшебства и чудес в 2025!

С Рождеством, друзья! 🎄

🎄🎁 Доступ к записи вебинара "Интеграции: REST API, GraphQL, gRPC + Postman" 🎁🎄

Поздравляем с наступившим 2025 годом! И верим, что вы отлично проводите время, отдыхаете и наслаждаетесь спокойствием 🙌

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


Цитаты коллег, кто был онлайн:

Станислав:
Меня очень впечатлило, как Екатерина доступно объясняет, спасибо Вам большое

Дарья:
Было супер! Спасибо о таком классном вебинаре, было очень подробно и понятно ♥️

Владимир:
Очень понравилось. Очень полезно. Уже записался на обучение Интеграции. Теперь уверен, что не зря. Спасибо

Акерке:
Вообще очень было все понятно до мелочей, в видах технологий 🤍🤍🤍💔💔💔


👉 Мы решили сделать новогодний подарок для вас и даём дополнительную возможность посмотреть запись эфира:

🎁 Интеграции по REST, GraphQL и gRPC: знакомство через Postman
🗓 с 4 до 12 января 2025
👉 Подробности и регистрация

‼️ Смотреть с компьютера и перед занятием обязательно открыть Postman, так как практика проводится именно в нём.


Занятие проводилось в поддержку практической программы Интеграции систем для системных аналитиков.


Оно поможет вам сделать шаг к профессиональному росту в системном анализе уже сегодня! 🙌

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

Для всех, кому хочется продуктивности в большие выходные!

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

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

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

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

🎧 От «умного дома» до «умного города»: новые челленджи IT-аналитиков - интеграции с умными устройствами

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

🎧 gRPC vs REST API - что выбрать для проекта

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

📝 Пример интеграционного Use Case

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

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

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

📚 Полный шаблон постановки задачи на интеграционный REST API-метод

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

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

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


📝 пост в канале
📚 книга, статья или шаблон документации от GetAnalyst
🎧 подкаст или видео


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

Отличного продолжения выходных!

🙅‍♀️❌ Шаблонные поздравления с Новым годом ❌🙅‍♀️
📚✅ Полезный пост с книгами ✅📚

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

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

Начните читать в каникулы. Они правда могут стать волшебным началом 2025 года и изменить вашу жизнь к лучшему 🙌

«То, как мы работаем, – не работает», Тони Шварц
Эта книга-мотиватор, которая помогает работать не много и упорно, а эффективно. Если вы встретились с выгоранием, часто перерабатываете и ничего не успеваете, то книга поможет перестроить ваши рабочие процессы и график. Уже почти 5 лет пользуюсь приёмами из неё.

«Ставка на себя. Как увидеть возможности, не упустить их и построить карьеру мечты», Энн Хайетт
Если вы понимаете, что засиделись на одном месте и боитесь что-то менять из-за неуверенности в своих силах, почитайте вдохновляющую историю Энн, которая начинала свою работу ассистентом в стартапе и младшим помощником руководителя, а по итогам работала рука об руку с основателями мировых IT-компаний как Google.

«Договориться можно обо всем! Как добиваться максимума в любых переговорах», Гэвин Кеннеди
Подойти к руководителю и попросить о повышении ЗП похоже на ночной кошмар, завершающийся отказом? Выход на собеседования вызывает желание вернуться обратно к работе и заниматься привычными задачами. Везде видятся сплошные отказы? Нормально, проходили. Читаем книгу и движемся вперёд.

«Магия утра», Хэл Элрод
Системность. Дисциплина и самоорганизация. Лишние часы в сутках. Эти три предложения отлично харакртеризуют мои результаты по итогам прочтения этой книги.


Желаю вдохновения, уверенности в своих силах и смелых шагов в 2025 году!

Пусть он станет временем, когда сбываются мечты!

Загадывай желания под бой курантов.
Пиши цели.
Я буду с тобой!

Всё получится! 🪄

С наилучшими пожеланиями,
Екатерина Ананьева
и команда GetAnalyst!

🤍 Итоги 2024 года в GetAnalyst 🤍

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

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

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

Картинки 🤍☝️

🎁 Доступны новые вебинары в записи 🎁

Ровно один раз в год я рассказываю про этот раздел нашего сайта. День настал! ☺️


Коллеги, у нас на сайте есть раздел:
🔗 Материалы для самостоятельного обучения

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

Мы рады сообщить, что за этот год раздел пополнился новыми материалами:
🔗 Проектирование архитектуры 1.0
🔗 REST API для аналитиков 4.0
🔗 Базы данных и SQL: продвинутый уровень

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

Практика и.... еще немного практики! А также все мои душа и сердце, которые я вкладываю в своё дело и в эти занятия.


🎁 В честь наступающих праздников, до 12 января 2025, дарим скидку 25% по промокоду HELLO2025 на все материалы.

Спасибо, что выбираете GetAnalyst ❤️

P.S. Есть вопросы? Пишите нам в @getanalyst или на сайте 👌

🔥 Связь "многие-ко-многим" в БД: разбор задачи с собеседования на системного аналитика 🔥

В эпизоде разбираем одну из самых популярных задач для собеседования на системного аналитика: проектирование БД, ER-диаграмма и связь “многие ко-многим”.

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

🔗 Сайт эпизода


Эпизод доступен в:
⏯ RuTube
⏯ YouTube
⏯ VK Video

Аудио:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Spotify


Делитесь с коллегами и подписывайтесь на канал подкаста, чтобы следить за релизами новых эпизодов ⚡

🚀 Интеграции систем - предобучение начинается сегодня 🚀

Я рада приветствовать нашу новую команду, которая будет работать над проектом по интеграциям! 💚

Сегодня открывается первый модуль “Предобучение”.
На этой неделе начнём подключение к Confluence для работы над проектом.

А первая онлайн встреча пройдёт уже в Новом году:
🗓14 января 2025, в 19:00 Мск

В этот раз у нас особенный поток 🙂

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


Это дополнительное время даёт следующие преимущества:

✅ Вы сможете пройти часть теоретических модулей до начала онлайн-занятий и выполнить первые домашние задания.

✅ Telegram-чат для консультаций уже открыт — задавайте вопросы в любое время!

✅ У меня есть несколько дополнительных заданий, которые я обычно предлагаю для самостоятельного выполнения после завершения курса. Среди них работа с GraphQL, SOAP API и создание диаграммы C4 через код. Их можно будет сделать раньше.

✅ Отсутствие рабочей суеты во время каникул позволит сосредоточиться на главной задаче — саморазвитии!


Пусть это время станет отличным стартом для ваших новых знаний и достижений в Новом году! 🚀


🔗 Узнать подробнее о практической программе
Вопросы по подключению к группе можно задать @getanalyst или через сайт

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

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

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

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


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

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

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


Если говорить про задачу интеграцию системы #EventTasksGA с Todoist для создания задач, то маппинг будет содержать несколько колонок:

- название поля на русском
- название поля в REST API Backend EventTasksGA
- название параметра в API системы Todoist, чтобы установить соответствие с её полями в интеграции
- название поля в БД EventTasksGA, т.к. задача после создания сохраняется в её БД
- описание поля, требования к его обработке и проверкам
- типы данных в API EventTasksGA, API Todoist и БД. Я бы добавила только отдельную колонку “Тип данных в API EventTasksGA”. Все остальные типы данных не так важны или очевидны.


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

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

🔎 Нужно ли уметь проектировать методы REST API системному аналитику? 🔎

REST API — это основной способ интеграции современных систем.

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


Однако некоторым аналитикам требуется не только умение читать чужую документацию, но и способность проектировать методы REST API с нуля.
Это включает как минимум:
✔️ выбор подходящих HTTP-методов (POST, GET, PUT, PATCH, DELETE),
✔️ определение URL,
✔️ и самостоятельное описание JSON-ов.


Что конкретно нужно знать по части REST API системному аналитику зависит от нескольких факторов:

👉 1. Грейд (уровень специалиста)
Все системные аналитики, включая начинающих (junior), должны уметь читать REST API-документацию.
Это включает:
+ Знание назначения методов POST, GET, PUT и других.
+ Понимание структуры URL и способность определить назначение метода, даже без пояснений на естественном языке.
+ Умение читать и описывать JSON, а также формулировать требования к его содержимому
На многих собеседованиях сейчас просят хотя бы на базовом уровне описать метод REST API с нуля. Даже junior-ов.


👉 2. Проект
Бывают простые проекты, бывают сложные. Бывают с REST API или без него (но это редкость).

👉 👉 2.1. В веб-разработке встречаются проекты без API, где UI и серверная логика объединены в одной кодовой базе. Обычно это внутренние системы.
Еще желательно, чтобы проект был без внешних интеграций.
В таком случае с REST API вы не встретитесь.
Такие проекты подходят для начального уровня, но редко интересны опытным аналитикам.

👉 👉 2.2. Если вы работаете над интеграциями с внешними системами, необходимо уметь читать REST API. Умение проектировать методы с нуля не всегда требуется.

👉 👉 2.3. Если ваша система должна предоставлять API для внешних систем, от системного аналитика ожидается умение собирать требования и проектировать методы REST API, т.е. составлять контракты: определять HTTP-метод, URL, JSON-ы и другие параметры.


👉 3. Команда и правила компании
В разных компаниях обязанности по проектированию REST API распределены по-разному.
В одних это зона ответственности разработчиков, в других — системных аналитиков. В любом случае, итоговое решение всегда принимает Backend-разработчик, который может скорректировать предложения аналитика.
Во многих компаниях есть выделенные Backend-команды. В них требуют, чтобы системные аналитики сосредотачивались исключительно на проектировании REST API, и нет задач на работу с пользовательским интерфейсом (UI).


--------
Итого…

Требования к умению проектировать REST API для системного аналитика зависят от уровня специалиста, специфики проекта и подхода компании.

На начальных этапах карьеры достаточно базовых знаний:
+ понимать структуру документации,
+ различать HTTP-методы,
+ и уметь читать JSON.

Однако с ростом квалификации и участием в более сложных проектах навыки проектирования REST API методов с нуля становятся необходимыми. Вмесе с этим просят умение работать с Postman и/или Swagger (знание OpenAPI).

REST API — это уже не просто дополнительный навык, а одна из основных компетенций системного аналитика.

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

❌ Работа над ошибками в REST API - часть 2 (читать аккуратно, вдумчиво, глядя на картинку с БД) ❌

Проблемы с иерархией.
C точки зрения внешней системы Todoist задачи рекомендуется делать внутри проектов (API-документация).
А с точки зрения нашей системы задачи нужны для выполнения заказа order.


В БД #EventTasksGA, которую добавила к посту, можно увидеть следующее:

👉 Сущность "Проект Todoist" отсутствует в БД
А в Todoist без проекта нельзя создавать задачи (требование бизнеса).
У нас есть четкое соответствие: для 1 заказа есть 1 проект в Todoist.
Кроме id нам от проекта в Todoist больше ничего не надо в EventTasksGA.
Поэтому давайте только его и хранить в заказе.
Итого: в таблицу order добавляем параметр todolist_project_id. Через него будем узнавать в каком проекте задачи.

👉 Сущность "Задачи Todoist" (todoist_project_task) есть в БД EventTasksGA, и она связана с заказом.
Каждая новая задача в Todoist будет приводить к записи новой задачи в таблицу todoist_project_task - создание новой строки.


После исследований нашей БД и сопоставления с Todoist, предлагаю действовать так:

✅ PATCH /orders/{orderId}/todoist-projects - создание проекта в Todoist под оплаченный заказ, т.е. дополнение таблицы БД “order” параметром project_id.
PATCH - т.к. нет создания новой строки в таблице, а есть только изменение существующей.

✅ POST /orders/{orderId}/tasks - создание задачи в Todoist (вызов API), после чего создаем в БД новую строку - запись о задаче в таблицу todoist_project_task.
POST - так как новая строка данными о задаче в БД.

✅ GET /orders/{orderId}/tasks - список задач по заказу, которые создали в Todoist. Выглядит аккуратно и логично.

✅ DELETE /orders/{orderId}/tasks/{taskId} - удаление задачи из заказа (проекта в Todoist).



Стандартизировались 🙌
Эти посты наглядно показыавают, что при проектировании REST API я не могу работать только с одним методом.
Важно видеть всю систему целиком, все данные.


Остаётся вам передать полные постановки задач на интеграцию 😉

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

🥶 Ледяные ванны — мой главный антистресс года 🥶

Я не выношу холод.
Но в этом году я попробовала то, что раньше казалось невозможным — ледяные ванны.

Схема простая:
1. 20 минут прогрева в сауне до состояния "я таю" 🫠
2. Погружение в ледяную купель с водой 4-5'C 🥶
Но не на пару секунд и побежала греться. А на 3-10 минут. Спокойно сижу, как в обычной ванной.
3. И так 2-3 круга.

Делаю это минимум два раза в неделю уже пол года.

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

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

Ещё интереснее, кто оказался моими "коллегами" по холодным погружениям.
Успешные, обеспеченные люди делают это для заботы о своём здоровье. И спортсмены для восстановления.
Это было неожиданно и еще более вдохновляюще.

За пол года эффект невероятный.
Когда только начинала, могла выдержать минуту и думала "зачем я вообще здесь себя так мучаю?".
К концу года спокойно сижу 3-4 минуты и думаю о прекрасном. Если в специальных защитных ботинках для ног, то все 10 минут могу оставаться в ледяной воде.
Это прекрасно снимает напряжение после долгих часов за компьютером и рабочих переживаний.

У нас это называется cold plunge. Их начинают устанавливать во многих спортзалах.

Хотела сделать подборку локаций в Мск и Спб, но не нашла ничего подобного 😞
P.S. Ныряние в прорубь это не совсем то 😂 Когда ты в обстановке как в СПА, рядом с сауной и горячим джакузи, то оно как-то приятнее всё))

Если кто-то такое тоже практиковал и знает места, поделитесь с нами в комментариях.

А если будете путешествовать и увидите вариант сходить в Cold Plangue - пробуйте!
Это классное хобби для восстановления и стрессоустойчивости с нашей работой 🤩

💫 Проектирование распределенных БД [23 декабря] 💫

Хотим напомнить вам про продвинутые практикумы по программе проектирование БД и SQL.


В понедельник буду вести занятие:

📚 Проектирование распределенных БД
🗓 23 декабря, 19:00 Мск
👩‍🏫 Екатерина Ананьева

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

План:
1. Базовые понятия архитектуры: сервис-ориентированная (SOA) и микросервисная (MSA).
2. Знакомство с проектом и выделение сущностей.
3. Определение логической и физической моделей БД с разбором примеров по проекту.
4. Практика. Фокус на проектировании физических моделей БД - PostgreSQL.
5. Обзор шаблона постановки задачи на разработчиков.

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


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

Есть вопросы? Пишите нам в аккаунт @getanalyst или на сайте 👌

👩‍💻 Интеграционный API-метод: как это работает? 👩‍💻

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

▫️Frontend – пользовательский интерфейс. Он не всегда есть в интеграционных задачах, но если присутствует, то выполняет роль инициатора запросов.

▫️Backend – серверное приложение, которое отвечает за логику обработки данных, их проверку и взаимодействие с внешними системами.

▫️Внешняя система – источник или получатель данных, с которым взаимодействует наш Backend.

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


👉 Интеграционный API-метод – это метод на стороне нашего Backend, который:
+ принимает запросы от Frontend-приложения;
+ взаимодействует с внешней системой для получения или записи данных;
+ реализует логику сопоставления (маппинга) и обработку данных.


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

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

✅ Безопасность:
Хранить секретные ключи на стороне Frontend небезопасно – они могут быть скомпрометированы (например, перехвачены через консоль браузера). Размещение ключей на Backend исключает этот риск.


Пример алгоритма работы интеграционного API-метода разобрала в мини-книге к посту 🤝

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

Коллеги, еще раз огромное и искреннее спасибо вам за участие во вчерашней онлайн-практике по REST, GraphQL и gRPC для интеграций! ❤️

Это был последний прямой эфир в 2024 году.
Проведен в качестве открытого урока практической программы Интеграции систем.
И прошел он невероятно! 😍


Что успели:

1️⃣ Протестировали три разных вида API в Postman: REST API, GraphQL и gRPC.

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

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

4️⃣ Разобрались в различиях между протоколами: например, помимо привычного HTTP/1.1 для REST API, изучили использование HTTP/2 в gRPC, его принципы работы и преимущества.

5️⃣ Обсудили множество вопросов, связанных не только с использованием, но и с проектированием методов REST API и GraphQL. В дополнение, коллегам была передана моя статья о работе с файлами .proto для gRPC.


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


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

‼️ Для тех, кто не был онлайн, либо отключился раньше:
+ мы пришлём запись в субботу утром всем, кто был зарегистрирован
+ запись будет доступна с 21 до 23 декабря
+ регистрация на получение записи будет открыта до пятницы (тем, кто был зарегистрирован на основной эфир, повторно регистрироваться НЕ надо)

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

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

У меня лучшая аудитория!
Активная, осознанная и вовлеченная.
Любящая свое дело.
И не меньше чем я увлеченная системной аналитикой!

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

❗️Уже через 3 часа❗️

Практический вебинар с Екатериной Ананьевой!

📹 Интеграции по REST, GraphQL и gRPC: знакомство через Postman
⏰ 19:00 МСК

Ссылку на прямой эфир пришлем в канал за 15 минут до начала.

📕 Подборка материалов по REST API, GraphQL, gRPC 📕

Уже сегодня на онлайн-практике будем изучать все виды API с использованием Postman.

А пока предлагаю познакомиться с нашими дополнительными материалами к занятию и посмотреть их до/после практики, чтобы закрепить результат 👇


⚡ REST API (Representational State Transfer)
Использует HTTP-протокол и основывается на концепциях ресурсов и методов (GET, POST, PUT, PATCH, DELETE и другие).
Широко используется для веб-, мобильных приложений и микросервисной архитектуры.
🔗 Официальная документация
📚 Проектирование REST API: спорные вопросы с проектов и собеседований на системного аналитика (и не только)
📚 Postman: навык тестирования REST API за вечер
📚 Вопросы и ответы по REST API: собеседование на системного аналитика (подкаст)

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


⚡ GraphQL
Позволяет клиенту запрашивать только те данные, которые ему необходимы, с помощью декларативного языка запросов.
Удобен для сложных приложений с изменяемыми потребностями в данных, для мобильных приложений и микросервисов с целью оптимизации трафика между клиентом и сервером, который реализует API.
🔗 Официальная документация
📚 GraphQL — знакомство на практике через Postman [пошаговая инструкция]

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


⚡ gRPC
Использует Protocol Buffers для сериализации данных и поддерживает как синхронные, так и асинхронные вызовы.
Эффективен для микросервисной архитектуры с высокими требованиями к производительности.
Очень много коллег, кто в новых проектах на микросервисной архитектуре его использует сразу, даже не рассматривая REST.
🔗 Официальная документация
📚 gRCP vs REST - что выбрать для проекта (подкаст + материалы)

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


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

🎲 Интеграционный Use Case: заполненный шаблон требований 🎲

В посте о проекте я описала общий процесс работы системы #EventTasksGA AS IS (как есть) и требования к его автоматизации.

За этим небольшим текстом с требованиями скрывается:
+ несколько независимых процессов работы пользователей,
+ десятки задач для разработчиков Backend и Frontend,
+ а также технические требования для их реализации.

👉 Чтобы показать, как описывать интеграционный Use Case, я взяла ключевой процесс:
“Автоматическое создание задач в Todoist после успешной оплаты заказа, без автоназначения ответственного”.

А так как я предпочитаю показывать суровую реальность… 🙈
Заполнила для вас основную часть шаблона постановки задачи на интеграцию в Confluence.
Маппинги, требования к интеграционным методам и брокеру еще впереди 😉

Заполненный шаблон с примером интеграционного Use Case прикреплен к посту 🎀

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

💚 DDD и Event Storming - архитектура для системного аналитика 💚

В этом эпизоде мы рассказываем об архитектуре систем, а именно о двух мощных инструментах, которые могут существенно изменить подход системного аналитика к проектированию сложных систем: Domain Driven Design (DDD) и Event Storming.

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

🔗 Сайт эпизода

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

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

🔵 Sructurizr - один из основных инструментов, который позволяет создавать схемы архитетуры в нотации C4 через код 🔵

В этой статье я показывала примеры кода для одного из демо-проектов, которые ранее разбирались в канале GetAnalyst.
P.S. В нем уровень контейнеров для Backend у меня упрощен.

Сейчас я хочу предложить вам познакомиться с архитектурой в C4 и кодом Sructurizr для проекта #FarmFreshGA и посмотреть на пару уровней, согласно официальным требованиям нотации по визуализации архитектуры.


👉 Уровень Контекст (C4 / Context)
Система, её интеграции и пользователи.
✔️ Главный прямоугольник - наша система
✔️ Серые прямоугольники вокруг - внешние системы
✔️ Пользователи

👩‍💻 Полезна бизнес- и техническим специалистам.


👉 Контейнеры (C4 / Container)
Независимые по коду приложения внутри системы, детализация главного прямоугольника c C4 / Context.
✔️ Пользователи и внешние системы с уровня C4 / Context
✔️ Мобильные, веб- и десктоп приложения
✔️ Сервер-приложения: монолит, сервисы, микросервисы, API Gateway
✔️ Базы данных и файловые хранилища
✔️ Виды API
✔️ Технологии (языки программирования, СУБД, протоколы для API и др)
✔️ Базы данных и файловые хранилища
✔️ Очереди и брокеры
Схему удобнее использовать в адаптированном виде, когда на этом уровне не показывают сервисы и микросервисы, а переносят их на уровень глубже - C4 / Component. Иначе она очень перегружена.

👩‍💻 Полезна архитекторам, разработчикам и системным аналитикам.


Схемы в виде скрина из Structurizr прикрепрены к посту.

Исходный код для вставки в Structurizr:
🔗 ссылка на файл с кодом

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

📚 Моделирование архитектуры в нотации С4 📚

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

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

Если в отрасли есть стандарты, лучше использовать их.
Поэтому предлагаю познакомиться с нотацией C4, где есть несколько уровней описания системы, которые помогают понять её 🙂

📚C4 - нотация моделирования архитектуры, которая упрощает визуализацию сложных систем.


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

👉 Контекст (C4 / Context) - система, её интеграции и пользователи.

👉 Контейнеры (C4 / Container) - независимые по коду приложения внутри системы, детализация главного прямоугольника c C4 / Context.

👉 Компоненты (C4 / Component) - модули кода и зависимости между ними, детализирует один из контейнеров с C4 / Container.

👉 Код (C4 / Code) - описывает реализацию кода для конкретных компонентов системы, детализирует C4 / Component.


Материалы для быстрого самостоятельного изучения C4:
🔗 Официальный сайт C4 (англ)
🔗 Шаблон с примером архитектуры в Miro
🔗 Нотация моделирования архитектуры С4 — примеры диаграмм и инструменты


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

👀 Пример использования Kafka в #FarmFreshGA 👀

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

Примеры:
1. SMS после регистрации пользователя
2. фоновые задачи после оплаты заказа

Алгоритмы с картинками в прикрепленном файле 🤝

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

👉 Алгоритм работы Kafka

1. Producer отправляет сообщение в определённый топик, разделы которого распределены по брокерам.

2. Kafka сохраняет сообщение.
Сообщение записывается в раздел топика и сохраняется на диске.

3. Consumer подключается к Kafka, выбирает топик и читает сообщения из нужного раздела.



👉 Kafka поддерживает несколько моделей доставки:

+ Сообщение доставляется максимум один раз.

+ Сообщение может быть доставлено несколько раз (с гарантией доставки).

+ Сообщение доставляется ровно один раз.



👉 Примеры использования Kafka:

Финансовые транзакции
1. Банковские системы отправляют транзакции в Kafka.
2. Сервисы банка получают и обрабатывают транзакции в реальном времени с высокой степенью надежности.

Централизованная система уведомлений
1. Разные сервисы системы отправляют уведомления в Kafka.
2. Отдельные сервис Уведомлений получает их для отправки email, SMS и push через интеграции.



👉 Проблемы Kafka
➖ Нуждается в хорошей настройке (особенно при больших объёмах данных).
➖ Не всегда оптимальна для задач с малым количеством данных.



👉 Почему выбирают
Kafka выделяется среди других решений по брокерам благодаря своей надёжности и способности обрабатывать огромные объёмы данных. Это делает её оптимальным выбором для высоконагруженных систем.


🔎 Я только начинаю знакомство с Kafka? Что делать?
Я бы рекомендовала начать с изучения официальной документации Kafka (не стесняемся пользоваться Google Translate или ChatGPT для переводов) или книги Kafka Streams в действии.


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

🔲 Про брокер Kafka 🔲

Kafka — это:

1. Брокер сообщений: Kafka позволяет приложениям обмениваться данными, как через очереди сообщений.

2. Платформа потоковой обработки: Она не только пересылает данные, но и позволяет обрабатывать их в реальном времени.

3. Хранилище событий: Kafka может сохранять данные длительное время, что делает её подходящей для анализа и аудита.


👉 Kafka состоит из следующих ключевых компонентов:

◽️ Producer (Производитель)
Приложение, которое отправляет данные (сообщения) в Kafka.
Пример: Сервис интернет-магазина отправляет данные о новых заказах.

◽️ Broker (Брокер)
Узел (сервер) в кластере Kafka, который обрабатывает сообщения.
В кластере может быть несколько брокеров, чтобы обеспечить масштабируемость и отказоустойчивость.

◽️ Topic (Топик)
Логическое место, куда отправляются сообщения.
Сообщения в топике упорядочены и распределены по разделам (partitions).

◽️ Partition (Раздел)
Каждый топик делится на разделы (partitions).
Сообщения в разделе упорядочены (по времени или оффсету).

◽️ Consumer (Потребитель)
Приложение, которое читает данные из топика.
Может быть несколько потребителей, объединённых в группы.

◽️ ZooKeeper (или KRaft)
Система координации, которая управляет метаданными Kafka. В новых версиях ZooKeeper заменён на собственный механизм KRaft.


👉 Особенности Kafka
➕ Высокая производительность: Kafka может обрабатывать миллионы сообщений в секунду.
➕ Масштабируемость: Кластер Kafka можно масштабировать, добавляя новые брокеры.
➕ Долговременное хранение:
Сообщения сохраняются в Kafka на заданное время или пока не удалены вручную.
➕ Устойчивость к сбоям:
Репликация разделов (partitions) между брокерами обеспечивает отказоустойчивость.


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


Продолжение завтра 👇

Брокер сообщений — это программное обеспечение, которое управляет обменом сообщениями между приложениями, сервисами или системами.

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

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

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

Очередь хранит и упорядочивает сообщения до тех пор, пока потребляющие приложения не смогут их обработать. В ней сообщения обычно хранятся в том порядке, в котором они были переданы от отправителя (Producer), и остаются там до подтверждения их получения получателем (Consumer).


Брокеры сообщений предлагают два основных паттерна (шаблона) обмена данными:

1. Точка-точка (Point-to-Point Messaging)
Это паттерн, используемый в очередях сообщений, где существует один отправитель и один получатель. Каждое сообщение в очереди отправляется только одному получателю и может быть обработано только один раз.

2. Публикация-подписка (Publish/Subscribe Messaging)
В этом паттерне отправитель (producer) публикует сообщения в определённую тему (topic), а подписчики (consumers) подписываются на темы, чтобы получать сообщения.
Все сообщения, опубликованные в теме, доставляются всем приложениям, подписанным на неё.
Применяется в случаях, где несколько систем должны получить одну и ту же информацию.


Возможности и логика работы брокеров отличаются в зависимости от конкретного решения.


Основные решения по брокерам на рынке:
✅ Apache Kafka
✅ RabbitMQ
✅ ActiveMQ
✅ Amazon MQ, Amazon SQS
✅ Яндекс Message Queue (YMQ) - аналог Amazon
✅ и другие.

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

🕵️ Исследуем конференции для СА и БА 🕵️

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

Давайте поможем им узнать больше и собрать полную подборку мероприятий по всему миру.

Расскажите о каких конференциях вы знаете в кратком опросе.


🎁 Среди тех, кто заполнит опрос, будет разыгран билет на любую конференцию в России для аналитиков, на выбор победителя. С победителем свяжутся через указанные контакты.

🕐 На заполнение нужно 5 минут.


Пройти опрос можно по ссылке.

💬 Очередь сообщений VS Брокер сообщений 💬

Очередь сообщений — это структура данных, которая хранит сообщения до тех пор, пока их не заберёт получатель.

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


❗️Вопросы с подвохом:

👉 1. Если у нас есть очередь сообщений, зачем нужен брокер?
Очередь сообщений — это только структура данных для хранения сообщений, а брокер сообщений предоставляет дополнительные функции, такие как:
+ Управление множеством очередей.
+ Маршрутизация сообщений.
+ Поддержка нескольких потребителей.
Брокер — это более комплексная система, в состав которой входят очереди.


👉 2. Может ли очередь работать без брокера?
Да, тогда это будет просто временное хранилище сообщений.


👉 3. Могу ли я использовать брокер без очередей сообщений?
Нет. Очереди — одна из базовых составляющих большинства брокеров. Однако брокеры предоставляют более широкую функциональность, например, топики для публикации/подписки, что выходит за рамки простых очередей.


👉 4. Если я использую очередь сообщений, могу ли я гарантировать доставку сообщения?
Не всегда. Очередь сообщений сама по себе не гарантирует доставку, если нет спец. механизмов. Брокер сообщений, с другой стороны, предоставляет такие функции, как подтверждение доставки и повторная доставка сообщений в случае сбоя.


👉 5. Очередь всегда работает по принципу FIFO (первое пришло - первое вышло из очереди)?
Нет, не всегда. Хотя FIFO — это распространённый механизм, очереди могут быть:
+ Приоритетными (Priority Queue): Сообщения с высоким приоритетом обрабатываются первыми.
+ LIFO (Last In, First Out): Последнее сообщение обрабатывается первым.
и другие.


👉 6. Может ли очередь работать с несколькими производителями и потребителями?
Технически да, но это усложняет реализацию, если очередь реализована без брокера.

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

💌 Очередь сообщений - что это и как работает? 💌

Очередь сообщений — это структура данных, которая хранит сообщения или пакеты данных до тех пор, пока их не заберёт получатель для последующей обработки.

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

✔️ Публикуют в неё сообщения (Producer).
✔️ Читают и обрабатывают сообщения из неё (Consumer).

Подробнее про очереди сообщений можно узнать в мини-книге, прикрепленной к посту 🙂

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

🚀 Завершается запись на открытый урок по Архитектуре 🚀

Коллеги, кому актуально освоение навыков для middle+ и senior аналитиков - вам сюда!



Простыми словами, решая реальную задачу, разбираю тему:

💎 Проектирование архитектуры: от монолита к микросервисам
🗓 Доступ с 30 ноября до 2 декабря (СБ-ПН)
👉 Подробности и регистрация



В результате этого обучения:

🌟 Поймете основы проектирования архитектуры.
🌟 Разберетесь в отличиях монолита, сервисов и микросервисов.
🌟 Научитесь проектировать архитектуру с нуля.
🌟 Узнаете, как происходит переезд с монолита на микросервисы.
🌟 Получите готовые схемы и подходы по проектированию.

Смотрите, перенимайте опыт, и применяйте в своей работе! ⚡️

💎 Пример схемы архитектуры проекта #FarmFreshGA (продолжение 👇) 💎


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

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

Итог: 5 сервисов обращаются к одному, что может привести к задержкам при синхронном взаимодействии из-за загрузки

Решение: для уменьшения нагрузки использовать асинхронное взаимодействие через брокеры сообщений (например, RabbitMQ или Kafka), чтобы уведомления отправлялись без ожидания ответа.



5. У каждого микросервиса своя БД

Это строго соответствует принципам микросервисной архитектуры.

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


6. Взаимодействие с сервисом чата организовано через WebSocket

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

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

Заключение:

Предложенная схема архитектуры FarmFresh демонстрирует базовую реализацию микросервисного взаимодействия с шаблоном API Gateway.

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


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

💎 Пример схемы архитектуры проекта #FarmFreshGA 💎

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

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


1. Для проектирования архитектуры FarmFresh выбран шаблон API Gateway
Все запросы от клиентских приложений (Frontend) направляются в единый централизованный шлюз и далее проксируются (перенаправляются) на отдельные микросервисы, в зависимости от запроса.


2. Согласно предложенной схеме, внутреннее взаимодействие микросервисов организовано также через API Gateway
Надо понимать, что такое решение не всегда удачно.
Пример: Если сервису заказов нужно вернуть полную информацию о нём на Frontend, включая данные о товарах, то вместо прямого запроса в микросервис "Каталог товаров" придётся прогонять запрос через лишний слой API Gateway. Это может создавать ненужную задержку.


3. Снаружи для клиентов может быть только REST API, а “под капотом” всё что угодно
На предложенной схеме видим, что часть микросервисов предлагает взаимодействие через gRPC для ускорения обмена данными, а часть — через REST API. Однако слишком много разных видов API может усложнить разработку и сопровождение.
Простота и единообразие — залог успешной архитектуры.
Но зависит от проекта))) Где-то это просто нужно и точка.


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


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

🌪 Способы обмена данными между приложениями и системами 🌪

В этом посте собрана подборка материалов по разным способам взаимодействия систем.


⚡ REST
🔗 Официальная документация
📚 Проектирование REST API: спорные вопросы с проектов и собеседований на системного аналитика (и не только)
📚 Postman: навык тестирования REST API за вечер
📚 Вопросы и ответы по REST API: собеседование на системного аналитика (подкаст)
Пример API-документации:
Wildberries


⚡ SOAP
🔗 Официальная документация
Пример API-документации:
PayPal (обратите внимание, что устаревший)


⚡ WebSocket
🔗 Официальная документация
Пример API-документации:
Binance Биржа


⚡ GraphQL
🔗 Официальная документация
📚 GraphQL — знакомство на практике через Postman [пошаговая инструкция]
Пример API-документации:
Contentful


⚡ gRPC
🔗 Официальная документация
📚 gRCP vs REST - что выбрать для проекта (подкаст + материалы)
Пример API-документации:
Dropbox от Google


⚡ SSE
🔗 Официальная документация


⚡+ есть Socket.IO

Знание всех подходов к взаимодействию между системами помогает в работе с проектированием архитектуры.

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

📚 Как выделять микросервисы? 📚

1️⃣ По группам функций
2️⃣ По доменам (Domain-driven Design, DDD)
3️⃣ По данным
4️⃣ По пользовательским сценариям
5️⃣ По уровню нагрузки

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

А подробнее и с примерами рассказала о них в мини-книге, прикрепленной к посту.

Сохраняем в личную библиотеку книг от GetAnalyst 💜

#АрхитектураGA #FarmFreshGA

🔸 Микросервисная архитектура MSA (Microservice Architecture)
MSA состоит из множества маленьких, независимо разрабатываемых и развертываемых сервисов, каждый из которых выполняет одну бизнес-функцию.

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

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

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

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



Выбор архитектуры проекта зависит от специфики и требований к системе.
На практике часто используют либо смесь подходов SOA и MSA, либо начинают проекты с монолита и через 3-5 лет задумываются о переезде на SOA в качестве первого этапа деления монолита на микросервисы.

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

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

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

🔸 Монолит, Сервисная и Микросервисная архитектура - сравнение 🔸

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

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

🔸 Монолитная архитектура
В монолитной архитектуре все компоненты приложения находятся в одной кодовой базе и работают как единое целое. Это обеспечивает простоту разработки и релизов системы.
Хорошо подходит для стартапов и небольших проектов.

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

Внутренние интеграции:
Все компоненты взаимодействуют только на уровне кода, интеграции компонентов внутри Backend по API и другими способами не нужны.


🔸 Сервисная архитектура SOA (Service-Oriented Architecture)
SOA разделяет функциональность на отдельные сервисы, которые взаимодействуют между собой через сетевые вызовы - по API, через шину данных (ESB) или другими способами.

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

Например, в Магазине доставки фермерских продуктов сервис каталога товаров и сервис заказов можно поделить, чтобы инсталлировать на сервере 10 копий сервиса каталога, но всего 3 копии сервиса заказов, т.к. до заказа товаров доходит меньше пользователей чем тех, кто просто смотрит каталог.

БД:
Каждый сервис может использовать свою собственную БД, что облегчает масштабирование и изоляцию сервисов, но также несколько сервисов могут использовать одну БД, что отличает SOA от MSA.

Внутренние интеграции:
Сервисы интегрируются через API, что упрощает интеграцию. Могут использовать шину - ESB.

#АрхитектураGA #FarmFreshGA

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

⚡️ НФТ - примеры по проекту доставки фермерских продуктов #FarmFreshGA ⚡️

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

Рассмотрим основные НФТ и их реализацию в контексте проекта FarmFresh (FF):

1. Производительность
2. Масштабируемость
3. Отказоустойчивость

Подробности на картинках к посту 🖼☝️☝️☝️

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

🌱 Открыта запись на Архитектуру для системных аналитиков 🌱

Погружение в архитектуру и опыт работы в сложных проектах с микросервисами - точки роста для опытных системных аналитиков уровня Middle+.

Чтобы помогать вам достигать максимального уровня в карьере, мы создали практическую программу “Архитектура систем”.

В ходе работы на ней мы будем:
✔️ Строить архитектуру проекта с нуля: монолит, сервисная, микросервисная.
✔️ Практиковаться работать с нотацией C4.
✔️ Подбирать API для проекта и учиться работать с ними на практике: REST, GraphQL, WebSocket и другие.
✔️ Ставить задачи на брокеры (Kafka, RabbitMQ), Webhooks и знакомиться с другими способами асинхронного взаимодействия систем.

Собрали всё, что нужно для проектирования систем на самом глубоком техническом уровне для аналитиков.


Цели, которые ставят и реализуют наши аналитики в процессе обучения:
✅ Повышают грейд внутри компании
✅ Переходят из проектной разработки в продукт
✅ Структурируют знания и проходят аттестации
✅ Получают повышения
✅ Проходят собеседования и выбирают офферы по душе 🩷

Приглашаем и вас достигать новые цели вместе с нами! 🙌

🌟 Проектирование архитектуры
🗓 Старт предобучения: 3 декабря 2024
👉 Подробности о программе и запись

🎁 До 25 ноября открыта предзапись на специальных условиях:
скидка + дополнительное обучение по проектированию REST API в подарок.

Все вопросы можно задать через сайт, на почту [email protected] или в Telegram @getanalyst.

💚🎁 Analyst Days 19 + GetAnalyst - дарим подарки 🎁💚

В любой профессии важно развивать нетворкинг и постоянно учиться новому. Благодаря профессиональным связям можно найти отличные карьерные возможности и перенять ценный опыт от коллег.

И если говорить о рекомендуемых конференциях для аналитиков, то однозначно Analyst Days.

Я сама участвовала в Analyst Days, в том числе как спикер. Поэтому знаю всю “внутрянку”:
➕ Строгий отбор докладов — только самое актуальное и полезное.
➕ Подготовка каждого спикера в течение 2+ месяцев.
➕ Мощные темы, особенно для тех, кто менее 3 лет в аналитике или только планирует входить в эту область.

Программа Analyst Days-19 выглядит так 😍



Мы не первый год сотрудничаем с Analyst Days, и в этом году решили подготовить для вас особенный сюрприз:

🎁 Промокод на скидку 15% для онлайн-участия: GetAnalyst

🎁 Розыгрыш одного БЕСПЛАТНОГО билета на Analyst Days-19 (онлайн, 22-23 ноября)

🎁 Розыгрыш БЕСПЛАТНОГО 3-месячного доступа к продвинутым практикумам по БД и SQL (можно активировать до 01.02.2025)

Бесплатный билет и доступ к подписке подарим двум разным участникам сообщества!



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

🔗 ССЫЛКА НА АНКЕТУ

Мы выберем двух победителей на основе лучших ответов, которые опубликуем в канале вместе с результатами! 😎 Читать будем всё 👀


Итоги объявим 18 ноября.

Участвуйте и не упустите шанс для очередного шага в профессиональном развитии! 🚀

📚 Подборка книг про архитектуру и микросервисы 📚

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

📚 Domain Driven Design. Предметно-ориентированное проектирование, Эрик Эванс

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

Особенно она помогла в подходах к определению сервисов и микросервисов системы, границ их функциональности.


В дополнение к ней я бы хотела порекомендовать:

📚 Release it! Проектирование и зайн ПО для тех, кому не все равно, Майкл Нейгард (тоже мой фаворит!)

📚 Создание микросервисов, Сэм Ньюмен

📚 Микросервисы. Паттерны разработки и рефакторинга, Крис Ричардсон

📚 Высконагруженные приложения, Мартин Клеппман

📚 Чистая архитектура. Искусство разработки программного обеспечения, Роберт Мартин

📚 Эволюционная Архитектура, Нил Форд, Ребекка Парсонс, Патрик Куа

📚 DDD - предметно ориентированное проектирование, Влад Хононов

Новогодние каникулы скоро, будет время на полезное чтение 🎄

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

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

📈 Масштабирование - что это и как его обеспечить в рамках системы 📈

Термин "масштабироваться" относится к способности системы адаптироваться к изменяющемуся количеству функций в ней или запросов от пользователей: увеличение или уменьшение ресурсов и мощностей для обеспечения эффективной работы.


Масштабирование может быть вертикальным или горизонтальным.

⭐ Вертикальное масштабирование (scaling up/down) означает добавление ресурсов к одному серверу или экземпляру приложения. Например, увеличение объёма оперативной памяти, мощности процессора или места на диске.

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

👉 Вертикальное масштабирование имеет свои ограничения, связанные с максимально доступными ресурсами оборудования - нельзя бесконечно добавлять память и ядра процессора.



⭐ Горизонтальное масштабирование (scaling out/in) подразумевает добавление дополнительных экземпляров серверов или приложений, работающих параллельно, для распределения нагрузки. Т.е. запускаются одинаковые копии приложений.

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

👉 Горизонтальное масштабирование обычно предпочтительнее, так как оно обеспечивает более высокую доступность и устойчивость к отказам.



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


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

⭐️ Онлайн-практикум по миграциям в БД [18 ноября - ПН] ⭐️

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

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

👉 Миграция в контексте БД это:
1. Доработка таблиц БД - добавление новых таблиц или полей, их изменение в существующей БД.
2. Перенос данных из одной БД в другую - например, при проектировании микросервисной архитектуры.

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

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

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

Проект: БД системы страховой компании.


👉 Практикум проводится в рамках подписки на практикумы по БД и SQL.

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

🔥📚 7 шаблонов проектирования архитектуры, которые важно понимать СА 📚🔥

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

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

А вот в сложных продуктовых компаниях, таких как банки, маркетплейсы и страховые компании, базовых знаний недостаточно. Здесь чаще встречается сложная сервисная (SOA) или микросервисная (MSA) архитектура.

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

👉 Собрала для вас 7 основных шаблонов проектирования архитектуры, которые важно понимать СА.

Рассказала о каждом с примерами и картинками, про связи между ними, и зачем их нужно знать аналитикам.

1. Монолит
2. Слоистая архитектура
3. Модульная архитектура
4. Клиент-Серверная архитектура
5. Сервис-ориентированная Архитектура (SOA)
6. Микросервисная архитектура (MSA)
7. Событийно-ориентированная архитектура (EDA)

Всю информацию собрала в мини-книгу прикрепленную к посту 📚

Загружайте и сохраняйте в личный архив!

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

One more step has been completed 😎 Друзья, отличного воскресенья и крутых новостей на следующей неделе! Всё получится 🙌

🔥🧩 Какие диаграммы нужно знать системному аналитику 🔥🧩

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

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

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

🔗 Сайт эпизода с гайдом по диаграммам

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

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

Ставьте реакции, делитесь эпизодом с коллегами и не забывайте сохранять себе полный гайд по диаграммам для СА со страницы эпизода ❤️‍🔥

🔷 Лайфхаки по поиску работы для аналитиков через LinkedIn 🔷

Поиск работы — важный этап в развитии карьеры, с которым IT-специалисты обычно встречаются каждые 3-5 лет. Делать это можно разными способами, на разных площадках.

Сегодня я хочу рассказать про LinkedIn - профессиональную социальную сеть, на которой вы по сути оформляете свой профиль как резюме. Можно сказать, что это продвинутый аналог hh.ru или Habr-карьеры.

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

В ней вы найдёте:

✅ Общую информацию про LinkedIn,
✅ 3 способа поиска работы (третий - самый эффективный),
✅ подборку материалов для подготовки к собеседованиям.

Даже если вы сейчас не ищете работу, рекомендую создать и поддерживать профиль в LinkedIn в актуальном состоянии, чтобы развивать свои профессиональные контакты как в России, так и за её пределами.

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

🔗 Ссылка на статью


Кто уже знаком с соцсетью, поделитесь в комментариях к посту вашим опытом с LinkedIn 🙏

📚 Что почитать и посмотреть по REST API: подборка материалов от GetAnalyst 📚

У нас много новых участников в сообществе 🙌 И…! Вместо того, чтобы рассказывать о себе, я решила сделать для вас подборку из полезных материалов по проектированию REST API. Так вы лучше узнаете меня - Екатерину Ананьеву - не на словах, а на деле 🙂

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

(В) Связь базы данных и дизайна REST API

(C) Простыми словами про API

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

(В) Проект “Система для автосервиса” - видео-обучение.
1. Системный анализ проекта с нуля: Сбор бизнес-требований, погружение в контекст
2. Системный анализ для проекта: определение сущностей и проектирование логической модели БД
3. REST API с нуля: дизайн методов для работы менеджера с заявками автосервиса

(C) Postman: Практическое руководство с примером тестирования открытого API

(С) Postman: Практическое руководство с примером тестирования открытого API - 2.0

(П) Вопросы и ответы по REST API: собеседование на СА

(С) Мини-книга с подробным разбором формата сообщений JSON

(В) Собеседование на СА: разбор задачи на асинхронные запросы в REST API

(C) Структура постановки задачи на REST API метод

(П) gRPС vs REST - что выбрать для проекта

(C) Проектирование REST API: спорные вопросы с проектов и собеседований на системного аналитика (и не только)

Также вы можете найти у нас мини-обучения по REST API и практическую программу "Дизайн REST API" для опытных аналитиков.

(В) Видео
(П) Подкасты
(С) Статьи

Делитесь с коллегами, особенно с джунами и мидлами СА!
Сохранили? ❤️

#RestApiGA

📄 Шаблон постановки задачи на REST API метод 📄

Структура требований для разработчиков Backend, которую можно использовать в Confluence при описании контрактов REST API методов.

1. Название метода
2. Общее описание
3. Алгоритм работы
4. Пример запроса
5. Пример ответа: успех и ошибки
6. Маппинг данных
7. Дополнительные требования

Аналогичную структуру постановки задачи можно реализовать через инструменты документирования и тестирования API - Postman и Swagger.

Подробнее в статье:
🔗Структура постановки задачи на REST API метод

Также по ней очень удобно делать команды к ChatGPT - это Искусственный Интеллект, который как младший системный аналитик помогает в разработке требований и делает половину работы за вас 🙌

#RestApiGA

Друзья, делитесь, а какие у вас были озарения после стажировки?😎

#GAhahaha