Проектирование front-to-back интеграций

Проектирование front-to-back интеграций

• Из каких шагов состоит клиентский путь?
• Как пользователь взаимодействует с UI на каждом из шагов?
• На каких этапах потребуется обращение к бэкенд-приложению?
• Должен ли пользователь ожидать результат выполнения операции?
• Какие данные потребуется передавать?

• Сколько пользователей может быть одновременно онлайн?
• Какой RPS они будут генерить?
• В каком объеме потребуется передавать данные?

Базовые паттерны взаимодействий front-to-back

Client pull

Server push

Выбор паттерна

• Требование отображать результаты запроса по мере их получения. Например, такое может понадобиться в агрегаторе товаров, который собирает информацию из нескольких источников с разными SLA.
• Требование реализовать онлайн-чат или мессенджер, в рамках которого нужен именно двусторонний обмен, но ключевой является необходимость инициировать передачу сообщений из бэкенда на фронтенд в онлайн-режиме.
• Необходимость отправлять уведомления в реальном времени на интерфейс пользователя.

Реализация Client pull

Множество источников данных

1. Первый вариант — сделать один запрос, в рамках которого будут возвращаться данные из всех источников, а потребители на своей стороне из всего массива данных берут те, что им нужны. В таком случае мы получаем сразу несколько потенциальных проблем:
   a. Время отклика будет равняться времени отклика самого медленного сервиса-источника.
   b. Низкая надёжность из-за зависимости всех процессов от всех сервисов, даже если их данные не нужны в этом процессе.
   c. Передача избыточного объёма данных, которая возлагает дополнительную нагрузку на сеть и увеличивает время передачи данных. Это и необходимость обрабатывать лишние данные, замедляет время отображения страниц для пользователей.
2. Второй — делать для каждого сценария отдельные операции запросов и выполнять композицию только тех сервисов, данные которых нужны в этом конкретном сценарии. В этом случае мы решим проблемы предыдущего пункта, но получим потенциально высокие накладные на разработку постоянно появляющихся новых сценариев, а также на доработку существующих операций, если контракты сервисов-источников изменятся.

1. Hasura GraphQL Engine

2. Apollo Federation

Запрос сущности со множеством атрибутов

1. Отображения всех объектов и их связей на доске. Однако сконцентрируемся просто на объектах. Для отображения объектов требуется его наименование, координаты на доске, используемая иконка, её цвет и т. д.
2. Отображение списка объектов для возможности скрыть или отобразить на доске. В данном случае требуются только наименования объектов.
3. Отображение карточки объекта, в которой была бы возможность посмотреть всю информацию по объекту, включая комментарии, теги, иконку, цвет, а также историю его изменений.

type Query {
    object(id: ID!): Object
    objects(boardId: ID!): [Object]

}

type Object {
    id: ID!
    version: Int
    name: String
    comments: [String]
    stateHistory: [Document]
    coordinates: String
    icon: String
    color: String
}

type ObjectState {
    id: ID!
    version: Int
    name: String
    comments: [String]
}

type Board {
    id: ID!
    objects: [Object]
} 

1. Для отображения на доске:
   Скопировать код

   GRAPHQL

   query {
    objects(boardId: "board1") {
      id
      name
      coordinates
      icon
      color
    }
   } 
2. Для отображения списка:
   Скопировать код

   GRAPHQL

   query {
    objects(boardId: "board2") {
      id
      name
    }
   } 
3. Для отображения карточки:
   Скопировать код

   GRAPHQL

   query {
    object(id: "object111") {
      id
      version
      name
      comments
      stateHistory
      icon
      color
    }
   } 

Кеширование в GraphQL

1. Кеширование на уровне полей
   Способность GraphQL извлекать именно то, что нужно. Поэтому один из вариантов — применить точечное кеширование в разрезе атрибутов данных. Этот подход очень эффективен и позволяет повторно использовать кешированные данные в различных запросах. Из минусов — он достаточно сложен в реализации, особенно в вопросах инвалидации кеша.
