साधारण HTTP को सट्टा तपाईं कहिले WebSockets, SSE, वा long-polling प्रयोग गर्नुहुन्छ?

Question

IT Interview Practice · Accepted Answer

साधारण HTTP **request/response** हो: client सोध्छ, server जवाफ दिन्छ, सकियो। यो **real-time** सुविधा (chat, लाइभ dashboard, notification, collaborative editing) का लागि नमिल्दो हो, जहाँ *server* लाई नयाँ केही हुनासाथ डेटा push गर्नुपर्छ। विकल्पहरू HTTP को client-सुरु मोडेल वरिपरि जाने तरिका हुन्, जटिलताको एउटा स्पेक्ट्रममा:

```text
Long-polling   client ──req──▶ server ...holds... ──resp──▶ then immediately re-asks
               (near-real-time over plain HTTP; one message per held request)

SSE            client ──req──▶ server ═══stream of events═══▶ (one-way, server→client)
               (HTTP-based, text, auto-reconnect; NO client→server on same channel)

WebSocket      client ──handshake──▶ server ══full-duplex, both directions══▶
               (persistent TCP; low overhead; binary or text; you build the rest)
```

**Long-polling** जताततै काम गर्ने fallback हो: client ले एउटा सामान्य request गर्छ जुन server ले डेटा नआएसम्म खुला राख्छ, अनि client ले तुरुन्तै फेरि request गर्छ। यसले साधारण HTTP मा push को नक्कल गर्छ तर प्रति message एउटा request चक्र खेर फाल्छ र latency थप्छ।

**SSE (Server-Sent Events)** एउटै लामो-जीवित HTTP response मा एउटा हल्का, मानकीकृत **एक-मार्गी** stream (server → client) हो। जब server ले मात्र push गर्छ यो आदर्श हुन्छ — लाइभ feed, notification, प्रगति, streaming LLM token। यो सरल छ, सामान्य HTTP/2 मा चल्छ (कुनै विशेष infrastructure छैन), र auto-reconnect गर्छ। सीमा: यो एक-मार्गी र text-मात्र हो।

**WebSockets** ले एउटै HTTP connection लाई एउटा टिकाउ, **full-duplex** TCP channel मा upgrade गर्छ जहाँ दुवै पक्षले न्यूनतम per-message overhead सहित जुनसुकै बेला पठाउँछन्। यसलाई साँच्चै द्विदिशात्मक, कम-latency अन्तरक्रियाका लागि प्रयोग गर्नुहोस्: chat, multiplayer game, collaborative editor, trading। मूल्य operational हो — यो एउटा stateful connection हो जसका लागि proxy, load balancer, र autoscaler configure गर्नुपर्छ, र तपाईंले reconnection, heartbeat, र backpressure आफैं बनाउनुपर्छ।

**अनुभवको नियम:** default मा साधारण HTTP प्रयोग गर्नुहोस्; server→client streaming का लागि **SSE** प्रयोग गर्नुहोस्; साँच्चै द्विदिशात्मक real-time चाहिँदा मात्र **WebSockets** तिर जानुहोस्; **long-polling** लाई विश्वव्यापी fallback का रूपमा राख्नुहोस्।

## यो किन महत्त्वपूर्ण छ

Real-time transport छान्नु एउटा उत्कृष्ट senior design निर्णय हो जहाँ सरल जवाफ ("सबैका लागि बस WebSockets प्रयोग गर") प्रायः गलत हुन्छ। Interviewer ले तपाईं उपकरणलाई *सञ्चार ढाँचा* सँग मिलाउनुहुन्छ कि — एक-मार्गी बनाम द्विदिशात्मक, latency आवश्यकता, message मात्रा — र stateful, लामो-जीवित connection को **operational लागत** तौलनुहुन्छ कि भनी हेर्न चाहन्छन्: sticky session, scaling, proxy timeout, र reconnection logic। SSE ले प्रायः "server ले update push गर्छ" लाई WebSockets भन्दा सरल तरिकाले पूरा गर्छ, र long-polling अझै एउटा बलियो fallback रहन्छ भनी चिन्नाले सबैभन्दा चम्किलो विकल्प तिर हात बढाउनुको सट्टा वास्तविक production अनुभव संकेत गर्छ।

यो किन महत्त्वपूर्ण छ

सम्बन्धित प्रश्नहरू