SSE — ano ito, Server-Sent Events at one-way streaming

Ano ang SSE?

SSE (Server-Sent Events) — teknolohiya na nagpapahintulot sa web server na magpadala ng data sa client anumang oras pagkatapos maitatag ang koneksyon. Ito ay na-standardize ng WHATWG bilang bahagi ng HTML Living Standard at gumagamit ng MIME type na text/event-stream. Sinusuportahan ng SSE ang pagpapadala ng text data na may kakayahang tukuyin ang identifier ng mensahe, uri ng kaganapan at pagkaantala ng muling pagkonekta.

Hindi tulad ng WebSocket, na nangangailangan ng two-way protocol at upgrade request, gumagana ang SSE sa ordinaryong HTTP. Itinatakda ng server ang header na Content-Type: text/event-stream, nagpapadala ng data sa mga bahagi at pinananatiling bukas ang koneksyon. Natatanggap ng client ang data sa pamamagitan ng EventSource API ng browser, na awtomatikong nagpa-parse ng stream at bumubuo ng mga kaganapan.

Ayon sa datos ng CanIUse (2025), ang EventSource API ay sinusuportahan sa 97.5% ng mga browser sa buong mundo. Hindi ito sinusuportahan sa Internet Explorer at ilang mobile browser (Samsung Internet hanggang bersyon 7.0). Para sa mga kasong ito mayroong mga polyfill na ginagaya ang EventSource sa pamamagitan ng XHR streaming. Hindi gumagana ang SSE sa HTTP/1.1 pipelining, ngunit ganap na katugma sa HTTP/2 server push.

Kasaysayan at standardisasyon

SSE ay iminungkahi bilang bahagi ng HTML5 na spesipikasyon noong 2009 sa ilalim ng pangalang Server-Sent DOM Events. Ang unang implementasyon ay lumitaw sa Opera 9.0, pagkatapos sa Firefox 6.0 (2011), Chrome 9.0 (2011) at Safari 5.0 (2010). Noong 2015, ang spesipikasyon ay inihiwalay sa isang hiwalay na seksyon ng HTML Living Standard. Sa kabila ng isang dekadang kasaysayan, ang SSE ay nananatiling hindi gaanong popular kaysa sa WebSocket dahil sa one-way na kalikasan nito.

Paano gumagana ang SSE

Mekanismo ng paggana ng SSE ay ang mga sumusunod: ang client ay lumilikha ng instance ng EventSource na may URL ng server endpoint. Ang browser ay nagpapadala ng GET request na may header na Accept: text/event-stream. Ang server ay tumutugon ng status 200 OK at header na Content-Type: text/event-stream, pagkatapos ay nagsimulang magpadala ng data sa format na event-stream. Ang koneksyon ay nananatiling bukas hanggang sa magpadala ang server ng terminate signal o tumawag ang client ng close().

Sa panig ng server, ang data ay ipinapadala sa mga bahagi (chunked transfer encoding). Ang bawat bloke ng data ay isang text message na binubuo ng mga linya ng field (event, data, id, retry). Ang server ay maaaring magpadala ng mga mensahe anumang oras, na ginagawang perpekto ang SSE para sa mga notification at update ng status. Ang koneksyon ay hindi nangangailangan ng patuloy na pagpapalitan ng heartbeat packets (tulad ng WebSocket), bagaman ang field na retry ay kumokontrol sa dalas ng muling pagkonekta.

Ayon sa datos ng mga pagsubok sa pagganap (2024), ang SSE ay nagbibigay ng throughput na hanggang 10,000 mensahe bawat segundo bawat koneksyon sa laki ng mensahe na 256 bytes. Sa panig ng server, bawat SSE connection ay kumokonsumo ng humigit-kumulang 5–10 KB ng memory, na nagpapahintulot sa isang server na suportahan ang 50,000+ sabay-sabay na koneksyon na may 1 GB RAM. Ito ay makabuluhang mas mababa kaysa sa WebSocket dahil sa kawalan ng binary protocol.