2. Кеширование по хешу запроса
   В этом подходе запрос преобразуется в хеш и становится ключом записи в кеш. Это проще, но такая реализация может приводить к избыточному потреблению памяти из-за дублирования данных в разных записях в кеше. Также может происходить полное дублирование записей, если одинаковые по своей сути запросы будут чем-то отличаться, например порядком атрибутов.
3. Использование постоянных запросов
   Продолжением и развитием подхода из предыдущего пункта является использование постоянных запросов. Основная идея — в том, чтобы заранее предопределить запросы, которые будут отправляться клиентами, и сформировать из них структуру в виде ключ-значение на каком-то промежуточном компоненте, например шлюзе API. Таким образом клиент будет отправлять именно ключ запроса, а шлюз по ключу будет получать предопределённое тело запроса и отправлять серверу.
   В такой реализации гораздо проще осуществлять кеширование, ведь оно, по сути, повторяет кеширование по HTTP, только не на основании URL, а на основании ключа запроса. Ещё появляется возможность переиспользовать запросы, снизить дублирование данных в разных записях кеша и предиктивно кешировать постоянные запросы ещё до получения первого фактического запроса от клиента.
   Однако такая реализация в каком-то смысле привносит ограничения, которые присущи REST в части использования фиксированных запросов с фиксированным набором данных, которые будут возвращены в ответе. Без хорошего решения с возможностью просто дорабатывать и менять постоянные запросы командой клиента такое решение во многом лишает использование GraphQL гибкости.
4. Кеширование на клиенте
   Кеширование на стороне клиента позволяет снизить нагрузку на сервер. Оно поддерживается популярными клиентскими библиотеками, например Apollo Client, и предлагает встроенные механизмы, которые помогают эффективно управлять нормализацией и хранением данных в кеше.

Реализация Server push

• WebSockets — протокол взаимодействия, который обеспечивает двустороннее взаимодействие между клиентом и сервером, используя при этом одно долговременное TCP соединение.
  WebSockets позволяют отойти от модели взаимодействия запрос-ответ и отправлять сообщения в обе стороны «асинхронно». Основное преимущество перед HTTP заключается в отсутствии необходимости повторно открывать соединение для каждой итерации взаимодействия.
• SSE (Server sent events) — это технология для интеграции, которая работает на базе HTTP. Она позволяет осуществлять односторонний обмен между сервером и клиентом. При этом предполагается, что именно сервер отправляет сообщения клиенту.
• GraphQL Subscriptions — это фича GraphQL, которая позволяет публиковать изменения о сущностях в рамках одного GraphQL API. В первую очередь она является именно спецификацией и не зависит от конкретной реализации и протокола взаимодействия. Однако самая популярная реализация graphql-ws использует «под капотом» WebSockets.

1. Двусторонний обмен сообщениями

2. Отправка событий о сущности из GraphQL API

subscription ObjectsFeed {

  objectsCreated {
    id
    name
  }
} 

3. Односторонняя отправка сообщений с сервера

• Эффективность использования ресурсов. WebSockets в рамках одного соединения могут обеспечивать очень высокую пропускную способность. В рамках одного соединения не требуется постоянной отправки большого количества метаинформации, как это происходит при стандартном взаимодействии по HTTP. Объём данных сокращается до тела сообщения. Дополнительно есть возможность передавать данные в бинарном виде, что ещё сильнее уменьшает размер сообщений.
• Высокая производительность и низкая задержка. В отличие от традиционных протоколов HTTP, которые инициируют новый цикл запрос-ответ для каждой передачи данных, WebSockets поддерживают постоянное соединение между клиентом и сервером. Это снижает задержку и накладные расходы. Следовательно, WebSockets предлагают значительные преимущества производительности для случаев использования с низкой задержкой, таких как чат и обновление данных в реальном времени.
• Поддерживается большинством браузеров. Это не является уникальным преимуществом, но стоит понимать, что большинство современных браузеров поддерживают WebSockets. Когда в браузере отсутствует поддержка, некоторые библиотеки и фреймворки «из коробки» предоставляют возможность откатиться на HTTP, при этом эмулируя взаимодействие через сокеты.

