🐙 Пошаговый план по API в действии: примеры GraphQL 🐙
Продолжаем вчерашнюю серию постов про GraphQL 🙌
2️⃣ Принцип формирования URL запроса
HTTP - основной протокол через который работает GraphQL.
Все запросы отправляются на один и тот же URL (эндпоинт), обычно /graphql. Это главное отличие от REST.
HTTP-сервер GraphQL должен уметь обрабатывать HTTP-методы GET и POST.
Если используется метод GET, то URL-запроса будет выглядеть так:
- это запрос на получение всех записей на прием для конкретного врача. Вся структура запроса отправляется в query-параметры URL.
Если используется метод POST, то URL-запроса будет:
А в теле запроса будут все необходимые параметры.
Предпочтение для всех запросов отдаётся методу POST, чтобы не засорять URL-запроса, т.к. его длина обычно ограничена.
🔗 Источник
3️⃣ Принцип формирования Body запроса
3 ключевых принципа формирования Body запроса в GraphQL:
1. Запросы (Queries)
2. Мутации (Mutations)
3. Подписки (Subscriptions)
🌸 Запросы (Queries)
Запросы используются для получения данных. Клиент определяет, какие именно данные ему нужны, и получает их в виде JSON-объекта. В запросах можно использовать фильтры для более точного выбора данных.
Похоже на GET в REST API.
Пример - Просмотр списка записей на прием к врачу с фильтром по доктору
POST https://telmed.com/graphql
🌸 Мутации (Mutations)
Продолжение 👇👇👇
#АрхитектураGA #TelMedGA
Продолжаем вчерашнюю серию постов про GraphQL 🙌
2️⃣ Принцип формирования URL запроса
HTTP - основной протокол через который работает GraphQL.
Все запросы отправляются на один и тот же URL (эндпоинт), обычно /graphql. Это главное отличие от REST.
HTTP-сервер GraphQL должен уметь обрабатывать HTTP-методы GET и POST.
Если используется метод GET, то URL-запроса будет выглядеть так:
https://telmed.com/graphql?query={appointments(doctorId:12345){date,time,doctor{name,specialization}}} - это запрос на получение всех записей на прием для конкретного врача. Вся структура запроса отправляется в query-параметры URL.
Если используется метод POST, то URL-запроса будет:
https://telmed.com/graphql
А в теле запроса будут все необходимые параметры.
Предпочтение для всех запросов отдаётся методу POST, чтобы не засорять URL-запроса, т.к. его длина обычно ограничена.
🔗 Источник
3️⃣ Принцип формирования Body запроса
3 ключевых принципа формирования Body запроса в GraphQL:
1. Запросы (Queries)
2. Мутации (Mutations)
3. Подписки (Subscriptions)
🌸 Запросы (Queries)
Запросы используются для получения данных. Клиент определяет, какие именно данные ему нужны, и получает их в виде JSON-объекта. В запросах можно использовать фильтры для более точного выбора данных.
Похоже на GET в REST API.
Пример - Просмотр списка записей на прием к врачу с фильтром по доктору
POST https://telmed.com/graphql
query {
appointments(doctorId: "doctor-456") {
id
date
time
patient {
id
name
}
doctor {
id
name
}
}
}🌸 Мутации (Mutations)
Продолжение 👇👇👇
#АрхитектураGA #TelMedGA
❤12👍5🔥4
🐙 Пошаговый план в действии: примеры GraphQL 🐙
3️⃣ Принцип формирования Body запроса
🌸 Мутации (Mutations)
Мутации используются для изменения данных на сервере, например, создания, обновления или удаления записей. Мутации похожи на запросы, но кроме получения данных, они изменяют их на сервере.
Похоже на POST, PUT, PATCH и DELETE в REST API.
Пример мутации - Запись на прием к врачу
POST https://telmed.com/graphql
Пример мутации - Изменение записи на прием к врачу
POST https://telmed.com/graphql
❗️Обращаем внимание на название методов в мутациях - именно в них ответственность за создание и изменение данных: createAppointment и updateAppointment.
🌸 Подписки (Subscriptions)
Подписки позволяют клиенту получать данные в реальном времени при изменении состояния данных на сервере. Они полезны для таких сценариев, как обновления в реальном времени.
Похоже на WebSocket.
Далее я рекомендую посмотреть Серию постов по GraphQL от GetAnalyst с дополнительными примерами.
Кажется, что по GraphQL напрашивается отдельное пособие в блог в ближайшее время, чтобы сразу с тестированием через Postman, набором примеров и ссылок?
Давайте больше 111 ❤️, чтобы я поняла насколько актуально))
#АрхитектураGA #TelMedGA
3️⃣ Принцип формирования Body запроса
🌸 Мутации (Mutations)
Мутации используются для изменения данных на сервере, например, создания, обновления или удаления записей. Мутации похожи на запросы, но кроме получения данных, они изменяют их на сервере.
Похоже на POST, PUT, PATCH и DELETE в REST API.
Пример мутации - Запись на прием к врачу
POST https://telmed.com/graphql
mutation {
createAppointment(input: {
date: "2024-06-01",
time: "10:00",
patientId: "patient-123",
doctorId: "doctor-456"
}) {
appointment {
id
date
time
patient {
id
name
}
doctor {
id
name
}
}
}
}
Пример мутации - Изменение записи на прием к врачу
POST https://telmed.com/graphql
mutation {
updateAppointment(id: "appointment-789", input: {
date: "2024-06-02",
time: "14:00"
}) {
appointment {
id
date
time
patient {
id
name
}
doctor {
id
name
}
}
}
}
❗️Обращаем внимание на название методов в мутациях - именно в них ответственность за создание и изменение данных: createAppointment и updateAppointment.
🌸 Подписки (Subscriptions)
Подписки позволяют клиенту получать данные в реальном времени при изменении состояния данных на сервере. Они полезны для таких сценариев, как обновления в реальном времени.
Похоже на WebSocket.
Далее я рекомендую посмотреть Серию постов по GraphQL от GetAnalyst с дополнительными примерами.
Кажется, что по GraphQL напрашивается отдельное пособие в блог в ближайшее время, чтобы сразу с тестированием через Postman, набором примеров и ссылок?
Давайте больше 111 ❤️, чтобы я поняла насколько актуально))
#АрхитектураGA #TelMedGA
❤74🔥4👍1
Я каждый раз пересматриваю обратную связь после вебинаров, и в этот раз на “Архитектуру и API” она особенная! Еще больше развернутых сообщений, чем обычно.
Искренне благодарю за то, что создаете эту атмосферу живого общения и большой аудитории в онлайн, задаете вопросы и учитесь ❤️ Вы делаете вебинары такими!
Екатерина:
Анна:
Константин:
Евгения:
Итоги:
✅ СА в задачах архитектуры: проще сказать где не подключают, чем ставить галочки почти на все задачи в списке обязанностей архитектора.
✅ Разобрали применение SOAP, gRPC, REST, GraphQL и WebSocket в различных видах архитектуры. Узнали рекомендации по выбору API.
✅ Спроектировали схему монолитной архитектуры для реального проекта по системе страхования. Определили все интеграции и приложения.
✅ Затем сделали схему архитектуры модульного монолита.
✅ Разобрали принципы проектирования сервисной (SOA) и микросервисной (MSA) архитектуры. Определили отличия между ними на примерах. Сделали схему смешанной архитектуры SOA + MSA для проекта: переезд от монолита к микросервисам.
Было много ценной информации, которую сразу применяли на практике. Уложились в 3 часа)))
По итогам получили три схемы архитектуры и практический кейс в копилку! 🙌
❗️Про запись информация будет опубликована до завтра
📚 В конце представила программу Проектирование Архитектуры, где мы с коллегами в течение 12 недель будем погружаться в новый проект, в деталях разбираться со всеми шаблонами проектирования, API и брокерами.
Жду встречи с новой командой! ❤️
Желаю вам хороших новостей и яркого дня сегодня!
Искренне благодарю за то, что создаете эту атмосферу живого общения и большой аудитории в онлайн, задаете вопросы и учитесь ❤️ Вы делаете вебинары такими!
Екатерина:
Было невероятно интересно и будучи Мидл были новые знания и очень интересная информация! Спасибо
Анна:
Екатерина просто ОГОНЬ, лучше спикера еще не слышала
Константин:
Было довольно наглядно, здорово, что каждая стрелка и каждый квадрат разбирается и что речь идёт о реальном кейсе, который проще представлять. И интересно, что показано, что архитектуры довольно смешанные, а не строгие) Спасибо!!
Евгения:
Спасибо за прекрасный вебинар! Очень полезно, подробно, много деталей и объяснений на практике.
Итоги:
✅ СА в задачах архитектуры: проще сказать где не подключают, чем ставить галочки почти на все задачи в списке обязанностей архитектора.
✅ Разобрали применение SOAP, gRPC, REST, GraphQL и WebSocket в различных видах архитектуры. Узнали рекомендации по выбору API.
✅ Спроектировали схему монолитной архитектуры для реального проекта по системе страхования. Определили все интеграции и приложения.
✅ Затем сделали схему архитектуры модульного монолита.
✅ Разобрали принципы проектирования сервисной (SOA) и микросервисной (MSA) архитектуры. Определили отличия между ними на примерах. Сделали схему смешанной архитектуры SOA + MSA для проекта: переезд от монолита к микросервисам.
Было много ценной информации, которую сразу применяли на практике. Уложились в 3 часа)))
По итогам получили три схемы архитектуры и практический кейс в копилку! 🙌
❗️Про запись информация будет опубликована до завтра
📚 В конце представила программу Проектирование Архитектуры, где мы с коллегами в течение 12 недель будем погружаться в новый проект, в деталях разбираться со всеми шаблонами проектирования, API и брокерами.
Жду встречи с новой командой! ❤️
Желаю вам хороших новостей и яркого дня сегодня!
❤🔥22👍12❤6🔥3
🏰 Системный аналитик в задачах на архитектуру 🏰
Проектирование архитектуры систем вместе с разработчиками и архитекторами — одна из больших задач системного аналитика. В этом процессе аналитик становится мостиком между бизнес-процессами и техническими решениями, в общем-то как и всегда. Понимать надо глубоко и то, и другое.
Основная сложность таких задач заключается в необходимости работать в условиях высокой степени неопределенности: готовых шаблонов или решений нет.
Аналитик делает множество исследовательских задач, предоставляет результаты команде и выбирает с ними обоснованные технические решения для проекта - надо ли делать отдельный микросервис под задачу, какой API выбрать для создания интеграционного шлюза, какой брокер взять для обработки сообщений, и почему здесь вообще нужен брокер.
Ниже приведен краткий гайд по основным задачам СА связанным с проектированием архитектуры:
🟢 1. Исследование и анализ
Первый шаг в проектировании архитектуры — это глубокое исследование и анализ текущей ситуации. Необходимо понять бизнес-требования, изучить существующую систему, если она есть, а также определить возможные ограничения и риски для проекта.
Основные задачи:
+ Сбор и анализ требований от всех заинтересованных сторон.
+ Изучение существующих решений и технологий.
+ Определение списка пользователей и приложений для них.
+ Выявление списка систем, с которыми нужны интеграции.
🟢 2. Выбор основного подхода к проектированию архитектуры
После проведения исследований и анализа необходимо выбрать основной подход к проектированию архитектуры, который будет наилучшим образом соответствовать требованиям и условиям проекта.
+ Оценка различных архитектурных стилей (монолитная, микросервисная, сервисно-ориентированная и т.д.).
+ Выбор подходящего архитектурного стиля на основе требований и ограничений. Если небольшой и новый проект, то тут чаще всего останавливаются на монолите.
#АрхитектураGA
Продолжение 👇👇👇
Проектирование архитектуры систем вместе с разработчиками и архитекторами — одна из больших задач системного аналитика. В этом процессе аналитик становится мостиком между бизнес-процессами и техническими решениями, в общем-то как и всегда. Понимать надо глубоко и то, и другое.
Основная сложность таких задач заключается в необходимости работать в условиях высокой степени неопределенности: готовых шаблонов или решений нет.
Аналитик делает множество исследовательских задач, предоставляет результаты команде и выбирает с ними обоснованные технические решения для проекта - надо ли делать отдельный микросервис под задачу, какой API выбрать для создания интеграционного шлюза, какой брокер взять для обработки сообщений, и почему здесь вообще нужен брокер.
Ниже приведен краткий гайд по основным задачам СА связанным с проектированием архитектуры:
🟢 1. Исследование и анализ
Первый шаг в проектировании архитектуры — это глубокое исследование и анализ текущей ситуации. Необходимо понять бизнес-требования, изучить существующую систему, если она есть, а также определить возможные ограничения и риски для проекта.
Основные задачи:
+ Сбор и анализ требований от всех заинтересованных сторон.
+ Изучение существующих решений и технологий.
+ Определение списка пользователей и приложений для них.
+ Выявление списка систем, с которыми нужны интеграции.
🟢 2. Выбор основного подхода к проектированию архитектуры
После проведения исследований и анализа необходимо выбрать основной подход к проектированию архитектуры, который будет наилучшим образом соответствовать требованиям и условиям проекта.
+ Оценка различных архитектурных стилей (монолитная, микросервисная, сервисно-ориентированная и т.д.).
+ Выбор подходящего архитектурного стиля на основе требований и ограничений. Если небольшой и новый проект, то тут чаще всего останавливаются на монолите.
#АрхитектураGA
Продолжение 👇👇👇
❤15👍1
🏰 Как Системный аналитик в задачах на архитектуру? 🏰
Продолжение 👇👇👇
+ Определение принципов и стандартов проектирования, которые будут использоваться. Их документирование.
+ Разработка стратегии миграции, если проект включает модернизацию существующей системы. Например, частая задача - миграция с монолита на микросервисы.
Работа над этим и последующими пунктами ведется совместно с архитекторами и разработчиками. Аналитик как правило отвечает за формирование базы знаний по проекту и сопоставление технических решений с бизнес-требованиями.
🟢 3. Формирование концептуальной схемы
Когда выбран основной подход, необходимо сформировать концептуальную схему будущей архитектуры. Это включает в себя высокоуровневое моделирование всех основных компонентов и их взаимодействий.
+ Создание концептуальной схемы архитектуры, охватывающей основные компоненты и их взаимодействия.
+ Определение границ и ответственности по функциональности для каждого компонента.
+ Распределение данных по различным БД и подбор СУБД.
+ Моделирование взаимодействий между компонентами с учетом функциональных и нефункциональных требований - выбор API, определение мест, где нужны Kafka, RabbtMQ или другие решения.
+ Проведение обзорных сессий с заинтересованными сторонами для получения обратной связи и внесения корректировок.
🟢 4. Влияние нефункциональных требований
Нефункциональные требования, такие как производительность, масштабируемость, надежность и безопасность, оказывают значительное влияние на архитектуру системы.
Системный аналитик должен уметь интегрировать эти требования в проект, чтобы обеспечить соответствие конечной системы ожиданиям всех заинтересованных сторон.
+ Определение нефункциональных требований, включая требования по производительности, масштабируемости, безопасности и доступности.
+ Оценка архитектуры на соответствие нефункциональным требованиям.
+ Документирование и передача сведений о нефункциональных требованиях на сотрудников инфраструктуры. Обсуждение совместно с ними и архитекторами получившейся концептуальной схемы архитектуры. Здесь определяют количество копий серверов для старта, условия масштабируемости и другие.
+ Документирование всех нефункциональных требований и проверка их реализации на всех этапах проекта.
Эти задачи покрывают ключевые этапы проектирования архитектуры, в которых может участвовать системный аналитик.
#АрхитектураGA
Продолжение 👇👇👇
+ Определение принципов и стандартов проектирования, которые будут использоваться. Их документирование.
+ Разработка стратегии миграции, если проект включает модернизацию существующей системы. Например, частая задача - миграция с монолита на микросервисы.
Работа над этим и последующими пунктами ведется совместно с архитекторами и разработчиками. Аналитик как правило отвечает за формирование базы знаний по проекту и сопоставление технических решений с бизнес-требованиями.
🟢 3. Формирование концептуальной схемы
Когда выбран основной подход, необходимо сформировать концептуальную схему будущей архитектуры. Это включает в себя высокоуровневое моделирование всех основных компонентов и их взаимодействий.
+ Создание концептуальной схемы архитектуры, охватывающей основные компоненты и их взаимодействия.
+ Определение границ и ответственности по функциональности для каждого компонента.
+ Распределение данных по различным БД и подбор СУБД.
+ Моделирование взаимодействий между компонентами с учетом функциональных и нефункциональных требований - выбор API, определение мест, где нужны Kafka, RabbtMQ или другие решения.
+ Проведение обзорных сессий с заинтересованными сторонами для получения обратной связи и внесения корректировок.
🟢 4. Влияние нефункциональных требований
Нефункциональные требования, такие как производительность, масштабируемость, надежность и безопасность, оказывают значительное влияние на архитектуру системы.
Системный аналитик должен уметь интегрировать эти требования в проект, чтобы обеспечить соответствие конечной системы ожиданиям всех заинтересованных сторон.
+ Определение нефункциональных требований, включая требования по производительности, масштабируемости, безопасности и доступности.
+ Оценка архитектуры на соответствие нефункциональным требованиям.
+ Документирование и передача сведений о нефункциональных требованиях на сотрудников инфраструктуры. Обсуждение совместно с ними и архитекторами получившейся концептуальной схемы архитектуры. Здесь определяют количество копий серверов для старта, условия масштабируемости и другие.
+ Документирование всех нефункциональных требований и проверка их реализации на всех этапах проекта.
Эти задачи покрывают ключевые этапы проектирования архитектуры, в которых может участвовать системный аналитик.
#АрхитектураGA
❤21👍2
📹🔴 Доступ к записи "Архитектура и API: от монолита к микросервисам" 🔴 📹
Мы благодарим всех, кто смог подключиться онлайн вчера! Как всегда - это была крутая практика с вопросами, которые помогли её улучшить.
Не все смогли присутствовать онлайн или спланировать этот вечер, чтобы успеть на вебинар. А часовые пояса - отдельная тема для откладывания на потом.
Поэтому мы подготовили возможность посмотреть повтор в удобное время, чтобы вы не упустили важную тему по архитектуре систем для системных аналитиков:
Запись вебинара:
🔴 Проектирование архитектуры: от монолита к микросервисам
🗓 Только 1 и 2 июня
🔗 ПОЛУЧИТЬ ДОСТУП
+ регистрация будет открыта до вечера субботы
+ если были зарегистрированы на основную дату, то повторно регистрироваться не нужно
Доступы к записи придут только на EMAIL в воскресенье утром ☀️
Мы благодарим всех, кто смог подключиться онлайн вчера! Как всегда - это была крутая практика с вопросами, которые помогли её улучшить.
Не все смогли присутствовать онлайн или спланировать этот вечер, чтобы успеть на вебинар. А часовые пояса - отдельная тема для откладывания на потом.
Поэтому мы подготовили возможность посмотреть повтор в удобное время, чтобы вы не упустили важную тему по архитектуре систем для системных аналитиков:
Запись вебинара:
🗓 Только 1 и 2 июня
🔗 ПОЛУЧИТЬ ДОСТУП
+ регистрация будет открыта до вечера субботы
+ если были зарегистрированы на основную дату, то повторно регистрироваться не нужно
Доступы к записи придут только на EMAIL в воскресенье утром ☀️
Please open Telegram to view this post
VIEW IN TELEGRAM
👍18❤6🔥2
🐙 Знакомство с gRPC 🐙
1️⃣ Общая информация
▫️gRPC — система удалённого вызова процедур.
Разработана в Google в 2015 году.
▫️Использует Protocol Buffers — protobuf — буферный протокол сериализации данных, проще говоря преобразования данных.
▫️RPC (Remote Procedure Call) — это способ, который позволяет одной программе на сервере А вызвать функцию в другой программе, которая находится на другом сервере B, как будто это локальный вызов. Другими словами, как будто вызов функции происходит на одном сервере A, а не на разных.
▫️Зачем нужна сериализация в gRPC?
(= Зачем нужно преобразование данных?)
1. Сериализация позволяет компактно представлять данные в бинарном виде, что уменьшает объем передаваемой информации и ускоряет передачу.
2. Сериализованные данные можно передавать между разными системами и языками программирования, сохраняя их структуру и типы данных.
3. Сериализованные данные проще проверять на целостность и корректность при передаче по сети.
➕ Назначение gRPC
Оптимизировать связь между приложениями и сервисами с помощью высокопроизводительных RPC.
➕ Общие принципы
1. gRPC использует протокол HTTP/2 для транспортировки данных, обеспечивая высокую производительность и двунаправленное потоковое взаимодействие.
2. Определение контрактов между клиентом и сервером осуществляется с помощью proto-файлов.
3. Proto-файлы компактны и позволяют автоматически генерировать исходный код для различных языков программирования.
4. gRPC поддерживает множество языков программирования, что облегчает интеграцию в различных системах.
➕ Особенности и отличия от других API
1. В отличие от REST, где каждый запрос требует нового HTTP-соединения, gRPC использует постоянное HTTP/2 соединение, что улучшает производительность.
2. Благодаря protobuf можно быстрее передавать данные по сети.
Итого:
gRPC выбираем, когда нужна высокая скорость обмена данными между системами или сервисами.
#АрхитектураGA
Продолжение 👇👇👇
1️⃣ Общая информация
▫️gRPC — система удалённого вызова процедур.
Разработана в Google в 2015 году.
▫️Использует Protocol Buffers — protobuf — буферный протокол сериализации данных, проще говоря преобразования данных.
▫️RPC (Remote Procedure Call) — это способ, который позволяет одной программе на сервере А вызвать функцию в другой программе, которая находится на другом сервере B, как будто это локальный вызов. Другими словами, как будто вызов функции происходит на одном сервере A, а не на разных.
▫️Зачем нужна сериализация в gRPC?
(= Зачем нужно преобразование данных?)
1. Сериализация позволяет компактно представлять данные в бинарном виде, что уменьшает объем передаваемой информации и ускоряет передачу.
2. Сериализованные данные можно передавать между разными системами и языками программирования, сохраняя их структуру и типы данных.
3. Сериализованные данные проще проверять на целостность и корректность при передаче по сети.
➕ Назначение gRPC
Оптимизировать связь между приложениями и сервисами с помощью высокопроизводительных RPC.
➕ Общие принципы
1. gRPC использует протокол HTTP/2 для транспортировки данных, обеспечивая высокую производительность и двунаправленное потоковое взаимодействие.
2. Определение контрактов между клиентом и сервером осуществляется с помощью proto-файлов.
3. Proto-файлы компактны и позволяют автоматически генерировать исходный код для различных языков программирования.
4. gRPC поддерживает множество языков программирования, что облегчает интеграцию в различных системах.
➕ Особенности и отличия от других API
1. В отличие от REST, где каждый запрос требует нового HTTP-соединения, gRPC использует постоянное HTTP/2 соединение, что улучшает производительность.
2. Благодаря protobuf можно быстрее передавать данные по сети.
Итого:
gRPC выбираем, когда нужна высокая скорость обмена данными между системами или сервисами.
#АрхитектураGA
Продолжение 👇👇👇
🔥21👍5❤4🥰2
🐙 Примеры и ссылки по gRPC 🐙
➕ Примеры использования
▫️Google Cloud
Google активно использует gRPC в своих облачных сервисах.
https://cloud.google.com/api-gateway/docs/grpc-overview
▫️Netflix
Netflix применяет gRPC для внутренней связи между микросервисами.
gRPC обеспечивает высокую производительность и надежность передачи данных между различными микросервисами, что важно для масштабируемых систем потокового видео.
https://www.cncf.io/blog/2021/08/04/grpc-in-action-example-using-java-microservices/
▫️Lyft (аналог Яндекс.Такси и Uber)
Использует gRPC для передачи данных о местоположении автомобилей в режиме реального времени.
Постоянное соединение gRPC позволяет непрерывно отправлять сообщения о местоположении автомобиля на мобильное приложение, что значительно улучшает пользовательский опыт и снижает задержки по сравнению с традиционным опросом сервера.
https://www.redhat.com/architect/grpc-use-cases
➕ Для каких видов архитектуры подходит
🙌 Идеален для микросервисной архитектуры, где требуется высокая скорость передачи данных между сервисами.
Можно использовать для мобильных приложений, но не рекомендуется для них из-за наличия этапа сериализации данных в процессе обмена.
➕ Влияние на выполнение НФТ
Высокая производительность (скорость обмена данными) за счет использования HTTP/2 и protobuf.
➕ Полезные ресурсы для изучения
1. Официальная документация gRPC
2. Подкаст GetAnalyst с Марией Кубениной по gRPC
3. Книга "gRPC: запуск и эксплуатация облачных приложений. Go и Java для Docker и Kubernetes", Индрасири Касун, Курупу Данеш:
Отличное руководство для разработчиков, но немного перебор для аналитиков. Полезно пролистать понятные страницы.
4. Примеры работы с gRPC API от Яндекс.Cloud тут 🙂
Вот так я применяю Пошаговый план: с чего начать изучение нового API? - идеальная инструкция для знакомства с разными API. С ним последовательно можно найти самую важную информацию.
#АрхитектураGA
➕ Примеры использования
▫️Google Cloud
Google активно использует gRPC в своих облачных сервисах.
https://cloud.google.com/api-gateway/docs/grpc-overview
▫️Netflix
Netflix применяет gRPC для внутренней связи между микросервисами.
gRPC обеспечивает высокую производительность и надежность передачи данных между различными микросервисами, что важно для масштабируемых систем потокового видео.
https://www.cncf.io/blog/2021/08/04/grpc-in-action-example-using-java-microservices/
▫️Lyft (аналог Яндекс.Такси и Uber)
Использует gRPC для передачи данных о местоположении автомобилей в режиме реального времени.
Постоянное соединение gRPC позволяет непрерывно отправлять сообщения о местоположении автомобиля на мобильное приложение, что значительно улучшает пользовательский опыт и снижает задержки по сравнению с традиционным опросом сервера.
https://www.redhat.com/architect/grpc-use-cases
➕ Для каких видов архитектуры подходит
🙌 Идеален для микросервисной архитектуры, где требуется высокая скорость передачи данных между сервисами.
Можно использовать для мобильных приложений, но не рекомендуется для них из-за наличия этапа сериализации данных в процессе обмена.
➕ Влияние на выполнение НФТ
Высокая производительность (скорость обмена данными) за счет использования HTTP/2 и protobuf.
➕ Полезные ресурсы для изучения
1. Официальная документация gRPC
2. Подкаст GetAnalyst с Марией Кубениной по gRPC
3. Книга "gRPC: запуск и эксплуатация облачных приложений. Go и Java для Docker и Kubernetes", Индрасири Касун, Курупу Данеш:
Отличное руководство для разработчиков, но немного перебор для аналитиков. Полезно пролистать понятные страницы.
4. Примеры работы с gRPC API от Яндекс.Cloud тут 🙂
Вот так я применяю Пошаговый план: с чего начать изучение нового API? - идеальная инструкция для знакомства с разными API. С ним последовательно можно найти самую важную информацию.
#АрхитектураGA
🔥12👍9
🛢 Оптимизация БД. Работа с индексами 🛢
Каждый месяц в GetAnalyst мы проводим практикумы, посвященные проектированию БД и SQL. В этом году я перешла на новый уровень, и предлагаю только самые продвинутые темы в онлайн формате.
Работа с индексами в БД - одна из них 💫
Приглашаю вас присоединиться!
🗓 3 ИЮНЯ, 19:00 Мск (пн)
🔗 Подробности и запись
План практики:
1. Нефункциональные требования к системе и их связь с БД.
2. Понятие индексов в БД и их назначение. Разбор примеров.
3. Практика: знакомство с БД проекта и определение таблиц с индексами.
4. Проблемы избыточной оптимизации БД.
5. Индексы в постановке задачи на разработку.
👨💻 Этот практикум идеально подходит для системных аналитиков, стремящихся углубить свои знания и навыки в области проектирования баз данных и оптимизации систем.
Присоединяйтесь к нам в следующий понедельник и получайте новый опыт 🙌
Каждый месяц в GetAnalyst мы проводим практикумы, посвященные проектированию БД и SQL. В этом году я перешла на новый уровень, и предлагаю только самые продвинутые темы в онлайн формате.
Работа с индексами в БД - одна из них 💫
Приглашаю вас присоединиться!
🗓 3 ИЮНЯ, 19:00 Мск (пн)
🔗 Подробности и запись
План практики:
1. Нефункциональные требования к системе и их связь с БД.
2. Понятие индексов в БД и их назначение. Разбор примеров.
3. Практика: знакомство с БД проекта и определение таблиц с индексами.
4. Проблемы избыточной оптимизации БД.
5. Индексы в постановке задачи на разработку.
👨💻 Этот практикум идеально подходит для системных аналитиков, стремящихся углубить свои знания и навыки в области проектирования баз данных и оптимизации систем.
Присоединяйтесь к нам в следующий понедельник и получайте новый опыт 🙌
👍17❤6🔥3👎1
🤝 Договориться можно обо всём 🤝
Мы постоянно сталкиваемся с переговорами. Предлагаем и защищаем свои решения в работе почти ежедневно.
А когда есть карьерные цели, то при обсуждении вопросов ЗП пытаемся угадать с какой стороны подойти к вопросу, чтобы аккуратно и т.д.
Договориться можно обо всём - это не красиво придуманное название поста, а название важной для меня книги Гевина Кеннеди. Она изменила мой взгляд на взаимоотношения с людьми. Как в рабочем плане, так и в личном.
Когда я только начала читать эту книгу, то поняла, что не умею договариваться. Всегда соглашалась на меньшее, и боялась просить больше. Сейчас ситуация поменялась.
Я бы хотела найти эту книгу как можно раньше в своей жизни. Поэтому делюсь ей с вами сегодня.
Важные уроки:
📗 1. Переговоры – это не только умение убеждать, но и искусство слушать и понимать другую сторону.
📗 2. Не стесняться высказывать свои мысли и защищать свои предложения. Зачастую, именно благодаря уверенности в себе и умению правильно преподнести аргументы, можно добиться успеха в любых переговорах.
Не бойтесь отстаивать свою точку зрения и быть настойчивыми – это поможет вам не только в профессиональной деятельности, но и в личной жизни.
О чем договорились, то и получаем 🙌
Мы постоянно сталкиваемся с переговорами. Предлагаем и защищаем свои решения в работе почти ежедневно.
А когда есть карьерные цели, то при обсуждении вопросов ЗП пытаемся угадать с какой стороны подойти к вопросу, чтобы аккуратно и т.д.
Договориться можно обо всём - это не красиво придуманное название поста, а название важной для меня книги Гевина Кеннеди. Она изменила мой взгляд на взаимоотношения с людьми. Как в рабочем плане, так и в личном.
Когда я только начала читать эту книгу, то поняла, что не умею договариваться. Всегда соглашалась на меньшее, и боялась просить больше. Сейчас ситуация поменялась.
Я бы хотела найти эту книгу как можно раньше в своей жизни. Поэтому делюсь ей с вами сегодня.
Важные уроки:
📗 1. Переговоры – это не только умение убеждать, но и искусство слушать и понимать другую сторону.
📗 2. Не стесняться высказывать свои мысли и защищать свои предложения. Зачастую, именно благодаря уверенности в себе и умению правильно преподнести аргументы, можно добиться успеха в любых переговорах.
Не бойтесь отстаивать свою точку зрения и быть настойчивыми – это поможет вам не только в профессиональной деятельности, но и в личной жизни.
О чем договорились, то и получаем 🙌
❤33👍10
GetAnalyst - Интеграция систем.pdf
7.5 MB
💻 Интеграция — что это? 💻
Ситуация: вам нужно купить билет на самолёт. И вместо того, чтобы гулять по сайтам авиакомпаний в поисках нужной цены, вы заходите в одно приложение и просто вбиваете пункты А-В и желаемые даты. Это приложение называется Агрегатор билетов.
Агрегатор выдаёт все возможные варианты, вы выбираете приемлемую цену и совершаете заказ. Согласитесь, это очень удобно!
Аналогично работают приложения Госуслуги, банки, сервисы по доставке еды и многие другие. Все возможности через единое окно!
Но, чтобы всё заработало, необходимо поддержать обмен данными между всеми используемыми системами. Здесь и становится нужна интеграция.
Как итог, пользователю не приходится обращаться к множеству ресурсов - всё в одном месте ✅
Еще немного теории, пример и ссылку на большую подборку видео, разборов проектов и статей по интеграциям от GetAnalyst оставила на последней странице мини-гайда, прикрепленного к посту 😉
Ситуация: вам нужно купить билет на самолёт. И вместо того, чтобы гулять по сайтам авиакомпаний в поисках нужной цены, вы заходите в одно приложение и просто вбиваете пункты А-В и желаемые даты. Это приложение называется Агрегатор билетов.
Агрегатор выдаёт все возможные варианты, вы выбираете приемлемую цену и совершаете заказ. Согласитесь, это очень удобно!
Аналогично работают приложения Госуслуги, банки, сервисы по доставке еды и многие другие. Все возможности через единое окно!
Но, чтобы всё заработало, необходимо поддержать обмен данными между всеми используемыми системами. Здесь и становится нужна интеграция.
Интеграция — это единый процесс, объединяющий технологии и системы в единую последовательную цепочку.
Интеграции преобразуют форматы данных между системами в единую структуру.
Как итог, пользователю не приходится обращаться к множеству ресурсов - всё в одном месте ✅
Еще немного теории, пример и ссылку на большую подборку видео, разборов проектов и статей по интеграциям от GetAnalyst оставила на последней странице мини-гайда, прикрепленного к посту 😉
❤17🔥9👍4
🏦 Новый проект: приложение для банковских переводов 🏧
В этом месяце мы будем работать над новым интеграционным проектом для мобильного приложения банка #GABank.
Чтобы сделать банковский перевод между счетами юридических лиц (далее - юрлиц) для оплаты товаров или услуг, пользователям приходится вводить вручную множество реквизитов. Это утомительный процесс, так как нужно заполнить такие данные, как ИНН, КПП, БИК банка, корреспондентский счет (КС), расчетный счет (РС), наименование банка и получателя, и другие.
Ввод каждого из этих реквизитов вручную занимает время и может приводить к ошибкам 😞
Наша задача - упростить процесс перевода денег между счетами в приложении #GABank, чтобы можно было делать это не заполняя все реквизиты вручную.
Основные возможности, которые хотим внедрить:
✨ Автозаполнение реквизитов
Приложение должно автоматически подтягивать нужную информацию с помощью интеграции с сервисом DaData по HTTP API (аналог REST API). Вводим ИНН юрлица, а все остальные поля заполнятся сами! 🧙♂️
✨ Сохранение истории
Все введенные реквизиты будут сохраняться в истории, так что в следующий раз можно будет повторить перевод в два клика 🕶️
✨ Обновление данных
Если нужной компании нет в базе DaData, не беда! Мы будем сохранять ее данные в нашей внутренней базе, чтобы помочь другим пользователям в будущем 📚
Наши задачи как аналитиков на проекте:
1. Сформулируем функциональные требования к интеграции.
2. Сделаем модель БД, которая обеспечит хранение всех необходимых данных.
3. Опишем архитектуру решения.
4. Исследуем API-документацию внешней системы DaData.
5. Протестируем API в Postman.
6. Сформулируем интеграционный Use Case.
7. Сделаем маппинг данных между системами.
Стартуем проект на июнь? 😉🔥
#ИнтеграцииGA
В этом месяце мы будем работать над новым интеграционным проектом для мобильного приложения банка #GABank.
Чтобы сделать банковский перевод между счетами юридических лиц (далее - юрлиц) для оплаты товаров или услуг, пользователям приходится вводить вручную множество реквизитов. Это утомительный процесс, так как нужно заполнить такие данные, как ИНН, КПП, БИК банка, корреспондентский счет (КС), расчетный счет (РС), наименование банка и получателя, и другие.
Ввод каждого из этих реквизитов вручную занимает время и может приводить к ошибкам 😞
Наша задача - упростить процесс перевода денег между счетами в приложении #GABank, чтобы можно было делать это не заполняя все реквизиты вручную.
Основные возможности, которые хотим внедрить:
✨ Автозаполнение реквизитов
Приложение должно автоматически подтягивать нужную информацию с помощью интеграции с сервисом DaData по HTTP API (аналог REST API). Вводим ИНН юрлица, а все остальные поля заполнятся сами! 🧙♂️
✨ Сохранение истории
Все введенные реквизиты будут сохраняться в истории, так что в следующий раз можно будет повторить перевод в два клика 🕶️
✨ Обновление данных
Если нужной компании нет в базе DaData, не беда! Мы будем сохранять ее данные в нашей внутренней базе, чтобы помочь другим пользователям в будущем 📚
Наши задачи как аналитиков на проекте:
1. Сформулируем функциональные требования к интеграции.
2. Сделаем модель БД, которая обеспечит хранение всех необходимых данных.
3. Опишем архитектуру решения.
4. Исследуем API-документацию внешней системы DaData.
5. Протестируем API в Postman.
6. Сформулируем интеграционный Use Case.
7. Сделаем маппинг данных между системами.
Стартуем проект на июнь? 😉🔥
#ИнтеграцииGA
🔥102⚡8💯7👍6❤5
🚀 Спасибо за то, что вы достигаете цели 🚀
В конце мая и в начале июня у нас одновременно завершилось два проекта по обучениям - Архитектура и Интеграции. Я просматриваю всю обратную связь, постоянно вижу от вас теплые и добрые слова и понимаю. что моя миссия реализуется.
Вы внедряете получаемые знания в свои проекты в процессе обучения, меняете проекты и получаете лучшие предложения, меняете профессию и приходите в системный анализ с GetAnalyst. Всё получается! 💜
Собрала несколько последних сообщений, которые получила только за последние пару недель.
Евгения
Владимир
Zalina D
Дарина А
Настя
Благодаря вашим словам поддержки я продолжаю развивать сообщество, создавать всё больше новых материалов для системных аналитиков, развиваться и делиться опытом с вами.
Ставим карьерные цели и идем к ним вместе. Я и команда GetAnalyst здесь, чтобы поддержать вас на пути к ним 🚀
В конце мая и в начале июня у нас одновременно завершилось два проекта по обучениям - Архитектура и Интеграции. Я просматриваю всю обратную связь, постоянно вижу от вас теплые и добрые слова и понимаю. что моя миссия реализуется.
Растить специалистов, которые будут создавать качественные и надёжные IT-продукты для бизнеса
Вы внедряете получаемые знания в свои проекты в процессе обучения, меняете проекты и получаете лучшие предложения, меняете профессию и приходите в системный анализ с GetAnalyst. Всё получается! 💜
Собрала несколько последних сообщений, которые получила только за последние пару недель.
Евгения
Кто провел пресейл, нарисовав заказчику С4 и расписав, как мы классно все интегрируем и настроим SSO с помощью Keycloack, и ваще, и довел дело до договора, тот я. Прям с колес, даже домашки по занятости так и не сделав. Большое человеческое спасибо
Владимир
Огромная благодарность за проделанную работу всем лекторам! 🥸 Ваш богатый опыт очень полезен, методика изложения материала доступна и удобна! 🔥
Zalina D
Спасибо большое за курс. Всё было очень полезно и познавательно ❤️❤️❤️
Дарина А
Большое спасибо за курс, было очень много полезной информации, видно Ваш богатый опыт! У Вас отличная команда! 👍🏼
Настя
спасибо тебе большое за ту миссию, что ты делаешь. А делаешь ты из сложного простое, и все меньше становится страшно ❤️
Благодаря вашим словам поддержки я продолжаю развивать сообщество, создавать всё больше новых материалов для системных аналитиков, развиваться и делиться опытом с вами.
Ставим карьерные цели и идем к ним вместе. Я и команда GetAnalyst здесь, чтобы поддержать вас на пути к ним 🚀
❤🔥15👍7❤2🤩2
🧩 Как интеграцию видит обычный пользователь? 🧩
Смотреть на приложения с точки зрения системного аналитика или разработчика всегда интересно. Поэтому сегодня я начну погружать вас в технические детали того, что может быть “под капотом” простой экранной формы с кучей полей ввода.
Пользователь банковского приложения #GABank для юрлиц выбирает функцию “Сделать перевод по реквизитам”, нажав на кнопку в одном из основных экранов. Отрисовывается новый экран - вы видите поля для ввода реквизитов. Пока никакого волшебства в виде запросов к серверу для загрузки данных нет.
Поля ввода для осуществления перевода:
+ ИНН получателя,
✅ КПП получателя,
✅ полное наименование получателя,
☑️ БИК банка,
✅ название банка,
✅ к/с банка (номер корреспондентского счета банка),
☑️ р/с (номер расчетного счета получателя),
+ сумма,
+ назначение платежа,
+ НДС.
Сейчас все заполняется вручную.
Но часть реквизитов может заполняться автоматически:
✅ - на основании данных DaData,
☑️ - из данных банка.
КАКОЙ СЦЕНАРИЙ ОЖИДАЕМ ПОЛУЧИТЬ:
1. Пользователь начинает вводить ИНН получателя.
После ввода 5 символов начинаем предлагать варианты выбора организации из списка.
🧩Варианты к выбору из списка получаем благодаря интеграции с DaData, параметры загружаются из неё.
Если пользователь выбрал организацию из списка или она найдена по ИНН, то автоматически заполнять все поля до БИК.
2. Пользователь начинает вводить БИК банка.
После ввода 4 символов начинать предлагать варианты банков для выбора.
🧩Интеграция с DaData.
Если удалось найти банк по БИК, то заполнять все поля. Р/с также будет заполнен автоматически, если данные о для этого юрица сохранены в БД банка.
3. Пользователь вводит оставшиеся параметры и делает перевод.
4. После успешного перевода, если р/с не был ранее сохранен, то сохраняем его в БД банка.
Итого:
+ Пользователь вводит только 5/10 полей.
+ Часть из них только наполовину.
Так начинается работа с интеграциеями. Понимание пользовательского сценария и бизнес-цели того, что мы делаем, важны.
#ИнтеграцииGA
Смотреть на приложения с точки зрения системного аналитика или разработчика всегда интересно. Поэтому сегодня я начну погружать вас в технические детали того, что может быть “под капотом” простой экранной формы с кучей полей ввода.
Пользователь банковского приложения #GABank для юрлиц выбирает функцию “Сделать перевод по реквизитам”, нажав на кнопку в одном из основных экранов. Отрисовывается новый экран - вы видите поля для ввода реквизитов. Пока никакого волшебства в виде запросов к серверу для загрузки данных нет.
Поля ввода для осуществления перевода:
+ ИНН получателя,
✅ КПП получателя,
✅ полное наименование получателя,
☑️ БИК банка,
✅ название банка,
✅ к/с банка (номер корреспондентского счета банка),
☑️ р/с (номер расчетного счета получателя),
+ сумма,
+ назначение платежа,
+ НДС.
Сейчас все заполняется вручную.
Но часть реквизитов может заполняться автоматически:
✅ - на основании данных DaData,
☑️ - из данных банка.
КАКОЙ СЦЕНАРИЙ ОЖИДАЕМ ПОЛУЧИТЬ:
1. Пользователь начинает вводить ИНН получателя.
После ввода 5 символов начинаем предлагать варианты выбора организации из списка.
🧩Варианты к выбору из списка получаем благодаря интеграции с DaData, параметры загружаются из неё.
Если пользователь выбрал организацию из списка или она найдена по ИНН, то автоматически заполнять все поля до БИК.
2. Пользователь начинает вводить БИК банка.
После ввода 4 символов начинать предлагать варианты банков для выбора.
🧩Интеграция с DaData.
Если удалось найти банк по БИК, то заполнять все поля. Р/с также будет заполнен автоматически, если данные о для этого юрица сохранены в БД банка.
3. Пользователь вводит оставшиеся параметры и делает перевод.
4. После успешного перевода, если р/с не был ранее сохранен, то сохраняем его в БД банка.
Итого:
+ Пользователь вводит только 5/10 полей.
+ Часть из них только наполовину.
Так начинается работа с интеграциеями. Понимание пользовательского сценария и бизнес-цели того, что мы делаем, важны.
#ИнтеграцииGA
👏18👍10🔥9❤4
GetAnalyst_Интеграции_ЧЕК_ЛИСТ_ФУНКЦИОНАЛЬНЫХ_ТРЕБОВАНИЙ.pdf
1.8 MB
✅ Функциональные требования к Интеграции: чек-лист ✅
Когда мы разрабатываем требования (ФТ) к интеграции систем, то на поверхности видны далеко не все требования, которые нужно описать для бизнес-заказчиков и разработчиков, чтобы все стороны ясно понимали объем работ.
Поэтому предлагаю вам познакомиться с универсальным чек-листом, который поможет написать полный список требований для новой интеграции в системе.
Чек-лист функциональных требований:
1. Конфигурационные параметры
2. Авторизация
3. Ре-авторизация
4. Хранение данных в БД - изменение модели
5. Интеграционные API методы (ключевые функции)
6. Логирование, метрики и алерты
Прочитать подробнее про каждый вид требования и изучить примеры можно в гайде для системных аналитиков.
Пользуйтесь и сохраняйте на будущее 💾❤️
#ИнтеграцииGA
Когда мы разрабатываем требования (ФТ) к интеграции систем, то на поверхности видны далеко не все требования, которые нужно описать для бизнес-заказчиков и разработчиков, чтобы все стороны ясно понимали объем работ.
Поэтому предлагаю вам познакомиться с универсальным чек-листом, который поможет написать полный список требований для новой интеграции в системе.
Чек-лист функциональных требований:
1. Конфигурационные параметры
2. Авторизация
3. Ре-авторизация
4. Хранение данных в БД - изменение модели
5. Интеграционные API методы (ключевые функции)
6. Логирование, метрики и алерты
Прочитать подробнее про каждый вид требования и изучить примеры можно в гайде для системных аналитиков.
Пользуйтесь и сохраняйте на будущее 💾❤️
#ИнтеграцииGA
❤🔥34👍18🔥4🤔1
👩💻 Пример ФТ к Интеграции с DaData для приложения #GABank 👩💻
С учетом пользовательского сценария для автозаполнения реквизитов на перевод средств в банке и чек-листа функциональных требований, опубликованного в предыдущем посте, у меня получился следующий список функциональных требований к разработке:
1-И. Обеспечить хранение конфигурационных параметров для интеграции с DaData: авторизационные параметры, URL-ы тестовой и боевой площадки, лимит на количество запросов.
2-И. Реализовать общий механизм авторизации банковской системы с внешней системой DaData.
3. Обеспечить хранение данных о расчетных счетах (р/c) юрлиц в различных банках.
4-И. Реализовать возможность поиска организации по ИНН с использованием интеграции с внешней системой DaData. Поиск организации должен осуществляться при вводе 5 или более символов.
НФТ: Запросы на поиск в систему DaData должны отправляться не чаще 1 раза в 2 сек.
5-И. Реализовать возможность поиска банка по БИК с использованием интеграции с внешней системой DaData. Поиск банка должен осуществляться при вводе 4 или более символов.
НФТ: как в п.4.
6-И. Вести учет количества запросов в сутки к внешней системе DaData, визуализировать на графике Grafana и информировать ответственных бизнес-сотрудников, если значения в сутки составляет более 85% от предоставленного лимита по оплаченному тарифу (ссылка на требования к оплате при использовании сервиса DaData, но нам для аналитики хватит и бесплатной версии).
И - связано с интеграцией
НФТ - нефункциональное требование
P.S.Я рада комментариям про альтернативные сценарии и обработку ошибок в интеграциях!)) Это тоже обсудим в рамках проекта, но на уровне ФТ считаю, что это будет обязательно заложено в логику работы.
Есть ли еще ФТ, которые хочется включить? Если все учли, то ставим 👍под постом и двигаемся далее.
#ИнтеграцииGA
С учетом пользовательского сценария для автозаполнения реквизитов на перевод средств в банке и чек-листа функциональных требований, опубликованного в предыдущем посте, у меня получился следующий список функциональных требований к разработке:
1-И. Обеспечить хранение конфигурационных параметров для интеграции с DaData: авторизационные параметры, URL-ы тестовой и боевой площадки, лимит на количество запросов.
2-И. Реализовать общий механизм авторизации банковской системы с внешней системой DaData.
3. Обеспечить хранение данных о расчетных счетах (р/c) юрлиц в различных банках.
4-И. Реализовать возможность поиска организации по ИНН с использованием интеграции с внешней системой DaData. Поиск организации должен осуществляться при вводе 5 или более символов.
НФТ: Запросы на поиск в систему DaData должны отправляться не чаще 1 раза в 2 сек.
5-И. Реализовать возможность поиска банка по БИК с использованием интеграции с внешней системой DaData. Поиск банка должен осуществляться при вводе 4 или более символов.
НФТ: как в п.4.
6-И. Вести учет количества запросов в сутки к внешней системе DaData, визуализировать на графике Grafana и информировать ответственных бизнес-сотрудников, если значения в сутки составляет более 85% от предоставленного лимита по оплаченному тарифу (ссылка на требования к оплате при использовании сервиса DaData, но нам для аналитики хватит и бесплатной версии).
И - связано с интеграцией
НФТ - нефункциональное требование
P.S.
Есть ли еще ФТ, которые хочется включить? Если все учли, то ставим 👍под постом и двигаемся далее.
#ИнтеграцииGA
👍16❤🔥2❤1
Подводя итоги половины 2024, поняла, что этот год перенасыщен событиями 🙌
Работа порой чуть ли не 24/7. Иногда кажется, что я ничего не успеваю. Но если взглянуть на количество галочек в ежедневнике за каждый день, то обычный человек может испугаться. А я думаю как вместить ещё.
Бывает тяжело, но у меня есть ежедневные ритуалы (спорт, завтраки, медитации, прогулки), которые помогают оставаться в форме и подзаряжаться ежедневно. И конечно я радуюсь и наполняюсь энергией, когда вижу результаты и обратную связь от людей, для которых работаю я и мои команды.
На прошлой неделе я смогла устроить небольшой отпуск, и теперь мне кажется, что на этой неделе я должна свернуть горы 🏔🌇
Она только начинается, а я уже в предвкушении, поскольку впереди:
☑️ Прилететь в Нью-Йорк и успеть хоть немного погулять по нему.
☑️ Бизнес-встречи.
☑️ Конференция по использованию ИИ в разработке (ИИ - Искусственный Интеллект).
☑️ Первая онлайн-встреча по проекту Архитектуры с новым потоком.
☑️ Стандартный объем задач по ведению проектов и работе с программами GetAnalyst.
Каждую неделю думаю, что сложная и насыщенная событиями неделя закончилась и дальше легче. А нет, вот и новая прилетела! Расписание загружено на 200%. Придётся успевать всё, что возможно, и что невозможно))
“Зона комфорта” не для меня, хочется постоянно чувствовать рост и проходить через челленджи. И 2024 даёт их сполна и помогает двигаться к поставленным целям!
А как у вас с рабочими моментами в этом году по ощущениям? Высокая загрузка? Есть челленджи, через которые сейчас проходите?
Делитесь с нами в комментариях и как справляетесь морально, когда тяжело 🙂
Работа порой чуть ли не 24/7. Иногда кажется, что я ничего не успеваю. Но если взглянуть на количество галочек в ежедневнике за каждый день, то обычный человек может испугаться. А я думаю как вместить ещё.
Бывает тяжело, но у меня есть ежедневные ритуалы (спорт, завтраки, медитации, прогулки), которые помогают оставаться в форме и подзаряжаться ежедневно. И конечно я радуюсь и наполняюсь энергией, когда вижу результаты и обратную связь от людей, для которых работаю я и мои команды.
На прошлой неделе я смогла устроить небольшой отпуск, и теперь мне кажется, что на этой неделе я должна свернуть горы 🏔🌇
Она только начинается, а я уже в предвкушении, поскольку впереди:
☑️ Прилететь в Нью-Йорк и успеть хоть немного погулять по нему.
☑️ Бизнес-встречи.
☑️ Конференция по использованию ИИ в разработке (ИИ - Искусственный Интеллект).
☑️ Первая онлайн-встреча по проекту Архитектуры с новым потоком.
☑️ Стандартный объем задач по ведению проектов и работе с программами GetAnalyst.
Каждую неделю думаю, что сложная и насыщенная событиями неделя закончилась и дальше легче. А нет, вот и новая прилетела! Расписание загружено на 200%. Придётся успевать всё, что возможно, и что невозможно))
“Зона комфорта” не для меня, хочется постоянно чувствовать рост и проходить через челленджи. И 2024 даёт их сполна и помогает двигаться к поставленным целям!
А как у вас с рабочими моментами в этом году по ощущениям? Высокая загрузка? Есть челленджи, через которые сейчас проходите?
Делитесь с нами в комментариях и как справляетесь морально, когда тяжело 🙂
🔥13❤8👍8❤🔥1🤯1
📁 БД системы и ее значение в задачах на Интеграции 📁
Один из ключевых этапов работы системного аналитика при постановке задач на интеграции - маппинг (сопоставление) данных между различными системами.
В описание маппинга включают данные:
- API внешней системы.
- API системы, в которой делают интеграцию.
- БД системы, в которой делают интеграцию.
- UI системы, в которой делают интеграцию, при постановке задач на пользовательские приложения с экранами (фронтенд).
Понимание структуры базы данных (БД) проекта является важным аспектом. Это необходимо для корректного маппинга данных, особенно в случаях, когда в результате работы интеграционного сценария нужно что-либо сохранить в БД или сопоставить с данными, хранимыми в системе.
Поэтому, прежде чем мы перейдём к следующему этапу работы с задачей по автозаполнению данных о юрлицах и их счетах в #GABank, я хочу познакомить вас с необходимой нам частью структуры БД проекта, которую мы будем использовать для маппинга данных в постановках задач.
👇
Эта таблица хранит информацию о компаниях (юридических лицах), которые являются участниками банковских операций.
Если компания открывает счет в GABank, то данные о ней создаются в системе. Если нет, то компания может быть добавлена в список как внешняя при создании перевода в неё.
+ id: Уникальный идентификатор компании (первичный ключ).
+ inn: ИНН компании.
+ kpp: КПП компании. Может быть сохранен на основании интеграции с DaData, при получении информации о компании по ИНН.
+ name: Краткое название компании. Может быть сохранено из DaData.
+ full_name: Полное название компании. Может быть сохранено из DaData.
#ИнтеграцииGA
Продолжение 👇
Один из ключевых этапов работы системного аналитика при постановке задач на интеграции - маппинг (сопоставление) данных между различными системами.
В описание маппинга включают данные:
- API внешней системы.
- API системы, в которой делают интеграцию.
- БД системы, в которой делают интеграцию.
- UI системы, в которой делают интеграцию, при постановке задач на пользовательские приложения с экранами (фронтенд).
Понимание структуры базы данных (БД) проекта является важным аспектом. Это необходимо для корректного маппинга данных, особенно в случаях, когда в результате работы интеграционного сценария нужно что-либо сохранить в БД или сопоставить с данными, хранимыми в системе.
Поэтому, прежде чем мы перейдём к следующему этапу работы с задачей по автозаполнению данных о юрлицах и их счетах в #GABank, я хочу познакомить вас с необходимой нам частью структуры БД проекта, которую мы будем использовать для маппинга данных в постановках задач.
👇
Таблица company
Эта таблица хранит информацию о компаниях (юридических лицах), которые являются участниками банковских операций.
Если компания открывает счет в GABank, то данные о ней создаются в системе. Если нет, то компания может быть добавлена в список как внешняя при создании перевода в неё.
+ id: Уникальный идентификатор компании (первичный ключ).
+ inn: ИНН компании.
+ kpp: КПП компании. Может быть сохранен на основании интеграции с DaData, при получении информации о компании по ИНН.
+ name: Краткое название компании. Может быть сохранено из DaData.
+ full_name: Полное название компании. Может быть сохранено из DaData.
#ИнтеграцииGA
Продолжение 👇
❤16👍9🔥3
📁 БД системы и ее значение в задачах на Интеграции 📁
Эта таблица устанавливает связи между компаниями, показывая, какие компании связаны друг с другом через переводы.
+ company_id: Идентификатор компании, которая имеет счет в GABank, и может делать переводы в другие компании, в том числе на их счета в других банках или на свой счет в другом банке (внешний ключ).
+ related_company_id: Идентификатор связанной компании (внешний ключ).
+ created_by_transfer_id: Идентификатор перевода, через который впервые установлена связь (внешний ключ).
is_visible: Поле, указывающее, видна ли связь пользователям - показывается ли сразу эта запись при переводе в списке подсказок..
Эта таблица хранит информацию о банках, через которые компании осуществляют переводы.
+ id: Уникальный идентификатор банка (первичный ключ).
+ name: Название банка. Может быть сохранено из DaData.
+ bik: БИК банка.
+ correspondent_number: Корреспондентский счет банка. Может быть сохранено из DaData.
created_at: Дата создания записи.
Эта таблица хранит информацию о счетах компаний внутри GABank.
+ id: Уникальный идентификатор счета (первичный ключ).
+ bank_id: Идентификатор банка, в котором счет (внешний ключ).
+ company_id: Идентификатор компании, которой принадлежит счет (внешний ключ).
+ number: Номер расчетного счета.
+ created_at: Дата создания счета.
Эта таблица хранит информацию о банковских счетах компаний в других банках.
+ id: Уникальный идентификатор внешнего счета (первичный ключ).
+ bank_id: Идентификатор банка (внешний ключ).
+ company_id: Идентификатор компании (внешний ключ).
+ number: Номер счета.
+ created_at: Дата создания записи.
Эта таблица хранит информацию о банковских переводах.
+ id: Уникальный идентификатор перевода (первичный ключ).
+ recipient_account_id: Идентификатор счета получателя (внешний ключ).
+ is_external: Флаг, указывающий, является ли перевод внешним, т.е. данные о счете будут в таблице external_account.
+ sender_account_id: Идентификатор счета отправителя (внешний ключ).
+ amount: Сумма перевода.
+ currency: Валюта перевода.
+ vat: НДС.
+ notes: Примечания к переводу.
+ status: Статус перевода.
+ created_at: Дата создания.
+ transferred_at: Дата осуществления перевода.
Эта структура БД обеспечивает хранение всех необходимых данных для выполнения и отслеживания банковских переводов между юридическими лицами в приложении #GABank.
Также она позволяет сохранять данные о компаниях, в которые уже были переводы ранее, чтобы уменьшить количество запросов во внешнюю систему DaData и оптимизироваь взаимодействие с ней. Это полезно в случаях, когда DaData недоступна, и в случаях, когда нам надо соблюдать лимиты связанные с платностью сервиса DaData.
#ИнтеграцииGA
Таблица related_companies
Эта таблица устанавливает связи между компаниями, показывая, какие компании связаны друг с другом через переводы.
+ company_id: Идентификатор компании, которая имеет счет в GABank, и может делать переводы в другие компании, в том числе на их счета в других банках или на свой счет в другом банке (внешний ключ).
+ related_company_id: Идентификатор связанной компании (внешний ключ).
+ created_by_transfer_id: Идентификатор перевода, через который впервые установлена связь (внешний ключ).
is_visible: Поле, указывающее, видна ли связь пользователям - показывается ли сразу эта запись при переводе в списке подсказок..
Таблица bank
Эта таблица хранит информацию о банках, через которые компании осуществляют переводы.
+ id: Уникальный идентификатор банка (первичный ключ).
+ name: Название банка. Может быть сохранено из DaData.
+ bik: БИК банка.
+ correspondent_number: Корреспондентский счет банка. Может быть сохранено из DaData.
created_at: Дата создания записи.
Таблица account
Эта таблица хранит информацию о счетах компаний внутри GABank.
+ id: Уникальный идентификатор счета (первичный ключ).
+ bank_id: Идентификатор банка, в котором счет (внешний ключ).
+ company_id: Идентификатор компании, которой принадлежит счет (внешний ключ).
+ number: Номер расчетного счета.
+ created_at: Дата создания счета.
Таблица external_account
Эта таблица хранит информацию о банковских счетах компаний в других банках.
+ id: Уникальный идентификатор внешнего счета (первичный ключ).
+ bank_id: Идентификатор банка (внешний ключ).
+ company_id: Идентификатор компании (внешний ключ).
+ number: Номер счета.
+ created_at: Дата создания записи.
Таблица transfer
Эта таблица хранит информацию о банковских переводах.
+ id: Уникальный идентификатор перевода (первичный ключ).
+ recipient_account_id: Идентификатор счета получателя (внешний ключ).
+ is_external: Флаг, указывающий, является ли перевод внешним, т.е. данные о счете будут в таблице external_account.
+ sender_account_id: Идентификатор счета отправителя (внешний ключ).
+ amount: Сумма перевода.
+ currency: Валюта перевода.
+ vat: НДС.
+ notes: Примечания к переводу.
+ status: Статус перевода.
+ created_at: Дата создания.
+ transferred_at: Дата осуществления перевода.
Эта структура БД обеспечивает хранение всех необходимых данных для выполнения и отслеживания банковских переводов между юридическими лицами в приложении #GABank.
Также она позволяет сохранять данные о компаниях, в которые уже были переводы ранее, чтобы уменьшить количество запросов во внешнюю систему DaData и оптимизироваь взаимодействие с ней. Это полезно в случаях, когда DaData недоступна, и в случаях, когда нам надо соблюдать лимиты связанные с платностью сервиса DaData.
#ИнтеграцииGA
🔥15👍7❤3
🔥 Проектирование БД для проекта с нуля - 2 важных видео🔥
Коллеги, выше показала небольшую модель БД, но не для всех может быть понятно как она получилась для приложения GABank.
Если у вас нет опыта проектирования БД с нуля, нужно структурировать знания по построению ER-диаграмм или необходимо прокачать знания по БД, то настоятельно рекомендую посмотреть эти видео:
1. Проектирование БД: концептуальный уровень
2. Проектирование БД: логический уровень + ChatGPT
В них на примере проекта в деталях рассказываю как проектировать БД с нуля. ❗️Всего два урока, после которых фундаментальные знания будут разложены по полочкам.
А если вам хочется глубже погружаться в работу с БД и SQL, то всегда можно подключиться на дополнительные практикумы.
Не откладывайте и обязательно смотрите эти два видео!)) Они очень помогут улучшить ваши знания и дадут опыт работы с БД! 🙌
Коллеги, выше показала небольшую модель БД, но не для всех может быть понятно как она получилась для приложения GABank.
Если у вас нет опыта проектирования БД с нуля, нужно структурировать знания по построению ER-диаграмм или необходимо прокачать знания по БД, то настоятельно рекомендую посмотреть эти видео:
1. Проектирование БД: концептуальный уровень
2. Проектирование БД: логический уровень + ChatGPT
В них на примере проекта в деталях рассказываю как проектировать БД с нуля. ❗️Всего два урока, после которых фундаментальные знания будут разложены по полочкам.
А если вам хочется глубже погружаться в работу с БД и SQL, то всегда можно подключиться на дополнительные практикумы.
Не откладывайте и обязательно смотрите эти два видео!)) Они очень помогут улучшить ваши знания и дадут опыт работы с БД! 🙌
❤24🔥4🥰3👍1🤣1