Saya menelusuri struktur feed ticker GRVT hari ini, terutama karena memahami apa yang sebenarnya dibawa oleh satu pembaruan ticker penting untuk menyelesaikan gambaran data pasar yang sedang saya bangun sepanjang sprint ini.
Sebuah ticker kemungkinan menampilkan harga terakhir yang diperdagangkan, tertinggi dan terendah 24 jam, volume 24 jam, serta kemungkinan perubahan persentase selama jendela yang sama—diperbarui sebagai cuplikan ringkas, bukan mengharuskan klien menurunkan statistik-statistik tersebut sendiri dari riwayat transaksi mentah.
Yang saya anggap menarik adalah bahwa ini pada dasarnya adalah lapisan kemudahan (convenience layer) yang berada di atas data yang sebenarnya bisa diturunkan secara teknis dari feed transaksi yang sebelumnya saya lihat. Secara teoretis, klien bisa menghitung high 24 jam, low 24 jam, dan volume dengan memproses seluruh riwayat transaksi mereka sendiri, tetapi GRVT menghitung dan men-stream ringkasan itu secara langsung sehingga menghilangkan beban komputasi nyata dari setiap klien yang seharusnya mempertahankan perhitungan bergulir yang sama secara independen.
Hal ini berkaitan dengan pola yang saya perhatikan di seluruh desain feed GRVT minggu ini: data mentah tersedia (depth orderbook, transaksi individual), tetapi ada juga tampilan ringkas yang sudah dihitung sebelumnya, berdampingan dengan data tersebut untuk kasus ketika detail lengkap sebenarnya tidak diperlukan.
Menutup sprint ini dengan temuan bahwa permukaan API GRVT tampaknya secara konsisten dirancang berdasarkan tradeoff yang sama: data granular untuk mereka yang membutuhkan ketelitian, dan data ringkas untuk mereka yang hanya perlu gambaran yang akurat dengan cepat.
@grvt_io #grvt
Sebuah ticker kemungkinan menampilkan harga terakhir yang diperdagangkan, tertinggi dan terendah 24 jam, volume 24 jam, serta kemungkinan perubahan persentase selama jendela yang sama—diperbarui sebagai cuplikan ringkas, bukan mengharuskan klien menurunkan statistik-statistik tersebut sendiri dari riwayat transaksi mentah.
Yang saya anggap menarik adalah bahwa ini pada dasarnya adalah lapisan kemudahan (convenience layer) yang berada di atas data yang sebenarnya bisa diturunkan secara teknis dari feed transaksi yang sebelumnya saya lihat. Secara teoretis, klien bisa menghitung high 24 jam, low 24 jam, dan volume dengan memproses seluruh riwayat transaksi mereka sendiri, tetapi GRVT menghitung dan men-stream ringkasan itu secara langsung sehingga menghilangkan beban komputasi nyata dari setiap klien yang seharusnya mempertahankan perhitungan bergulir yang sama secara independen.
Hal ini berkaitan dengan pola yang saya perhatikan di seluruh desain feed GRVT minggu ini: data mentah tersedia (depth orderbook, transaksi individual), tetapi ada juga tampilan ringkas yang sudah dihitung sebelumnya, berdampingan dengan data tersebut untuk kasus ketika detail lengkap sebenarnya tidak diperlukan.
Menutup sprint ini dengan temuan bahwa permukaan API GRVT tampaknya secara konsisten dirancang berdasarkan tradeoff yang sama: data granular untuk mereka yang membutuhkan ketelitian, dan data ringkas untuk mereka yang hanya perlu gambaran yang akurat dengan cepat.
@grvt_io #grvt