🧐 Как определить, что в проекте нужна микросервисная архитектура? 🧐
Микросервисную архитектуру стоит рассматривать как решение, если проекту уже несколько лет, он работает как монолит, и наблюдается успешная динамика роста:
+ постоянно внедряется новая функциональность,
+ растет нагрузка и число пользователей.
Также для государственных систем, банков и подобных проектов, где при создании новой системы гарантировано огромное количество пользователей с первых дней работы.
Микросервисы идеальны:
✅ Для больших и сложных систем, где необходимо обеспечить гибкость изменений и независимость компонентов. Например, нужно обеспечить скорость разработки и работу 5 и более команд одновременно над разными независимыми частями проекта.
✅ При высоких требованиях к масштабируемости: микросервисы могут масштабироваться независимо, что позволяет оптимизировать ресурсы на серверах и управлять нагрузкой на сервера эффективнее.
✅ В динамичных и инновационных проектах, где частые изменения и эксперименты с новыми технологиями являются нормой.
Для начинающих свой жизненный путь проектов и стартапов, когда мало пользователей, микросервисная архитектура не рекомендуется из-за своей сложности. Лучше брать монолитный подход и стартовать с ним. Так проще, дешевле и надежнее.
Поэтому задача “переехать с монолита на микросервисы или сервисы” встречается гораздо чаще в реальном мире, чем задача “спроектировать микросервисную архитектуру для нового проекта”.
#АрхитектураGA
Микросервисную архитектуру стоит рассматривать как решение, если проекту уже несколько лет, он работает как монолит, и наблюдается успешная динамика роста:
+ постоянно внедряется новая функциональность,
+ растет нагрузка и число пользователей.
Также для государственных систем, банков и подобных проектов, где при создании новой системы гарантировано огромное количество пользователей с первых дней работы.
Микросервисы идеальны:
✅ Для больших и сложных систем, где необходимо обеспечить гибкость изменений и независимость компонентов. Например, нужно обеспечить скорость разработки и работу 5 и более команд одновременно над разными независимыми частями проекта.
✅ При высоких требованиях к масштабируемости: микросервисы могут масштабироваться независимо, что позволяет оптимизировать ресурсы на серверах и управлять нагрузкой на сервера эффективнее.
✅ В динамичных и инновационных проектах, где частые изменения и эксперименты с новыми технологиями являются нормой.
Для начинающих свой жизненный путь проектов и стартапов, когда мало пользователей, микросервисная архитектура не рекомендуется из-за своей сложности. Лучше брать монолитный подход и стартовать с ним. Так проще, дешевле и надежнее.
Поэтому задача “переехать с монолита на микросервисы или сервисы” встречается гораздо чаще в реальном мире, чем задача “спроектировать микросервисную архитектуру для нового проекта”.
#АрхитектураGA
👍9❤2👏1
Микросервисы не нужны, монолит лучше 😬
Ниже приведены ситуации, когда использование микросервисной архитектуры может быть неоправданным решением:
❌ Быстрый старт проекта:
Микросервисы могут замедлить процесс запуска проекта из-за необходимости разработки и поддержки более сложной инфраструктуры.
Монолитные архитектуры позволяют быстрее выйти на рынок, что особенно важно для стартапов и проектов с ограниченными сроками.
❌ Высокие требования к согласованности данных:
Микросервисы часто используют паттерн "база данных на сервис", что может усложнить согласованность данных между различными сервисами.
Для проектов, требующих высокой согласованности данных, микросервисы могут не подойти.
❌ Тесная связанность компонентов:
Если функциональные компоненты приложения тесно связаны и не могут быть легко изолированы, переход на микросервисы потребует значительной переработки кода и архитектуры.
Актуально не только для задач на переезд, но и для этапа проектирования новых систем.
❌ Сложности отладки и мониторинга:
В микросервисных архитектурах отладка и мониторинг могут быть затруднены, поскольку проблемы могут распространяться по множеству сервисов и зависеть от их взаимодействия.
❌ Сложность организации инфраструктуры и процесса разработки:
Разработка и создание инфраструктуры для микросервисов требует значительных усилий и ресурсов на начальном этапе, что может быть неоправданно для небольших проектов или проектов, где скорость выхода на рынок критична.
❌ Необходимость в высокой квалификации разработчиков и системных аналитиков:
Микросервисы требуют от команды разработчиков высокого уровня квалификации и понимания распределенных систем, что может быть проблематично для небольших команд или стартапов.
Важно помнить, что микросервисы — это инструмент, а не цель. Перед переходом на микросервисную архитектуру необходимо провести тщательный анализ, учитывая специфику проекта, цели бизнеса и имеющиеся ресурсы.
Мартин Фаулер, один из основоположников идеи микросервисов, предлагает подход "Сначала — монолит" (MonolithFirst). Этот подход предполагает начало работы в монолитной архитектуре, и последующий постепенный переход на микросервисы, когда это станет необходимо: при достижении определенного уровня сложности и размера проекта.
Так что задача перехода с монолита на микросервисы еще долго будет оставаться актуальной 🙂
#АрхитектураGA
Ниже приведены ситуации, когда использование микросервисной архитектуры может быть неоправданным решением:
❌ Быстрый старт проекта:
Микросервисы могут замедлить процесс запуска проекта из-за необходимости разработки и поддержки более сложной инфраструктуры.
Монолитные архитектуры позволяют быстрее выйти на рынок, что особенно важно для стартапов и проектов с ограниченными сроками.
❌ Высокие требования к согласованности данных:
Микросервисы часто используют паттерн "база данных на сервис", что может усложнить согласованность данных между различными сервисами.
Для проектов, требующих высокой согласованности данных, микросервисы могут не подойти.
❌ Тесная связанность компонентов:
Если функциональные компоненты приложения тесно связаны и не могут быть легко изолированы, переход на микросервисы потребует значительной переработки кода и архитектуры.
Актуально не только для задач на переезд, но и для этапа проектирования новых систем.
❌ Сложности отладки и мониторинга:
В микросервисных архитектурах отладка и мониторинг могут быть затруднены, поскольку проблемы могут распространяться по множеству сервисов и зависеть от их взаимодействия.
❌ Сложность организации инфраструктуры и процесса разработки:
Разработка и создание инфраструктуры для микросервисов требует значительных усилий и ресурсов на начальном этапе, что может быть неоправданно для небольших проектов или проектов, где скорость выхода на рынок критична.
❌ Необходимость в высокой квалификации разработчиков и системных аналитиков:
Микросервисы требуют от команды разработчиков высокого уровня квалификации и понимания распределенных систем, что может быть проблематично для небольших команд или стартапов.
Важно помнить, что микросервисы — это инструмент, а не цель. Перед переходом на микросервисную архитектуру необходимо провести тщательный анализ, учитывая специфику проекта, цели бизнеса и имеющиеся ресурсы.
Мартин Фаулер, один из основоположников идеи микросервисов, предлагает подход "Сначала — монолит" (MonolithFirst). Этот подход предполагает начало работы в монолитной архитектуре, и последующий постепенный переход на микросервисы, когда это станет необходимо: при достижении определенного уровня сложности и размера проекта.
Так что задача перехода с монолита на микросервисы еще долго будет оставаться актуальной 🙂
#АрхитектураGA
👍13❤2🔥2👏1
GetAnalyst_Архитектура_5_основных_сервисов_и_микросервисов.pdf
1.4 MB
🌐 5 основных сервисов и микросервисов, о которых нужно знать 🌐
В большинстве проектов, которые используют подход сервисной и микросервисной архитектуры, можно встретить эти пять основных сервисов.
Если я работаю над проектом с нуля, то использую этот список как чек-лист “С чего начать". Поможет всем IT-специалистам в задачах, связанных с архитектурой.
❤️ Аутентификация и авторизация
Управление процессами аутентификации пользователей и контроля доступа к ресурсам системы.
Пользователи отправляют свои учетные данные (логин и пароль) в микросервис аутентификации. Микросервис взаимодействует с БД пользователей для проверки учетных данных и, если необходимо, генерирует токены доступа (например, JWT). После успешной аутентификации микросервис возвращает токен для пользователя. Токен проверяется на каждом запросе к защищенным ресурсам.
❤️ Управление пользователями
Обработка регистраций, управление профилями пользователей, хранение и обработка данных пользователей. Взаимодействует с сервисом аутентификации для создания учетных записей и управления ими.
❤️ Уведомления и рассылки
Отправка уведомлений и сообщений пользователям через различные каналы (email, SMS, push-уведомления).
Получает запросы на отправку уведомлений от других сервисов. Обеспечивает интеграцию с внешними поставщиками услуг для отправки email, SMS и push-уведомлений, управляет очередями сообщений и шаблонами уведомлений.
❤️ Управление контентом (блоги на сайтах, новости и подобное)
Управление статическим и динамическим контентом (тексты, изображения, видео), организация структуры и хранения контента. Взаимодействует с базами данных и файловыми хранилищами.
❤️ Биллинг и платежи
Обработка и учет платежей, интеграция с платежными шлюзами, выставление счетов. Взаимодействует с внешними платежными шлюзами и банковскими системами.
Обоснование для выделения сервисов и их назначение более подробно описаны в прикрепленной мини-книге.
Пересылайте пост в ЛС и сохраняйте в избранное, чтобы не потерять ❤️
#АрхитектураGA
В большинстве проектов, которые используют подход сервисной и микросервисной архитектуры, можно встретить эти пять основных сервисов.
Если я работаю над проектом с нуля, то использую этот список как чек-лист “С чего начать". Поможет всем IT-специалистам в задачах, связанных с архитектурой.
❤️ Аутентификация и авторизация
Управление процессами аутентификации пользователей и контроля доступа к ресурсам системы.
Пользователи отправляют свои учетные данные (логин и пароль) в микросервис аутентификации. Микросервис взаимодействует с БД пользователей для проверки учетных данных и, если необходимо, генерирует токены доступа (например, JWT). После успешной аутентификации микросервис возвращает токен для пользователя. Токен проверяется на каждом запросе к защищенным ресурсам.
❤️ Управление пользователями
Обработка регистраций, управление профилями пользователей, хранение и обработка данных пользователей. Взаимодействует с сервисом аутентификации для создания учетных записей и управления ими.
❤️ Уведомления и рассылки
Отправка уведомлений и сообщений пользователям через различные каналы (email, SMS, push-уведомления).
Получает запросы на отправку уведомлений от других сервисов. Обеспечивает интеграцию с внешними поставщиками услуг для отправки email, SMS и push-уведомлений, управляет очередями сообщений и шаблонами уведомлений.
❤️ Управление контентом (блоги на сайтах, новости и подобное)
Управление статическим и динамическим контентом (тексты, изображения, видео), организация структуры и хранения контента. Взаимодействует с базами данных и файловыми хранилищами.
❤️ Биллинг и платежи
Обработка и учет платежей, интеграция с платежными шлюзами, выставление счетов. Взаимодействует с внешними платежными шлюзами и банковскими системами.
Обоснование для выделения сервисов и их назначение более подробно описаны в прикрепленной мини-книге.
Пересылайте пост в ЛС и сохраняйте в избранное, чтобы не потерять ❤️
#АрхитектураGA
👍26❤🔥8🔥3❤2⚡1👏1
⚡ Виды API для взаимодействия компонентов системы ⚡
API (Application Programming Interface) — это набор правил и методов, позволяющих разным программам взаимодействовать друг с другом. Он позволяет одной программе общаться с другой, отправляя запросы и получая ответы, даже если они написаны на разных языках программирования или работают на разных устройствах / серверах.
Другими словами, если для взаимодействия пользователя и программы как правило используется пользовательский интерфейс (UI - User Interface), то для взаимодействия программы с другой программой используется программный интерфейс (API - Application Programming Interface) 🧈
Основные виды API:
⚡ REST
⚡ SOAP
⚡ GraphQL
⚡ gRPC
⚡ WebSocket
В деталях 👇
⚡ REST API (Representational State Transfer)
Использует HTTP-протокол и основывается на концепциях ресурсов и методов (GET, POST, PUT, PATCH, DELETE и другие).
Широко используется для веб-, мобильных приложений и микросервисной архитектуры.
Пример документации:
Wildberries
Pinterest
⚡ SOAP API (Simple Object Access Protocol)
Использует XML для обмена сообщениями и поддерживает сложные операции и стандарты безопасности.
Считается, что в основном применяется в корпоративных системах, требующих высокого уровня надежности и безопасности. Устаревает. Современные средства безопасности на уровне инфраструктуры делают REST более приятным и менее тяжеловесным в использованию по сравнению с SOAP.
Пример документации:
PayPal (обратите внимание, что устаревший)
Самые интересные API с примерами документации чуть позже 😉👇
#АрхитектураGA
API (Application Programming Interface) — это набор правил и методов, позволяющих разным программам взаимодействовать друг с другом. Он позволяет одной программе общаться с другой, отправляя запросы и получая ответы, даже если они написаны на разных языках программирования или работают на разных устройствах / серверах.
Другими словами, если для взаимодействия пользователя и программы как правило используется пользовательский интерфейс (UI - User Interface), то для взаимодействия программы с другой программой используется программный интерфейс (API - Application Programming Interface) 🧈
Основные виды API:
⚡ REST
⚡ SOAP
⚡ GraphQL
⚡ gRPC
⚡ WebSocket
В деталях 👇
⚡ REST API (Representational State Transfer)
Использует HTTP-протокол и основывается на концепциях ресурсов и методов (GET, POST, PUT, PATCH, DELETE и другие).
Широко используется для веб-, мобильных приложений и микросервисной архитектуры.
Пример документации:
Wildberries
⚡ SOAP API (Simple Object Access Protocol)
Использует XML для обмена сообщениями и поддерживает сложные операции и стандарты безопасности.
Считается, что в основном применяется в корпоративных системах, требующих высокого уровня надежности и безопасности. Устаревает. Современные средства безопасности на уровне инфраструктуры делают REST более приятным и менее тяжеловесным в использованию по сравнению с SOAP.
Пример документации:
PayPal (обратите внимание, что устаревший)
Самые интересные API с примерами документации чуть позже 😉👇
#АрхитектураGA
🔥24👍5❤4👏1🤩1
⚡ GraphQL
Позволяет клиенту запрашивать только те данные, которые ему необходимы, с помощью декларативного языка запросов.
Удобен для сложных приложений с изменяемыми потребностями в данных, для мобильных приложений и микросервисов с целью оптимизации трафика между клиентом и сервером, который реализует API.
Пример документации:
Contentful
⚡ gRPC
Использует Protocol Buffers для сериализации данных и поддерживает как синхронные, так и асинхронные вызовы.
Эффективен для микросервисной архитектуры с высокими требованиями к производительности. Очень много коллег, кто в новых проектах на микросервисной архитектуре его использует сразу, даже не рассматривая REST.
Пример документации:
Dropbox от Google
⚡ WebSocket
Обеспечивает двухстороннюю связь между клиентом и сервером в режиме реального времени.
Используется для приложений, требующих мгновенного обмена данными, например, чаты или системы оповещений.
Пример документации:
Binance Биржа
Для системного аналитика важно понимать, когда и в каких случаях используются определенные виды API, чтобы точно описывать требования к различным интеграциям и понимать, с помощью каких технологий можно реализовывать различные сценарии работы системы.
#АрхитектураGA
Позволяет клиенту запрашивать только те данные, которые ему необходимы, с помощью декларативного языка запросов.
Удобен для сложных приложений с изменяемыми потребностями в данных, для мобильных приложений и микросервисов с целью оптимизации трафика между клиентом и сервером, который реализует API.
Пример документации:
Contentful
⚡ gRPC
Использует Protocol Buffers для сериализации данных и поддерживает как синхронные, так и асинхронные вызовы.
Эффективен для микросервисной архитектуры с высокими требованиями к производительности. Очень много коллег, кто в новых проектах на микросервисной архитектуре его использует сразу, даже не рассматривая REST.
Пример документации:
Dropbox от Google
⚡ WebSocket
Обеспечивает двухстороннюю связь между клиентом и сервером в режиме реального времени.
Используется для приложений, требующих мгновенного обмена данными, например, чаты или системы оповещений.
Пример документации:
Binance Биржа
Для системного аналитика важно понимать, когда и в каких случаях используются определенные виды API, чтобы точно описывать требования к различным интеграциям и понимать, с помощью каких технологий можно реализовывать различные сценарии работы системы.
#АрхитектураGA
👍8❤4❤🔥1👏1💯1
😱 Я боюсь публичных выступлений 😥
Немного о моем пути в изучении английского...
Да, я говорю по-английски. Свободно, быстро. Меня понимают, но я слышу ошибки в своей речи, слышу акцент. И. Неожиданно. У меня страх публичных выступлений на английском. С ним я борюсь уже не первый год.
Два последних года я пыталась самостоятельно преодолеть этот барьер, но максимум, который я достигла - в работе с клиентами и в разговорах один на один я чувствую себя уверенно и не теряюсь. А вот на публику презентации делать боюсь.
Впервые, чуть больше 5 лет назад, я серьезно занялась английским, так как мне надо было учиться в США. Тогда я просто каждый день учила новые слова, читала, смотрела новости и работала с преподавателями, чтобы меня двигали вперед и направляли в обучении. С педагогами база и задания, далее самостоятельная отработка и проверка.
Это продвинуло мой английский с уровня "Hello, my name is Katya" и отсутствия понимания собеседников, до сложных душевных и бизнесовых диалогов.
Пришел час X. Сейчас мне нужно выступать на английском. И одна я себя с места не сдвину. Поэтому теперь у меня еще минус 3 часа в неделю на дополнительное обучение. Я уверена в своих силах, я знаю, что могу достичь идеала, но мне нужен тот самый прорыв, который, кажется, мне не под силу сделать без наставника.
Сейчас я ищу митапы и конференции, на которых смогу позориться, как мне кажется. Это большой шаг для меня, страшно, но мне нужны эти изменения.
Иногда, чтобы действительно двигаться вперед, нужно признать, что даже самым упорным из нас может понадобиться чья-то помощь. Верю, что к первому дедлайну должна стать лучшей версией англоговорящей себя.
Пожелайте удачи! 🦄🙏❤️
Немного о моем пути в изучении английского...
Да, я говорю по-английски. Свободно, быстро. Меня понимают, но я слышу ошибки в своей речи, слышу акцент. И. Неожиданно. У меня страх публичных выступлений на английском. С ним я борюсь уже не первый год.
Два последних года я пыталась самостоятельно преодолеть этот барьер, но максимум, который я достигла - в работе с клиентами и в разговорах один на один я чувствую себя уверенно и не теряюсь. А вот на публику презентации делать боюсь.
Впервые, чуть больше 5 лет назад, я серьезно занялась английским, так как мне надо было учиться в США. Тогда я просто каждый день учила новые слова, читала, смотрела новости и работала с преподавателями, чтобы меня двигали вперед и направляли в обучении. С педагогами база и задания, далее самостоятельная отработка и проверка.
Это продвинуло мой английский с уровня "Hello, my name is Katya" и отсутствия понимания собеседников, до сложных душевных и бизнесовых диалогов.
Пришел час X. Сейчас мне нужно выступать на английском. И одна я себя с места не сдвину. Поэтому теперь у меня еще минус 3 часа в неделю на дополнительное обучение. Я уверена в своих силах, я знаю, что могу достичь идеала, но мне нужен тот самый прорыв, который, кажется, мне не под силу сделать без наставника.
Сейчас я ищу митапы и конференции, на которых смогу позориться, как мне кажется. Это большой шаг для меня, страшно, но мне нужны эти изменения.
Иногда, чтобы действительно двигаться вперед, нужно признать, что даже самым упорным из нас может понадобиться чья-то помощь. Верю, что к первому дедлайну должна стать лучшей версией англоговорящей себя.
Пожелайте удачи! 🦄🙏❤️
❤61🔥21👏13👍6❤🔥3⚡2
С днём рождения, GetAnalyst 🎊🎉🥳
18 мая 2021 года - официальная дата запуска проекта. Купили домен. Сделали первую версию синего сайта. Я отправилась на конференцию собирать первых аналитиков в сообщество на 0 участников. А на этой неделе нас перевалило за 8 тысяч человек.
В прошлом году я рассказывала через что прошла, чтобы сделать GetAnalyst. Трудоголизм, дисциплина и желание делиться опытом.
Бывает всякое. За кулисами есть разные дни)) Много непрерывных улучшений. Каждую неделю десятки новых постов, до 5 презентаций по обучению проходят преобразование или разработку. Много задач. Но я дисциплинированный трудоголик, который любит своё дело. С одной работы на вторую, но я вижу результаты. Это важно.
В этом году на позитиве расскажу, что сделано с 18 мая 2023 нашей командой:
1. Запустили подкаст.
2. Развиваем YouTube-канал.
3. Запустили программу Архитектура - самый топ для системных аналитиков.
4. Запустили уникальные практикумы по БД на продвинутые темы.
5. Одна голова - хорошо, а больше опытных в узких темах экспертов - лучше. Улучшаем всё что возможно и дополняем новым опытом.
6. Редизайн всего. Мелочь, а приятно.
7. Сайт почти на 100% обновили. Платформа получилась)) Обратите внимание на блог и подкасты, если еще там не были.
8. Почти 400 аналитиков выросли с нами за год.
(9. Благодаря GetAnalyst и приобретенной публичности, мне удалось получить продвинутое членство в международных ассоциациях, признание Young Professional, рекомендации и благодарственные письма от крупных компаний 🙏)
Спасибо вам, что рекомендуете сообщество своим коллегам и начинающим аналитикам. Делитесь полезными материалами из канала, приходите на открытые вебинары и остаётесь с нами.
Благодаря вам GetAnalyst продолжает становиться лучше.
GetAnalyst - это не Катя Ананьева. GetAnalyst - это вы ❤️
С тремя годиками. Расти большой 🚀
Happy Birthday! 🥳
С любовью,
Екатерина Ананьева
и команда GetAnalyst.
18 мая 2021 года - официальная дата запуска проекта. Купили домен. Сделали первую версию синего сайта. Я отправилась на конференцию собирать первых аналитиков в сообщество на 0 участников. А на этой неделе нас перевалило за 8 тысяч человек.
В прошлом году я рассказывала через что прошла, чтобы сделать GetAnalyst. Трудоголизм, дисциплина и желание делиться опытом.
Бывает всякое. За кулисами есть разные дни)) Много непрерывных улучшений. Каждую неделю десятки новых постов, до 5 презентаций по обучению проходят преобразование или разработку. Много задач. Но я дисциплинированный трудоголик, который любит своё дело. С одной работы на вторую, но я вижу результаты. Это важно.
В этом году на позитиве расскажу, что сделано с 18 мая 2023 нашей командой:
1. Запустили подкаст.
2. Развиваем YouTube-канал.
3. Запустили программу Архитектура - самый топ для системных аналитиков.
4. Запустили уникальные практикумы по БД на продвинутые темы.
5. Одна голова - хорошо, а больше опытных в узких темах экспертов - лучше. Улучшаем всё что возможно и дополняем новым опытом.
6. Редизайн всего. Мелочь, а приятно.
7. Сайт почти на 100% обновили. Платформа получилась)) Обратите внимание на блог и подкасты, если еще там не были.
8. Почти 400 аналитиков выросли с нами за год.
(9. Благодаря GetAnalyst и приобретенной публичности, мне удалось получить продвинутое членство в международных ассоциациях, признание Young Professional, рекомендации и благодарственные письма от крупных компаний 🙏)
Спасибо вам, что рекомендуете сообщество своим коллегам и начинающим аналитикам. Делитесь полезными материалами из канала, приходите на открытые вебинары и остаётесь с нами.
Благодаря вам GetAnalyst продолжает становиться лучше.
GetAnalyst - это не Катя Ананьева. GetAnalyst - это вы ❤️
С тремя годиками. Расти большой 🚀
Happy Birthday! 🥳
С любовью,
Екатерина Ананьева
и команда GetAnalyst.
❤67🍾40❤🔥11🔥11👏5🎉5👍3
⚡ API как часть архитектурного проектирования ⚡
Взаимодействие приложений в системе через API - одно из ключевых архитектурных решений, особенно в сервисной и микросервисной архитектуре.
При разработке схемы архитектуры в С4 необходимо указывать технологии для каждого элемента системы (сервиса, микросервиса, приложения), а также виды API, обеспечивающие взаимодействие этих элементов.
Это справедливо не только для C4. В любой упрощенной схеме архитектуры следует делать то же самое.
🟢 API и правила их выбора определяют на этапе проектирования архитектуры.
Интересный факт:
Для одного сервиса может быть два или даже три вида API, которые он предоставляет своим клиентам. Всё зависит от бизнес-логики и назначения сервиса. Это отражается на схеме и в архитектурной документации.
Касательно нотации моделирования архитектуры C4, которую мы разбираем на примере проекта TelMed, API отображаются на следующих уровнях:
⚪️ Контекстная диаграмма (Context Diagram):
Показывать виды API не обязательно, но полезно указать, через какие API происходит взаимодействие с внешними системами.
⚪️ Диаграмма контейнеров (Container Diagram):
API могут быть отображены как интерфейсы между приложениями, сервисами и внешними системами.
⚪️ Диаграмма компонентов (Component Diagram):
Показывает API, которые реализуются внутри контейнера - приложения, сервиса или микросервиса, чтобы к ним могли обращаться другие системы и сервисы. Также показывает API к внешним системам, если есть интеграции.
⚪️ Диаграмму кода мы не рассматриваем, так как она не актуальна для аналитиков.
Обратите внимание, что на схемах для каждого вида API также указываются протоколы и форматы сообщений, с которыми они работают, например, HTTP/JSON.
Знание основных видов API, принципов их работы, примеров использования и умение проверять их работу, помогают системным аналитикам (с архитекторами и разработчиками) приземлить отдельные бизнес- и нефункциональные требования на конкретные технологии.
Примеры схем С4 с API:
+ Шаблон C4 в Miro
+ Статья по C4
#АрхитектураGA
Взаимодействие приложений в системе через API - одно из ключевых архитектурных решений, особенно в сервисной и микросервисной архитектуре.
При разработке схемы архитектуры в С4 необходимо указывать технологии для каждого элемента системы (сервиса, микросервиса, приложения), а также виды API, обеспечивающие взаимодействие этих элементов.
Это справедливо не только для C4. В любой упрощенной схеме архитектуры следует делать то же самое.
🟢 API и правила их выбора определяют на этапе проектирования архитектуры.
Интересный факт:
Для одного сервиса может быть два или даже три вида API, которые он предоставляет своим клиентам. Всё зависит от бизнес-логики и назначения сервиса. Это отражается на схеме и в архитектурной документации.
Касательно нотации моделирования архитектуры C4, которую мы разбираем на примере проекта TelMed, API отображаются на следующих уровнях:
⚪️ Контекстная диаграмма (Context Diagram):
Показывать виды API не обязательно, но полезно указать, через какие API происходит взаимодействие с внешними системами.
⚪️ Диаграмма контейнеров (Container Diagram):
API могут быть отображены как интерфейсы между приложениями, сервисами и внешними системами.
⚪️ Диаграмма компонентов (Component Diagram):
Показывает API, которые реализуются внутри контейнера - приложения, сервиса или микросервиса, чтобы к ним могли обращаться другие системы и сервисы. Также показывает API к внешним системам, если есть интеграции.
⚪️ Диаграмму кода мы не рассматриваем, так как она не актуальна для аналитиков.
Обратите внимание, что на схемах для каждого вида API также указываются протоколы и форматы сообщений, с которыми они работают, например, HTTP/JSON.
Знание основных видов API, принципов их работы, примеров использования и умение проверять их работу, помогают системным аналитикам (с архитекторами и разработчиками) приземлить отдельные бизнес- и нефункциональные требования на конкретные технологии.
Примеры схем С4 с API:
+ Шаблон C4 в Miro
+ Статья по C4
#АрхитектураGA
❤7👍5🔥1💯1
💥 Сервисная архитектура с нуля для проекта TelMed 💥
Мы познакомились с теорией по сервис-ориентированному и микросервисному подходам к проектированию архитектуры, понимаем отличия от монолитов.
Пришло время разобраться на практике, как может выглядеть архитектура проекта TelMed.
Хочу сразу отметить, что буду использовать смешанный подход: чистых микросервисов или чистого SOA не будет. Это смесь, как в реальной жизни. Теория-теорией, но в реальности она другая. Поэтому в заголовке поста название "сервисная", как нечто более общее.
Для выделения списка сервисов воспользуюсь чек-листом из предыдущего поста и знанием бизнес-контекстов проекта (очень помогает!).
Сервисы и микросервисы TelMed:
1. Аутентификация и авторизация
2. Управление пользователями
3. Уведомления и рассылки
4. Личный кабинет пациента
Регистрация пациентов, хранение персональных данных, медицинской карты и медицинской истории.
5. Запись на прием
Поиск врачей, планирование и отслеживание консультаций, уведомление пациентов.
6. Учет оборудования
Управление заказом и доставкой медицинского оборудования.
7. Онлайн-консультации
Обеспечение защищенной видеосвязи, чат и обмен документами.
8. Аптечные услуги
Создание электронных рецептов, мониторинг наличия лекарств, управление доставкой.
9. Анализы
Выдача направлений на анализы, автоматическое получение результатов.
10. Платежи
Обработка и учет платежей, интеграция с платежными системами.
11. Личный кабинет врача
Управление профилем врача и настройка доступного времени для консультаций.
Для отображения архитектуры я буду использовать нотацию C4 / Container.
В каком инструменте сделать пример сервисной архитектуры, чтобы вы могли забрать себе исходник?
1. Miro - пример будет как тут 👍
2. Structurizr - через код, доп. примеры по нему тут ❤️
3. Draw.io 🔥
Голосуйте реакцией 👍❤️🔥
#АрхитектураGA #TelMedGA
Мы познакомились с теорией по сервис-ориентированному и микросервисному подходам к проектированию архитектуры, понимаем отличия от монолитов.
Пришло время разобраться на практике, как может выглядеть архитектура проекта TelMed.
Хочу сразу отметить, что буду использовать смешанный подход: чистых микросервисов или чистого SOA не будет. Это смесь, как в реальной жизни. Теория-теорией, но в реальности она другая. Поэтому в заголовке поста название "сервисная", как нечто более общее.
Для выделения списка сервисов воспользуюсь чек-листом из предыдущего поста и знанием бизнес-контекстов проекта (очень помогает!).
Сервисы и микросервисы TelMed:
1. Аутентификация и авторизация
2. Управление пользователями
3. Уведомления и рассылки
4. Личный кабинет пациента
Регистрация пациентов, хранение персональных данных, медицинской карты и медицинской истории.
5. Запись на прием
Поиск врачей, планирование и отслеживание консультаций, уведомление пациентов.
6. Учет оборудования
Управление заказом и доставкой медицинского оборудования.
7. Онлайн-консультации
Обеспечение защищенной видеосвязи, чат и обмен документами.
8. Аптечные услуги
Создание электронных рецептов, мониторинг наличия лекарств, управление доставкой.
9. Анализы
Выдача направлений на анализы, автоматическое получение результатов.
10. Платежи
Обработка и учет платежей, интеграция с платежными системами.
11. Личный кабинет врача
Управление профилем врача и настройка доступного времени для консультаций.
Для отображения архитектуры я буду использовать нотацию C4 / Container.
В каком инструменте сделать пример сервисной архитектуры, чтобы вы могли забрать себе исходник?
1. Miro - пример будет как тут 👍
2. Structurizr - через код, доп. примеры по нему тут ❤️
3. Draw.io 🔥
Голосуйте реакцией 👍❤️🔥
#АрхитектураGA #TelMedGA
🔥47👍15❤13
Ищу эксперта в REST API, Postman и Swagger, готового учиться публично выступать 👀
Если ты эксперт, то подробности и Google-форма тут 🤝
Если ты эксперт, то подробности и Google-форма тут 🤝
Forwarded from 👩🏻💻 Подкаст Системных Аналитиков | GetAnalyst
🙌 Новый эпизод подкаста GetAnalyst про Нефункциональные требования 🙌
В этом эпизоде мы обсуждаем нефункциональные требования: не только в теории, но и на практике. Приводятся конкретные примеры для каждого вида таких требований, которые могут быть применены в реальных ИТ-проектах.
Этот выпуск поможет системным и бизнес-аналитикам при подготовке к собеседованиям или перед стартом работы над нефункциональными требованиями для ТЗ нового проекта.
1:08 - Когда мы встречаемся с нефункциональными требованиями и что важно знать о них перед началом работы. Знакомство с проектом TelMed (https://t.me/getanalysts/1646).
08:09 - Что такое нефункциональные требования (НФТ). О проверяемости нефункциональных требований.
12:28 - Определение нефункциональных требований по Вигерсу (книга “Разработка требований к программному обеспечению”), ГОСТ-34 и Software Requirements Specification, IEEE.
23:21 - Источники нефункциональных требований.
29:54 - Виды нефункциональных требований на примере медицинского проекта TelMed. Этап сбора потребностей из источников - первичная аналитика.
45:04 - Работа с нефункциональными требованиями для ТЗ и рядовых постановок задач на разработчиков. Личный опыт. Связь с принципами дизайна UI и архитектурой.
51:06 - Доступность. SLA - service-level agreement. Удобство установки.
01:01:36 - Целостность данных. Совместимость. Производительность.
01:06:24 - Надежность. Устойчивость. Защита и безопасность.
1:13:00 - Удобство использования. О боли про “Интуитивно понятный интерфейс”.
1:16:10 - Эффективность использования ресурсов.
1:18:10 - Модификация. Переносимость. Возможность повторного использования.
1:21:41 - Масштабируемость.
1:24:03 - Проверяемость и тестируемость. Другие требования по ГОСТ-34.
1:27:28 - Порядок работы с нефункциональными требованиями.
1:34:54 - Заключение и рекомендации.
📚 Статья к подкасту
Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Castbox
⏯ Spotify
Делитесь с коллегами и подписывайтесь на всех площадках! 😉
В этом эпизоде мы обсуждаем нефункциональные требования: не только в теории, но и на практике. Приводятся конкретные примеры для каждого вида таких требований, которые могут быть применены в реальных ИТ-проектах.
Этот выпуск поможет системным и бизнес-аналитикам при подготовке к собеседованиям или перед стартом работы над нефункциональными требованиями для ТЗ нового проекта.
1:08 - Когда мы встречаемся с нефункциональными требованиями и что важно знать о них перед началом работы. Знакомство с проектом TelMed (https://t.me/getanalysts/1646).
08:09 - Что такое нефункциональные требования (НФТ). О проверяемости нефункциональных требований.
12:28 - Определение нефункциональных требований по Вигерсу (книга “Разработка требований к программному обеспечению”), ГОСТ-34 и Software Requirements Specification, IEEE.
23:21 - Источники нефункциональных требований.
29:54 - Виды нефункциональных требований на примере медицинского проекта TelMed. Этап сбора потребностей из источников - первичная аналитика.
45:04 - Работа с нефункциональными требованиями для ТЗ и рядовых постановок задач на разработчиков. Личный опыт. Связь с принципами дизайна UI и архитектурой.
51:06 - Доступность. SLA - service-level agreement. Удобство установки.
01:01:36 - Целостность данных. Совместимость. Производительность.
01:06:24 - Надежность. Устойчивость. Защита и безопасность.
1:13:00 - Удобство использования. О боли про “Интуитивно понятный интерфейс”.
1:16:10 - Эффективность использования ресурсов.
1:18:10 - Модификация. Переносимость. Возможность повторного использования.
1:21:41 - Масштабируемость.
1:24:03 - Проверяемость и тестируемость. Другие требования по ГОСТ-34.
1:27:28 - Порядок работы с нефункциональными требованиями.
1:34:54 - Заключение и рекомендации.
📚 Статья к подкасту
Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Castbox
⏯ Spotify
Делитесь с коллегами и подписывайтесь на всех площадках! 😉
🔥19❤5❤🔥2👍2🦄2⚡1
😕 Завышение сложности архитектуры (овер-инжиниринг): создание избыточно сложной архитектуры в проектах, где в этом нет необходимости 😕
Завышение сложности архитектуры случается, когда для системы создают слишком сложную систему, не всегда нужную для обеспечения её работы.
Это может включать использование избыточного количества технологий, паттернов проектирования или большого количества компонентов для реализации, усложняющих понимание, разработку, тестирование и поддержку системы.
◽ Пример:
Разработка системы интернет-магазина для малого бизнеса, который продает всего несколько видов товаров. Вместо использования простой монолитной архитектуры или шаблонного "интернет-магазина из коробки", команда решила реализовать собственную систему на основе микросервисов, разделив каждую функцию (обработку заказов, управление каталогом товаров, обработку платежей) на отдельные сервисы.
Это значительно увеличило сложность проекта, требуя дополнительных ресурсов для разработки, координации между сервисами и обеспечения их надежной работы. В результате, затраты на разработку и поддержку системы оказались гораздо выше, чем если бы была выбрана более простая архитектура, адекватная масштабам и потребностям бизнеса.
Почему происходит:
🔻 Переоценка требований.
🔻 Стремление к совершенству
🔻 Недостаточный опыт
Рекомендации:
✅ Стремитесь к простоте в проектировании, избегая ненужной сложности в целом. Идеальная архитектура простая и понятная.
✅ Не учитывайте функциональность до тех пор, пока она действительно не потребуется.
✅ Держите баланс между долгосрочным планированием и текущими потенциальными усложнениями.
✅ Используйте принцип итеративной разработки. Разрабатывайте функции в системе поэтапно, добавляя сложность только тогда, когда это оправдано.
✅ Регулярно пересматривайте архитектуру на возможность упрощения и улучшения.
Какие еще ошибки встречаются в проектировании архитектуры? 🧐
Подробности и ответ в статье:
🔗 Ошибки в проектировании архитектуры: на что обращать внимание
#АрхитектураGA
Завышение сложности архитектуры случается, когда для системы создают слишком сложную систему, не всегда нужную для обеспечения её работы.
Это может включать использование избыточного количества технологий, паттернов проектирования или большого количества компонентов для реализации, усложняющих понимание, разработку, тестирование и поддержку системы.
◽ Пример:
Разработка системы интернет-магазина для малого бизнеса, который продает всего несколько видов товаров. Вместо использования простой монолитной архитектуры или шаблонного "интернет-магазина из коробки", команда решила реализовать собственную систему на основе микросервисов, разделив каждую функцию (обработку заказов, управление каталогом товаров, обработку платежей) на отдельные сервисы.
Это значительно увеличило сложность проекта, требуя дополнительных ресурсов для разработки, координации между сервисами и обеспечения их надежной работы. В результате, затраты на разработку и поддержку системы оказались гораздо выше, чем если бы была выбрана более простая архитектура, адекватная масштабам и потребностям бизнеса.
Почему происходит:
🔻 Переоценка требований.
🔻 Стремление к совершенству
🔻 Недостаточный опыт
Рекомендации:
✅ Стремитесь к простоте в проектировании, избегая ненужной сложности в целом. Идеальная архитектура простая и понятная.
✅ Не учитывайте функциональность до тех пор, пока она действительно не потребуется.
✅ Держите баланс между долгосрочным планированием и текущими потенциальными усложнениями.
✅ Используйте принцип итеративной разработки. Разрабатывайте функции в системе поэтапно, добавляя сложность только тогда, когда это оправдано.
✅ Регулярно пересматривайте архитектуру на возможность упрощения и улучшения.
Какие еще ошибки встречаются в проектировании архитектуры? 🧐
Подробности и ответ в статье:
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11👍7🔥1
🔔 Завершаем предзапись на архитектуру сегодня в 23:59 Мск🔔
Подробнее об условиях предзаписи можно почитать здесь и в программе на сайте.
Старт предобучения 28 мая 2024
Подробности о программе и запись
А пока мы продолжаем рассказывать о программе словами коллег-аналитиков, которые буквально вчера завершили обучение на первом потоке 🙌 🎉🥳
Больше обратной связи будем постепенно добавлять на сайт 💛
Если честно, то нам тоже надо оставлять публичную обратную связь на тех, кто у нас учится. Я и все эксперты, кто работал с группой "Архитектура" (и не только), разными словами делимся друг с другом впечатлениями о том, насколько осознанная группа и насколько круто было работать.
Команда аналитиков с нами не для галочки "я на обучении", все работают на результат 💪💎🤝 Спасибо вам за это!
Уже работаем над улучшениями и готовимся ко встрече с новой командой "Архитектура"!
Подробнее об условиях предзаписи можно почитать здесь и в программе на сайте.
Старт предобучения 28 мая 2024
Подробности о программе и запись
А пока мы продолжаем рассказывать о программе словами коллег-аналитиков, которые буквально вчера завершили обучение на первом потоке 🙌 🎉🥳
Решила пойти не думая, т.к. предыдущие курсы, которые прошла, очень понравились
подачей, объемом информации и, самое главное, качественной объемной практикой с ДЗ и качественной проверкой ДЗ.
Задания не абстрактные, а конкретные, жизненные, привязанные к системам, которыми мы пользуемся ежедневно. Выполняя задание, мы можем сразу увидеть как это все работает уже со стороны не только пользователя, но и аналитика.
Было очень интересно познавать, как это работает с точки зрения архитектуры, микросервисов и БД. Хочу отметить, что проверка ДЗ ведется глубоко и индивидуально, "не для галочки".
Больше обратной связи будем постепенно добавлять на сайт 💛
Если честно, то нам тоже надо оставлять публичную обратную связь на тех, кто у нас учится. Я и все эксперты, кто работал с группой "Архитектура" (и не только), разными словами делимся друг с другом впечатлениями о том, насколько осознанная группа и насколько круто было работать.
Команда аналитиков с нами не для галочки "я на обучении", все работают на результат 💪💎🤝 Спасибо вам за это!
Уже работаем над улучшениями и готовимся ко встрече с новой командой "Архитектура"!
👍6❤3👌1
✅ Шаблон Draw.Io для C4 - примеры для проекта TelMed ✅
Собрала Draw.Io с примером для проекта TelMed и структурировала информацию для вас.
1. Страница "Элементы C4"
На ней вы найдете сгруппированные элементы, которые могут присутствовать на каждом из уровней C4, которые реально используются в проектах (Context, Container, Component).
Также мини-инструкция, как включить эти элементы в Draw.Io в левой панели.
2. Страница "С4 - Проект TelMed от GetAnalyst"
На ней вы найдете:
+ Проект TelMed - C4 / Context (пояснения тут)
+ Проект TelMed - C4 / Container для монолитной архитектуры (пояснения тут)
+ Проект TelMed - C4 / Container для смешанной архитектуры - сервисная + микросервисная (пояснения тут)
📌 Файл Draw.Io для просмотра в онлайн:
https://app.diagrams.net/#G1nk3D0XqRQ9A-2Bw9yGlLY2ZOOutSEStR#%7B%22pageId%22%3A%22qvlD7eRmiriUJArze8cl%22%7D
Для просмотра потребуется авторизация на Google Диске.
Как забрать себе и использовать:
📌 Файл Draw.Io, который вы можете сохранить себе, доступен по этой ссылке
1. Перейти по ссылке.
2. Сверху будет иконка "Скачать"
3. После скачивания:
3.1. Загружаете на свой гугл-диск и открываете с помощью приложения draw io.
3.2. Открываете на десктопном (установленном на компьютер) draw io.
Теперь вы можете самостоятельно создавать C4 и подглядывать на пример, который сделан согласно нотации на 100%.
#АрхитектураGA #TelMedGA
Собрала Draw.Io с примером для проекта TelMed и структурировала информацию для вас.
1. Страница "Элементы C4"
На ней вы найдете сгруппированные элементы, которые могут присутствовать на каждом из уровней C4, которые реально используются в проектах (Context, Container, Component).
Также мини-инструкция, как включить эти элементы в Draw.Io в левой панели.
2. Страница "С4 - Проект TelMed от GetAnalyst"
На ней вы найдете:
+ Проект TelMed - C4 / Context (пояснения тут)
+ Проект TelMed - C4 / Container для монолитной архитектуры (пояснения тут)
+ Проект TelMed - C4 / Container для смешанной архитектуры - сервисная + микросервисная (пояснения тут)
📌 Файл Draw.Io для просмотра в онлайн:
https://app.diagrams.net/#G1nk3D0XqRQ9A-2Bw9yGlLY2ZOOutSEStR#%7B%22pageId%22%3A%22qvlD7eRmiriUJArze8cl%22%7D
Для просмотра потребуется авторизация на Google Диске.
Как забрать себе и использовать:
📌 Файл Draw.Io, который вы можете сохранить себе, доступен по этой ссылке
1. Перейти по ссылке.
2. Сверху будет иконка "Скачать"
3. После скачивания:
3.1. Загружаете на свой гугл-диск и открываете с помощью приложения draw io.
3.2. Открываете на десктопном (установленном на компьютер) draw io.
Теперь вы можете самостоятельно создавать C4 и подглядывать на пример, который сделан согласно нотации на 100%.
#АрхитектураGA #TelMedGA
🔥28👍11❤6😍5
🔥 Онлайн-практика по Архитектуре систем 29 мая 🔥
Обсуждения Backend-разработчиков могут вызывать страх и желание уточнять каждое слово через Google: "Выделяем микросервис, делаем API-Gateway, тут оркестратор не нужен, здесь берём REST API, а GraphQL не подойдёт, а там возможно gRPC".
Так, стооп, а почему? Нет времени объяснять.
Но запроектировать интеграцию внутри системы и описать метод gRPC уже просят.
И вот ты в шоке. С заметками по встрече. И начинаются приключения с поиском информации.
Чтобы понять тему и перенести знания в реальный проект, нужны большие и реалистичные примеры, а не "три квадратика, две стрелочки - смотри как просто" 😠
Поэтому мы готовим для вас практический вебинар с жизненным примером, чтобы разобраться с новой темой:
🔥 Архитектура и API: от монолита к микросервисам
🗓 29 МАЯ, 19:00 МСК (СРЕДА)
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
Отработанные на реальной задаче навыки по архитектуре и API помогут перейти на новый уровень в системном анализе и стать более ценным специалистом для вашей компании 🙌
Готовы получать новые навыки сразу на практике?
Регистрируйтесь и делитесь постом с коллегами! 😉
Обсуждения Backend-разработчиков могут вызывать страх и желание уточнять каждое слово через Google: "Выделяем микросервис, делаем API-Gateway, тут оркестратор не нужен, здесь берём REST API, а GraphQL не подойдёт, а там возможно gRPC".
Так, стооп, а почему? Нет времени объяснять.
Но запроектировать интеграцию внутри системы и описать метод gRPC уже просят.
И вот ты в шоке. С заметками по встрече. И начинаются приключения с поиском информации.
Чтобы понять тему и перенести знания в реальный проект, нужны большие и реалистичные примеры, а не "три квадратика, две стрелочки - смотри как просто" 😠
Поэтому мы готовим для вас практический вебинар с жизненным примером, чтобы разобраться с новой темой:
🔥 Архитектура и API: от монолита к микросервисам
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
Отработанные на реальной задаче навыки по архитектуре и API помогут перейти на новый уровень в системном анализе и стать более ценным специалистом для вашей компании 🙌
Готовы получать новые навыки сразу на практике?
Регистрируйтесь и делитесь постом с коллегами! 😉
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15👍7❤2
💫 Как быстро разобраться с новым API: REST, SOAP, GraphQL, и другие 💫
Работа с неизвестными API так или иначе встречается в нашей работе, когда мы растем: расширяем опыт и экспертизу. С потребностью изучения API аналитики встречаются в ситуациях, когда делают интеграции с новыми системами, проектируют архитектуру и выбирают API для межсервисного взаимодействия с архитекторами, при переходе в новые компании и проекты.
Мои первые API, с которыми я начинала работать, были REST и SOAP. Сначала я знакомилась с ними в интеграциях, потом при проектировании методов и постановке задач на Backend-разработчиков.
Больше всего опыта у меня связано с REST и он основа моих знаний. одновременно с ним был SOAP, но в меньших объемах. Когда появилась потребность узнать WebSocket, я уже интуитивно понимала, что важно искать в API-документации и куда смотреть, чтобы разобраться.
Выработался алгоритм “как в знакомиться с новым способом обмена данными между системами”. Так что GraphQL, SDK и прочие страшные на первый взгляд названия уже не были страшны.
Как я вижу - изучение API сравнимо с изучением иностранных языков. С детства ты учишь и используешь один язык (для меня это был REST API), в школе тебя заставляют учить второй язык и он дается тяжело. Из любопытства учишь 3-ий, и начинаешь понимать особенности “как учить”. А с 4-ого тебе всё легко 🙃
Делюсь своим подходом к изучению API с вами 💫
-------------
С чего начать изучение нового API?
1️⃣ Узнать общую информацию
2️⃣ Принцип формирования URL запроса
3️⃣ Принцип формирования Body запроса
4️⃣ Принцип формирования ответа (коды + тело)
5️⃣ Требования к авторизации и аутентификации запросов
6️⃣ Примеры документации
7️⃣ Тестирование через Postman или другие инструменты
🎱 Всё остальное познается через практику и опыт работы над проектами.
-------------
Подробнее каждый пункт разберу в следующем посте 👇
#АрхитектураGA
Работа с неизвестными API так или иначе встречается в нашей работе, когда мы растем: расширяем опыт и экспертизу. С потребностью изучения API аналитики встречаются в ситуациях, когда делают интеграции с новыми системами, проектируют архитектуру и выбирают API для межсервисного взаимодействия с архитекторами, при переходе в новые компании и проекты.
Мои первые API, с которыми я начинала работать, были REST и SOAP. Сначала я знакомилась с ними в интеграциях, потом при проектировании методов и постановке задач на Backend-разработчиков.
Больше всего опыта у меня связано с REST и он основа моих знаний. одновременно с ним был SOAP, но в меньших объемах. Когда появилась потребность узнать WebSocket, я уже интуитивно понимала, что важно искать в API-документации и куда смотреть, чтобы разобраться.
Выработался алгоритм “как в знакомиться с новым способом обмена данными между системами”. Так что GraphQL, SDK и прочие страшные на первый взгляд названия уже не были страшны.
Как я вижу - изучение API сравнимо с изучением иностранных языков. С детства ты учишь и используешь один язык (для меня это был REST API), в школе тебя заставляют учить второй язык и он дается тяжело. Из любопытства учишь 3-ий, и начинаешь понимать особенности “как учить”. А с 4-ого тебе всё легко 🙃
Делюсь своим подходом к изучению API с вами 💫
-------------
С чего начать изучение нового API?
1️⃣ Узнать общую информацию
2️⃣ Принцип формирования URL запроса
3️⃣ Принцип формирования Body запроса
4️⃣ Принцип формирования ответа (коды + тело)
5️⃣ Требования к авторизации и аутентификации запросов
6️⃣ Примеры документации
7️⃣ Тестирование через Postman или другие инструменты
🎱 Всё остальное познается через практику и опыт работы над проектами.
-------------
Подробнее каждый пункт разберу в следующем посте 👇
#АрхитектураGA
👍34❤7🔥4👎2
💫 Пошаговый план: с чего начать изучение нового API? 💫
1️⃣ Узнать общую информацию
Найдите статьи в сети, где рассказывают об использовании:
+ назначение,
+ общие принципы,
+ особенности и отличия от других API,
+ примеры использования в разных системах,
+ для каких видов архитектуры подходит,
+ влияние на выполнение нефункциональных требований проекта (НФТ).
2️⃣ Принцип формирования URL запроса
Есть ли типы методов, по аналогии с REST: POST, GET, PUT и другие.
Принцип формирования адреса запроса: структура и нейминг (именование).
3️⃣ Принцип формирования Body запроса
+ Используемый формат сообщений (JSON / XML и другие).
+ Особенности работы с этим форматом сообщений: структура, нейминг параметров, работа с массивами и уровнями вложенности.
4️⃣ Принцип формирования ответа (коды + тело)
+ Используемые стандартизованные коды ошибок (по аналогии со стандартными кодами HTTP-200, HTTP-404 и др).
+ Возможность и рекомендации для использования внутренних кодов ошибок.
+ Используемый формат сообщений (JSON / XML и другие).
+ Особенности работы с этим форматом сообщений: структура, нейминг параметров, работа с массивами и уровнями вложенности.
5️⃣ Требования к авторизации и аутентификации запросов
+ Какие способы авторизации используются.
+ Как она настраивается для запросов.
+ Как авторизационные данные хранятся на сервере для всей системы или для отдельных пользователей.
6️⃣ Примеры документации
+ Ищу примеры API-документации, которую можно протестировать.
+ Примеры документации, которая легко и понятно читается, чтобы использовать за образец на будущее при постановке задач на бэкенд разработчиков.
+ Также примеры документации, оформленной через разные инструменты (например, Swagger).
7️⃣ Тестирование через Postman или другие инструменты
+ Сначала определяю список инструментов, через которые можно проверять методы API (Postman, Swagger, Insomnia и другие).
+ Потом список инструментов, через которые можно документировать методы API (Confluence не считается).
+ Затем тестирую API и создаю коллекции запросов, создаю примеры документации, которые потенциально отправляются в моё портфолио.
🎱 Всё остальное познается через практику и опыт работы над проектами.
Этот подход точно применим для REST, SOAP, WebSocket, gRPC, GraphQL.
Рекомендую использовать его в самостоятельном обучении. Также с его помощью передаю свой опыт коллегам, которые приходят на проекты GetAnalyst 💫
Делитесь с коллегами и сохраняйте в закладки ❤️
#АрхитектураGA
1️⃣ Узнать общую информацию
Найдите статьи в сети, где рассказывают об использовании:
+ назначение,
+ общие принципы,
+ особенности и отличия от других API,
+ примеры использования в разных системах,
+ для каких видов архитектуры подходит,
+ влияние на выполнение нефункциональных требований проекта (НФТ).
2️⃣ Принцип формирования URL запроса
Есть ли типы методов, по аналогии с REST: POST, GET, PUT и другие.
Принцип формирования адреса запроса: структура и нейминг (именование).
3️⃣ Принцип формирования Body запроса
+ Используемый формат сообщений (JSON / XML и другие).
+ Особенности работы с этим форматом сообщений: структура, нейминг параметров, работа с массивами и уровнями вложенности.
4️⃣ Принцип формирования ответа (коды + тело)
+ Используемые стандартизованные коды ошибок (по аналогии со стандартными кодами HTTP-200, HTTP-404 и др).
+ Возможность и рекомендации для использования внутренних кодов ошибок.
+ Используемый формат сообщений (JSON / XML и другие).
+ Особенности работы с этим форматом сообщений: структура, нейминг параметров, работа с массивами и уровнями вложенности.
5️⃣ Требования к авторизации и аутентификации запросов
+ Какие способы авторизации используются.
+ Как она настраивается для запросов.
+ Как авторизационные данные хранятся на сервере для всей системы или для отдельных пользователей.
6️⃣ Примеры документации
+ Ищу примеры API-документации, которую можно протестировать.
+ Примеры документации, которая легко и понятно читается, чтобы использовать за образец на будущее при постановке задач на бэкенд разработчиков.
+ Также примеры документации, оформленной через разные инструменты (например, Swagger).
7️⃣ Тестирование через Postman или другие инструменты
+ Сначала определяю список инструментов, через которые можно проверять методы API (Postman, Swagger, Insomnia и другие).
+ Потом список инструментов, через которые можно документировать методы API (Confluence не считается).
+ Затем тестирую API и создаю коллекции запросов, создаю примеры документации, которые потенциально отправляются в моё портфолио.
🎱 Всё остальное познается через практику и опыт работы над проектами.
Этот подход точно применим для REST, SOAP, WebSocket, gRPC, GraphQL.
Рекомендую использовать его в самостоятельном обучении. Также с его помощью передаю свой опыт коллегам, которые приходят на проекты GetAnalyst 💫
Делитесь с коллегами и сохраняйте в закладки ❤️
#АрхитектураGA
❤🔥20👍14💯4❤1
🕘 Планирование: как успеть всё и ничего не забыть? 🕘
Планирование времени - одна из важнейших частей жизни. Когда я серьезно занялась этим вопросом, то начала лучше управлять своей жизнью и стала успевать гораздо больше.
При планировании и отчетности перед собой я вижу ценность в работе, количество выполненных дел удовлетворяет, нахожу время на отдых. А еще я спокойна и мотивирована, когда все 24 часа используются разумно и планируются адекватно.
Я серьёзно занялась этим вопросом, когда начала замечать как жадно беру на себя всё больше и больше задач, но ничего не успеваю. Jira и регулярные отчеты перед командами и заказчиками иногда заставляли краснеть. А чтобы это было реально “иногда”,
мне приходилось работать больше и без входных, и никто за это не платил и ничего не обещал. Это была моя инициатива и я о ней никому не говорила.
Лучший способ сгореть на работе. Почти так и получалось.
Чтение в моей жизни всегда было регулярным занятием. До определенного момента это была только классическая литература, детективы и романы, ИТ-книги. Но пост в Instagram и приближающееся выгорание принесли в мою жизнь судьбоносную книгу “То, как мы работаем - не работает”. После её прочтения я полностью переключилась на профессиональную литературу: управление временем, менеджмент и так далее. Кстати, сейчас перечитываю эту книгу, чтобы напомнить себе важные правила.
После этой книги я завела ежедневник. Начала планировать в ней каждый рабочий и выходной день: созвоны, почта, разбор мессенджеров, написание статьи под задачу, обед. Точность планирования до 15 минут.
С этим подходом я стала адекватнее относиться к взваливанию на себя новых задач с нереальными сроками. Видела, что 2 недели уже до конца расписаны и новое не воткнуть. Стала продуктивнее и счастливее, потому что отдых был спланирован.
Начинала с принципа “Я успею всё за сегодня”. Пришла к “1 день = 1 главная задача”. Но поверьте - меня частенько шатает.
👇👇👇
Планирование времени - одна из важнейших частей жизни. Когда я серьезно занялась этим вопросом, то начала лучше управлять своей жизнью и стала успевать гораздо больше.
При планировании и отчетности перед собой я вижу ценность в работе, количество выполненных дел удовлетворяет, нахожу время на отдых. А еще я спокойна и мотивирована, когда все 24 часа используются разумно и планируются адекватно.
Я серьёзно занялась этим вопросом, когда начала замечать как жадно беру на себя всё больше и больше задач, но ничего не успеваю. Jira и регулярные отчеты перед командами и заказчиками иногда заставляли краснеть. А чтобы это было реально “иногда”,
мне приходилось работать больше и без входных, и никто за это не платил и ничего не обещал. Это была моя инициатива и я о ней никому не говорила.
Я же обещала, значит сделаю. Пусть и ценой сна, личной жизни и отдыха.
Лучший способ сгореть на работе. Почти так и получалось.
Чтение в моей жизни всегда было регулярным занятием. До определенного момента это была только классическая литература, детективы и романы, ИТ-книги. Но пост в Instagram и приближающееся выгорание принесли в мою жизнь судьбоносную книгу “То, как мы работаем - не работает”. После её прочтения я полностью переключилась на профессиональную литературу: управление временем, менеджмент и так далее. Кстати, сейчас перечитываю эту книгу, чтобы напомнить себе важные правила.
После этой книги я завела ежедневник. Начала планировать в ней каждый рабочий и выходной день: созвоны, почта, разбор мессенджеров, написание статьи под задачу, обед. Точность планирования до 15 минут.
С этим подходом я стала адекватнее относиться к взваливанию на себя новых задач с нереальными сроками. Видела, что 2 недели уже до конца расписаны и новое не воткнуть. Стала продуктивнее и счастливее, потому что отдых был спланирован.
Начинала с принципа “Я успею всё за сегодня”. Пришла к “1 день = 1 главная задача”. Но поверьте - меня частенько шатает.
👇👇👇
❤15👏3👍2
🕘 Планирование: как успеть всё и ничего не забыть? 🕘
Начинала с принципа “Я успею всё за сегодня”. Пришла к “1 день = 1 главная задача”. Но поверьте - меня частенько шатает.
В ежедневнике за 2023-2024 так:
1. 10+ задач на день
2. 5-10 задач на день
3. 3-5 задач на день
4. 1-2 задачи на день + мелочи типа “разгребать чаты”
5. 3-5 задач на день
6. 5-10 задач….
А дальше вы догадались 🙂
Ревью делаю каждые 3-6 месяцев. Психую, что опять скатилась в многозадачность, и иду обратно к фокусировке внимания на “1 задача на 1 день”. При адекватном планировании жизнь гораздо счастливее.
Важное, чем хочу поделиться:
1. Я успеваю не всё, что у меня в планах на день. Поэтому пт всегда отдаю на “хвосты”.
2. Все задачи в памяти ежедневника. Голова - чтобы думать, а не чтобы хранить в ней тонны ненужной и нервирующей информации.
3. Учеба - тоже задача. Пусть и дополнительная к работе. На следующий день после учебы нужен отдых после работы.
4. Всю мелочевку на вечер - разборы чатов и почты раз в день, не более 1 часа, либо два раза по 30 минут. Это самое сложное с учетом специфики работы аналитиков.
5. Все рутинные и отчетные созвоны на вечер, когда голова уже работает не так бодро.
6. На каждые 90 минут в расписании 5-10 мин прогулки. В плане есть обед и перекусы.
7. Время для спортзала и другие личные планы тоже в ежедневнике.
Контроль времени помогает мне адекватнее планировать выполнение текущих задач, использовать опыт предыдущих задач для планирования будущих. Меньше неадекватных сроков, хотя честно признаюсь - они всё ещё. Я спокойнее и счастливее, когда есть планы и понятно что делать, чтобы дойти до цели.
Если вы сейчас в состоянии бесконечной работы и усталости, не видите целей и близки к выгораню, ищите новые способы управления временем, то я очень рекомендую книгу из предыдущего сообщения. Она поможет.
Друзья, а какие у вас лайфхаки по управлению временем?
Делитесь в комментариях. Возможно я и коллеги узнаем что-то новое для себя и применим в своей жизни))
Начинала с принципа “Я успею всё за сегодня”. Пришла к “1 день = 1 главная задача”. Но поверьте - меня частенько шатает.
В ежедневнике за 2023-2024 так:
1. 10+ задач на день
2. 5-10 задач на день
3. 3-5 задач на день
4. 1-2 задачи на день + мелочи типа “разгребать чаты”
5. 3-5 задач на день
6. 5-10 задач….
А дальше вы догадались 🙂
Ревью делаю каждые 3-6 месяцев. Психую, что опять скатилась в многозадачность, и иду обратно к фокусировке внимания на “1 задача на 1 день”. При адекватном планировании жизнь гораздо счастливее.
Важное, чем хочу поделиться:
1. Я успеваю не всё, что у меня в планах на день. Поэтому пт всегда отдаю на “хвосты”.
2. Все задачи в памяти ежедневника. Голова - чтобы думать, а не чтобы хранить в ней тонны ненужной и нервирующей информации.
3. Учеба - тоже задача. Пусть и дополнительная к работе. На следующий день после учебы нужен отдых после работы.
4. Всю мелочевку на вечер - разборы чатов и почты раз в день, не более 1 часа, либо два раза по 30 минут. Это самое сложное с учетом специфики работы аналитиков.
5. Все рутинные и отчетные созвоны на вечер, когда голова уже работает не так бодро.
6. На каждые 90 минут в расписании 5-10 мин прогулки. В плане есть обед и перекусы.
7. Время для спортзала и другие личные планы тоже в ежедневнике.
Контроль времени помогает мне адекватнее планировать выполнение текущих задач, использовать опыт предыдущих задач для планирования будущих. Меньше неадекватных сроков, хотя честно признаюсь - они всё ещё. Я спокойнее и счастливее, когда есть планы и понятно что делать, чтобы дойти до цели.
Если вы сейчас в состоянии бесконечной работы и усталости, не видите целей и близки к выгораню, ищите новые способы управления временем, то я очень рекомендую книгу из предыдущего сообщения. Она поможет.
Друзья, а какие у вас лайфхаки по управлению временем?
Делитесь в комментариях. Возможно я и коллеги узнаем что-то новое для себя и применим в своей жизни))
❤24👍12❤🔥5😁2
🐙 Пошаговый план в действии: знакомство с GraphQL 🐙
Сегодня мы погрузимся в GraphQL и разберем, как использовать “Пошаговый план: с чего начать изучение нового API?”.
Рассмотрим основные пункты и приведу примеры для проекта #TelMedGA 💊💉🧑⚕
1️⃣ Узнать общую информацию
➕ Назначение:
Запрашивать только те данные от сервера, которые нужны клиенту.
GraphQL — это язык запросов для API, который позволяет клиентам запрашивать только те данные, которые им нужны.
Интересно обратить внимание на терминологию:
- Язык запросов (GraphQL) фокусируется на том, как клиент формирует запросы к данным и какие операции он может выполнять. Это инструмент для взаимодействия с данными.
- Архитектурный стиль (REST) описывает, как строится и организуется сама система API, включая правила и стандарты для взаимодействия между клиентами и серверами.
➕ Общие принципы
1. Запросы к серверу используются для получения данных, а мутации — для их изменения.
2. Все запросы и мутации к одному URL.
3. Сервер GraphQL определяет схему, которая описывает типы данных и операции, доступные для клиентов.
4. Клиенты могут запрашивать только те данные, которые им нужны. Это уменьшает объем передаваемых данных и улучшает производительность.
➕ Особенности и отличия от других API
1. В отличие от REST, где нужно делать отдельный URL для каждого запроса (метода / функции), в GraphQL нужен только один URL для всех запросов.
2. За один запрос можно выбрать только те данные о сущностях, которые нужны. Сравнимо с SQL (тоже язык запросов), только это про API.
3. Язык запросов свой и не похож на другие API, а вот ответ обычно возвращается в формате JSON. Структура JSON строится на основе запроса.
#АрхитектураGA
Продолжение 👇👇👇
Сегодня мы погрузимся в GraphQL и разберем, как использовать “Пошаговый план: с чего начать изучение нового API?”.
Рассмотрим основные пункты и приведу примеры для проекта #TelMedGA 💊💉🧑⚕
1️⃣ Узнать общую информацию
➕ Назначение:
Запрашивать только те данные от сервера, которые нужны клиенту.
GraphQL — это язык запросов для API, который позволяет клиентам запрашивать только те данные, которые им нужны.
Интересно обратить внимание на терминологию:
- Язык запросов (GraphQL) фокусируется на том, как клиент формирует запросы к данным и какие операции он может выполнять. Это инструмент для взаимодействия с данными.
- Архитектурный стиль (REST) описывает, как строится и организуется сама система API, включая правила и стандарты для взаимодействия между клиентами и серверами.
➕ Общие принципы
1. Запросы к серверу используются для получения данных, а мутации — для их изменения.
2. Все запросы и мутации к одному URL.
3. Сервер GraphQL определяет схему, которая описывает типы данных и операции, доступные для клиентов.
4. Клиенты могут запрашивать только те данные, которые им нужны. Это уменьшает объем передаваемых данных и улучшает производительность.
➕ Особенности и отличия от других API
1. В отличие от REST, где нужно делать отдельный URL для каждого запроса (метода / функции), в GraphQL нужен только один URL для всех запросов.
2. За один запрос можно выбрать только те данные о сущностях, которые нужны. Сравнимо с SQL (тоже язык запросов), только это про API.
3. Язык запросов свой и не похож на другие API, а вот ответ обычно возвращается в формате JSON. Структура JSON строится на основе запроса.
#АрхитектураGA
Продолжение 👇👇👇
❤🔥12🔥8❤5👍4⚡1💯1
🐙 Пошаговый план в действии: ссылки по GraphQL 🐙
➕ Примеры использования:
1. Социальные сети (Facebook)
Непубличный внутренний API для мобильных и других приложений. Не путать с Graph API, это другое.
https://stackoverflow.com/questions/42750054/is-facebooks-graph-api-using-graphql
Позволяет мобильным приложениям минимизировать объем передаваемых данных, что важно для производительности и потребления трафика.
2. Финансовые приложения (Stripe)
https://docs.stripe.com/connectors/adobe-commerce/custom-storefront
Оптимизирует запросы для повышения производительности и уменьшения задержек за счет получения только нужных данных от сервера.
3. Confluence
https://developer.atlassian.com/platform/atlassian-graphql-api/graphql/#overview
Возможность запрашивать только нужные данные из различных сущностей Confluence в одном запросе, что упрощает интеграцию и повышает производительность.
➕ Для каких видов архитектуры подходит:
Можно использовать в любой архитектуре. Важно понимать, что он создан для снижения объема передаваемых данных по сети.
Идеален для использования мобильными приложениями при получении данных от сервера и может помочь в повышении эффективности микросервисной архитектуры.
➕ Влияние на выполнение НФТ:
1. Производительность: Оптимизация запросов за счет получения только необходимых данных.
2. Масштабируемость: Следствие производительности, позволяет лучше использовать ресурсы памяти и не покупать лишние.
➕ Полезные ресурсы для изучения:
1. Введение в GraphQL от GraphQL Foundation (ENG) - первоисточник + переводчик всегда лучше любого другого ресурса.
2. Серия постов по GraphQL от GetAnalyst со всеми примерами, потому что разбор почти по всему остальному плану знакомства я уже делала для вас на примере другого проекта.
3. В чем разница между GraphQL и REST от Amazon - среднего уровня статья, больше про теорию.
4. Руководство по GraphQL - потрясающая подборка примеров, мой любимый подход “теория на практике”.
#АрхитектураGA
➕ Примеры использования:
1. Социальные сети (Facebook)
Непубличный внутренний API для мобильных и других приложений. Не путать с Graph API, это другое.
https://stackoverflow.com/questions/42750054/is-facebooks-graph-api-using-graphql
Позволяет мобильным приложениям минимизировать объем передаваемых данных, что важно для производительности и потребления трафика.
2. Финансовые приложения (Stripe)
https://docs.stripe.com/connectors/adobe-commerce/custom-storefront
Оптимизирует запросы для повышения производительности и уменьшения задержек за счет получения только нужных данных от сервера.
3. Confluence
https://developer.atlassian.com/platform/atlassian-graphql-api/graphql/#overview
Возможность запрашивать только нужные данные из различных сущностей Confluence в одном запросе, что упрощает интеграцию и повышает производительность.
➕ Для каких видов архитектуры подходит:
Можно использовать в любой архитектуре. Важно понимать, что он создан для снижения объема передаваемых данных по сети.
Идеален для использования мобильными приложениями при получении данных от сервера и может помочь в повышении эффективности микросервисной архитектуры.
➕ Влияние на выполнение НФТ:
1. Производительность: Оптимизация запросов за счет получения только необходимых данных.
2. Масштабируемость: Следствие производительности, позволяет лучше использовать ресурсы памяти и не покупать лишние.
➕ Полезные ресурсы для изучения:
1. Введение в GraphQL от GraphQL Foundation (ENG) - первоисточник + переводчик всегда лучше любого другого ресурса.
2. Серия постов по GraphQL от GetAnalyst со всеми примерами, потому что разбор почти по всему остальному плану знакомства я уже делала для вас на примере другого проекта.
3. В чем разница между GraphQL и REST от Amazon - среднего уровня статья, больше про теорию.
4. Руководство по GraphQL - потрясающая подборка примеров, мой любимый подход “теория на практике”.
#АрхитектураGA
💯8👍7❤3