ਇੱਕ ਲੋਡਿੰਗ ਸਪਿਨਰ ਤੁਹਾਨੂੰ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ। ਜਦੋਂ ਕੋਈ AI ਟਾਸਕ ਕਈ ਮਿੰਟਾਂ ਤੱਕ ਚੱਲਦਾ ਹੈ—ਜਾਂ ਤੀਜੀ ਵਾਰ ਕੋਸ਼ (queue) ਵਿੱਚ ਵਾਪਸ ਆਉਂਦਾ ਹੈ—ਤਾਂ ਤੁਹਾਨੂੰ ਸਟੇਟ (state) ਦੇਖਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। Server-Sent Events ਤੁਹਾਨੂੰ WebSockets ਦੇ ਹੈਂਡਸ਼ੇਕ ਓਵਰਹੈੱਡ ਜਾਂ long polling ਦੀ ਕੋਰੀਓਗ੍ਰਾਫੀ ਤੋਂ ਬਿਨਾਂ ਉਹ ਵਿਜ਼ੀਬਿਲਟੀ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਸਰਵਰ ਇੱਕ ਸਿੰਗਲ HTTP ਰਿਸਪਾਂਸ ਨੂੰ ਖੁੱਲ੍ਹਾ ਰੱਖਦਾ ਹੈ ਅਤੇ ਜਿਵੇਂ-ਜਿਵੇਂ ਚੀਜ਼ਾਂ ਬਦਲਦੀਆਂ ਹਨ, ਪਲੇਨ-ਟੈਕਸਟ ਅਪਡੇਟਸ ਪੁਸ਼ ਕਰਦਾ ਹੈ। ਕਲਾਇੰਟ ਉਹਨਾਂ ਨੂੰ ਆਉਂਦੇ ਹੀ ਪੜ੍ਹ ਲੈਂਦਾ ਹੈ।
ਜੇਕਰ ਕਨੈਕਸ਼ਨ ਟੁੱਟ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸ਼ਾਇਦ ਤੁਸੀਂ ਸ਼ੁਰੂ ਤੋਂ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਨਾ ਚਾਹੋਗੇ। ਇੱਕ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਬਣਾਈ ਗਈ SSE ਸਟ੍ਰੀਮ ਯਾਦ ਰੱਖਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿੱਥੇ ਸੀ। ਸਿਰਫ਼ Node.js 20 ਅਤੇ ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਤੁਸੀਂ ਇਸ ਨੂੰ ਸੈੱਟ ਕਰ ਸਕਦੇ ਹੋ। ਕਿਸੇ ਬਾਹਰੀ ਪੈਕੇਜ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।
ਵਾਇਰ ਫਾਰਮੈਟ (wire format) ਕਿਹੋ ਜਿਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ
ਇੱਕ SSE ਮੈਸੇਜ ਸਧਾਰਨ ਟੈਕਸਟ ਹੁੰਦਾ ਹੈ। ਸਰਵਰ ਤਿੰਨ ਚੀਜ਼ਾਂ ਲਿਖਦਾ ਹੈ: ਇੱਕ ਵਿਕਲਪਿਕ event name, ਇੱਕ ਲੋੜੀਂਦਾ data ਫੀਲਡ, ਅਤੇ ਇੱਕ id ਫੀਲਡ ਜੋ ਤੁਹਾਡਾ ਸੇਵ ਪੁਆਇੰਟ ਬਣ ਜਾਂਦਾ ਹੈ। ਹਰ ਰਿਕਾਰਡ ਦੋ ਨਿਊਲਾਈਨ ਕੈਰੇਕਟਰਸ (newline characters) ਨਾਲ ਖਤਮ ਹੁੰਦਾ ਹੈ—ਇੱਕ ਖਾਲੀ ਲਾਈਨ ਜੋ ਸੀਮਾ (boundary) ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ।
ਇੱਕ ਸਿਹਤਮੰਦ ਸਟ੍ਰੀਮ ਵਾਇਰ 'ਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇ ਸਕਦੀ ਹੈ:
id: 14
event: status
data: {"phase":"testing","progress":43}
id: 15
event: status
data: {"phase":"retrying","attempt":2}
ਬ੍ਰਾਊਜ਼ਰ ਦਾ EventSource ਕਲਾਇੰਟ ਇਹਨਾਂ ਲਾਈਨਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਪੜ੍ਹ ਲੈਂਦਾ ਹੈ। ਇਹ ਹਰੇਕ ਬਲਾਕ ਲਈ ਇੱਕ ਇਵੈਂਟ (event) ਜਾਰੀ ਕਰਦਾ ਹੈ ਅਤੇ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਨਵੇਂ id ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਜੇਕਰ TCP ਕਨੈਕਸ਼ਨ ਟੁੱਟ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕਲਾਇੰਟ ਉਡੀਕ ਕਰਦਾ ਹੈ, ਦੁਬਾਰਾ ਕਨੈਕਟ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਸਟੋਰ ਕੀਤੇ ਹੋਏ ਆਈਡੀ (identifier) ਨੂੰ Last-Event-ID ਹੈਡਰ ਵਜੋਂ ਸਰਵਰ ਨੂੰ ਵਾਪਸ ਭੇਜਦਾ ਹੈ। ਇਹ ਹੈਡਰ ਹੀ ਉਹ ਮੁੱਖ ਕਾਰਨ ਹੈ ਜਿਸ ਕਰਕੇ ਇਹ ਪੈਟਰਨ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਸ ਤੋਂ ਬਿਨਾਂ, ਤੁਹਾਡੇ ਕੋਲ ਕੋਈ ਡਿਊਰੇਬਲ ਕਰਸਰ (durable cursor) ਨਹੀਂ ਹੋਵੇਗਾ।
Node.js ਵਿੱਚ ਸਰਵਰ ਨੂੰ ਵਾਇਰ ਕਰਨਾ
Node ਦਾ ਬਿਲਟ-ਇਨ http ਮੋਡਿਊਲ ਇਸ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸੰਭਾਲ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਰਿਕਵੈਸਟ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਸਹੀ ਹੈਡਰਜ਼ ਸੈੱਟ ਕਰੋ ਤਾਂ ਜੋ ਕਲਾਇੰਟ ਨੂੰ ਪਤਾ ਲੱਗ ਸਕੇ ਕਿ ਇਹ ਇੱਕ ਸਟ੍ਰੀਮ ਹੈ, ਕੋਈ ਪੇਜ ਨਹੀਂ:
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive
ਬਫਰਿੰਗ (buffering) ਨੂੰ ਹਟਾ ਦਿਓ। ਪ੍ਰੌਕਸੀਆਂ (Proxies) ਅਤੇ ਫਰੇਮਵਰਕਸ ਕਦੇ-ਕਦੇ ਰਿਸਪਾਂਸ ਨੂੰ ਬੈਚ ਵਿੱਚ ਭੇਜਦੇ ਹਨ, ਜੋ ਰੀਅਲ-ਟਾਈਮ ਅਹਿਸਾਸ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਹਰ ਚੰਕ (chunk) ਤੋਂ ਬਾਅਦ ਫਲਸ਼ (flush) ਕਰੋ।
ਪਹਿਲਾਂ ID ਭੇਜੋ, ਫਿਰ event type, ਫਿਰ payload data, ਅਤੇ ਫਿਰ ਖਤਮ ਕਰਨ ਵਾਲੀ ਖਾਲੀ ਲਾਈਨ। ਆਰਡਰ ਸਿਰਫ਼ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ID ਖਾਲੀ ਲਾਈਨ ਤੋਂ ਪਹਿਲਾਂ ਪਹੁੰਚਣੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਜੋ ਕਲਾਇੰਟ ਇਸਨੂੰ ਕੈਪਚਰ ਕਰ ਸਕੇ। ਜੇਕਰ ਤੁਸੀਂ ਨੇਟਿਵ response.write() ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਆਉਟਪੁੱਟ ਬਿਲਕੁਲ ਇਹ ਹੋਵੇਗੀ:
response.write(`id: ${cursor}\n`);
response.write(`event: ${eventName}\n`);
response.write(`data: ${JSON.stringify(payload)}\n\n`);
ਉਹ ਅਖੀਰਲੀ \n\n ਸਿਰਫ਼ ਸਜਾਵਟ ਲਈ ਨਹੀਂ ਹੈ। SSE ਪਾਰਸਰਜ਼ ਇਸਨੂੰ ਰਿਕਾਰਡ ਟਰਮੀਨੇਟਰ (record terminator) ਵਜੋਂ ਮੰਨਦੇ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ ਮਿਸ ਕਰਦੇ ਹੋ, ਤਾਂ ਕਲਾਇੰਟ ਹੋਰ ਡੇਟਾ ਦੀ ਉਡੀਕ ਵਿੱਚ ਅਟਕ ਜਾਵੇਗਾ।
ਕਰਸਰ ਹੀ ਸਭ ਕੁਝ ਹੈ
ਇੱਕ ਨਵਾਂ HTTP ਕਨੈਕਸ਼ਨ ਨਵੀਂ ਸਟੇਟ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ। ਜਦੋਂ ਕੋਈ ਕਲਾਇੰਟ ਦੁਬਾਰਾ ਕਨੈਕਟ ਹੁੰਦਾ ਹੈ, ਤਾਂ Last-Event-ID ਹੈਡਰ ਤੁਹਾਨੂੰ ਉਹ ਆਖਰੀ ਮੈਸੇਜ ਦੱਸਦਾ ਹੈ ਜੋ ਉਹਨਾਂ ਨੇ ਪ੍ਰਾਪਤ ਕੀਤਾ ਸੀ। ਤੁਹਾਡਾ ਕੰਮ ਅਗਲੇ ਮੈਸੇਜ ਤੋਂ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ, ਨਾ ਕਿ ਸ਼ੁਰੂ ਤੋਂ।
ਇਸਦਾ ਮਤਲਬ ਹੈ ਸਰਵਰ-ਸਾਈਡ 'ਤੇ ਇਵੈਂਟਸ ਦਾ ਇੱਕ ਕ੍ਰਮਵਾਰ ਲੌਗ (ordered log) ਜਾਂ ਜਰਨਲ ਬਣਾਈ ਰੱਖਣਾ। ਇੱਕ ਡੈਮੋ ਲਈ ਇਨ-ਮੈਮੋਰੀ ਐਰੇ (in-memory array) ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ। ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਤੁਸੀਂ ਕੁਝ ਡਿਊਰੇਬਲ ਚਾਹੁੰਦੇ ਹੋ—ਜਿਵੇਂ ਕਿ ਡੇਟਾਬੇਸ ਲੌਗ, Redis ਸਟ੍ਰੀਮ, ਜਾਂ write-ahead journal ਵਿੱਚ ਡੇਟਾ ਜੋੜਨਾ—ਕਿਉਂਕਿ ਸਰਵਰ ਰੀਸਟਾਰਟ ਹੋਣ ਨਾਲ ਇਤਿਹਾਸ ਮਿਟਣਾ ਨਹੀਂ ਚਾਹੀਦਾ ਅਤੇ ਹਰ ਕਲਾਇੰਟ ਨੂੰ ਜ਼ੀਰੋ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ।
ਆਪਣੇ ਇਵੈਂਟਸ ਨੂੰ ਇੱਕ ਮੋਨੋਟੋਨਿਕਲੀ ਵਧਣ ਵਾਲੇ ਇੰਟੀਜਰ (monotonically increasing integer) ਜਾਂ ULID ਦੁਆਰਾ ਇੰਡੈਕਸ ਕਰੋ। ਜਦੋਂ ਰੀਕਨੈਕਟ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਉਹਨ ਇਵੈਂਟਸ ਲਈ ਕੁਐਰੀ ਕਰੋ ਜਿੱਥੇ id > lastEventId ਹੋਵੇ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕ੍ਰਮ ਅਨੁਸਾਰ ਦੁਬਾਰਾ ਚਲਾਓ (replay)। ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਸੈਂਕੜੇ ਬੈਕਲੌਗ ਮੈਸੇਜ ਹਨ, ਤਾਂ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਆਰਟੀਫੀਸ਼ੀਅਲ ਡਿਲੇ ਜਾਂ ਬੈਚ ਸ਼ਾਮਲ ਕਰੋ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਪੁਰਾਣੇ ਤੋਂ ਨਵੇਂ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਭੇਜੋ ਤਾਂ ਜੋ ਕਲਾਇੰਟ ਕ੍ਰੋਨੋਲੋਜੀਕਲ ਤੌਰ 'ਤੇ ਸਟੇਟ ਨੂੰ ਮੁੜ ਬਣਾ ਸਕੇ।
ਡੁਪਲੀਕੇਟਸ ਦੀ ਉਮੀਦ ਰੱਖੋ
ਨੈੱਟਵਰਕ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਹੁੰਦੇ। ਸਰਵਰ ਇੱਕ ਇਵੈਂਟ ਭੇਜ ਸਕਦਾ ਹੈ, TCP ਐਕਨੌਲੇਜਮੈਂਟ ਗੁਆ ਸਕਦਾ ਹੈ, ਅਤੇ ਟਾਈਮਆਊਟ ਤੋਂ ਬਾਅਦ ਇਸਨੂੰ ਦੁਬਾਰਾ ਭੇਜ ਸਕਦਾ ਹੈ। ਸ਼ੁਰੂ ਤੋਂ ਹੀ at-least-once ਡਿਲੀਵਰੀ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ।
ਕਲਾਇੰਟ 'ਤੇ, ਡਿਡੂਪਲੀਕੇਸ਼ਨ (deduplication) ਸਸਤਾ ਹੈ। Event ID ਦੁਆਰਾ ਕੀਅਡ (keyed) ਇੱਕ Map ਰੱਖੋ। ਜਦੋਂ ਕੋਈ ਨਵਾਂ ਇਵੈਂਟ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਮੈਪ ਦੀ ਜਾਂਚ ਕਰੋ। ਜੇਕਰ ID ਮੌਜੂਦ ਹੈ, ਤਾਂ ਡੁਪਲੀਕੇਟ ਨੂੰ ਚੁੱਪਚਾਪ ਡ੍ਰੌਪ ਕਰ ਦਿਓ। ਕਿਉਂਕਿ ਤੁਹਾਡਾ ਸਰਵਰ ਡਿਟਰਮਨਿਸਟਿਕ IDs (deterministic IDs) ਅਸਾਈਨ ਕਰਦਾ ਹੈ, ਇਸ ਨਾਲ ਡੁਪਲੀਕੇਟ ਨੁਕਸਾਨਦੇਹ ਨਹੀਂ ਰਹਿੰਦੇ। ਮੈਪ ਨੂੰ ਹਮੇਸ਼ਾ ਵਧਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਪੁਸ਼ਟੀ ਕਰ ਲੈਂਦੇ ਹੋ ਕਿ ਇੱਕ ਇਵੈਂਟ ਸੁਰੱਖਿਅਤ ਰੂਪ ਵਿੱਚ ਪ੍ਰੋਸੈਸ ਹੋ ਗਿਆ ਹੈ, ਤਾਂ ਪੁਰਾਣੀਆਂ IDs ਨੂੰ ਹਟਾ ਦਿਓ। ਬ੍ਰਾਊਜ਼ਰ ਕਲਾਇੰਟਾਂ ਲਈ ਕੁਝ ਸੌ ਐਂਟਰੀਆਂ ਦੀ ਇੱਕ ਸਲਾਈਡਿੰਗ ਵਿੰਡੋ (sliding window) ਆਮ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਹੁੰਦੀ ਹੈ।
ਜਦੋਂ ਕਰਸਰ ਐਕਸਪਾਇਰ ਹੋ ਜਾਂਦਾ ਹੈ
ਅੰਤ ਵਿੱਚ, ਇੱਕ ਕਲਾਇੰਟ ਘੰਟਿਆਂ ਜਾਂ ਦਿਨਾਂ ਬਾਅਦ ਦੁਬਾਰਾ ਕਨੈਕਟ ਕਰੇਗਾ। ਜੇਕਰ ਤੁਹਾਡਾ ਹਿਸਟਰੀ ਬਫਰ ਸਿਰਫ਼ ਪਿਛਲੇ ਹਜ਼ਾਰ ਇਵੈਂਟਸ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਦੋ ਹਜ਼ਾਰ ਇਵੈਂਟਸ ਪਿੱਛੇ ਹੈ, ਤਾਂ ਗੈਪਸ ਨੂੰ ਰੀਪਲੇਅ ਕਰਨਾ ਅਸੰਭਵ ਹੈ।
ਅਧੂਰੀ ਹਿਸਟਰੀ ਸਟ੍ਰੀਮ ਨਾ ਕਰੋ। ਇਹ ਕਲਾਇੰਟ ਨੂੰ ਇੱਕ ਅਸੰਗਤ ਸਟੇਟ (inconsistent state) ਵਿੱਚ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਇਸ ਦੀ ਬਜਾਏ, ਇੱਕ ਐਕਸਪਾਇਰਡ ਕਰਸਰ ਦਾ ਪਤਾ ਲਗਾਓ ਅਤੇ ਅਗਲੇ ਇਵੈਂਟ ਵਜੋਂ ਇੱਕ ਫੁੱਲ ਸਨੈਪਸ਼ਾਟ (full snapshot) ਭੇਜੋ। ਸਨੈਪਸ਼ਾਟ ਵਿੱਚ ਇੱਕ ਨਵਾਂ ਕਰਸਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਕਲਾਇੰਟ ਨੂੰ ਮੌਜੂਦਾ ਸਟੇਟ ਨਾਲ ਜੋੜਦਾ ਹੈ। ਉੱਥੋਂ, ਲਾਈਵ ਡੈਲਟਾ (live deltas) ਆਮ ਤੌਰ 'ਤੇ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਹੋ ਜਾਣਗੇ। ਆਪਣੇ ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ ਇਸ ਸੀਮਾ ਨੂੰ ਸਪੱਸ਼ਟ ਰੂਪ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰੋ ਤਾਂ ਜੋ ਕਲਾਇੰਟ ਕੋਡ ਨੂੰ ਪਤਾ ਲੱਗ ਸਕੇ ਕਿ ਆਪਣੀ ਲੋਕਲ ਮਾਡਲ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ ਹੈ ਜਾਂ ਅੱਗੇ ਜੋੜਨਾ ਹੈ।
ਸਟ੍ਰੀਮ ਦੀ ਰੱਖਿਆ ਕਰੋ
ਖੁੱਲ੍ਹੇ SSE ਐਂਡਪੁਆਇੰਟਸ (endpoints) ਆਕਰਸ਼ਕ ਨਿਸ਼ਾਨੇ ਹਨ। ਕੋਈ ਵੀ ਕਨੈਕਸ਼ਨ ਬਣਾਈ ਰੱਖ ਸਕਦਾ ਹੈ, ਅਤੇ ਰੀਪਲੇਅ ਰਿਕਵੈਸਟਾਂ ਤੁਹਾਡੇ ਸਟੋਰੇਜ 'ਤੇ ਰੀਡ ਲੋਡ ਨੂੰ ਵਧਾ ਸਕਦੀਆਂ ਹਨ।
ਐਂਡਪੁਆਇੰਟ ਨੂੰ ਸਹੀ ਅਧਿਕਾਰ (authorization) ਨਾਲ ਸੁਰੱਖਿਅਤ ਕਰੋ। ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ EventSource ਕਸਟਮ ਹੈਡਰਾਂ (custom headers) ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਟੋਕਨ ਨੂੰ ਕੁਐਰੀ ਸਟ੍ਰਿੰਗ (query string) ਵਿੱਚ pass ਕਰੋ ਜਾਂ ਸਖ਼ਤ SameSite ਨੀਤੀਆਂ ਵਾਲੇ ਕੁਕੀਜ਼ (cookies) ਦੀ ਵਰਤੋਂ ਕਰੋ। ਸਟ੍ਰੀਮ ਸਰੋਤਾਂ (stream resources) ਨੂੰ ਅਲਾਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਟੋਕਨ ਦੀ ਪੁਸ਼ਟੀ (validate) ਕਰੋ।
ਹਿਸਟਰੀ ਦੀਆਂ ਸੀਮਾਵਾਂ ਅਤੇ ਪ੍ਰਤੀ-ਵਰਤੋਂਕਾਰ ਕੋਟਾ (per-user quotas) ਸੈੱਟ ਕਰੋ। ਪ੍ਰਤੀ ਟਾਸਕ ਸਟੋਰ ਕੀਤੇ ਗਏ ਈਵੈਂਟਸ (events) ਦੀ ਗਿਣਤੀ ਨੂੰ ਸੀਮਤ ਕਰੋ, ਅਤੇ ਪ੍ਰਤੀ ਕਲਾਇੰਟ ਇਕੱਠੇ ਹੋਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨਾਂ (concurrent connections) ਦੀ ਗਿਣਤੀ ਨੂੰ ਵੀ ਸੀਮਤ ਕਰੋ। ਡਿਸਕਨੈਕਟਸ (disconnects) ਅਤੇ ਰੀਪਲੇਅਜ਼ (replays) ਨੂੰ ਲੌਗ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਕਿਸੇ ਅਜਿਹੇ ਸ਼ਰਾਰਤੀ ਕਲਾਇੰਟ (rogue client) ਦੀ ਪਛਾਣ ਕਰ ਸਕੋ ਜੋ ਤੁਹਾਡੇ ਕਰਸਰ ਐਂਡਪੁਆਇੰਟ (cursor endpoint) 'ਤੇ ਲਗਾਤਾਰ ਹਮਲਾ ਕਰ ਰਿਹਾ ਹੋਵੇ।
ਇਹ ਪੈਟਰਨ ਹਰ ਜਗ੍ਹਾ ਲਾਗੂ ਹੁੰਦਾ ਹੈ
ਇਹ ਪਹੁੰਚ ਸਿਰਫ਼ HTTP ਤੱਕ ਸੀਮਤ ਨਹੀਂ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ WebSockets, ਮੈਸੇਜ ਕਿਊਜ਼ (message queues), ਜਾਂ ਏਜੰਟ-ਟੂ-ਏਜੰਟ ਇੰਟਰਫੇਸਾਂ (agent-to-agent interfaces) ਵੱਲ ਵਧਦੇ ਹੋ, ਤਾਂ ਉਹੀ ਨਿਯਮ ਲਾਗੂ ਹੁੰਦੇ ਹਨ। ਟ੍ਰਾਂਸਪੋਰਟ ਬਦਲ ਜਾਂਦਾ ਹੈ—ਤੁਸੀਂ ਬਾਈਨਰੀ ਫਰੇਮਾਂ (binary frames) ਜਾਂ ਟੌਪਿਕ ਸਬਸਕ੍ਰਿਪਸ਼ਨਾਂ (topic subscriptions) ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ—ਪਰ ਮੂਲ ਸਮੱਸਿਆ ਉਹੀ ਰਹਿੰਦੀ ਹੈ। ਤੁਹਾਨੂੰ ਇੱਕ ਕਰਸਰ (cursor), ਇੱਕ ਟਿਕਾਊ ਲੌਗ (durable log), at-least-once semantics, ਕਲਾਇੰਟ ਡਿਡੂਪਲੀਕੇਸ਼ਨ (client deduplication), ਅਤੇ ਜਦੋਂ ਕਰਸਰ ਪੁਰਾਣਾ (stale) ਹੋ ਜਾਵੇ ਤਾਂ ਫੁੱਲ ਸਨੈਪਸ਼ਾਟ (full snapshots) 'ਤੇ ਵਾਪਸੀ (fallback) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਸਟੇਟ ਕਨਵਰਜੈਂਸ (state convergence) ਨੂੰ ਇੱਕ ਵਾਰ ਹੱਲ ਕਰੋ, ਅਤੇ ਤੁਸੀਂ ਕੋਰ ਲੌਜਿਕ ਨੂੰ ਦੁਬਾਰਾ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਬਿਨਾਂ ਇਸਨੂੰ TCP, WebSocket, ਜਾਂ RabbitMQ ਵਰਗੇ ਬ੍ਰੋਕਰ 'ਤੇ ਭੇਜ ਸਕਦੇ ਹੋ।
ਇਸਨੂੰ ਸਰਲ ਰੱਖੋ
Server-Sent Events ਇਸ ਲਈ ਕੰਮ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਆਮ HTTP 'ਤੇ ਚੱਲਦੇ ਹਨ। ਪ੍ਰੌਕਸੀਆਂ (Proxies) ਉਹਨਾਂ ਨੂੰ ਸਮਝਦੀਆਂ ਹਨ। ਲੋਡ ਬੈਲੇਂਸਰ (Load balancers) ਉਹਨਾਂ ਦੀ ਹੈਲਥ-ਚੈੱਕ ਕਰ ਸਕਦੇ ਹਨ। ਡੀਬੱਗਿੰਗ (Debugging) curl ਵਾਂਗ ਆਸਾਨ ਹੈ। ਪਰ ਜੇਕਰ ਤੁਸੀਂ ਐਜ ਕੇਸਾਂ (edge cases) ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਹ ਸਰਲਤਾ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ। ਕਰਸਰ ਬਣਾਓ। ਰੀਪਲੇਅਜ਼ (replays) ਦੀ ਉਮੀਦ ਰੱਖੋ। ਕਲਾਇੰਟ 'ਤੇ ਡਿਡੂਪਲੀਕੇਸ਼ਨ (deduplicate) ਕਰੋ। ਜਦੋਂ ਹਿਸਟਰੀ ਖਤਮ ਹੋ ਜਾਵੇ ਤਾਂ ਸਨੈਪਸ਼ਾਟ (snapshot) ਲਓ। ਅਜਿਹਾ ਕਰਨ ਨਾਲ, ਤੁਹਾਡੇ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੇ AI ਟਾਸਕ, ਕਮਜ਼ੋਰ Wi-Fi, ਸਰਵਰ ਰੀਸਟਾਰਟ, ਅਤੇ ਕਦੇ-ਕਦੇ ਰਾਤ ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਸਲੀਪ ਮੋਡ ਵਿੱਚ ਜਾਣ ਦੇ ਬਾਵਜੂਦ, ਆਪਣੀ ਪ੍ਰਗਤੀ ਦੀ ਸਹੀ ਰਿਪੋਰਟ ਦੇਣਗੇ।
ਸਰੋਤ: Build a Reconnecting SSE Task Stream with Node.js
ਚਰਚਾ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਵੋ: GyaanSetu AI Community