Как передавать пользователю данные?

Дарья Матвеева · September 1, 2023

Задачи

В этом посте разберем еще одну задачу из книги Cracking the coding interview. Задача про биржу, но мне кажется удобнее ее немного обобщить, что я и сделала в заголовке.

Задача.

Представьте, что вы разрабатываете сервис, который передает клиентам данные по итогу закрытия биржевых торгов. Например, цену открытия и закрытия акций компании, а также максимальную и минимальную цену за день. К вашему сервису будут обращаться порядка 1000 клиентских приложений.

Можете считать, что все необходимые данные у вас есть. Вы можете хранить их в любом удобном вам формате и использовать любой механизм для передачи данных клиенту.

Как бы вы спроектировали этот сервис? Также имейте в виду, что вам необходимо не просто разработать систему, а обеспечивать ее развертывание, мониторинг, и поддержку. Предложите разные подходы к решению и объясните, какой подход вы рекомендуете и почему.

Решение.

Согласно условию задачи, можно считать, что у нас есть скрипты, которые магическим образом собирают для нас нужные данные. Поэтому сосредоточимся на том, как именно мы передаем их клиентам.

Решение 1. TXT файл + FTP-сервер.

Первый вариант - мы можем просто хранить данные в обычном текстовом файле, а клиенты будут скачивать файлы через FTP-сервер.

Плюсы:

  • Такую схему легко поддерживать. Легко загружать файлы и делать резервные копии.

Минусы.

  • Чтобы извлечь нужную информацию, клиентам необходимо будет делать парсинг целого текстового файла.
  • Клиентам нужно писать собственные парсеры, что может быть неудобно.
  • Если будем добавлять новые данные, парсеры клиентов могут сломаться.

Решение 2. SQl база данных.

Можно использовать стандартную SQL базу данных, чтобы клиенты сами подключались к ней.

Плюсы.

  • Гибкость извлечения данных. Клиенты смогут легко получать их под конкретные случаи, например, “вернуть все акции, где цена открытия больше N и цена закрытия меньше M”.

  • Создание резервных копий и обеспечение безопасности можно реализовать стандартным функционалом БД. Не нужно изобретать колесо.

  • Клиентам легко делать интеграцию со своими приложениями.

Минусы.

  • Это решение намного более тяжеловесное и ресурсозатратное, чем нам требуется на самом деле. Придется поддерживать целую базу данных лишь ради того, чтобы предоставить несколько файлов с данными.

  • Решение сложновато для человеческого восприятия. Скорее всего нам понадобиться реализовать еще один слой системы для просмотра данных, что увеличивает расходы на разработку.

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

Решение 3. XML/JSON

Еще одно хорошее решение - JSON или XML. Наши данные имеют фиксированный формат и размер. JSON-файл может выглядеть так:

[
  {
    "date": "2023-09-01",
    "company": [
      {
        "name": "You need coffee corp.",
        "open": "90.23",
        "high": "190.27",
        "low": "98.83",
        "closingPrice": "130.30"
      },
      {
        "name": "Best coffee Inc.",
        "open": "10.93",
        "high": "18.27",
        "low": "15.29",
        "closingPrice": "16.91"
      }
    ]
  },
  {
    "date": "2023-09-04",
    ...
  }
]

Плюсы.

  • Данные легко воспринимать человеку и обрабатывать компьютеру.

  • Большинство языков программирования имеют стандартные библиотеки для парсинга XML и JSON файлов, поэтому клиенту будет легко с ними работать.

  • Добавление новых данных в файл становится простым делом - просто нужно добавить новые ноды. И это не сломает клиентский парсер.

Минусы

  • В этом решении клиент получает все данные, даже если ему нужна только их часть, что неэффективно.
  • Чтобы сделать запрос и достать конкретное значение, нужно распарсить целый файл.

В дополнение мы можем спроектировать веб-сервис (SOAP или REST), который и будут вызывать наши клиенты. Это добавляет новый слой в систему, но увеличивает безопасность. К тому же, это может упростить для клиентов интеграцию со своими приложениями.

Еще одно преимущество (а также и недостаток) в том, что наши клиенты смогут получать данные только тем способом, который мы предусмотрим.
В случае же БД они, например, смогут получить компанию с самой высокой ценой за день, даже если мы не предусмотрели такой вариант.

Какой способ выбрать в итоге?

Точного ответ дать не получится. Простой текстовый файл скорее всего будет плохим решением, но что касается выбора между БД и JSON в совокупности с веб-сервисом, для ответа нужно ставить задачу более конкретно.

VK, Telegram