🟢🟠 Инструменты для работы с API: полный гайд для СА 🟡🟣
Зачем аналитику знать инструменты для тестирования и документирования API?
👉 Интеграции:
СА необходимо убедиться, что API внешней системы будет работать именно так, как описано в документации (если она есть, а если нет - то составить), чтобы затем предоставить информацию разработчикам.
Тестирование API внешних систем в специализированных инструментах помогает выявить проблемы в работе внешних систем на ранних стадиях разработки, несоответствия документации реальности, а также проверить полноту данных и доступность сервисов в целом.
👉 Backend-команды, которым нужно ставить задачи на API:
Нужно уметь самому с нуля проектировать и документировать API, желательно с использованием специализированных инструментов как Postman и Swagger, а не только в Confluence-подобных системах.
Список инструментов, которые помогают системным аналитикам в тестировании и документировании API:
🟠 Postman
🟡 SoapUI
🟣 Insomnia
🟢 Swagger
Подробности в картинках к посту ☝️
+🐶 Bruno - аналог Postman, всё больше завоёвывает сердца аналитиков, его нет в картинках к посту.
👉 Рекомендую поработать со всеми инструментами и выбрать наиболее удобный для себя.
Делюсь практическими гайдами, с которыми вы сможете поработать с инструментами сами, с понятными пошаговыми инструкциями:
▫️ Postman: Практическое руководство с примером тестирования открытого API
▫️ GraphQL — знакомство на практике через Postman [пошаговая инструкция]
▫️ Postman: навык тестирования REST API за вечер
▫️ Swagger - практическое руководство по документированию API
Пользуйтесь! 🤩
#RestApiGA
Зачем аналитику знать инструменты для тестирования и документирования API?
👉 Интеграции:
СА необходимо убедиться, что API внешней системы будет работать именно так, как описано в документации (если она есть, а если нет - то составить), чтобы затем предоставить информацию разработчикам.
Тестирование API внешних систем в специализированных инструментах помогает выявить проблемы в работе внешних систем на ранних стадиях разработки, несоответствия документации реальности, а также проверить полноту данных и доступность сервисов в целом.
👉 Backend-команды, которым нужно ставить задачи на API:
Нужно уметь самому с нуля проектировать и документировать API, желательно с использованием специализированных инструментов как Postman и Swagger, а не только в Confluence-подобных системах.
Список инструментов, которые помогают системным аналитикам в тестировании и документировании API:
🟠 Postman
🟡 SoapUI
🟣 Insomnia
🟢 Swagger
Подробности в картинках к посту ☝️
+
👉 Рекомендую поработать со всеми инструментами и выбрать наиболее удобный для себя.
Делюсь практическими гайдами, с которыми вы сможете поработать с инструментами сами, с понятными пошаговыми инструкциями:
▫️ Postman: Практическое руководство с примером тестирования открытого API
▫️ GraphQL — знакомство на практике через Postman [пошаговая инструкция]
▫️ Postman: навык тестирования REST API за вечер
▫️ Swagger - практическое руководство по документированию API
Пользуйтесь! 🤩
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤35👍4🔥3👏2
🔐 Авторизация и аутентификация в REST API: что, зачем и как 🔐
▫️ Аутентификация (Authentication) — подтверждение, что это действительно тот клиент / пользователь, за кого он себя выдаёт.
Проверяется при входе в систему, когда пользователь предоставляет ключи доступа:
+ логин+пароль
+ токен
Если аутентификация не пройдена, то API должен вернуть ошибку HTTP-401.
▫️ Авторизация (Authorization) — проверка прав аутентифицированного клиента: что ему можно, а что нет.
При выполнении очередного действия в системе, например - удаление мероприятия в календаре, надо проверить, что у него есть права на это (он его создал, оно в его календаре).
Если нет прав, то API должен вернуть ошибку HTTP-403.
▫️ Основные схемы аутентификации
🔑 API-ключи
• Простая пара «ключ=значение» в заголовке X-API-Key.
• Быстро настраивается, но статичен и часто уязвим (нет ротации, нет TTL).
Пример Header:
🔒 HTTP Basic Auth
• Передаёт логин/пароль закодированным в Base64 в заголовке Authorization: Basic <credentials>.
• Использовать только по HTTPS.
Пример Header:
🚀 JWT (JSON Web Token)
• Короткоживущий токен с подписанным payload’ом (claims).
• Передача в заголовке Authorization: Bearer <token>.
• Удобен для распределённых систем: нет обращений к БД при каждом запросе.
🌐 OAuth 2.0
• Полноценный фреймворк (стандарт) для выдачи и обновления токенов: Access + Refresh Token.
• Подходит для публичных API и сторонних интеграций.
• Поддерживает разные гранты (Client Credentials, Authorization Code и другие).
▫️ В описании API-метода обязательно указать:
+ какую схему аутентификации поддерживаем
+ формат токена (JWT, UUID и т.д.)
+ куда передавать (заголовок, query-параметр, cookie)
+ список возможных ошибок и их тело (JSON-ответ)
🎧 Подкаст и статья тут 🙂
#RestApiGA
▫️ Аутентификация (Authentication) — подтверждение, что это действительно тот клиент / пользователь, за кого он себя выдаёт.
Проверяется при входе в систему, когда пользователь предоставляет ключи доступа:
+ логин+пароль
+ токен
Если аутентификация не пройдена, то API должен вернуть ошибку HTTP-401.
▫️ Авторизация (Authorization) — проверка прав аутентифицированного клиента: что ему можно, а что нет.
При выполнении очередного действия в системе, например - удаление мероприятия в календаре, надо проверить, что у него есть права на это (он его создал, оно в его календаре).
Если нет прав, то API должен вернуть ошибку HTTP-403.
▫️ Основные схемы аутентификации
🔑 API-ключи
• Простая пара «ключ=значение» в заголовке X-API-Key.
• Быстро настраивается, но статичен и часто уязвим (нет ротации, нет TTL).
Пример Header:
X-API-Key: 123e4567-e89b-12d3-a456-426614174000
🔒 HTTP Basic Auth
• Передаёт логин/пароль закодированным в Base64 в заголовке Authorization: Basic <credentials>.
• Использовать только по HTTPS.
Пример Header:
Authorization: Basic bXlVc2VyOm15UGFzc3dvcmQ=
🚀 JWT (JSON Web Token)
• Короткоживущий токен с подписанным payload’ом (claims).
• Передача в заголовке Authorization: Bearer <token>.
• Удобен для распределённых систем: нет обращений к БД при каждом запросе.
🌐 OAuth 2.0
• Полноценный фреймворк (стандарт) для выдачи и обновления токенов: Access + Refresh Token.
• Подходит для публичных API и сторонних интеграций.
• Поддерживает разные гранты (Client Credentials, Authorization Code и другие).
▫️ В описании API-метода обязательно указать:
+ какую схему аутентификации поддерживаем
+ формат токена (JWT, UUID и т.д.)
+ куда передавать (заголовок, query-параметр, cookie)
+ список возможных ошибок и их тело (JSON-ответ)
Нужно глубже погрузиться в тему аутентификации
и авторизации в API?
🎧 Подкаст и статья тут 🙂
#RestApiGA
❤26🔥8
Бесплатное практическое занятие по REST API + Postman + AI [2 - 5 августа]👇
Этот открытый урок сэкономит вам кучу времени и нервов, как на изучение REST API, так и на реальную работу с ним, если вы научитесь использовать AI.
🐞 Как избежать ошибок в REST API:
🤖 от практики в Postman до помощи AI-ассистента
🗓 Доступ 2 - 5 августа [сб-вт]
🕘 Время на обучение: 4 часа
👉 Подробности и регистрация
План:
1. Теория по REST API на практике - через Postman
2. Практика на выявление ошибок проектирования
3. Как вести проектную API-документацию: шаблоны и важные рекомендации
4. AI-ассистент при проектировании REST API
---------------
Подготовка:
Перед занятием установите Postman и зарегистрируйте аккаунт в нём!
Попробуйте сделать Workspace и первую коллекцию.
Всё остальное покажем во время урока.
Инструкция по Postman с нуля
---------------
Это занятие — бесплатный вводный урок к практической программе Дизайн REST API.
Регистрируйтесь, планируйте время на обучение и совершенствуйте свои навыки! 🚀
Этот открытый урок сэкономит вам кучу времени и нервов, как на изучение REST API, так и на реальную работу с ним, если вы научитесь использовать AI.
🐞 Как избежать ошибок в REST API:
🗓 Доступ 2 - 5 августа [сб-вт]
🕘 Время на обучение: 4 часа
👉 Подробности и регистрация
План:
1. Теория по REST API на практике - через Postman
2. Практика на выявление ошибок проектирования
3. Как вести проектную API-документацию: шаблоны и важные рекомендации
4. AI-ассистент при проектировании REST API
---------------
Подготовка:
Перед занятием установите Postman и зарегистрируйте аккаунт в нём!
Попробуйте сделать Workspace и первую коллекцию.
Всё остальное покажем во время урока.
Инструкция по Postman с нуля
---------------
Это занятие — бесплатный вводный урок к практической программе Дизайн REST API.
Регистрируйтесь, планируйте время на обучение и совершенствуйте свои навыки! 🚀
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17❤10
Привет! Сегодня расскажу про свою учёбу по AI в Harvard 🎓
Начну с того, что это не только про «узнать что-то новое». Многое уже давно знакомо.
Но даже те знания, которые у меня уже были, раскрываются с совершенно другой стороны 🤩
Что особенно цепляет:
— новые реальные примеры использования AI,
— обсуждение, какие IT-продукты выживут, а какие уже «в зоне риска»,
— куда всё идёт и как готовиться.
👉 Важные моменты, которыми хочу поделиться:
📌 Инсайт 1:
Выиграли те, кто это понял раньше всех: Google, Amazon, Netflix, Яндекс, и т.д.
Теперь та же история, только с когнитивными способностями:
Простые задачи он уже берёт на себя. И это только начало.
ChatGPT и подобные продукты — аналог браузера.
А что дальше?
Пока мы только на пороге зарождения AI-компаний, и настоящих передовых AI-продуктов пока нет.
📌 Инсайт 2:
Не потому что «AI всех заменит», а потому что с ним можно делать больше, быстрее и точнее. Он повышает продуктивность.
На это уже смотрят при найме в ведущих IT-компаниях.
📌 Инсайт 3:
Был отдельный раздел про галлюцинации AI.
Важная мысль:
Он создан не для «найти ответ», а для «придумать что-то новое».
Это Generative AI (генеративный икусственный интеллект). От слова генерировать = создавать. Но не искать 😅
Жалобы «какую-то ерунду ответил, опять не то, опять придумал» — это просто недопонимание того, как работает генеративный AI.
Он не ищет, он генерирует.
Поэтому и ответы у нас с вами разные.
Тем не менее.... 😄
Это самый популярный Use Case. И под поиск ChatGPT добавил отдельный режим. Если пользуетесь им как поисковиком - включать его.
👉 Я работаю над проектом по внедрению AI в образование.
Учёба идёт интенсивно, времени уходит много — но это именно тот путь, который мне интересен.
Каждый день ощущаю, что становлюсь сильнее как специалист (= лучшей версией себя).
Радуюсь новым шагам 🙌
Начну с того, что это не только про «узнать что-то новое». Многое уже давно знакомо.
Но даже те знания, которые у меня уже были, раскрываются с совершенно другой стороны 🤩
Что особенно цепляет:
— новые реальные примеры использования AI,
— обсуждение, какие IT-продукты выживут, а какие уже «в зоне риска»,
— куда всё идёт и как готовиться.
👉 Важные моменты, которыми хочу поделиться:
📌 Инсайт 1:
Когда появились браузеры и интернет — доступ к информации стал дешевле.
Выиграли те, кто это понял раньше всех: Google, Amazon, Netflix, Яндекс, и т.д.
Теперь та же история, только с когнитивными способностями:
AI делает доступ к мышлению дешевле.
Простые задачи он уже берёт на себя. И это только начало.
ChatGPT и подобные продукты — аналог браузера.
А что дальше?
Пока мы только на пороге зарождения AI-компаний, и настоящих передовых AI-продуктов пока нет.
📌 Инсайт 2:
Те, кто умеют использовать ИИ — будут на шаг впереди.
Не потому что «AI всех заменит», а потому что с ним можно делать больше, быстрее и точнее. Он повышает продуктивность.
На это уже смотрят при найме в ведущих IT-компаниях.
📌 Инсайт 3:
Был отдельный раздел про галлюцинации AI.
Важная мысль:
ChatGPT — не поисковик.
Он создан не для «найти ответ», а для «придумать что-то новое».
Это Generative AI (генеративный икусственный интеллект). От слова генерировать = создавать. Но не искать 😅
Жалобы «какую-то ерунду ответил, опять не то, опять придумал» — это просто недопонимание того, как работает генеративный AI.
Он не ищет, он генерирует.
Поэтому и ответы у нас с вами разные.
Тем не менее.... 😄
Это самый популярный Use Case. И под поиск ChatGPT добавил отдельный режим. Если пользуетесь им как поисковиком - включать его.
👉 Я работаю над проектом по внедрению AI в образование.
Учёба идёт интенсивно, времени уходит много — но это именно тот путь, который мне интересен.
Каждый день ощущаю, что становлюсь сильнее как специалист (= лучшей версией себя).
Радуюсь новым шагам 🙌
🔥70👏15❤10👍6❤🔥1😁1
🟠🤖 Только до завтра: доступ к бесплатной практике по REST API + Postman + AI 🤖🟠
Тема:
Как избежать ошибок в REST API:
от практики в Postman до помощи AI-ассистента
Доступ:
до 5 августа 23:59 Мск [вт]
Время на обучение:
4 часа
👉 Подробности и регистрация
Ваша обратная связь👇
«Очень полезная информация, много подчеркнул и взял на заметку, спасибо огромное!»
— Артём
«Интересно, полезно, на практике всё намного быстрее доходит. Спасибо за такой полезный урок!»
— Полина
«Всё кратко изложено по теме и разложено по полочкам»
— Андрей
👇
Этот урок — первый шаг к практической программе «Дизайн REST API» для аналитиков, где вы:
— научитесь проектировать методы,
— разберётесь в нюансах передачи данных и обработки ошибок,
— закрепите знания на практике,
— получите опыт работы в Postman и Swagger (OpenAPI),
— научитесь использовать ChatGPT как помощника в проектировании API.
💡 Первое онлайн-занятие состоится в следующий вторник!
До 5 августа действует специальная цена, а также:
+3 месяца доступа в подарок
+3 онлайн-встречи по второму проекту
Успейте присоединиться, пока открыта регистрация!
👉 Узнать о программе REST API
Тема:
Как избежать ошибок в REST API:
от практики в Postman до помощи AI-ассистента
Доступ:
до 5 августа 23:59 Мск [вт]
Время на обучение:
4 часа
👉 Подробности и регистрация
Ваша обратная связь👇
«Очень полезная информация, много подчеркнул и взял на заметку, спасибо огромное!»
— Артём
«Интересно, полезно, на практике всё намного быстрее доходит. Спасибо за такой полезный урок!»
— Полина
«Всё кратко изложено по теме и разложено по полочкам»
— Андрей
👇
Этот урок — первый шаг к практической программе «Дизайн REST API» для аналитиков, где вы:
— научитесь проектировать методы,
— разберётесь в нюансах передачи данных и обработки ошибок,
— закрепите знания на практике,
— получите опыт работы в Postman и Swagger (OpenAPI),
— научитесь использовать ChatGPT как помощника в проектировании API.
💡 Первое онлайн-занятие состоится в следующий вторник!
До 5 августа действует специальная цена, а также:
+3 месяца доступа в подарок
+3 онлайн-встречи по второму проекту
Успейте присоединиться, пока открыта регистрация!
👉 Узнать о программе REST API
❤13👍2🥰1
🙌 Как выглядит идеальная API-документация в Postman для портфолио СА? 🙌
1️⃣ Есть общее описание проекта.
2️⃣ Есть информация о способе авторизации запросов.
3️⃣ Используются переменные окружения — удобно для переключения между средами.
4️⃣ У каждого метода есть описание: что делает, кому доступен, ограничения.
5️⃣ Приведены примеры всех возможных ответов:
и успешных,
и ошибочных.
6️⃣ Примеры JSON-запросов и ответов — реалистичные.
7️⃣ Headers настроены там, где это требуется.
8️⃣ В демо документации показано только 2 метода — для портфолио желательно не менее 10 📌
Образец документации для проекта #MeetsGA в открытом доступе:
📎 https://documenter.getpostman.com/view/20545501/2sB3BANYdP
Метод создания встречи аккуратно перенесён из Confluence.
Все методы оформлены так, как должно быть в идеальном портфолио системного аналитика 🙌
Да и не только в портфолио, а конечно же и в ваши проектах!
🟠 По нажатию на "Run in Postman" вы можете открыть Postman-коллекцию и посмотреть как она была создана.
Сохраняйте и используйте как пример для своих проектов 🤝
#RestApiGA
1️⃣ Есть общее описание проекта.
2️⃣ Есть информация о способе авторизации запросов.
3️⃣ Используются переменные окружения — удобно для переключения между средами.
4️⃣ У каждого метода есть описание: что делает, кому доступен, ограничения.
5️⃣ Приведены примеры всех возможных ответов:
и успешных,
и ошибочных.
6️⃣ Примеры JSON-запросов и ответов — реалистичные.
7️⃣ Headers настроены там, где это требуется.
8️⃣ В демо документации показано только 2 метода — для портфолио желательно не менее 10 📌
Образец документации для проекта #MeetsGA в открытом доступе:
Метод создания встречи аккуратно перенесён из Confluence.
Все методы оформлены так, как должно быть в идеальном портфолио системного аналитика 🙌
Да и не только в портфолио, а конечно же и в ваши проектах!
🟠 По нажатию на "Run in Postman" вы можете открыть Postman-коллекцию и посмотреть как она была создана.
Сохраняйте и используйте как пример для своих проектов 🤝
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👏22❤19👍6
🟢 Практическое руководство по Swagger [OpenAPI] для СА 🟢
Чтобы работать с REST API, важно понимать, что такое OpenAPI и зачем нужен Swagger.
👉 OpenAPI — это стандарт описания REST API в формате .yaml или .json.
Это не документация «для людей», это машиночитаемая спецификация, на основе которой можно:
✅ генерировать и валидировать код (или наоборот собирать её из кода)
✅ писать автотесты
✅ создавать мок-сервера
✅ и коформлять документацию в Swagger
🛠 Swagger — набор инструментов для работы с OpenAPI:
– Swagger Editor — редактор .yaml файлов OpenAPI
– Swagger UI — интерфейс с кнопками и примерами
– SwaggerHub — облако, где можно делиться документацией (и делать портфолио)
– Codegen — генератор серверов и клиентов
👉 Что входит в идеальную API-документацию в Swagger (OpenAPI) для портфолио СА:
1️⃣ Общее описание проекта
2️⃣ Настроенная авторизация
3️⃣ Выбор окружения (mock, dev, prod)
4️⃣ Описания у каждого метода
5️⃣ Примеры всех ответов: успех и ошибки
6️⃣ Реалистичные JSON-примеры
7️⃣ Настроенные Headers
8️⃣ В демо — 2 метода. Для портфолио нужно хотя бы 10 👍
Пример спецификации OpenAPI для проекта #MeetsGA в SwaggerHub:
🔗 Swagger-документация
🔗 Swagger Editor с исходным кодом
(для РФ возможно потребуется VPN)
📍Часто спецификация OpenAPI генерируется из кода, автоматически, но также часто бывают ситуацим, когда его надо описывать вручную аналитикам.
OpenAPI для MeetsGA я собрала с помощью AI на основе Postman — всего за 10 минут🤖
Чтобы разобраться с OpenAPI предлагаю вам серию практических руководств:
🔗 1. Регистрация аккаунта и создание демо-проекта
🔗 2. Создание собственного проекта и работа с базовыми настройками, первые строки кода
🔗 3. Описание методов POST и GET по спецификации OpenAPI
Умение работать с OpenAPI помогает структурировать понимание REST API.
А ещё это отличный способ показать свои навыки проектирования API через портфолио 📂
#RestApiGA
Чтобы работать с REST API, важно понимать, что такое OpenAPI и зачем нужен Swagger.
👉 OpenAPI — это стандарт описания REST API в формате .yaml или .json.
Это не документация «для людей», это машиночитаемая спецификация, на основе которой можно:
✅ генерировать и валидировать код (или наоборот собирать её из кода)
✅ писать автотесты
✅ создавать мок-сервера
✅ и коформлять документацию в Swagger
🛠 Swagger — набор инструментов для работы с OpenAPI:
– Swagger Editor — редактор .yaml файлов OpenAPI
– Swagger UI — интерфейс с кнопками и примерами
– SwaggerHub — облако, где можно делиться документацией (и делать портфолио)
– Codegen — генератор серверов и клиентов
👉 Что входит в идеальную API-документацию в Swagger (OpenAPI) для портфолио СА:
1️⃣ Общее описание проекта
2️⃣ Настроенная авторизация
3️⃣ Выбор окружения (mock, dev, prod)
4️⃣ Описания у каждого метода
5️⃣ Примеры всех ответов: успех и ошибки
6️⃣ Реалистичные JSON-примеры
7️⃣ Настроенные Headers
8️⃣ В демо — 2 метода. Для портфолио нужно хотя бы 10 👍
Пример спецификации OpenAPI для проекта #MeetsGA в SwaggerHub:
(для РФ возможно потребуется VPN)
📍Часто спецификация OpenAPI генерируется из кода, автоматически, но также часто бывают ситуацим, когда его надо описывать вручную аналитикам.
OpenAPI для MeetsGA я собрала с помощью AI на основе Postman — всего за 10 минут
Чтобы разобраться с OpenAPI предлагаю вам серию практических руководств:
Умение работать с OpenAPI помогает структурировать понимание REST API.
А ещё это отличный способ показать свои навыки проектирования API через портфолио 📂
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥23🔥8❤3🥰2👍1
Приглашаем вас на новый продвинутый практикум по БД и SQL!
📚 Проектирование распределенных БД
🗓 11 августа, 19:00 Мск
👩🏫 Екатерина Ананьева
План:
1. Базовые понятия архитектуры: сервис-ориентированная (SOA) и микросервисная (MSA) // изучаете в записи, перед занятием
2. Знакомство с проектом: выделение сервисов с собственными БД и распределение сущностей по ним
3. Практика проектирования распределенных БД. Фокус на физических моделях (PostgreSQL)
Актуальный проект:
Маркетплейс (аналог Ozon, Wieldberries и тд)
👉 Сразу после записи на практику доступно последнее актуальное занятие по миграции данных между БД, чтобы сразу было что изучать.
Участие в занятии актуально для аналитиков, кто уже знаком с проектированием БД и хочет погружаться в работу с более сложными задачами 💪
До встречи онлайн!
Вопросы? Пишите @getanalyst или через сайт 👌
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14❤6
📌 84 термина по Архитектуре, которые важно знать Системному Аналитику 📌
◻️ Общие архитектурные понятия
1. Архитектура системы
2. Компонент
3. Модуль
4. Подсистема
5. Сервис
6. Backend
7. Frontend
8. Web-приложение
9. Сайт
10. Desktop-приложение
11. Мобильное приложение
12. Виджет
🧱 Архитектурные стили и подходы
13. Монолитная архитектура
14. Модульный монолит
15. Сервис-ориентированная архитектура (SOA)
16. Микросервисы (MSA)
17. Событийно-ориентированная архитектура (EDA)
18. Слоистая архитектура
19. API Gateway
20. Хореография
21. Оркестрация
22. Service Registry and Discovery
23. Backend for Frontend (BFF)
24. Database-per-Service (БД на сервис)
25. CQRS (Command Query Responsibility Segregation)
26. Domain-Driven Design (DDD)
27. Event Storming
28. Чистая архитектура
🔗 Интеграция и взаимодействие компонентов
29. API (Application Programming Interface)
30. REST API
31. GraphQL
32. gRPC
33. SOAP
34. WebSocket
35. Синхронное взаимодействие
36. Асинхронное взаимодействие
37. Webhooks
38. Polling
39. Long Polling
40. Message Broker (Брокер сообщений)
41. Kafka
42. RabbitMQ
43. ESB (Enterprise Service Bus)
💾 Хранение данных
44. База данных (БД)
45. СУБД
46. Реляционные БД (PostgreSQL, SQLite, MySQL, Oracle и др.)
47. NoSQL БД (MongoDB, Redis и др.)
48. Файловое хранилище
49. Шардирование
50. Репликация
51. Кэширование
🔐 Безопасность
52. Authentication (Аутентификация)
53. Authorization (Авторизация)
54. SSO (Single Sign-On)
55. OAuth 2.0
56. JWT
57. Token
58. Bearer Token
59. Basic Authentication
60. Keycloak
61. TLS
62. HTTPS
63. WWS
64. Аудит
🖼 Нефункциональные требования (НФТ)
65. Масштабируемость
66. Доступность
67. Отказоустойчивость
68. Производительность
69. Сопровождаемость
70. Безопасность
⚙️ DevOps и инфраструктура
71. CI/CD (Continuous Integration / Continuous Delivery)
72. Балансировщик нагрузки (Load Balancer)
73. Docker
74. Kubernetes
75. Service Mesh
76. Мониторинг (Prometheus, Grafana, Zabbix и др.)
77. Логирование (ELK с Kibana, Loki + Grafana и др.)
78. Дашборды
79. Tracing
80. Health Check
📐 Проектирование и документация
81. UML Sequence Diagram
82. UML Activity Diagram
83. C4 Model (Context, Container, Component, Code)
84. Archimate
85. ERD (Entity-Relationship Diagram)
86. Нефункциональные требования (НФТ)
87. Архитектурные решения
📍 Сохрани себе — пригодится при знакомстве с архитектурой, микросервисами, API и подготовке к собеседованиям 😎
P.S. Есть что добавить? Пиши в комментарии!
#АрхитектураGA
◻️ Общие архитектурные понятия
1. Архитектура системы
2. Компонент
3. Модуль
4. Подсистема
5. Сервис
6. Backend
7. Frontend
8. Web-приложение
9. Сайт
10. Desktop-приложение
11. Мобильное приложение
12. Виджет
🧱 Архитектурные стили и подходы
13. Монолитная архитектура
14. Модульный монолит
15. Сервис-ориентированная архитектура (SOA)
16. Микросервисы (MSA)
17. Событийно-ориентированная архитектура (EDA)
18. Слоистая архитектура
19. API Gateway
20. Хореография
21. Оркестрация
22. Service Registry and Discovery
23. Backend for Frontend (BFF)
24. Database-per-Service (БД на сервис)
25. CQRS (Command Query Responsibility Segregation)
26. Domain-Driven Design (DDD)
27. Event Storming
28. Чистая архитектура
🔗 Интеграция и взаимодействие компонентов
29. API (Application Programming Interface)
30. REST API
31. GraphQL
32. gRPC
33. SOAP
34. WebSocket
35. Синхронное взаимодействие
36. Асинхронное взаимодействие
37. Webhooks
38. Polling
39. Long Polling
40. Message Broker (Брокер сообщений)
41. Kafka
42. RabbitMQ
43. ESB (Enterprise Service Bus)
💾 Хранение данных
44. База данных (БД)
45. СУБД
46. Реляционные БД (PostgreSQL, SQLite, MySQL, Oracle и др.)
47. NoSQL БД (MongoDB, Redis и др.)
48. Файловое хранилище
49. Шардирование
50. Репликация
51. Кэширование
🔐 Безопасность
52. Authentication (Аутентификация)
53. Authorization (Авторизация)
54. SSO (Single Sign-On)
55. OAuth 2.0
56. JWT
57. Token
58. Bearer Token
59. Basic Authentication
60. Keycloak
61. TLS
62. HTTPS
63. WWS
64. Аудит
🖼 Нефункциональные требования (НФТ)
65. Масштабируемость
66. Доступность
67. Отказоустойчивость
68. Производительность
69. Сопровождаемость
70. Безопасность
⚙️ DevOps и инфраструктура
71. CI/CD (Continuous Integration / Continuous Delivery)
72. Балансировщик нагрузки (Load Balancer)
73. Docker
74. Kubernetes
75. Service Mesh
76. Мониторинг (Prometheus, Grafana, Zabbix и др.)
77. Логирование (ELK с Kibana, Loki + Grafana и др.)
78. Дашборды
79. Tracing
80. Health Check
📐 Проектирование и документация
81. UML Sequence Diagram
82. UML Activity Diagram
83. C4 Model (Context, Container, Component, Code)
84. Archimate
85. ERD (Entity-Relationship Diagram)
86. Нефункциональные требования (НФТ)
87. Архитектурные решения
📍 Сохрани себе — пригодится при знакомстве с архитектурой, микросервисами, API и подготовке к собеседованиям 😎
P.S. Есть что добавить? Пиши в комментарии!
#АрхитектураGA
🔥54❤20👌3🤔1🤩1
✅ Компоненты архитектуры: шпаргалка для системных аналитиков и архитекторов ✅
Компонент — логически и технологически изолированный модуль архитектуры, реализующий строго определённые функции.
👉 обладает собственной кодовой базой и конфигурацией,
👉 разворачивается и масштабируется автономно,
👉 с другими модулями взаимодействует через формализованные интерфейсы.
При построении архитектурной схемы системный аналитик / архитектор должен зафиксировать все компоненты, их зоны ответственности и показать способы взаимодействия — используемые протоколы, API или SDK.
🖥 Сайты — информационные веб-страницы, без функций управления данными, только чтение. Дополнительно могут работать с заявками, управлением контентом (CMS), минималистичными ЛК пользователей и приемом платежей.
📱 Мобильные приложения — нативные (iOS, Android) или кросс‑платформенные (Flutter/React Native) клиенты с доступом к датчикам и оборудованию устройства, офлайн‑кэшем и пуш‑уведомлениями.
🖥 Веб-приложения — одно‑ или многостраничные приложения, работающие в браузере. Могут устанавливаться на сервера как независимо от Backend, так и включать в себя Backend (монолиты).
💻 Десктоп-приложения — устанавливаемые на компьютер программы, которые получают доступ к файловой системе, драйверам, оборудованию, и могут работать оффлайн. Например, редакторы фотографий, приложения банкоматов, кассы.
🔗 Виджеты — встраиваемые мини‑приложения (JS/iframe‑компоненты), добавляющие отдельную функцию в чужой интерфейс, без изменения кода и полного перезапуска той системы, куда они встраиваются.
🔹 Монолит — единое backend-приложение, где все логические модули системы организованы в одной общей кодовой базе. Деплоится и масштабируется только целиком, нельзя обновить только отдельный модуль внутри монолита. Обычно имеет только одну БД со всеми данными в ней.
🔹 Сервисы — логически выделенный компонент системы, отдельное backend-приложение средних размеров с ограниченным набором бизнес-логики. Деплоится и масштабируется независимо от остальных сервисов. Может иметь свою БД или использовать общую с другими сервисами.
🔹 Микросервисы — небольшой автономный сервис, владеющий узким бизнес‑контекстом, меньшим, чем у обычных сервисов, и (часто) со своей БД. Деплоится и масштабируется независимо от остальных сервисов.
🔹 API Gateway — единая точка входа в Backend-приложение с архитектурой из сервисов или микросервисов. Отвечает за маршрутизацию запросов в нужные сервисы, может выполнять функции аутентификации и авторизации, проверять лимиты по запросам от клиентов, выполнять агрегацию и трансформацию ответов, кэшировать данные и собирать метрики для мониторинга.
🔹 Базы данных (БД) — отвечают за хранение текстовых данных в определенной структуре: реляционные (PostgreSQL, Oracle и другие), NoSQL, time‑series.
🔹 Файловое хранилище (ФХ) — компонент, отвечающий за долговременное хранение документов, фото, медиа и других файлов системы.
🔹 Брокеры сообщений — асинхронный обмен сообщениями (Kafka, RabbitMQ и другие).
🔹 Шина данных, ESB (Enterprise Service Bus) — интеграционная шина уровня предприятия, которая объединяет разнородные приложения через единый коммуникационный слой и «умную» посредническую логику. Типична для SOA архитектуры.
🩶 Внешние системы — платёжные системы, CRM, ЭДО и другие системы, с которыми нужна интеграция.
🎥 Камеры
🖨 Принтеры, чековые терминалы
💳 Считыватели банковских карт
🎙 Микрофоны
📦 RFID/Barcode‑сканеры
🌡 IoT‑датчики (температура, влажность, движение).
и другие.
Используйте этот перечень как чек‑лист.
Он гарантирует, что в архитектурном описании не останется «слепых зон».
Каждый компонент должен быть явно показан на схеме — например, в нотации C4.
#АрхитектураGA
Компонент — логически и технологически изолированный модуль архитектуры, реализующий строго определённые функции.
👉 обладает собственной кодовой базой и конфигурацией,
👉 разворачивается и масштабируется автономно,
👉 с другими модулями взаимодействует через формализованные интерфейсы.
При построении архитектурной схемы системный аналитик / архитектор должен зафиксировать все компоненты, их зоны ответственности и показать способы взаимодействия — используемые протоколы, API или SDK.
Frontend-компоненты:
🖥 Сайты — информационные веб-страницы, без функций управления данными, только чтение. Дополнительно могут работать с заявками, управлением контентом (CMS), минималистичными ЛК пользователей и приемом платежей.
📱 Мобильные приложения — нативные (iOS, Android) или кросс‑платформенные (Flutter/React Native) клиенты с доступом к датчикам и оборудованию устройства, офлайн‑кэшем и пуш‑уведомлениями.
🖥 Веб-приложения — одно‑ или многостраничные приложения, работающие в браузере. Могут устанавливаться на сервера как независимо от Backend, так и включать в себя Backend (монолиты).
💻 Десктоп-приложения — устанавливаемые на компьютер программы, которые получают доступ к файловой системе, драйверам, оборудованию, и могут работать оффлайн. Например, редакторы фотографий, приложения банкоматов, кассы.
🔗 Виджеты — встраиваемые мини‑приложения (JS/iframe‑компоненты), добавляющие отдельную функцию в чужой интерфейс, без изменения кода и полного перезапуска той системы, куда они встраиваются.
Backend-компоненты:
🔹 Монолит — единое backend-приложение, где все логические модули системы организованы в одной общей кодовой базе. Деплоится и масштабируется только целиком, нельзя обновить только отдельный модуль внутри монолита. Обычно имеет только одну БД со всеми данными в ней.
🔹 Сервисы — логически выделенный компонент системы, отдельное backend-приложение средних размеров с ограниченным набором бизнес-логики. Деплоится и масштабируется независимо от остальных сервисов. Может иметь свою БД или использовать общую с другими сервисами.
🔹 Микросервисы — небольшой автономный сервис, владеющий узким бизнес‑контекстом, меньшим, чем у обычных сервисов, и (часто) со своей БД. Деплоится и масштабируется независимо от остальных сервисов.
🔹 API Gateway — единая точка входа в Backend-приложение с архитектурой из сервисов или микросервисов. Отвечает за маршрутизацию запросов в нужные сервисы, может выполнять функции аутентификации и авторизации, проверять лимиты по запросам от клиентов, выполнять агрегацию и трансформацию ответов, кэшировать данные и собирать метрики для мониторинга.
🔹 Базы данных (БД) — отвечают за хранение текстовых данных в определенной структуре: реляционные (PostgreSQL, Oracle и другие), NoSQL, time‑series.
🔹 Файловое хранилище (ФХ) — компонент, отвечающий за долговременное хранение документов, фото, медиа и других файлов системы.
🔹 Брокеры сообщений — асинхронный обмен сообщениями (Kafka, RabbitMQ и другие).
🔹 Шина данных, ESB (Enterprise Service Bus) — интеграционная шина уровня предприятия, которая объединяет разнородные приложения через единый коммуникационный слой и «умную» посредническую логику. Типична для SOA архитектуры.
🩶 Внешние системы — платёжные системы, CRM, ЭДО и другие системы, с которыми нужна интеграция.
Hardware-компоненты:
🎥 Камеры
🖨 Принтеры, чековые терминалы
💳 Считыватели банковских карт
🎙 Микрофоны
📦 RFID/Barcode‑сканеры
🌡 IoT‑датчики (температура, влажность, движение).
и другие.
Используйте этот перечень как чек‑лист.
Он гарантирует, что в архитектурном описании не останется «слепых зон».
Каждый компонент должен быть явно показан на схеме — например, в нотации C4.
#АрхитектураGA
❤35❤🔥10🦄5👍3
Когда ты почти год с огромной отдачей работаешь с людьми, это оставляет огромный след в душе. Навсегда ♥️
Я хочу поблагодарить всю команду, с которой мы работали над проектом.
Завершен поток 2024 года по программе повышения квалификации до middle СА с нуля.
За прошедший год:
- материалы как всегда улучшены и обновлены
- добавлено много лайфхаков по AI
- добавлены темы для senior
- больше индивидуального подхода к каждому аналитику
- почти все 27 встреч со мной (Екатерина Ананьева)
Что дальше:
С сентября 2025 стартует последний полный онлайн-поток программы для системных аналитиков с нуля.
С 2026 года — переход в формат просмотра записей и наставничества.
Почему так:
Я расту и беру на себя всё больше задач и проектов за пределами GetAnalyst.
Времени на полный формат уже не хватает, а качество больших курсов в режиме «разберётесь сами» — не мой подход. Поэтому буду стараться сохранить индивидуальное внимание каждому участнику настолько, насколько это возможно. До последнего.
Этот проект всегда будет с заботой о каждом.
Потому что вы выбираете нас, а мы искренне хотим дать вам всё — и даже больше 🙌
Я хочу поблагодарить всю команду, с которой мы работали над проектом.
Завершен поток 2024 года по программе повышения квалификации до middle СА с нуля.
За прошедший год:
- материалы как всегда улучшены и обновлены
- добавлено много лайфхаков по AI
- добавлены темы для senior
- больше индивидуального подхода к каждому аналитику
- почти все 27 встреч со мной (Екатерина Ананьева)
Что дальше:
С сентября 2025 стартует последний полный онлайн-поток программы для системных аналитиков с нуля.
С 2026 года — переход в формат просмотра записей и наставничества.
Почему так:
Я расту и беру на себя всё больше задач и проектов за пределами GetAnalyst.
Времени на полный формат уже не хватает, а качество больших курсов в режиме «разберётесь сами» — не мой подход. Поэтому буду стараться сохранить индивидуальное внимание каждому участнику настолько, насколько это возможно. До последнего.
Этот проект всегда будет с заботой о каждом.
Потому что вы выбираете нас, а мы искренне хотим дать вам всё — и даже больше 🙌
❤26❤🔥8🤔5😁2⚡1