Format ng event-stream

Format ng text/event-stream — isang simpleng text protocol kung saan ang bawat mensahe ay binubuo ng mga pinangalanang field na pinaghihiwalay ng mga bagong line character. Ang bawat field ay may format na “PangalanField: halaga”. Ang mga mensahe ay pinaghihiwalay ng dalawang bagong line character ( ).

Mga sinusuportahang field: event (uri ng kaganapan, default ay message), data (string ng data, maaaring multi-line), id (huling identifier ng kaganapan, iniimbak sa Last-Event-ID), retry (oras ng muling pagkonekta sa millisecond). Ang mga komento ay nagsisimula sa tutuldok (:) at binabalewala ng parser, ngunit maaaring gamitin para sa heartbeat.

Halimbawa ng daloy ng event-stream

: heartbeat comment
event: update
data: {"user": "Alice", "action": "typing"}
id: 1001

event: notification
data: {"type": "info", "text": "New version available"}
data: {"type": "action", "url": "/upgrade"}
retry: 3000

event: close
data: Session ended

EventSource API sa panig ng client

EventSource API — ang built-in na interface ng browser para sa pagtanggap ng SSE. Upang lumikha ng koneksyon, sapat na na tawagan ang constructor na may URL ng endpoint. Awtomatikong nagtatatag ang EventSource ng koneksyon, humahawak ng muling pagkonekta at nagpa-parse ng mga papasok na mensahe sa mga kaganapan ng JavaScript.

Mga kaganapan ng EventSource: open (nakatatag ang koneksyon), message (natanggap ang mensahe nang walang tinukoy na event), error (error sa koneksyon). Para sa mga custom na kaganapan (event: custom) maaaring gumamit ng addEventListener na may pangalan ng kaganapan. Awtomatikong nagpapadala ang EventSource ng header na Last-Event-ID sa muling pagkonekta, na nagpapahintulot sa server na ipagpatuloy ang stream mula sa naputol na punto.

Ayon sa dokumentasyon ng MDN (2025), sinusuportahan ng EventSource ang CORS at pagpapadala ng credentials (withCredentials). Para sa pagpapadala ng custom headers o body ng request, hindi angkop ang EventSource — kinakailangan ang manual na implementasyon sa pamamagitan ng fetch + ReadableStream. Hindi sinusuportahan ng EventSource ang binary data — tanging text at JSON lamang.

Client-side JavaScript code

const eventSource = new EventSource('/api/events/stream');

eventSource.addEventListener('open', () => {
    console.log('Binuksan ang SSE connection');
});

eventSource.addEventListener('message', (event) => {
    const data = JSON.parse(event.data);
    console.log('Natanggap:', data);
    renderUpdate(data);
});

eventSource.addEventListener('notification', (event) => {
    const notification = JSON.parse(event.data);
    showNotification(notification.text);
});

eventSource.addEventListener('error', (error) => {
    console.error('Error sa SSE:', error);
    // Awtomatikong muling pagkonekta ng browser
});

// Isara ang koneksyon
eventSource.close();

SSE vs WebSocket: paghahambing

SSE at WebSocket — magkaibang teknolohiya para sa real-time na komunikasyon, bawat isa ay may kanya-kanyang lakas. Ang WebSocket ay angkop para sa two-way na pagpapalitan ng data (chat, laro, pag-edit nang magkakasama), ang SSE ay para sa one-way na daloy mula sa server patungo sa client (notification, news feed, ticker).

