Сегодня я просмотрел структуру тикерного фида GRVT — главным образом потому, что понимание того, что именно несёт одно обновление тикера, важно для закрытия той картины рыночных данных, которую я собирал в течение этого спринта.
Тикер, как предполагается, показывает последнюю цену сделки, максимум и минимум за 24 часа, объём за 24 часа и, вероятно, процентное изменение за то же окно — причём обновляется в виде компактного снимка, а не заставляет клиента самостоятельно вычислять эти статистические показатели из первичной истории сделок.
Что я считаю примечательным — это то, что по сути это уровень удобства, расположенный поверх данных, которые технически можно вывести из фида сделок, который я рассматривал ранее. Клиент теоретически мог бы вычислить максимум за 24 часа, минимум и объём, обработав всю историю сделок самостоятельно, но вычисление и потоковая передача этого сводного отчёта со стороны GRVT снимают реальную вычислительную нагрузку с каждого отдельного клиента, который в противном случае должен был бы поддерживать ту же скользящую обработку независимо.
Это перекликается с паттерном, который я заметил на этой неделе в более широком дизайне фидов GRVT: существует исходная детальная гранулярная информация — глубина стакана, отдельные сделки, но также существуют рядом с ней сводные, заранее вычисленные представления для тех случаев, когда полной детализации на самом деле не требуется.
Завершая этот спринт на основе наблюдения, что поверхность API GRVT, похоже, последовательно проектируется, исходя из того же компромисса: детальные данные для тех, кому нужна точность, и сводные данные для тех, кому достаточно быстро получить корректную картину.
@grvt_io #grvt
Тикер, как предполагается, показывает последнюю цену сделки, максимум и минимум за 24 часа, объём за 24 часа и, вероятно, процентное изменение за то же окно — причём обновляется в виде компактного снимка, а не заставляет клиента самостоятельно вычислять эти статистические показатели из первичной истории сделок.
Что я считаю примечательным — это то, что по сути это уровень удобства, расположенный поверх данных, которые технически можно вывести из фида сделок, который я рассматривал ранее. Клиент теоретически мог бы вычислить максимум за 24 часа, минимум и объём, обработав всю историю сделок самостоятельно, но вычисление и потоковая передача этого сводного отчёта со стороны GRVT снимают реальную вычислительную нагрузку с каждого отдельного клиента, который в противном случае должен был бы поддерживать ту же скользящую обработку независимо.
Это перекликается с паттерном, который я заметил на этой неделе в более широком дизайне фидов GRVT: существует исходная детальная гранулярная информация — глубина стакана, отдельные сделки, но также существуют рядом с ней сводные, заранее вычисленные представления для тех случаев, когда полной детализации на самом деле не требуется.
Завершая этот спринт на основе наблюдения, что поверхность API GRVT, похоже, последовательно проектируется, исходя из того же компромисса: детальные данные для тех, кому нужна точность, и сводные данные для тех, кому достаточно быстро получить корректную картину.
@grvt_io #grvt