День 2250. #SystemDesign101
Начинаю серию постов про System Design. Это будут небольшие шпаргалки, описывающие ту или иную технологию. Надеюсь, вам понравится.
1. Виды коммуникаций API
Архитектурные стили определяют, как различные компоненты системы взаимодействуют друг с другом. В результате они обеспечивают эффективность, надёжность и простоту интеграции с другими системами, предоставляя стандартный подход к проектированию и созданию API. Вот наиболее часто используемые стили:
SOAP
- Зрелый, всеобъемлющий, на основе XML;
- Лучше всего подходит для корпоративных приложений.
RESTful
- Популярный, простые в реализации методы HTTP;
- Идеально подходит для веб-сервисов.
GraphQL
- Язык запросов, запрашивает только нужные данные;
- Снижает сетевые издержки, ускоряет ответы.
gRPC
- Современный, высокопроизводительный;
- Подходит для архитектур микросервисов.
WebSocket
- Двунаправленные, постоянные соединения в реальном времени;
- Идеально подходит для обмена данными с малой задержкой.
Webhook
- Управляемый событиями, использует обратные вызовы HTTP, асинхронный;
- Уведомляет системы о событиях.
Источник: https://github.com/ByteByteGoHq/system-design-101
Начинаю серию постов про System Design. Это будут небольшие шпаргалки, описывающие ту или иную технологию. Надеюсь, вам понравится.
1. Виды коммуникаций API
Архитектурные стили определяют, как различные компоненты системы взаимодействуют друг с другом. В результате они обеспечивают эффективность, надёжность и простоту интеграции с другими системами, предоставляя стандартный подход к проектированию и созданию API. Вот наиболее часто используемые стили:
SOAP
- Зрелый, всеобъемлющий, на основе XML;
- Лучше всего подходит для корпоративных приложений.
RESTful
- Популярный, простые в реализации методы HTTP;
- Идеально подходит для веб-сервисов.
GraphQL
- Язык запросов, запрашивает только нужные данные;
- Снижает сетевые издержки, ускоряет ответы.
gRPC
- Современный, высокопроизводительный;
- Подходит для архитектур микросервисов.
WebSocket
- Двунаправленные, постоянные соединения в реальном времени;
- Идеально подходит для обмена данными с малой задержкой.
Webhook
- Управляемый событиями, использует обратные вызовы HTTP, асинхронный;
- Уведомляет системы о событиях.
Источник: https://github.com/ByteByteGoHq/system-design-101
👍30👎1
День 2254. #SystemDesign101
REST API или GraphQL
REST
➕ Использует стандартные методы HTTP, такие как GET, POST, PUT, DELETE для операций CRUD.
➕ Хорошо работает, когда вам нужны простые, единообразные интерфейсы между отдельными сервисами/приложениями.
➕ Стратегии кэширования просты в реализации.
➖ Может потребоваться несколько циклов для сбора связанных данных из отдельных конечных точек.
GraphQL
➕ Предоставляет клиентам единую конечную точку для запроса именно тех данных, которые им нужны.
➕ Клиенты указывают требуемые поля во вложенных запросах, и сервер возвращает данные, содержащие только эти поля.
➕ Поддерживает мутации для изменения данных и подписки для уведомлений в реальном времени.
➕ Отлично подходит для агрегации данных из нескольких источников и хорошо работает с быстро меняющимися требованиями к внешнему интерфейсу.
➖ Переносит сложность на сторону клиента и может допускать опасные запросы, если не защищён должным образом.
➖ Стратегии кэширования могут быть сложнее, чем REST.
Выбор между REST и GraphQL зависит от конкретных требований приложения и команды разработчиков. GraphQL хорошо подходит для сложных или часто меняющихся потребностей интерфейса, в то время как REST подходит для приложений, где предпочтительны простые и последовательные контракты.
Ни один из подходов не является панацеей. Тщательная оценка требований и компромиссов важна для выбора правильного стиля. И REST, и GraphQL являются допустимыми вариантами для раскрытия данных и поддержки современных приложений.
Источник: https://github.com/ByteByteGoHq/system-design-101
REST API или GraphQL
REST
➕ Использует стандартные методы HTTP, такие как GET, POST, PUT, DELETE для операций CRUD.
➕ Хорошо работает, когда вам нужны простые, единообразные интерфейсы между отдельными сервисами/приложениями.
➕ Стратегии кэширования просты в реализации.
➖ Может потребоваться несколько циклов для сбора связанных данных из отдельных конечных точек.
GraphQL
➕ Предоставляет клиентам единую конечную точку для запроса именно тех данных, которые им нужны.
➕ Клиенты указывают требуемые поля во вложенных запросах, и сервер возвращает данные, содержащие только эти поля.
➕ Поддерживает мутации для изменения данных и подписки для уведомлений в реальном времени.
➕ Отлично подходит для агрегации данных из нескольких источников и хорошо работает с быстро меняющимися требованиями к внешнему интерфейсу.
➖ Переносит сложность на сторону клиента и может допускать опасные запросы, если не защищён должным образом.
➖ Стратегии кэширования могут быть сложнее, чем REST.
Выбор между REST и GraphQL зависит от конкретных требований приложения и команды разработчиков. GraphQL хорошо подходит для сложных или часто меняющихся потребностей интерфейса, в то время как REST подходит для приложений, где предпочтительны простые и последовательные контракты.
Ни один из подходов не является панацеей. Тщательная оценка требований и компромиссов важна для выбора правильного стиля. И REST, и GraphQL являются допустимыми вариантами для раскрытия данных и поддержки современных приложений.
Источник: https://github.com/ByteByteGoHq/system-design-101
👍15
День 2261. #SystemDesign101
Как работает gRPC?
RPC (Remote Procedure Call – Удалённый Вызов Процедур) называется «удалённым», потому что он обеспечивает связь между удалёнными сервисами, когда они развёрнуты на разных серверах в архитектуре микросервисов. С точки зрения клиента он действует как локальный вызов функции.
На схеме выше показан поток данных для gRPC.
1. Выполняется REST-запрос от клиента. Тело запроса обычно имеет формат JSON.
2–4. Сервис заказов (клиент gRPC) получает REST-запрос, преобразует его и выполняет вызов RPC к сервису платежей. gPRC кодирует заглушку клиента в двоичный формат и отправляет её на низкоуровневый транспортный уровень.
5. gRPC отправляет пакеты по сети через HTTP2. Благодаря двоичному кодированию и сетевой оптимизации gRPC примерно в 5 раз быстрее JSON.
6–8. Сервис платежей (сервер gRPC) получает пакеты из сети, декодирует их и вызывает серверное приложение.
9–11. Результат возвращается из серверного приложения, кодируется и отправляется на транспортный уровень.
12–14. Сервис заказов получает пакеты, декодирует их и отправляет результат клиентскому приложению.
Источник: https://github.com/ByteByteGoHq/system-design-101
Как работает gRPC?
RPC (Remote Procedure Call – Удалённый Вызов Процедур) называется «удалённым», потому что он обеспечивает связь между удалёнными сервисами, когда они развёрнуты на разных серверах в архитектуре микросервисов. С точки зрения клиента он действует как локальный вызов функции.
На схеме выше показан поток данных для gRPC.
1. Выполняется REST-запрос от клиента. Тело запроса обычно имеет формат JSON.
2–4. Сервис заказов (клиент gRPC) получает REST-запрос, преобразует его и выполняет вызов RPC к сервису платежей. gPRC кодирует заглушку клиента в двоичный формат и отправляет её на низкоуровневый транспортный уровень.
5. gRPC отправляет пакеты по сети через HTTP2. Благодаря двоичному кодированию и сетевой оптимизации gRPC примерно в 5 раз быстрее JSON.
6–8. Сервис платежей (сервер gRPC) получает пакеты из сети, декодирует их и вызывает серверное приложение.
9–11. Результат возвращается из серверного приложения, кодируется и отправляется на транспортный уровень.
12–14. Сервис заказов получает пакеты, декодирует их и отправляет результат клиентскому приложению.
Источник: https://github.com/ByteByteGoHq/system-design-101
👍19
День 2267. #SystemDesign101
Что Такое Веб-Хук?
Допустим, мы управляем сайтом электронной коммерции. Клиенты отправляют заказы в сервис заказов через API-шлюз, а потом попадают в сервис платежей службу для платёжных транзакций. Сервис платежей обращается к внешнему поставщику платёжных услуг (PSP) для завершения транзакций.
Существует два способа общения с внешним PSP.
1. Поллинг (polling)
После отправки платёжного запроса в PSP сервис платежей постоянно опрашивает PSP о статусе платежа. Рано или поздно PSP вернёт статус.
Недостатки:
- Требует ресурсов от сервиса платежей.
- Прямое взаимодействие сервиса платежей с внешним поставщиком услуг создаёт уязвимости безопасности.
2. Веб-хук (webhook)
Мы можем зарегистрировать веб-хук во внешнем сервисе. Это означает: вызовите определённый мной URL, когда у вас появятся обновления по запросу. Когда PSP завершит обработку, он сделает HTTP-запрос для обновления статуса платежа.
Платёжному сервису больше не нужно тратить ресурсы на опрос статуса платежа.
Что, если PSP не вызовет URL? Можем настроить задание для проверки статуса платежа каждый час.
Веб-хуки часто называют обратными API или push-API, потому что сервер отправляет HTTP-запросы клиенту. При использовании веб-хука нужно обратить внимание на 3 вещи:
- Разработать правильный API для вызова внешнего сервиса.
- Настроить правила в API-шлюзе из соображений безопасности.
- Зарегистрировать правильный URL обратного вызова во внешнем сервисе.
Что использовать?
Поллинг — надёжный вариант, когда есть некоторые инфраструктурные ограничения, которые не позволяют использовать веб-хуки. Кроме того, при использовании веб-хуки существует риск пропуска уведомлений из-за проблем с сетью, поэтому необходимы надлежащие механизмы повторных попыток.
Веб-хуки рекомендуются для приложений, которым требуется мгновенная доставка данных при их возникновении. Кроме того, они эффективны с точки зрения использования ресурсов, особенно в средах с высокой нагрузкой.
Источник: https://github.com/ByteByteGoHq/system-design-101
Что Такое Веб-Хук?
Допустим, мы управляем сайтом электронной коммерции. Клиенты отправляют заказы в сервис заказов через API-шлюз, а потом попадают в сервис платежей службу для платёжных транзакций. Сервис платежей обращается к внешнему поставщику платёжных услуг (PSP) для завершения транзакций.
Существует два способа общения с внешним PSP.
1. Поллинг (polling)
После отправки платёжного запроса в PSP сервис платежей постоянно опрашивает PSP о статусе платежа. Рано или поздно PSP вернёт статус.
Недостатки:
- Требует ресурсов от сервиса платежей.
- Прямое взаимодействие сервиса платежей с внешним поставщиком услуг создаёт уязвимости безопасности.
2. Веб-хук (webhook)
Мы можем зарегистрировать веб-хук во внешнем сервисе. Это означает: вызовите определённый мной URL, когда у вас появятся обновления по запросу. Когда PSP завершит обработку, он сделает HTTP-запрос для обновления статуса платежа.
Платёжному сервису больше не нужно тратить ресурсы на опрос статуса платежа.
Что, если PSP не вызовет URL? Можем настроить задание для проверки статуса платежа каждый час.
Веб-хуки часто называют обратными API или push-API, потому что сервер отправляет HTTP-запросы клиенту. При использовании веб-хука нужно обратить внимание на 3 вещи:
- Разработать правильный API для вызова внешнего сервиса.
- Настроить правила в API-шлюзе из соображений безопасности.
- Зарегистрировать правильный URL обратного вызова во внешнем сервисе.
Что использовать?
Поллинг — надёжный вариант, когда есть некоторые инфраструктурные ограничения, которые не позволяют использовать веб-хуки. Кроме того, при использовании веб-хуки существует риск пропуска уведомлений из-за проблем с сетью, поэтому необходимы надлежащие механизмы повторных попыток.
Веб-хуки рекомендуются для приложений, которым требуется мгновенная доставка данных при их возникновении. Кроме того, они эффективны с точки зрения использования ресурсов, особенно в средах с высокой нагрузкой.
Источник: https://github.com/ByteByteGoHq/system-design-101
👍19