Pangunahing pagkakaiba — ang WebSocket ay nangangailangan ng upgrade request mula HTTP/1.1 patungo sa WebSocket protocol (ws://), na maaaring harangin ng corporate proxy. Gumagana ang SSE sa ordinaryong HTTP, dumadaan sa lahat ng proxy at hindi nangangailangan ng espesyal na configuration ng server. Ang SSE ay mas simple din sa implementasyon — ang server ay hindi nangangailangan ng karagdagang library, sapat na ang tamang pag-format ng HTTP response.

Ayon sa datos ng comparative testing (2024), sa isang server process, ang SSE ay sumusuporta ng 30–50% mas maraming koneksyon kaysa sa WebSocket dahil sa mas simpleng protocol. Gayunpaman, ang latency ng SSE ay mas mataas (50–200 ms kumpara sa 10–50 ms para sa WebSocket) dahil gumagamit ang SSE ng chunked HTTP, hindi isang ganap na two-way stream na may binary frames.

Paano ipatupad ang SSE sa server

Implementasyon ng SSE sa server ay hindi nangangailangan ng library — sapat na itakda ang tamang HTTP headers at magpadala ng data sa format na text/event-stream. Tingnan natin ang isang halimbawa sa Node.js gamit ang built-in na http module. Itinatakda ng server ang headers na Content-Type at Cache-Control, pagkatapos ay nagpapadala ng mga mensahe bawat N segundo.

Ayon sa MDN Web Docs (2025), ang mga mandatoryong header para sa SSE ay: Content-Type: text/event-stream, Cache-Control: no-cache at Connection: keep-alive. Kung walang Cache-Control, maaaring i-cache ng browser ang SSE stream, na magreresulta sa pagtigil ng paghahatid. Ang Connection: keep-alive ay malinaw na nagpapahiwatig sa browser na panatilihing bukas ang koneksyon.

Server code sa Node.js

const http = require('http');

http.createServer((req, res) => {
    res.writeHead(200, {
        'Content-Type': 'text/event-stream',
        'Cache-Control': 'no-cache',
        'Connection': 'keep-alive'
    });

    let eventId = 0;
    const interval = setInterval(() => {
        eventId++;
        res.write(`id: ${eventId}\n`);
        res.write(`event: update\n`);
        res.write(`data: {"oras": "${new Date().toISOString()}", "id":${eventId}}\n\n`);
    }, 2000);

    req.on('close', () => {
        clearInterval(interval);
    });
}).listen(3000);

SSE sa Python (Flask)

from flask import Response, Flask
import time
import json

app = Flask(__name__)

@app.route('/stream')
def stream():
    def generate():
        event_id = 0
        while True:
            event_id += 1
            data = json.dumps(
                {'ticker': 'AAPL', 'price': 150.25})
            yield f'id: {event_id}\nevent: price\ndata: {data}\n\n'
            time.sleep(1)
    return Response(generate(),
        mimetype='text/event-stream')

SSE sa mga mobile app

Paggamit ng SSE sa mga mobile app ay limitado dahil sa kawalan ng native na implementasyon ng EventSource para sa iOS at Android. Sa mga mobile platform, ang SSE ay ipinapatupad sa pamamagitan ng third-party na mga library: sa iOS — sa pamamagitan ng URLSession na may NSURLProtocol, sa Android — sa pamamagitan ng OkHttp na may suporta sa SSE (okhttp-sse). Para sa React Native at Flutter, may mga available na package na ginagaya ang EventSource.

Sa iOS ang native na implementasyon ng SSE ay posible sa pamamagitan ng URLSessionDataDelegate. Kapag tumatanggap ng data sa paraang urlSession(_:dataTask:didReceive:), ang app ay nag-iipon ng buffer at manu-manong nagpa-parse ng event-stream format. Ayon sa blog ng iOS development (2024), ang konsumo ng baterya sa SSE sa iOS ay 40% na mas mababa kaysa sa pare-parehong WebSocket connection, dahil sa kawalan ng heartbeat packets.

Sa Android ang OkHttp ay nagbibigay ng klase na EventSource.Factory para sa pag-subscribe sa SSE streams. Ang mga Android app ay maaaring gumamit ng SSE para sa mga notification kapag hindi available ang FCM o para sa pag-synchronize ng data sa background. Ang SSE sa Android ay gumagana nang maayos sa WorkManager para sa mga pangmatagalang background task. Ayon sa dokumentasyon ng OkHttp (2025), ang okhttp-sse ay sumusuporta sa awtomatikong muling pagkonekta na may custom listener.