Hôm nay tôi đã xem qua cấu trúc luồng mã (ticker) của GRVT, chủ yếu vì muốn hiểu một lần cập nhật ticker thực sự mang những gì để hoàn tất bức tranh dữ liệu thị trường mà tôi đã xây dựng trong suốt sprint này.
Một ticker hẳn sẽ hiển thị giá giao dịch cuối cùng, mức cao và thấp trong 24 giờ, khối lượng trong 24 giờ, và có lẽ cả phần trăm thay đổi trong cùng khoảng thời gian đó—được cập nhật dưới dạng một ảnh chụp nhanh gọn nhẹ, thay vì bắt một client phải tự suy ra các thống kê này từ lịch sử giao dịch thô.
Điểm tôi thấy đáng chú ý là về bản chất đây là một lớp tiện lợi nằm phía trên dữ liệu có thể được suy ra một cách kỹ thuật từ luồng giao dịch mà tôi đã xem trước đó. Về mặt lý thuyết, client có thể tự tính toán mức cao, mức thấp và khối lượng 24 giờ bằng cách xử lý toàn bộ lịch sử giao dịch, nhưng việc GRVT tính toán và phát trực tiếp bản tóm tắt đó sẽ loại bỏ gánh nặng tính toán thực sự khỏi từng client riêng lẻ—những client vốn sẽ phải duy trì phép tính lăn (rolling) tương tự một cách độc lập.
Điều này gắn với một kiểu mẫu mà tôi nhận thấy trong thiết kế luồng dữ liệu tổng quát hơn của GRVT trong tuần này: dữ liệu thô ở mức chi tiết tồn tại—độ sâu sổ lệnh (order book depth), từng giao dịch riêng lẻ—nhưng đồng thời cũng có các dạng đã được tóm tắt, được tính sẵn, bên cạnh đó trong những trường hợp mà chi tiết đầy đủ thực sự không cần thiết.
Kết thúc sprint này với nhận xét rằng bề mặt API của GRVT có vẻ được thiết kế một cách nhất quán xoay quanh cùng sự đánh đổi này: dữ liệu chi tiết cho những ai cần độ chính xác, dữ liệu đã tóm tắt cho những ai chỉ cần một cái nhìn chính xác một cách nhanh chóng.
@grvt_io #grvt
Một ticker hẳn sẽ hiển thị giá giao dịch cuối cùng, mức cao và thấp trong 24 giờ, khối lượng trong 24 giờ, và có lẽ cả phần trăm thay đổi trong cùng khoảng thời gian đó—được cập nhật dưới dạng một ảnh chụp nhanh gọn nhẹ, thay vì bắt một client phải tự suy ra các thống kê này từ lịch sử giao dịch thô.
Điểm tôi thấy đáng chú ý là về bản chất đây là một lớp tiện lợi nằm phía trên dữ liệu có thể được suy ra một cách kỹ thuật từ luồng giao dịch mà tôi đã xem trước đó. Về mặt lý thuyết, client có thể tự tính toán mức cao, mức thấp và khối lượng 24 giờ bằng cách xử lý toàn bộ lịch sử giao dịch, nhưng việc GRVT tính toán và phát trực tiếp bản tóm tắt đó sẽ loại bỏ gánh nặng tính toán thực sự khỏi từng client riêng lẻ—những client vốn sẽ phải duy trì phép tính lăn (rolling) tương tự một cách độc lập.
Điều này gắn với một kiểu mẫu mà tôi nhận thấy trong thiết kế luồng dữ liệu tổng quát hơn của GRVT trong tuần này: dữ liệu thô ở mức chi tiết tồn tại—độ sâu sổ lệnh (order book depth), từng giao dịch riêng lẻ—nhưng đồng thời cũng có các dạng đã được tóm tắt, được tính sẵn, bên cạnh đó trong những trường hợp mà chi tiết đầy đủ thực sự không cần thiết.
Kết thúc sprint này với nhận xét rằng bề mặt API của GRVT có vẻ được thiết kế một cách nhất quán xoay quanh cùng sự đánh đổi này: dữ liệu chi tiết cho những ai cần độ chính xác, dữ liệu đã tóm tắt cho những ai chỉ cần một cái nhìn chính xác một cách nhanh chóng.
@grvt_io #grvt