તમે plain HTTP ને બદલે WebSockets, SSE, કે long-polling ક્યારે વાપરશો?

Question

IT Interview Practice · Accepted Answer

Plain HTTP એ **request/response** છે: client પૂછે છે, server જવાબ આપે છે, પૂરું. તે **real-time** features (chat, live dashboards, notifications, collaborative editing) માટે ખરાબ બંધ બેસે છે જ્યાં *server* ને જ્યારે પણ કંઈક નવું હોય ત્યારે data push કરવાની જરૂર હોય. વિકલ્પો એ HTTP ના client-initiated મોડલની આસપાસ જવાની રીતો છે, complexity ના spectrum સાથે:

```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 data ન હોય ત્યાં સુધી ખુલ્લો રાખે છે, પછી client તરત ફરી request કરે છે. તે plain HTTP પર push નું અનુમાન કરે છે પણ message દીઠ એક request cycle વેડફે છે અને latency ઉમેરે છે.

**SSE (Server-Sent Events)** એ એક હલકો, standardized **એક-માર્ગી** stream (server → client) છે જે એક જ લાંબા-જીવંત HTTP response પર ચાલે છે. જ્યારે માત્ર server push કરે ત્યારે તે આદર્શ છે — live feeds, notifications, progress, streaming LLM tokens. તે સરળ છે, સામાન્ય HTTP/2 પર ચાલે છે (કોઈ ખાસ infrastructure નહીં), અને auto-reconnects. મર્યાદા: તે એક-દિશાત્મક અને માત્ર-text છે.

**WebSockets** એક જ HTTP connection ને એક persistent, **full-duplex** TCP channel માં upgrade કરે છે જ્યાં બંને બાજુ ન્યૂનતમ per-message overhead સાથે ગમે ત્યારે મોકલે છે. તેને ખરેખર bidirectional, low-latency interaction માટે વાપરો: chat, multiplayer games, collaborative editors, trading. કિંમત operational છે — તે એક stateful connection છે જેના માટે proxies, load balancers, અને autoscalers ને configure કરવા પડે, અને તમારે reconnection, heartbeats, અને backpressure પોતે બનાવવા પડે.

**અંગૂઠાનો નિયમ:** default માં plain HTTP વાપરો; server→client streaming માટે **SSE** વાપરો; **WebSockets** તરફ ત્યારે જ પહોંચો જ્યારે તમને ખરેખર bidirectional real-time જોઈએ; **long-polling** ને સાર્વત્રિક fallback તરીકે રાખો.

## આ શા માટે મહત્વનું છે

Real-time transport પસંદ કરવો એ એક ક્લાસિક senior ડિઝાઇન નિર્ણય છે જ્યાં નિષ્કપટ જવાબ ("દરેક વસ્તુ માટે માત્ર WebSockets વાપરો") સામાન્ય રીતે ખોટો છે. Interviewers જોવા માંગે છે કે તમે સાધનને *communication pattern* સાથે મેળવો છો — એક-માર્ગી vs bidirectional, latency જરૂરિયાતો, message volume — અને કે તમે stateful, લાંબા-જીવંત connections ના **operational ખર્ચ** ને તોળો છો: sticky sessions, scaling, proxy timeouts, અને reconnection logic. એ ઓળખવું કે SSE ઘણી વાર "server updates push કરે છે" ને WebSockets કરતાં વધુ સરળ રીતે આવરી લે છે, અને કે long-polling એક મજબૂત fallback રહે છે, એ સૌથી ચમકદાર વિકલ્પ તરફ પહોંચવાને બદલે વાસ્તવિક production અનુભવ સૂચવે છે.

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો