Arsitektur streaming data telemetri menuntut efisiensi I/O tinggi, latensi rendah, dan konsumsi memori server yang stabil. Dalam studi kasus pemrosesan telemetri orbital seperti data feed NASA Horizons—yang memancarkan koordinat efemeris, vektor kecepatan, dan jarak secara periodik—pemilihan transport layer menentukan skalabilitas infrastruktur. Perdebatan umumnya berpusat pada dua pendekatan: koneksi dua arah full-duplex via WebSockets versus Server-Sent Events (SSE) berbasis hypermedia menggunakan Datastar.

Karakteristik Kasus: NASA Horizons Telemetry Feed

Data telemetri efemeris Horizons bersifat unidirectional (server ke klien). Klien mengirimkan parameter inisial (ID target, rentang waktu, observer frame), kemudian server secara terus-menerus memancarkan kalkulasi numerik terkini. Beban kerja ini menghasilkan karakteristik transmisi berikut:

  • Trafik didominasi arah downstream (95%+ output dari server).
  • Data berfrekuensi tinggi (10 Hz hingga 60 Hz untuk visualisasi real-time orbit).
  • Kebutuhan mutlak terhadap transmisi hemat overhead: pemborosan beberapa byte per frame terakumulasi cepat pada ribuan klien bersamaan.

Perbandingan Teknis: Server-Sent Events (Datastar) vs WebSockets

1. Model Protokol dan Komputasi Server

WebSockets meng-upgrade koneksi HTTP standar ke layer TCP tersendiri (RFC 6455). Operasi ini bersifat stateful secara penuh. Server harus mengalokasikan context object, ping/pong keepalive loop, dan state tracking di memori kernel maupun runtime aplikasi.

Datastar memanfaatkan SSE (Server-Sent Events) standar di atas HTTP/1.1 chunked transfer atau HTTP/2 streams. Datastar membaca data fragmen HTML langsung melalui header text/event-stream dan memperbarui DOM target secara presisi tanpa parsing JSON manual di frontend.

2. Memory Footprint dan Manajemen Koneksi

WebSockets mempertahankan koneksi layer transport khusus. Jika sistem berada di balik reverse proxy (seperti NGINX atau Envoy), connection pooling tidak dapat diterapkan secara fleksibel. Setiap socket mengunci satu worker stream, menghabiskan alokasi buffer write/read TCP secara mandiri.

SSE di atas HTTP/2 memanfaatkan mekanisme multiplexing. Puluhan transmisi data telemetri yang menuju satu klien fisik dapat berjalan di atas satu koneksi TCP yang sama. Ini memangkas kebutuhan alokasi file descriptor dan footprint memori server secara signifikan.

3. Reconnection dan State Recovery

WebSockets tidak memiliki native reconnection spec. Pengembang wajib mengimplementasikan heartbeat, buffer antrean saat koneksi terputus, dan backoff retry di sisi klien menggunakan JavaScript kustom.

SSE memiliki native reconnection yang ditangani langsung oleh browser engine via field id dan header Last-Event-ID. Jika koneksi terputus karena fluktuasi jaringan, browser secara otomatis mengirimkan ID terakhir yang diterima, memungkinkan server melanjutkan streaming telemetri tanpa data loss dan tanpa baris kode tambahan di frontend.

Implementasi: Streaming Telemetri Horizons via Datastar

Berikut implementasi backend Go standar yang memancarkan data koordinat vektor telemetri ke UI menggunakan payload SSE yang kompatibel dengan Datastar:

package main

import (
	"fmt"
	"net/http"
	"time"
)

type HorizonsVector struct {
	Target string
	X      float64
	Y      float64
	Z      float64
	Epoch  int64
}

func telemetryHandler(w http.ResponseWriter, r *http.Request) {
	flusher, ok := w.(http.Flusher)
	if !ok {
		http.Error(w, "Streaming unsupported", http.StatusInternalServerError)
		return
	}

	w.Header().Set("Content-Type", "text/event-stream")
	w.Header().Set("Cache-Control", "no-cache")
	w.Header().Set("Connection", "keep-alive")

	ticker := time.NewTicker(100 * time.Millisecond) // 10 Hz stream
	defer ticker.Stop()

	for {
		select {
		case <-r.Context().Done():
			return
		case t := <-ticker.C:
			// Simulasi kalkulasi telemetri posisi orbit
			vec := HorizonsVector{
				Target: "399-Earth",
				X:      1.496e8,
				Y:      2.341e4,
				Z:      -1.205e3,
				Epoch:  t.UnixNano(),
			}

			// Format fragment HTML SSE Datastar
			html := fmt.Sprintf("<div id=\"telemetry-display\"><span>X: %.2f</span> <span>Y: %.2f</span> <span>Z: %.2f</span></div>", vec.X, vec.Y, vec.Z)
			
			// Kirim SSE event Datastar
			fmt.Fprintf(w, "event: datastar-merge-fragments\ndata: fragments %s\n\n", html)
			flusher.Flush()
		}
	}
}

func main() {
	http.HandleFunc("/stream/telemetry", telemetryHandler)
	http.ListenAndServe(":8080", nil)
}

Di sisi klien, integrasi selesai tanpa bundler, tanpa React, dan tanpa boilerplate state manager:

<!DOCTYPE html>
<html lang="en">
<head>
    <script type="module" src="https://cdn.jsdelivr.net/npm/@starfederation/datastar"></script>
</head>
<body>
    <div data-on-load="@get('/stream/telemetry')">
        <div id="telemetry-display">Menunggu sinyal telemetri...</div>
    </div>
</body>
</html>

Matriks Evaluasi: Datastar vs WebSockets

KriteriaDatastar (SSE Hypermedia)WebSockets (Stateful Full-Duplex)
Overhead ProtokolRendah (HTTP/2 Multiplexing, standard headers)Sangat Rendah per frame, tetapi ada framing cost & handshake
Memory ServerRendah; di-handle via pool HTTP/2 streamTinggi; TCP buffer persisten per open socket
Infrastruktur JaringanKompatibel native dengan proxy, CDN, firewall biasaMemerlukan konfigurasi khusus proxy (Upgrade header, timeout bypass)
Reliabilitas KoneksiNative automatic reconnect & Last-Event-IDManual implementasi via application code
Kompleksitas FrontendNol boilerplate; reaktif langsung ke DOMTinggi; perlu parser JSON, DOM mutator, state tracker
Arah KomunikasiUnidirectional (Server to Client)Bidirectional (Duplex)

Trade-off dan Limitasi Datastar

Meskipun Datastar memangkas beban arsitektur frontend secara drastis, pendekatan ini memiliki trade-off yang harus diantisipasi:

  • Throughput Payload: Datastar mengirimkan fragment HTML (atau JSON signals) yang ukurannya sedikit lebih besar dibanding data biner WebSocket (seperti Protocol Buffers atau raw ArrayBuffer). Untuk throughput ekstrem di atas 120 Hz, overhead teks HTML mulai berdampak pada bandwidth egress.
  • Beban CPU Render Server: Templating HTML dilakukan di CPU server. Jika server melayani puluhan ribu update per detik, string formatting dan HTML interpolation menambah utilisasi core CPU server dibandingkan sekadar menyalurkan binary array via WebSocket.

Rekomendasi Teknis Berbasis Beban I/O

Pilih Datastar (SSE) jika:

  1. Arsitektur didominasi transmisi searah (telemetri, monitoring metrik, event sensor, log streams).
  2. Tim ingin mengeliminasi kompleksitas frontend framework (React/Vue), client-side state store, dan dependensi npm.
  3. Infrastruktur berjalan di atas HTTP/2 atau HTTP/3 dengan reverse proxy standar.
  4. Frekuensi update berada pada rentang 1 Hz hingga 60 Hz.

Pilih WebSockets jika:

  1. Aplikasi membutuhkan komunikasi dua arah frekuensi tinggi simultan dengan latensi sub-milidetik (misalnya kontrol input joystick teleoperasi rover).
  2. Payload wajib dikompresi ke level biner (Protobuf/FlatBuffers) untuk menghemat bandwidth telekomunikasi terbatas.
  3. Klien menuntut peer-to-peer signalling atau integrasi non-browser native socket.