• Блокировка корпоративными средствами защиты. В случае использования WebSockets в корпоративной разработке, особенно в компаниях с жёсткими правилами ИБ, есть большая вероятность столкнуться со сложностями согласований и конфигурации средств защиты для возможности взаимодействия через WebSockets.
• Нет встроенной поддержки переподключения в случае разрыва соединения. Если соединение разорвётся (например, из-за проблем с сетью), по умолчанию клиентское приложение не попытается переподключиться. Эту низкоуровневую функциональность вам необходимо будет реализовать либо самостоятельно, либо с применением специализированных клиентских библиотек.

• Поддерживается большинством браузеров. Более того, в случае Server-sent events можно обеспечить поддержку с помощью JavaScript в браузерах, которые его ещё не поддерживают. Это полезно для обратной совместимости, поскольку вы можете положиться на существующую реализацию, а не писать альтернативу.
• Встроенная поддержка переподключения. SSE Connections поддерживает автоматическое переподключение в случае разрыва соединения.
• Отсутствие блокировок корпоративными средствами защиты. В случае использования SSE, у вас вряд ли будут проблемы с корпоративными брандмауэрами.

• Ограничения формата данных. В рамках SSE можно использовать только кодировку UTF-8, другие кодировки или двоичные форматы не поддерживаются.
• Ограниченное количество одновременных подключений внутри одного браузера. В любой момент времени один клиентский браузер может открыть только шесть одновременных подключений SSE. Несколько открытых вкладок с подключениями SSE могут быть непредсказуемо зависимы в случаях, когда другие веб-приложения, которые открыты у пользователя, также используют SSE.

Что почитать про front-to-back интеграции

• O'Reilly Online Learning WebSocket — детально разобраться в протоколе, понять, как он работает и как его использовать.
• Amazom Web Services, Inc. What is RESTful API? - RESTful API Explained - AWS — Что такое API RESTful? Для тех, кто хочет обновить информацию о REST.
• Introduction to GraphQL — официальная документация по GraphQL — лучший способ в нём разобраться.
• GraphQL | A query Language for your API
• Scaling a GraphQL Website – The Art of Machinery — неплохая статья про повышение производительности приложения с GraphQL API.
• Hasura Community Edition — Open-source платформа для генерации GraphQL API на основе базы данных.
• Документация GraphQL — руководство по WebSocket протоколу для реального времени в GraphQL.
• Зачем нужна customer journey map и как её правильно построить — статья о создании карты взаимодействий клиента с продуктом для улучшения пользовательского опыта.

Итоги

• Front-to-back взаимодействие — это процесс обмена данными между клиентской частью приложения (фронтендом) и серверной частью (бэкендом). Оно определяет, как пользователи получают доступ к данным и функциональности системы, влияет на скорость загрузки, актуальность отображаемой информации и общую производительность приложения, что, в свою очередь, сильно влияет на пользовательский опыт.
• Выбор паттерна взаимодействия зависит от требований к обновлению данных и производительности приложения. Паттерн Client Pull используется, когда клиент сам периодически запрашивает данные у сервера, что подходит для приложений с нечастыми обновлениями. Server Push предпочтителен, если важно, чтобы клиент получал обновления сразу после их появления на сервере, например для чатов или биржевых данных.
• При реализации паттерна Client Pull наиболее распространённые технологии — REST и GraphQL. В случае REST клиент отправляет запросы на определённые URL для получения данных, обновления или удаления информации. Это простой и широко применяемый подход. GraphQL, в отличие от REST, позволяет клиенту запрашивать только те данные, которые ему нужны, в одном запросе, что уменьшает объём передаваемых данных и количество запросов.
• Для паттерна Server Push популярны технологии WebSockets и SSE. SSE позволяет серверу отправлять данные клиенту через однонаправленный поток, что подходит для непрерывных обновлений, таких как ленты новостей. WebSockets обеспечивают двустороннюю связь, позволяя клиенту и серверу обмениваться данными в реальном времени, что идеально для приложений с высокими требованиями к интерактивности, таких как онлайн-чаты или игровые платформы.