Hoy revisé la estructura del feed de cotizaciones de GRVT, principalmente porque entender qué información incluye una sola actualización de un ticker realmente importa para cerrar el panorama de datos de mercado que he estado construyendo durante este sprint.
Un ticker presumiblemente muestra el último precio negociado, el máximo y mínimo de 24 horas, el volumen de 24 horas y probablemente el cambio porcentual en esa misma ventana, actualizado como una instantánea compacta en lugar de exigir que el cliente derive estas estadísticas por su cuenta a partir del historial de operaciones en bruto.
Lo que encuentro notable es que, fundamentalmente, esto es una capa de conveniencia que se sitúa encima de datos que técnicamente pueden derivarse del feed de operaciones que revisé anteriormente. Un cliente podría, en teoría, calcular el máximo de 24 horas, el mínimo y el volumen procesando por sí mismo todo el historial de operaciones, pero el hecho de que GRVT lo compute y lo transmita como un resumen directamente elimina la carga computacional real de cada cliente que, de otro modo, tendría que mantener el mismo cálculo móvil de forma independiente.
Esto se conecta con un patrón que he notado esta semana en el diseño más amplio del feed de GRVT: existen datos granulares sin procesar (profundidad del libro de órdenes, operaciones individuales), pero también existen vistas resumidas y precomputadas junto a ellos para casos en los que el detalle completo en realidad no es necesario.
Cierro este sprint con la observación de que la API de GRVT parece estar diseñada de manera consistente en torno a este mismo intercambio: datos granulares para quienes necesitan precisión, y datos resumidos para quienes solo necesitan una imagen precisa rápidamente.
@grvt_io #grvt
Un ticker presumiblemente muestra el último precio negociado, el máximo y mínimo de 24 horas, el volumen de 24 horas y probablemente el cambio porcentual en esa misma ventana, actualizado como una instantánea compacta en lugar de exigir que el cliente derive estas estadísticas por su cuenta a partir del historial de operaciones en bruto.
Lo que encuentro notable es que, fundamentalmente, esto es una capa de conveniencia que se sitúa encima de datos que técnicamente pueden derivarse del feed de operaciones que revisé anteriormente. Un cliente podría, en teoría, calcular el máximo de 24 horas, el mínimo y el volumen procesando por sí mismo todo el historial de operaciones, pero el hecho de que GRVT lo compute y lo transmita como un resumen directamente elimina la carga computacional real de cada cliente que, de otro modo, tendría que mantener el mismo cálculo móvil de forma independiente.
Esto se conecta con un patrón que he notado esta semana en el diseño más amplio del feed de GRVT: existen datos granulares sin procesar (profundidad del libro de órdenes, operaciones individuales), pero también existen vistas resumidas y precomputadas junto a ellos para casos en los que el detalle completo en realidad no es necesario.
Cierro este sprint con la observación de que la API de GRVT parece estar diseñada de manera consistente en torno a este mismo intercambio: datos granulares para quienes necesitan precisión, y datos resumidos para quienes solo necesitan una imagen precisa rápidamente.
@grvt_io #grvt