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

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


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

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

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



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


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

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


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

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

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


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

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

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


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

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


Как сделать аналогичную документацию в 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: что важно для работы с требованиями и собеседований 🔐

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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


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

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

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

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

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

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

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

✨ Монолит ⚔ Сервисы (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