Okxlivro - Post Mortem

Привет! Сегодня я делюсь своими мыслями о написании удобных Раст библиотек. Это первый пост из серии "Post Mortem", где я буду препарировать разные проекты. Сегодня на нашем столе будет техническое задание, которое мне дали в одной из компаний после собеседования. Я не люблю тратить своё личное время, поэтому обычно отказываюсь от прохождения этого этапа, но здесь проект показался мне интересным и я его выполнил.

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

Портфели, стаканы и заказы

Если вы не знакомы с торгами, то рекомендую перед дальнейшим прочтением изучить небольшое видео об этом или статью на Википедии. Далее я излагаю своё понимание темы, которoe может оказаться неточным или неполным.

Итак, в Торгах мы имеем:

• Портфель заказов
  • Заказы на продажу (Ask side Order)
    • Идентификатор торговой пары (что на что меняю), объём и цена
  • Заказы на покупку (Bid side Order)

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

Суть

Пробуем применять Структуру на Основе Видимости Модулей. Идеей и основной задачей является написание библиотеки для работы с OKX биржей, API должен быть удобен в использовании, а реализация в расширении и поддержкe.

Я решил что стоит пробовать писать идеоматичный, но современный Раст код - использующий асинхронную модель, строгую типизацию и сокрытие реализации.

Reverse

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

/// Low to high price ordered Map ([`Price`], [`Amount`]) of Asks.
pub struct Asks(BTreeMap<Price, Amount>);
// High to low price ordered Map ([`Price`], [`Amount`]) of Bids.
pub struct Bids(BTreeMap<Reverse<Price>, Amount>);

Вы можете использовать схожий тип данных - как я использовал Цену, но обернуть её в Reverse. Тогда при сравнении мы будем инвертировать результат, в нашем случае сортируя цены в обратную сторону.

Stream

Изначально я использовал подход через каналы отправки сообщений, но затем переписал на вариант, более эргономичный для использования клиентами библиотеки: изменения

pub fn orderbook_updates(instrument_id: &str) -> Pin<Box<impl Stream<Item = Result<RealtimeData, RealtimeError>>>> {
  ...
  Box::pin(stream! {
    ...
    while let Some(msg) = read.next().await {
      ...
      yield Ok(data);
    }
  )
}

как мы видим, данный подход ещё требует дополнительных макросов и асинхронные итераторы не являются чем-то родным стандартной библиотеке, продолжаем надееться и ждать.

Enum

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

pub enum RealtimeData {
    Snapshot(SnapshotData),
    Update(UpdateData),
}
pub struct SnapshotData(pub (Vec<Order>, Vec<Order>));
pub struct UpdateData(pub (Vec<Order>, Vec<Order>));

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

Convert

Для трансформации типов, я всегда стараюсь использовать типажи core::convert::(Try)From - что приближает мой код к коду стандартной библиотеки.

impl TryFrom<&Value> for Order {
  type Error = DeserializationError;
  fn try_from(value: &Value) -> Result<Self, Self::Error> {
    ...
  }
}

Error

Обожаю простую, но безумно полезную библиотеку derive_more с процедурными макросами вывода на все случаи жизни, например для создания типов ошибок:

#[derive(Debug, Display, Error, From)]
pub enum RealtimeError {
  WebSocket(WsError),
  Json(JsonError),
  MissingField { source: DeserializationError },
}

Здесь, благодаря макросам, перечисление становится Раст ошибкой, может быть выведено в виде строки и сконвертировано из низкоуровневых ошибок - всё это без лишнего кода написанного от руки. Он есть - но генерируется автоматически.

Дополнительные материалы

Если вам интересно "поиграть" с примером из данной статьи, то вот полный код проекта.