03 ਅਪ੍ਰੈ 2025·8 ਮਿੰਟ
ਏਆਈ ਐਪਾਂ ਵਿੱਚ ਫਰੰਟਐਂਡ ਅਤੇ ਬੈਕਐਂਡ ਵਿੱਚ ਸਟੇਟ ਦਾ ਪ੍ਰਬੰਧ
ਸਿੱਖੋ ਕਿ ਏਆਈ ਐਪਾਂ ਵਿੱਚ UI, ਸੈਸ਼ਨ ਅਤੇ ਡੇਟਾ ਸਟੇਟ ਫਰੰਟਐਂਡ ਅਤੇ ਬੈਕਐਂਡ ਵਿੱਚ ਕਿਵੇਂ ਸਾਂਝੇ ਕੀਤੇ ਜਾਂਦੇ ਹਨ — ਸਿੰਕਿੰਗ, ਪਾਇਦਾਰੀ, ਕੈਸ਼ਿੰਗ ਅਤੇ ਸੁਰੱਖਿਆ ਲਈ ਵਰਤੋਂਯੋਗ ਨਮੂਨੇ ਸਮੇਤ।
ਏਆਈ-ਤਿਆਰ ਕੀਤੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ “ਸਟੇਟ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ
“ਸਟੇਟ” ਉਹ ਸਭ ਕੁਝ ਹੈ ਜੋ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਇੱਕ ਪਲ ਤੋਂ ਦੂਜੇ ਪਲ ਤੱਕ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਯਾਦ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜੇ ਇੱਕ ਯੂਜ਼ਰ ਚੈਟ UI ਵਿੱਚ Send ਤੇ ਕਲਿਕ ਕਰਦਾ ਹੈ, ਤਾਂ ਐਪ ਨੂੰ ਇਹ ਨਹੀਂ ਭੁੱਲਣਾ ਚਾਹੀਦਾ ਕਿ ਉਸने ਕੀ ਲਿਖਿਆ, ਸਹਾਇਕ ਨੇ ਪਹਿਲਾਂ ਕੀ ਜਵਾਬ ਦਿੱਤਾ, ਕੀ ਕੋਈ ਬੇਨਤੀ ਅਜੇ ਚਲ ਰਹੀ ਹੈ, ਜਾਂ ਕਿਹੜੀਆਂ ਸੈਟਿੰਗਜ਼ (ਟੋਨ, ਮਾਡਲ, ਟੂਲ) ਐਨੇਬਲ ਹਨ। ਇਹ ਸਭ ਸਟੇਟ ਹੈ।
ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਸਟੇਟ
ਸਟੇਟ ਬਾਰੇ ਸੋਚਣ ਦਾ ਇਕ ਫਾਇਦੇਮੰਦ ਤਰੀਕਾ ਹੈ: ਐਪ ਦੀ ਮੌਜੂਦਾ ਹਕੀਕਤ—ਉਹ ਮੁੱਲ ਜੋ ਦੇਖਣ ਅਤੇ ਅਗਲਾ ਕਦਮ ਕਰਨ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦੇ ਹਨ। ਇਸ ਵਿੱਚ ਆਮ ਗੱਲਾਂ ਜਿਵੇਂ ਫਾਰਮ ਇਨਪੁੱਟਸ ਸ਼ਾਮਲ ਹਨ, ਪਰ ਇੱਥੇ ਕੁਝ “ਅਦ੍ਰਿਸ਼ਟ” ਤੱਥ ਵੀ ਹਨ, ਜਿਵੇਂ:
- ਯੂਜ਼ਰ ਕਿਸ ਗੱਲਬਾਤ ਵਿੱਚ ਹੈ
- ਆਖਰੀ ਜਵਾਬ ਸਟ੍ਰੀਮ ਹੋ ਰਿਹਾ ਹੈ ਜਾਂ ਮੁਕੰਮਲ ਹੋ ਗਿਆ ਹੈ
- ਸੁਨੇਹਿਆਂ ਦੀ ਸੂਚੀ ਅਤੇ ਉਹਨਾਂ ਦਾ ਕ੍ਰਮ
- ਟੂਲ ਕਾਲਜ਼ ਅਤੇ ਟੂਲ ਨਤੀਜੇ (ਸਰਚ ਨਤੀਜੇ, ਡੇਟਾਬੇਸ ਲੁੱਕਅਪ, ਫਾਇਲ ਐਕਸਟ੍ਰੈਕਟ)
- ਐਰਰ, ਰੀਟ੍ਰਾਈ ਅਤੇ ਰੇਟ-ਲਿਮਿਟ ਬੈਕਆਫ
ਕਿਉਂ ਏਆਈ ਐਪਾਂ ਵਿੱਚ ਹੋਰ ਚਲਦਾਰ ਚੀਜ਼ਾਂ ਹੁੰਦੀਆਂ ਹਨ
ਪ੍ਰੰਪਰਾਗਤ ਐਪ ਅਕਸਰ ਡੇਟਾ ਪੜ੍ਹਦੇ, ਦਿਖਾਉਂਦੇ ਅਤੇ ਅਪਡੇਟ ਸੇਵ ਕਰਦੇ ਹਨ। ਏਆਈ ਐਪ ਇਸ ਵਿੱਚ ਵਾਧੂ ਕਦਮ ਅਤੇ ਅੰਤਰਿਮ ਆਉਟਪੁੱਟ ਜੋੜਦੇ ਹਨ:
- ਇੱਕ ਇਕੱਲਾ ਯੂਜ਼ਰ ਕਾਰਵਾਈ ਕਈ ਬੈਕਐਂਡ ਓਪਰੇਸ਼ਨ (LLM ਕਾਲ, ਟੂਲ ਕਾਲ, ਹੋਰ LLM ਕਾਲ) ਟ੍ਰਿਗਰ ਕਰ ਸਕਦੀ ਹੈ।
- ਜਵਾਬ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਆ ਸਕਦੇ ਹਨ (ਸਟ੍ਰੀਮਿੰਗ ਟੋਕਨ), ਇਸ ਲਈ UI ਨੂੰ جزوی ਸਟੇਟ ਦਾ ਪ੍ਰਬੰਧ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
- ਸੰਦਰਭ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ: ਪ੍ਰਣਾਲੀ ਨੂੰ ਕੰਵਰਸੇਸ਼ਨ ਮੈਮੋਰੀ, ਟੂਲ ਨਤੀਜਿਆਂ ਅਤੇ ਮਾਡਲ ਸੈਟਿੰਗਜ਼ ਨੂੰ ਅਨੁਰੋਧਾਂ ਵਿੱਚ ਸੰਗਤ ਰੱਖਣਾ ਪੈਂਦਾ ਹੈ।
ਇਹ ਵਾਧੂ ਗਤੀ ਕਾਰਨ ਹੀ ਸਟੇਟ ਪ੍ਰਬੰਧਨ ਅਕਸਰ ਏਆਈ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਛੁਪਾ ਹੋਇਆ ਜਟਿਲਤਾ ਬਣ ਜਾਂਦਾ ਹੈ।
ਇਹ ਗਾਈਡ ਕੀ ਕਵਰ ਕਰੇਗੀ
ਅੱਗੇ ਵਾਲੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਅਸੀਂ ਸਟੇਟ ਨੂੰ ਪ੍ਰਯੋਗਿਕ ਵਰਗਾਂ ਵਿੱਚ ਵੰਡਾਂਗੇ (UI ਸਟੇਟ, ਸੈਸ਼ਨ ਸਟੇਟ, ਪਾਇਦਾਰ ਡੇਟਾ, ਅਤੇ ਮਾਡਲ/ਰਨਟਾਈਮ ਸਟੇਟ), ਅਤੇ ਦਿਖਾਵਾਂਗੇ ਕਿ ਹਰ ਇੱਕ ਕਿੱਥੇ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ (ਫਰੰਟਐਂਡ ਵਿਰੁੱਧ ਬੈਕਐਂਡ)। ਅਸੀਂ ਸਿੰਕਿੰਗ, ਕੈਸ਼ਿੰਗ, ਲੰਮੀ ਚੱਲਣ ਵਾਲੀਆਂ ਨੌਕਰੀਆਂ, ਸਟ੍ਰੀਮਿੰਗ ਅਪਡੇਟ ਅਤੇ ਸੁਰੱਖਿਆ ਵੀ ਕਵਰ ਕਰਾਂਗੇ—ਕਿਉਂਕਿ ਸਟੇਟ ਤਦ ਹੀ ਲਾਭਦਾਇਕ ਹੈ ਜਦੋਂ ਇਹ ਸਹੀ ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੋਵੇ।
ਛੇਤੀ ਉਦਾਹਰਨ ਪਰਿਸਥਿਤੀ
ਕਲਪਨਾ ਕਰੋ ਇੱਕ ਚੈਟ ਐਪ ਦੀ ਜਿੱਥੇ ਯੂਜ਼ਰ ਪੁੱਛਦਾ ਹੈ: “ਪਿਛਲੇ ਮਹੀਨੇ ਦੇ ਇਨਵੌਇਸ ਸੰਖੇਪ ਕਰੋ ਅਤੇ ਕੋਈ ਅਸਾਧਾਰਣ ਚੀਜ਼ ਚਿੰਨ੍ਹਿਤ ਕਰੋ।” ਬੈਕਐਂਡ ਹੋ ਸਕਦਾ ਹੈ (1) ਇਨਵੌਇਸ ਲਿਆਵੇ, (2) ਇਕ ਵਿਸ਼ਲੇਸ਼ਣ ਟੂਲ ਚੱਲਾਏ, (3) ਸੰਖੇਪ UI ਨੂੰ ਸਟ੍ਰੀਮ ਕਰਕੇ ਭੇਜੇ, ਅਤੇ (4) ਅਖੀਰਕਾਰ ਰਿਪੋਰਟ ਸੇਵ ਕਰ ਦੇਵੇ।
ਇਹ ਸਹੀ ਤਰ੍ਹਾਂ seamless ਮਹਿਸੂਸ ਕਰਨ ਲਈ, ਐਪ ਨੂੰ ਸੁਨੇਹਿਆਂ, ਟੂਲ ਨਤੀਜਿਆਂ, ਪ੍ਰਗਤੀ, ਅਤੇ ਸੇਵ ਕੀਤੇ ਆਉਟਪੁੱਟ ਦਾ ਟ੍ਰੈਕ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ—ਬਿਨਾਂ ਗੱਲਬਾਤਾਂ ਨੂੰ ਗਲਤ ਮਿਲਾਉਣ ਜਾਂ ਯੂਜ਼ਰਾਂ ਵਿਚਕਾਰ ਡੇਟਾ ਲੀਕ ਕਰਨ ਦੇ।
ਸਟੇਟ ਦੇ ਚਾਰ ਪਰਤਾਂ: UI, ਸੈਸ਼ਨ, ਡੇਟਾ, ਅਤੇ ਮਾਡਲ
ਲੋਕ ਜਦੋਂ ਇੱਕ ਏਆਈ ਐਪ ਵਿੱਚ “ਸਟੇਟ” ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਨ, ਉਹ ਅਕਸਰ ਬਹੁਤ ਵੱਖ-ਵੱਖ ਚੀਜ਼ਾਂ ਨੂੰ ਮਿਲਾ ਦਿੰਦੇ ਹਨ। ਸਟੇਟ ਨੂੰ ਚਾਰ ਪਰਤਾਂ ਵਿੱਚ ਵੰਡਣਾ—UI, ਸੈਸ਼ਨ, ਡੇਟਾ, ਅਤੇ ਮਾਡਲ/ਰਨਟਾਈਮ—ਇਹ ਧਾਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਕਿਸ ਚੀਜ਼ ਨੂੰ ਕਿੱਥੇ ਰੱਖਣਾ ਹੈ, ਕੌਣ ਬਦਲ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਿਵੇਂ ਸਟੋਰ ਕੀਤਾ ਜਾਵੇ।
1) UI ਸਟੇਟ (ਉਹ ਜੋ ਯੂਜ਼ਰ ਇਸ ਵੇਲੇ ਕਰ ਰਿਹਾ ਹੈ)
UI ਸਟੇਟ ਬ੍ਰਾਾਊਜ਼ਰ ਜਾਂ ਮੋਬਾਈਲ ਐਪ ਵਿੱਚ ਜਿਓਂ-ਦੀ-ਜਿਓਂ ਰਹਿਣ ਵਾਲੀ ਸਥਿਤੀ ਹੁੰਦੀ ਹੈ: ਟੈਕਸਟ ਇਨਪੁੱਟ, ਟੋਗਲ, ਚੁਣੇ ਹੋਏ ਆਈਟਮ, ਖੁੱਲ੍ਹੀ ਟੈਬ, ਅਤੇ ਕਿ ਬਟਨ ਡਿਸੇਬਲ ਹੈ ਜਾਂ ਨਹੀਂ।
ਏਆਈ ਐਪ ਕੁਝ UI-ਖਾਸ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜੋੜਦੇ ਹਨ:
- ਲੋਡਿੰਗ ਇੰਡੀਕੇਟਰ ਅਤੇ “ਸੋਚ ਰਹਿਆ ਹੈ” ਵਾਲੇ ਸਟੇਟ
- ਸਟ੍ਰੀਮ ਕੀਤੇ ਟੋਕਨ (ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਟੈਕਸਟ ਹਿਸ਼ਿਆਂ-ਹਿਸ਼ਿਆਂ ਆਉਂਦਾ ਹੈ)
- ਲੋਕਲ ਡ੍ਰਾਫਟ ਸੁਨੇਹੇ (ਜਦ ਤੱਕ ਉਹ ਭੇਜੇ ਨਾ ਜਾਣ)
UI ਸਟੇਟ ਨੂੰ ਰੀਸੈਟ ਕਰਨਾ ਆਸਾਨ ਅਤੇ ਖੋ ਜਾਣ ਲਈ ਸੁਰੱਖਿਅਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਯੂਜ਼ਰ ਪੇਜ ਰੀਫ੍ਰੇਸ਼ ਕਰ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਹ ਗੁਆ ਸਕਦੇ ਹੋ—ਅਕਸਰ ਇਹ ਠੀਕ ਹੁੰਦਾ ਹੈ।
2) ਸੈਸ਼ਨ / ਗੱਲਬਾਤ ਸਟੇਟ (ਯੂਜ਼ਰ ਦੇ ਫਲੋ ਲਈ ਸਾਂਝਾ ਸੰਦਰਭ)
ਸੈਸ਼ਨ ਸਟੇਟ ਯੂਜ਼ਰ ਨੂੰ ਇਕ ਚੱਲ ਰਹੀ ਇੰਟਰੈਕਸ਼ਨ ਨਾਲ ਜੋੜਦਾ ਹੈ: ਯੂਜ਼ਰ ਪਛਾਣ, ਇੱਕ ਗੱਲਬਾਤ ID, ਅਤੇ ਸੁਨੇਹਾ ਇਤਿਹਾਸ ਦੀ ਇਕ ਸੰਗਤ ਦ੍ਰਿਸ਼ਟੀ।
ਏਆਈ ਐਪ ਵਿੱਚ, ਇਹ ਅਕਸਰ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ:
- ਸੁਨੇਹਾ ਇਤਿਹਾਸ (ਜਾਂ ਉਸ ਦੇ ਹਵਾਲੇ)
- ਟੂਲ ਟਰੇਸ (ਕਿਹੜੀਆਂ ਫੰਕਸ਼ਨ/ਟੂਲ ਚੱਲੀਆਂ ਅਤੇ ਕਿਹੜੇ ਨਤੀਜੇ ਆਏ)
- “ਵਰਕਿੰਗ ਸੈੱਟ” ਚੋਣਾਂ ਜਿਵੇਂ ਮੌਜੂਦਾ ਪ੍ਰੋਜੈਕਟ/ਡੌਕਿਊਮੈਂਟ, ਚੁਣਿਆ ਮਾਡਲ, ਜਾਂ ਵਰਕਸਪੇਸ
ਇਹ ਪੱਧਰ ਆਮ ਤੌਰ 'ਤੇ ਫਰੰਟਐਂਡ ਅਤੇ ਬੈਕਐਂਡ ਦੋਹਾਂ 'ਚ ਫੈਲਿਆ ਹੁੰਦਾ ਹੈ: ਫਰੰਟਐਂਡ ਹਲਕੇ-ਫੁਲਕੇ ਆਈਡੈਂਟੀਫਾਇਰ ਰੱਖਦਾ ਹੈ, ਜਦਕਿ ਬੈਕਐਂਡ ਸੈਸ਼ਨ ਲਗਾਤਾਰਤਾ ਅਤੇ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਲਈ ਪ੍ਰਮਾਣਿਕ ਹੁੰਦਾ ਹੈ।
3) ਡੇਟਾ ਸਟੇਟ (ਸਟੋਰੇਜ ਵਿੱਚ ਟਿਕਾਉ ਰਿਕਾਰਡ)
ਡੇਟਾ ਸਟੇਟ ਉਹ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਜਾਣਬੂਝ ਕੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕਰਦੇ ਹੋ: ਪ੍ਰੋਜੈਕਟ, ਡੌਕੂਮੈਂਟ, ਐਮਬੈੱਡਿੰਗ, ਪ੍ਰੈਫਰੰਸ, ਆਡੀਟ ਲਾਗ, ਬਿਲਿੰਗ ਘਟਨਾਵਾਂ, ਅਤੇ ਸੇਵ ਕੀਤੇ ਗੱਲਬਾਤ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ।
UI ਅਤੇ ਸੈਸ਼ਨ ਸਟੇਟ ਦੇ ਉਲਟ, ਡੇਟਾ ਸਟੇਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
- ਟਿਕਾਉ (ਰਿਸਟਾਰਟਾਂ ਤੋਂ ਬਚਦਾ ਹੈ)
- ਪੁੱਛ-ਤਾਛ ਯੋਗ (ਤੁਸੀਂ ਇਸ ਨੂੰ ਸਰਚ/ਫਿਲਟਰ ਕਰ ਸਕਦੇ ਹੋ)
- ਆਡੀਟਯੋਗ (ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਸਮਝ ਸਕੋ ਕਿ ਕੀ ਹੋਇਆ)
4) ਮਾਡਲ / ਰਨਟਾਈਮ ਸਟੇਟ (ਏਆਈ ਹੁਣ ਕਿਵੇਂ ਕনਫਿਗਰ ਹੈ)
ਮਾਡਲ/ਰਨਟਾਈਮ ਸਟੇਟ ਉਹ ਆਪਰੇਸ਼ਨਲ ਸੈਟਅਪ ਹੈ ਜੋ ਜਵਾਬ ਬਣਾਉਂਦਾ ਹੈ: ਸਿਸਟਮ ਪ੍ਰੌਮਪਟ, ਐਨੇਬਲਡ ਟੂਲ, ਟੈਮਪਰੇਚਰ/ਮੈਕਸ ਟੋਕਨ, ਸੇਫਟੀ ਸੈਟਿੰਗਜ਼, ਰੇਟ ਲਿਮਿਟ ਅਤੇ ਅਸਥਾਈ ਕੈਸ਼।
ਇਸ ਦਾ ਕੁਝ ਹਿੱਸਾ ਕੰਫਿਗਰੇਸ਼ਨ ਹੁੰਦਾ ਹੈ (ਸਥਿਰ ਡੀਫੌਲਟ); ਕੁਝ ਅਸਥਾਈ ਹੁੰਦਾ ਹੈ (ਛੋਟੇ ਸਮੇਂ ਵਾਲੇ ਕੈਸ਼ ਜਾਂ ਪ੍ਰਤੀ-ਅਨੁਰੋਧ ਟੋਕਨ ਬਜਟ)। ਜ਼ਿਆਦਾਤਰ ਇਹ ਬੈਕਐਂਡ 'ਤੇ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਇਸ ਨੂੰ ਸਥਿਰਤਾ ਨਾਲ ਕੰਟਰੋਲ ਕੀਤਾ ਜਾ ਸਕੇ ਅਤੇ ਜ਼ਰੂਰਤ ਤੋਂ ਵੱਧ ਖੁਲਾਸਾ ਨਾ ਹੋਵੇ।
ਵੱਖਰੇ ਕਰਨ ਨਾਲ ਬੱਗ ਘਟਦੇ ਹਨ
ਜਦੋਂ ਇਹ ਪੱਧਰ ਗੁੰਝਲੇ ਹੋ ਜਾਂਦੇ ਹਨ, ਤੁਹਾਨੂੰ ਆਮ ਫੇਲੀਆਂ ਮਿਲਦੀਆਂ ਹਨ: UI ਉਹ ਦਿਖਾ ਰਿਹਾ ਹੈ ਜੋ ਸੇਵ ਨਹੀਂ ਹੋਇਆ, ਬੈਕਐਂਡ ਵੱਖਰਾ ਪ੍ਰੌਮਪਟ ਸੈਟ ਕਰਦਾ ਹੈ ਜਿੰਨਾ ਫਰੰਟਐਂਡ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਜਾਂ ਗੱਲਬਾਤ ਮੈਮੋਰੀ ਇੱਕ ਯੂਜ਼ਰ ਤੋਂ ਦੂਜੇ ਵਿੱਚ ਲੀਕ ਹੋ ਜਾਂਦੀ ਹੈ। ਸਾਫ ਹੱਦਬੰਦੀ ਇਕ ਸਪਸ਼ਟ ਸਤ੍ਹਾ-of-truth ਬਣਾਉਂਦੀ ਹੈ—ਅਤੇ ਇਹ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਕੀ ਸਥਿਰ ਰਹਿਣਾ ਹੈ, ਕੀ ਦੁਬਾਰਾ ਗਣਨਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੀ ਸੁਰੱਖਿਅਤ ਰੱਖਣਾ ਹੈ।
ਫਰੰਟਐਂਡ ਦੇ ਕਿੰਨ੍ਹੇ ਹਿੱਸੇ ਅਤੇ ਬੈਕਐਂਡ ਦੇ ਕਿੰਨ੍ਹੇ (ਅਤੇ ਕਿਉਂ)
ਏਆਈ ਐਪਾਂ ਵਿੱਚ ਤਰੁਟੀਆਂ ਘਟਾਉਣ ਦਾ ਇੱਕ ਭਰੋਸੇਯੋਗ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਹਰ ਇੱਕ ਸਟੇਟ ਟੁਕੜੇ ਲਈ ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ ਇਹ ਕਿੱਥੇ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ: ਬ੍ਰਾਉਜ਼ਰ (ਫਰੰਟਐਂਡ), ਸਰਵਰ (ਬੈਕਐਂਡ), ਜਾਂ ਦੋਹਾਂ ਵਿੱਚ। ਇਹ ਚੋਣ ਭਰੋਸੇਯੋਗਤਾ, ਸੁਰੱਖਿਆ, ਅਤੇ ਇਸ ਗੱਲ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦੀ ਹੈ ਕਿ ਯੂਜ਼ਰ ਜਦੋਂ ਰੀਫ੍ਰੇਸ਼ ਕਰਦਾ ਹੈ, ਨਵੀਂ ਟੈਬ ਖੋਲ੍ਹਦਾ ਹੈ, ਜਾਂ ਨੈੱਟਵਰਕ ਗੁਆ ਦਿੰਦਾ ਹੈ ਤਾਂ ਐਪ ਕਿੰਨਾ “ਹੈਰਾਨ” ਮਹਿਸੂਸ ਹੋਵੇਗਾ।
ਫਰੰਟਐਂਡ ਸਟੇਟ: ਤੇਜ਼, ਅਸਥਾਈ, ਅਤੇ ਯੂਜ਼ਰ-ਚਲਿਤ
ਫਰੰਟਐਂਡ ਸਟੇਟ ਉਹ ਚੀਜ਼ਾਂ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੀਆਂ ਹਨ ਅਤੇ ਰੀਫ੍ਰੈਸ਼ ਸਹਿਣੀ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇਸ ਨੂੰ ਲੋਕਲ ਰੱਖਣ ਨਾਲ UI ਤੇਜ਼ ਬਣਦੀ ਹੈ ਅਤੇ ਜ਼ਰੂਰੀ API ਕਾਲਾਂ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਆਮ ਫਰੰਟਐਂਡ-ਕੇਵਲ ਉਦਾਹਰਣ:
- ਯੂਜ਼ਰ ਟਾਈਪ ਕਰ ਰਿਹਾ ਡ੍ਰਾਫਟ ਸੁਨੇਹਾ
- ਟੇਬਲ ਵਿੱਚ ਲੋਕਲ ਫਿਲਟਰ ਅਤੇ ਸਾਰਟ ਆਰਡਰ
- ਮੋਡਲ ਖੁੱਲ੍ਹਾ/ਬੰਦ ਰਿਹਾ, ਚੁਣੀ ਟੈਬ, ਹੋਵਰ ਸਟੇਟ
ਜੇ ਤੁਸੀਂ ਇਹ ਸਟੇਟ ਰੀਫ੍ਰੇਸ਼ 'ਤੇ ਗੁਆ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਕਬੂਲੀਯੋਗ ਹੁੰਦਾ ਹੈ।
ਬੈਕਐਂਡ ਸਟੇਟ: ਪ੍ਰਮਾਣਿਕ, ਸੰਵੇਦਨਸ਼ੀਲ, ਅਤੇ ਸਾਂਝਾ
ਬੈਕਐਂਡ ਸਟੇਟ ਉਹ ਸਮਭਾਲੇ ਕਿ ਜਿਹੜੀ ਚੀਜ਼ ਭਰੋਸੇਯੋਗ, ਆਡੀਟਯੋਗ ਜਾਂ ਲਾਗੂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਉਹ ਸਟੇਟ ਆਉਂਦਾ ਹੈ ਜੋ ਹੋਰ ਡਿਵਾਈਸ/ਟੈਬ ਵੀ ਦੇਖਣ ਚਾਹੀਦੇ ਹਨ, ਜਾਂ ਜੋ ਕਲਾਇੰਟ ਬਦਲਣ 'ਤੇ ਸਹੀ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ।
ਆਮ ਬੈਕਐਂਡ-ਕੇਵਲ ਉਦਾਹਰਣ:
- ਅਧਿਕਾਰ ਅਤੇ ਭੂਮਿਕਾਵਾਂ
- ਬਿਲਿੰਗ/ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਸਥਿਤੀ ਅਤੇ ਉਪਯੋਗ ਸੀਮਾਵਾਂ
- ਲੰਬੇ ਸਮੇਂ ਚੱਲਣ ਵਾਲੀਆਂ ਨੌਕਰੀਆਂ ਅਤੇ ਉਹਨਾਂ ਦੀ ਸਥਿਤੀ
ਇੱਕ ਵਧੀਆ ਮਨੋਭਾਵ: ਜੇ ਗਲਤ ਸਟੇਟ ਪੈਸਾ ਖ਼ਰਚ ਹੋਵਾ ਸਕਦਾ ਹੈ, ਡੇਟਾ ਲੀਕ ਹੋ ਸਕਦੀ ਹੈ, ਜਾਂ ਪਹੁੰਚ ਟੁੱਟ ਸਕਦੀ ਹੈ, ਤਾਂ ਇਹ ਬੈਕਐਂਡ 'ਤੇ ਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਸਾਂਝਾ ਸਟੇਟ: ਸਮਨ্বਿਤ, ਪਰ ਇੱਕ ਸਤ੍ਹਾ-of-truth ਨਾਲ
ਕੁਝ ਸਟੇਟ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਸਾਂਝੇ ਹੁੰਦੇ ਹਨ:
- ਗੱਲਬਾਤ ਦਾ ਸਿਰਲੇਖ
- ਚੈਟ ਲਈ ਚੁਣੇ ਗਿਆ ਜ਼ਾਨਕਾਰੀ ਸਰੋਤ
- ਯੂਜ਼ਰ ਪ੍ਰੋਫ਼ਾਈਲ ਫੀਲਡ ਜੋ ਡਿਵਾਈਸਾਂ ਵਿੱਚ ਵਰਤੀ ਜਾਂਦੀ ਹੈ
ਜਦੋਂ ਸਾਂਝਾ ਹੋ, ਤਬ ਵੀ ਇੱਕ “ਸਰੋਤ-of-truth” ਚੁਣੋ। ਆਮ ਤੌਰ 'ਤੇ ਬੈਕਐਂਡ ਪ੍ਰਮਾਣਿਕ ਹੁੰਦਾ ਹੈ ਅਤੇ ਫਰੰਟਐਂਡ ਤੇਜ਼ੀ ਲਈ ਕੈਸ਼ ਰੱਖਦਾ ਹੈ।
ਨਿਯਮ-ਨੁਸਖਾ (ਅਤੇ ਇੱਕ ਆਮ ਐਂਟੀ-ਪੈਟਰਨ)
ਸਟੇਟ ਨੂੰ ਉਸ ਥਾਂ ਨੇੜੇ ਰੱਖੋ ਜਿੱਥੇ ਇਸਦੀ ਲੋੜ ਹੈ, ਪਰ ਜੋ ਕਈ ਡਿਵਾਈਸ/ਰੀਫ੍ਰੇਸ਼/ਰੁਕਾਵਟ ਤੋਂ ਬਾਅਦ ਬਣਿਆ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਉਸਨੂੰ ਪਾਇਦਾਰ ਰੱਖੋ।
ਇਕ ਆਮ ਗਲਤੀ: ਪ੍ਰਮਾਣਿਕ ਜਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਸਟੇਟ ਸਿਰਫ ਬਰਾਊਜ਼ਰ ਵਿੱਚ ਰੱਖਣਾ (ਉਦਾਹਰਣ ਲਈ, ਕਲਾਇੰਟ-ਸਾਈਡ isAdmin ਫਲੈਗ, ਯੋਜਨਾ ਟੀਅਰ, ਜਾਂ ਨੌਕਰੀ ਸਫਲਤਾ ਸਟੇਟ) ਨੂੰ ਸੱਚ ਮੰਨਣਾ। UI ਇਹ ਮੁੱਲ ਦਿਖਾ ਸਕਦਾ ਹੈ, ਪਰ ਬੈਕਐਂਡ ਨੂੰ ਇਹ ਵੇਰਫਾਈ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਆਮ ਏਆਈ ਰਿਕਵੇਸਟ ਲਾਈਫਸਾਇਕਲ: ਕਲਿਕ ਤੋਂ ਮੁਕੰਮਲ ਹੋਣ ਤੱਕ
ਇੱਕ ਏਆਈ ਫੀਚਰ ਇੱਕ ਕਾਰਵਾਈ ਵਾਂਗ ਨਹੀਂ ਹੁੰਦੀ; ਇਹ ਦਰਅਸਲ ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਸਰਵਰ ਵਿੱਚ ਸਾਂਝੇ ਸਟੇਟ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨਾਂ ਦੀ ਇੱਕ ਲੜੀ ਹੁੰਦੀ ਹੈ। ਲਾਈਫਸਾਇਕਲ ਨੂੰ ਸਮਝਣਾ ਮਿਸ਼ਮੈਚਡ UI, ਗੁੰਮ ਸੰਦਰਭ, ਅਤੇ ਡੁਪਲਿਕੇਟ ਚਾਰਜਾਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
1) ਯੂਜ਼ਰ ਕਾਰਵਾਈ → ਫਰੰਟਐਂਡ ਇਰਾਦਾ ਤਿਆਰ ਕਰਦਾ ਹੈ
ਯੂਜ਼ਰ Send 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ। UI ਤੁਰੰਤ ਲੋਕਲ ਸਟੇਟ ਅਪਡੇਟ ਕਰਦਾ ਹੈ: ਇੱਕ “ਪੈਂਡਿੰਗ” ਸੁਨੇਹਾ ਬਬਲ ਜੋੜ ਸਕਦਾ ਹੈ, ਸੈਂਡ ਬਟਨ ਡਿਸੇਬਲ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਮੌਜੂਦਾ ਇਨਪੁੱਟ (ਟੈਕਸਟ, ਅਟੈਚਮੈਂਟ, ਚੁਣੇ ਹੋਏ ਟੂਲ) ਕੈਪਚਰ ਕਰ ਲੈਂਦਾ ਹੈ।
ਇਸ ਵੇਲੇ ਫਰੰਟਐਂਡ ਨੂੰ ਕੋਰੈਲੇਸ਼ਨ ਆਈਡੀ ਜਨਰੇਟ ਜਾਂ ਅਟੈਚ ਕਰ ਲੈਣੇ ਚਾਹੀਦੇ ਹਨ:
conversation_id: ਇਹ ਕਿਸ ਥ੍ਰੈਡ ਨਾਲ ਸਬੰਧਿਤ ਹੈmessage_id: ਕਲਾਇੰਟ ਦੀ ਨਵੀਂ ਯੂਜ਼ਰ ਸੁਨੇਹੇ ਲਈ IDrequest_id: ਹਰ ਕੋਸ਼ਿਸ਼ ਲਈ ਵਿਲੱਖਣ (ਰੀਟ੍ਰਾਈ ਲਈ ਲਾਭਦਾਇਕ)
ਇਹ ID ਦੋਹਾਂ ਪਾਸਿਆਂ ਨੂੰ ਇਕੋ ਘਟਨਾ ਬਾਰੇ ਗੱਲ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾ ਦਿੰਦੇ ਹਨ—ਭਾਵੇਂ ਜਵਾਬ ਦੇਰੀ ਨਾਲ ਆਏ ਜਾਂ ਦੋ ਵਾਰੀ ਆ ਜਾਵੇ।
2) API ਕਾਲ → ਸਰਵਰ ਵੈਧਤਾ ਅਤੇ ਪਾਇਸਤ
ਫਰੰਟਐਂਡ ਇੱਕ API ਬੇਨਤੀ ਭੇਜਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਯੂਜ਼ਰ ਸੁਨੇਹਾ ਅਤੇ ID ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਸਰਵਰ ਅਧਿਕਾਰ, ਰੇਟ ਲਿਮਿਟ, ਅਤੇ ਪੇਲੋਡ ਸ਼ੇਪ ਵੇਰਿਫ਼ਾਈ ਕਰਦਾ ਹੈ, ਫਿਰ ਯੂਜ਼ਰ ਸੁਨੇਹੇ ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ (ਜਾਂ ਘੱਟੋ ਘੱਟ ਇੱਕ ਅਪਰਿਵਰਤਨਸ਼ੀਲ ਲਾਗ ਰਿਕਾਰਡ) ਜੋ conversation_id ਅਤੇ message_id ਨਾਲ ਕੀਡ ਕੀਤਾ ਗਿਆ ਹੁੰਦਾ ਹੈ।
ਇਹ ਪਾਇਸਤ ਕਦਮ “ਫੈਂਟਮ ਇਤਿਹਾਸ” ਤੋਂ ਰੋਕਦਾ ਹੈ ਜਦੋਂ ਯੂਜ਼ਰ ਮੱਧ-ਬੇਨਤੀ ਰਿਹਰਫਰੇਸ਼ ਕਰਦਾ ਹੈ।
3) ਸਰਵਰ ਸੰਦਰਭ ਦੁਬਾਰਾ ਬਨਾਉਂਦਾ ਹੈ
ਮਾਡਲ ਨੂੰ ਕਾਲ ਕਰਨ ਲਈ, ਸਰਵਰ ਆਪਣੇ ਸਰੋਤ-of-truth ਤੋਂ ਸੰਦਰਭ ਦੁਬਾਰਾ ਬਣਾਉਂਦਾ ਹੈ:
conversation_idਲਈ ਹਾਲੀਆ ਸੁਨੇਹੇ ਫੈਚ ਕਰੋ- ਸੰਬੰਧਿਤ ਰਿਕਾਰਡ ਖਿੱਚੋ (ਡੌਕੂਮੈਂਟ, ਪਸੰਦੀਦਗੀਆਂ, ਟੂਲ ਆਉਟਪੁੱਟ)
- ਗੱਲਬਾਤ ਨੀਤੀਆਂ ਲਾਗੂ ਕਰੋ (ਸਿਸਟਮ ਪ੍ਰੌਮਪਟ, ਮੈਮੋਰੀ ਨਿਯਮ, ਟ੍ਰੰਕੇਸ਼ਨ)
ਮੁੱਖ ਵਿਚਾਰ: ਕਲਾਇੰਟ 'ਤੇ ਪੂਰਾ ਇਤਿਹਾਸ ਭਰੋਸਾ ਨਾ ਕਰੋ। ਕਲਾਇੰਟ ਪੁਰਾਣਾ ਹੋ ਸਕਦਾ ਹੈ।
4) ਮਾਡਲ/ਟੂਲ ਐਕਸੈਕਿਊਸ਼ਨ → ਅੰਤਰਿਮ ਸਟੇਟ
ਸਰਵਰ ਮਾਡਲ ਕਾਲ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂ ਦੌਰਾਨ ਟੂਲ (ਸਰਚ, ਡੇਟਾਬੇਸ ਲੁੱਕਅਪ) ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ। ਹਰ ਟੂਲ ਕਾਲ ਅੰਤਰਿਮ ਸਟੇਟ ਪੈਦਾ ਕਰਦੀ ਹੈ ਜਿਸਨੂੰ request_id ਨਾਲ ਟ੍ਰੈਕ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਇਸਨੂੰ ਆਡੀਟ ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਰੀਪਲੇ/ਰੀਟ੍ਰਾਈ ਕੀਤਾ ਜਾ ਸਕੇ।
5) ਜਵਾਬ (ਸਟ੍ਰੀਮਿੰਗ ਜਾਂ ਨਹੀਂ) → UI ਮੁਕੰਮਲਤਾ
ਸਟ੍ਰੀਮਿੰਗ ਨਾਲ, ਸਰਵਰ ਹਿੱਸੇ-ਹਿੱਸੇ ਟੋਕਨ/ਈਵੈਂਟ ਭੇਜਦਾ ਹੈ। UI ਪੈਂਡਿੰਗ ਸਹਾਇਕ ਸੁਨੇਹਾ ਨੂੰ ਧੀਰੇ-ਧੀਰੇ ਅਪਡੇਟ ਕਰਦਾ ਹੈ, ਪਰ ਅਜੇ ਵੀ ਇਸਨੂੰ “ਚੱਲ ਰਿਹਾ” ਸਮਝਦਾ ਹੈ ਜਦ ਤੱਕ ਇੱਕ ਅਖੀਰੀ ਈਵੈਂਟ ਮੁਕੰਮਲ ਹੋਣ ਦਾ ਪਤਾ ਨਾ ਦੱਸੇ।
6) ਫੇਲ੍ਹ ਪਾਇੰਟਾਂ ਦੀ ਯੋਜਨਾ ਬਣਾਓ
ਰੀਟ੍ਰਾਈਜ਼, ਡਬਲ-ਸਬਮਿਟਸ, ਅਤੇ ਆਉਟ-ਆਫ-ਆਰਡਰ ਜਵਾਬ ਹੁੰਦੇ ਹਨ। ਸਰਵਰ 'ਤੇ dedupe ਲਈ request_id ਵਰਤੋ, ਅਤੇ UI ਵਿੱਚ reconcile ਲਈ message_id ਵਰਤੋ (ਐਕਟਿਵ ਰਿਕਵੇਸਟ ਨਾਲ ਮਿਲਦੇ ਨਾ ਹੋਏ ਵਲਦੇ ਚੰਕਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰੋ)। ਹਮੇਸ਼ਾਂ ਇੱਕ ਸਾਫ਼ “ਫੇਲਡ” ਸਥਿਤੀ ਦਿਖਾਓ ਅਤੇ ਇੱਕ ਸੁਰੱਖਿਅਤ ਰੀਟ੍ਰਾਈ ਦਿਓ ਜੋ ਡੁਪਲਿਕੇਟ ਸੁਨੇਹੇ ਨਾ ਬਣਾਵੇ।
ਸੈਸ਼ਨ ਅਤੇ ਗੱਲਬਾਤ ਮੈਮੋਰੀ: ਸੰਦਰਭ ਨੂੰ ਬਿਨਾਂ ਹੰਗਾਮੇ ਦੇ ਰੱਖਣਾ
ਸਟੇਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖੋ
ਸਰਵਰ-ਸਾਈਡ ਅਥਾਰਾਈਜ਼ੇਸ਼ਨ ਚੈਕ ਅਤੇ ਸੁਰੱਖਿਅਤ ਵੈਧਤਾ ਪੈਟਰਨ ਜਨਰੇਟ ਕਰੋ।
ਇੱਕ ਸੈਸ਼ਨ ਉਹ “ਥ੍ਰੈਡ” ਹੈ ਜੋ ਯੂਜ਼ਰ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਜੋੜਦਾ ਹੈ: ਉਹ ਵਰਕਸਪੇਸ ਜਿਸ ਵਿੱਚ ਉਹ ਹਨ, ਉਹਨਾਂ ਨੇ ਆਖਿਰਕਾਰ ਕੀ ਖੋਜਿਆ, ਕਿਹੜਾ ਡ੍ਰਾਫਟ ਉਹ ਸੋਧ ਰਹੇ ਸਨ, ਅਤੇ ਕਿ ਕਿਹੜੀ ਗੱਲਬਾਤ ਨੂੰ ਏਆਈ ਉੱਤਰ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। ਚੰਗੀ ਸੈਸ਼ਨ ਸਟੇਟ ਐਪ ਨੂੰ ਪੰਨਿਆਂ ਪਾਰ ਲਗਾਤਾਰ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ ਹੈ—ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਡਿਵਾਈਸਾਂ 'ਤੇ ਵੀ—ਬਿਨਾਂ ਤੁਹਾਡੇ ਬੈਕਐਂਡ ਨੂੰ ਯੂਜ਼ਰ ਦੀ ਹਰ ਗੱਲ ਬੇਕਾਰ ਤੌਰ 'ਤੇ ਸਾਂਭਣ ਵਾਲਾ ਬਣਾਉਣ ਦੇ।
ਸੈਸ਼ਨ ਸਟੇਟ ਦੇ ਲਕਸ਼
ਲਕਸ਼ ਹੋਣ ਚਾਹੀਦੇ ਹਨ: (1) ਲਗਾਤਾਰਤਾ (ਯੂਜ਼ਰ ਛੱਡ ਕੇ ਵਾਪਸ ਆ ਸਕੇ), (2) ਸਹੀਤਾ (ਏਆਈ ਸਹੀ ਗੱਲਬਾਤ ਲਈ ਸਹੀ ਸੰਦਰਭ ਵਰਤਦਾ ਹੈ), ਅਤੇ (3) ਸੰਚਾਰ containment (ਇੱਕ ਸੈਸ਼ਨ ਦੂਜੇ ਵਿੱਚ ਲੀਕ ਨਾ ਹੋਵੇ)। ਜੇ ਤੁਸੀਂ ਕਈ ਡਿਵਾਈਸ ਸਹਾਇਤਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਸੈਸ਼ਨਾਂ ਨੂੰ ਯੂਜ਼ਰ-ਸਕੋਪ ਕੀਤਾ ਅਤੇ ਡਿਵਾਈਸ-ਸਕੋਪ ਵੀ ਸੋਚੋ: “ਉਹੀ ਅਕਾਊਂਟ” ਮਤਲਬ ਹਮੇਸ਼ਾਂ “ਉਹੀ ਖੁੱਲ੍ਹਾ ਵਰਕ” ਨਹੀਂ ਹੁੰਦਾ।
ਕੁਕੀਜ਼ ਵੀਰੁੱਧ ਟੋਕਨ ਵੀਰੁੱਧ ਸਰਵਰ ਸੈਸ਼ਨ
ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਢੰਗ ਚੁਣਦੇ ਹੋ ਜਿਨ੍ਹਾਂ ਨਾਲ ਸੈਸ਼ਨ ਦੀ ਪਹਿਚਾਣ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:
- ਕੁਕੀਜ਼: ਵੈੱਬ ਐਪ ਲਈ ਸੱਭ ਤੋਂ ਸਧਾਰਨ ਕਿਉਂਕਿ ਬ੍ਰਾਉਜ਼ਰ ਆਪਣੇ ਆਪ ਇਹ ਭੇਜਦਾ ਹੈ। ਰਿਵਾਇਤੀ ਸੈਸ਼ਨਾਂ ਲਈ ਵਧੀਆ, ਪਰ ਤੁਹਾਨੂੰ secure ਫਲੈਗ (
HttpOnly,Secure,SameSite) ਅਤੇ CSRF ਹੈਂਡਲਿੰਗ ਨੂੰ ਹੱਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। - ਟੋਕਨ (ਜਿਵੇਂ JWT): APIs ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਲਈ ਚੰਗਾ ਕਿਉਂਕਿ ਕਲਾਇੰਟ ਖੁਦ ਇਸ ਨੂੰ ਜੁੜਦਾ ਹੈ। ਇਹ ਸਕੇਲ ਕਰਦੇ ਹਨ, ਪਰ ਰਿਵੋਕੇਸ਼ਨ ਅਤੇ ਰੋਟੇਸ਼ਨ ਲਈ ਵਾਧੂ ਡਿਜ਼ਾਈਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਅਤੇ ਤੁਸੀਂ ਸੈੰਸੇਟਿਵ ਸਟੇਟ ਟੋਕਨ ਵਿੱਚ ਨਹੀਂ ਭਰਨਾ ਚਾਹੀਦਾ)।
- ਸਰਵਰ ਸੈਸ਼ਨ: ਸਰਵਰ ਸੈਸ਼ਨ ਡੇਟਾ ਸਟੋਰ ਕਰਦਾ ਹੈ (ਅਕਸਰ Redis), ਅਤੇ ਕਲਾਇੰਟ ਸਿਰਫ ਇੱਕ ਓਪੈਕ ਸੈਸ਼ਨ ID ਰੱਖਦਾ ਹੈ। ਰਿਵੋਕ ਕਰਨ ਅਤੇ ਅਪਡੇਟ ਕਰਨ ਲਈ ਆਸਾਨ, ਪਰ ਤੁਸੀਂ ਸੈਸ਼ਨ ਸਟੋਰ ਚਲਾਉਣਾ ਅਤੇ ਸਕੇਲ ਕਰਨਾ ਪਏਗਾ।
ਗੱਲਬਾਤ ਮੈਮੋਰੀ ਨੀਤੀਆਂ
“ਮੈਮੋਰੀ” ਸਿਰਫ ਉਹ ਸਟੇਟ ਹੈ ਜੋ ਤੁਸੀਂ ਮਾਡਲ ਵਿੱਚ ਵਾਪਸ ਭੇਜਣਾ ਚੁਣਦੇ ਹੋ।
- ਪੂਰਾ ਇਤਿਹਾਸ: ਸਭ ਤੋਂ ਸਹੀ, ਪਰ ਮਹਿੰਗਾ ਅਤੇ পুরਾਣੇ ਸੰਵੇਦਨਸ਼ੀਲ ਸਮੱਗਰੀ ਨੂੰ surface ਕਰ ਸਕਦਾ ਹੈ।
- ਸੰਖੇਪ ਕੀਤਾ ਇਤਿਹਾਸ: ਚੱਲਦਾ ਰਨਿੰਗ ਸੰਖੇਪ + ਕੁਝ ਹਾਲੀਆ ਟਰਨ; ਸਸਤਾ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ “ਕਾਫ਼ੀ ਚੰਗਾ”।
- ਵਿੰਡੋਡ ਸੰਦਰਭ: ਸਿਰਫ ਆਖਰੀ N ਸੁਨੇਹੇ; ਸਭ ਤੋਂ ਸਧਾਰਨ ਪਰ ਮਹੱਤਵਪੂਰਨ ਪਹਿਲਾਂ ਵਾਲੇ ਫੈਸਲੇ ਗੁਆ ਸਕਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਪੈਟਰਨ ਹੈ ਸੰਖੇਪ + ਵਿੰਡੋ: ਇਹ ਪੇਸ਼ਗੋਈਯੋਗ ਹੈ ਅਤੇ ਮਾਡਲ ਦੇ ਹੈਰਾਨ ਕਰਨ ਵਾਲੇ ਵਿਹਾਰ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਟੂਲ ਕਾਲਜ਼: ਦੁਹਰਾਏ ਜਾਣ ਯੋਗ ਅਤੇ ਆਡੀਟਯੋਗ
ਜੇ ਏਆਈ ਟੂਲ ਵਰਤਦਾ ਹੈ (ਸਰਚ, ਡੇਟਾਬੇਸ ਕ੍ਵੈਰੀ, ਫਾਇਲ ਰੀਡ), ਹਰ ਟੂਲ ਕਾਲ ਨੂੰ ਇੰਪੁੱਟ, ਟਾਈਮਸਟੈਂਪ, ਟੂਲ ਵੇਰਜ਼ਨ, ਅਤੇ ਵਾਪਸ ਆਏ ਨਤੀਜੇ (ਜਾਂ ਉਸਦਾ ਰੈਫਰੈਂਸ) ਨਾਲ ਸਟੋਰ ਕਰੋ। ਇਸ ਨਾਲ ਤੁਸੀਂ ਦਿਖਾ ਸਕਦੇ ਹੋ “ਏਆਈ ਨੇ ਕਿਉਂ ਇਹ ਕਿਹਾ”, ਡੀਬੱਗ ਲਈ ਰਨ ਰੀਪਲੇ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਨਤੀਜੇ तबਦੀਲ ਹੋਏ ਹਨ ਕਿਉਂਕਿ ਟੂਲ ਜਾਂ ਡੇਟਾਸੈੱਟ ਬਦਲ ਗਿਆ।
ਨਿੱਜਤਾ ਗਾਰਡਰੇਲ
ਲੰਬੇ ਸਮੇਂ ਦੀ ਮੈਮੋਰੀ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਸਟੋਰ ਨਾ ਕਰੋ। ਸਿਰਫ ਓਹੀ ਰੱਖੋ ਜੋ ਲਗਾਤਾਰਤਾ ਲਈ ਲੋੜੀਂਦਾ ਹੈ (ਗੱਲਬਾਤ IDs, ਸੰਖੇਪ, ਅਤੇ ਟੂਲ ਲਾਗ), ਰੀਟੇਂਸ਼ਨ ਸੀਮਾਵਾਂ ਸੈੱਟ ਕਰੋ, ਅਤੇ ਕੱਚਾ ਯੂਜ਼ਰ ਟੈਕਸਟ ਸੇਵ ਕਰਨ ਤੋਂ ਬਚੋ ਜਦ ਤੱਕ ਸਪੱਸ਼ਟ ਉਤਪਾਦ ਕਾਰਨ ਅਤੇ ਯੂਜ਼ਰ ਦੀ ਸਹਿਮਤੀ ਨਾ ਹੋਵੇ।
ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸਟੇਟ ਸਿਨਕ ਕਰਨਾ: ਸਰੋਤ-of-truth ਅਤੇ ਸੰਘਰਸ਼ ਸੰਭਾਲ
ਜਦੋਂ ਇੱਕੋ “ਚੀਜ਼” ਨੂੰ ਕਈ ਥਾਵਾਂ 'ਤੇ ਸੋਧਿਆ ਜਾ ਸਕਦਾ ਹੈ—ਤੁਹਾਡਾ UI, ਦੂਜੀ ਬਰਾਊਜ਼ਰ ਟੈਬ, ਜਾਂ ਇੱਕ ਬੈਕਗ੍ਰਾਊਂਡ ਨੌਕਰੀ—ਤਦ ਸਟੇਟ ਖ਼ਤਰਨਾਕ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਸਦਾ ਹੱਲ ਬਹੁਤ ਵਧੀਆ ਕੋਡ ਤੋਂ ਵੱਧ ਸਪਸ਼ਟ ਮਾਲਕੀਅਤ ਵਿੱਚ ਹੈ।
ਸਰੋਤ-of-truth 定義 ਕਰੋ
ਹਰ ਸਟੇਟ ਟੁਕੜੇ ਲਈ ਨਿਸ਼ਚਤ ਕਰੋ ਕਿ ਕਿਹੜੀ ਪ੍ਰਣਾਲੀ ਪ੍ਰਮਾਣਿਕ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਏਆਈ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਬੈਕਐਂਡ ਉਹ canonical ਰਿਕਾਰਡ ਰੱਖਦਾ ਹੈ: ਗੱਲਬਾਤ ਸੈਟਿੰਗਜ਼, ਟੂਲ ਅਨੁਮਤੀਆਂ, ਸੁਨੇਹਾ ਇਤਿਹਾਸ, ਬਿਲਿੰਗ ਸੀਮਾਵਾਂ, ਅਤੇ ਨੌਕਰੀ ਸਥਿਤੀ। ਫਰੰਟਐਂਡ ਤੇਜ਼ੀ ਲਈ ਕੈਸ਼ ਰੱਖ ਸਕਦਾ ਹੈ (ਚੁਣੀ ਟੈਬ, ਡ੍ਰਾਫਟ ਟੈਕਸਟ, “ਲਿਖ ਰਿਹਾ ਹੈ” ਸੰਕੇਤ), ਪਰ ਜਦੋਂ ਗ਼ਲਤ ਹੋਵੇ ਤਾਂ ਬੈਕਐਂਡ ਸਹੀ ਮੰਨੋ।
ਇਕ ਪ੍ਰਯੋਗਿਕ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਰੀਫ੍ਰੇਸ਼ 'ਤੇ ਇਸਨੂੰ ਖੋ ਦੇਣ 'ਤੇ ਉਦਾਸ ਹੋਵੋਗੇ, ਤਾਂ ਇਹ ਸੰਭਵਤ: ਬੈਕਐਂਡ 'ਤੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
Optimistic UI ਅੱਵਧਾਰਣ (ਧਿਆਨ ਨਾਲ ਵਰਤੋਂ)
Optimistic ਅਪਡੇਟ ਐਪ ਨੂੰ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੇ ਹਨ: ਸੈਟਿੰਗ ਟੌਗਲ ਕਰੋ, UI ਤੁਰੰਤ ਅਪਡੇਟ ਹੋ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਸਰਵਰ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ। ਇਹ ਘੱਟ-ਖਤਰਨਾਕ ਅਤੇ ਵਾਪਸ-ਲੈਣਯੋਗ ਕਾਰਵਾਈਆਂ (ਜਿਵੇਂ conversation ਨੂੰ starring) ਲਈ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ।
ਜਦੋਂ ਸਰਵਰ ਰਿਜੈਕਟ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਬਦਲ ਸਕਦਾ ਹੈ (ਅਧਿਕਾਰ ਜਾਂ ਕੋਟਾ ਜਾਂ ਵੈਧਤਾ), ਤਾਂ ਇਹ ਉਲਝਣ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਐਸੇ ਮਾਮਲਿਆਂ ਵਿੱਚ “saving…” ਸਥਿਤੀ ਦਿਖਾਓ ਅਤੇ ਸਿਰਫ ਪੁਸ਼ਟੀ ਹੋਣ ਉੱਪਰ UI ਅਪਡੇਟ ਕਰੋ।
ਸੰਘਰਸ਼ ਸੰਭਾਲਣਾ (ਦੋ ਟੈਬ, ਇਕ ਗੱਲਬਾਤ)
ਸੰਘਰਸ਼ ਹੋਂਦੇ ਹਨ ਜਦੋਂ ਦੋ ਕਲਾਇੰਟ ਇੱਕੋ ਰਿਕਾਰਡ ਨੂੰ ਵੱਖ-ਵੱਖ ਸ਼ੁਰੂਆਤੀ ਵਰਜ਼ਨ 'ਤੇ ਅਪਡੇਟ ਕਰਦੇ ਹਨ। ਆਮ ਉਦਾਹਰਨ: Tab A ਅਤੇ Tab B ਦੋਹਾਂ model temperature ਬਦਲਦੇ ਹਨ।
ਹਲ: ਹਲਕੇ-ਫੁੱਲੇ ਵਰਜ਼ਨਿੰਗ ਵਰਤੋ ਤਾਂ ਕਿ ਬੈਕਐਂਡ stale writes ਪਛਾਣ ਸਕੇ:
updated_atਟਾਈਮਸਟੈਂਪਸ (ਸਧਾਰਨ, ਮਨੁੱਖ-ਪੜ੍ਹਨਯੋਗ)- ETags /
If-Matchਹੇਡਰ (HTTP-ਨੈਟਿਵ) - ਇੰਕ੍ਰੀਮੈਂਟਿੰਗ ਰਿਵਿਜ਼ਨ ਨੰਬਰ (ਸਪਸ਼ਟ ਸੰਘਰਸ਼ ਪਛਾਣ)
ਜੇ ਵਰਜ਼ਨ ਮਿਲਦਾ ਨਹੀਂ, ਤਾਂ ਇੱਕ conflict ਜਵਾਬ (ਅਕਸਰ HTTP 409) ਵਾਪਸ ਕਰੋ ਅਤੇ ਨਵਾਂ ਸਰਵਰ ਆਬਜੈਕਟ ਭੇਜੋ।
API ਡਿਜ਼ਾਈਨ ਤਾਂ ਕਿ ਮਿਸ਼ਮੈਚ ਘਟੇ
ਕਿਸੇ ਵੀ ਲਿਖਾਈ ਤੋਂ ਬਾਅਦ, API ਸੇਵ ਕੀਤਾ ਹੋਇਆ ਆਬਜੈਕਟ ਵਾਪਸ ਭੇਜੇ (ਸਰਵਰ-ਜਨਰੇਟ ਕੀਤੇ ਡੀਫੌਲਟ, ਨਾਰਮਲਾਈਜ਼ਡ ਫੀਲਡ, ਅਤੇ ਨਵਾਂ ਵਰਜ਼ਨ ਸਮੇਤ)। ਇਸ ਨਾਲ ਫਰੰਟਐਂਡ ਆਪਣੀ ਕੈਸ਼ ਕੀ ਤੁਰੰਤ ਬਦਲ ਸਕਦਾ ਹੈ—ਇੱਕ ਸਰੋਤ-ਆਫ-ਟ੍ਰੂਥ ਅਪਡੇਟ ਬਣਦਾ ਹੈ ਬਜਾਏ ਇਸਦੇ ਕਿ ਅਨੁਮਾਨ ਲਾਇਆ ਜਾਵੇ ਕਿ ਕੀ ਬਦਲਿਆ।
ਕੈਸ਼ਿੰਗ ਅਤੇ ਪਰਫਾਰਮੈਂਸ: ਤੇਜ਼ੀ ਨਾਲ ਬਿਨਾਂ ਪੁਰਾਣਾ ਸਟੇਟ ਦੇ
ਕੈਸ਼ਿੰਗ ਉਹ ਜਲਦੀ ਤਰੀਕਾ ਹੈ ਜੋ ਐਪ ਨੂੰ ਤੇਜ਼ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ ਹੈ, ਪਰ ਇਹ ਦੂਜੀ ਨਕਲ ਦਾ ਰੂਪ ਵੀ ਬਣਾਉਂਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਗਲਤ ਚੀਜ਼ ਕੈਸ਼ ਕਰੋ ਜਾਂ ਗਲਤ ਥਾਂ 'ਤੇ ਰੱਖੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਤੇਜ਼ ਪਰ ਉਲਝਣ ਭਰੀ UI ਭੇਜੋਗੇ।
ਕਲਾਇੰਟ 'ਤੇ ਕੀ ਕੈਸ਼ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ
ਕਲਾਇੰਟ-ਸਾਈਡ ਕੈਸ਼ਾਂ ਅਨੁਭਵ 'ਤੇ ਧਿਆਨ ਦੇਣ: ਚੰਗੇ ਉਮੀਦਵਾਰ ਹਨ ਹਾਲੀਆ ਗੱਲਬਾਤ ਪ੍ਰੀਵਿਊ (ਸਿਰਲੇਖ, ਆਖਰੀ ਸੁਨੇਹਾ), UI ਪਸੰਦਾਂ (ਥੀਮ, ਚੁਣਿਆ ਮਾਡਲ, ਸਾਇਡਬਾਰ ਸਟੇਟ), ਅਤੇ optimistic UI ਸਟੇਟ (ਜੋ ਸੁਨੇਹੇ “ਭੇਜੇ ਜਾ ਰਹੇ” ਦਿਖਦੇ ਹਨ)।
ਕਲਾਇੰਟ ਕੈਸ਼ ਨੂੰ ਛੋਟਾ ਅਤੇ ਨਸ਼ਟਿਯੋਗ ਰੱਖੋ: ਜੇ ਇਹ ਸਾਫ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਐਪ ਸਰਵਰ ਤੋਂ ਫੇਰੋਂ ਫੈਚ ਕਰਕੇ ਵੀ ਕੰਮ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।
ਸਰਵਰ 'ਤੇ ਕੀ ਕੈਸ਼ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ
ਸਰਵਰ ਕੈਸ਼ ਉਹ ਮਹਿੰਗਾ ਜਾਂ ਬਾਰ-ਬਾਰ ਹੋਣ ਵਾਲੇ ਕੰਮ ਲਈ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
- ਉਹ ਟੂਲ ਨਤੀਜੇ ਜੋ ਦੁਬਾਰਾ ਵਰਤ ਸਕਦੇ ਹੋ (ਉਦਾਹਰਣ ਲਈ, ਇੱਕੋ ਸ਼ਹਿਰ ਲਈ 5 ਮਿੰਟ ਵਿੱਚ ਮੌਸਮ ਲੁੱਕਅਪ)
- ਐਮਬੈੱਡਿੰਗ ਲੁੱਕਅਪ ਅਤੇ ਵੈਕਟਰ ਸਰਚ ਨਤੀਜੇ (ਛੋਟੇ TTL ਨਾਲ)
- ਰੇਟ-ਲਿਮਿਟ ਸਥਿਤੀ ਅਤੇ ਥ੍ਰੋਟਲਿੰਗ ਕਾਊਂਟਰ
ਇੱਥੇ ਤੁਸੀਂ ਡੈਰੀਵਡ ਸਟੇਟ ਵੀ ਕੈਸ਼ ਕਰ ਸਕਦੇ ਹੋ ਜਿਵੇਂ ਕਿ ਟੋਕਨ ਗਿਣਤੀ, ਮੋਡਰੇਸ਼ਨ ਫੈਸਲੇ, ਜਾਂ ਡੌਕ ਪਾਰਸਿੰਗ ਆਉਟਪੁੱਟ—ਕੁਝ ਵੀ ਜੋ ਨਿਰਧਾਰਿਤ ਅਤੇ ਮਹਿੰਗਾ ਹੋ।
ਕੈਸ਼ ਇਨਵੈਲੀਡੇਸ਼ਨ ਬੁਨਿਆਂਦੀ ਨਿਯਮ
ਤੀਨ ਵਰਤੋਂਯੋਗ ਨਿਯਮ:
- ਸਪਸ਼ਟ ਕੈਸ਼ ਕੀਜ਼ ਵਰਤੋ ਜੋ ਇਨਪੁੱਟ ਐਨਕੋਡ ਕਰਦੀਆਂ ਹਨ (
user_id, ਮਾਡਲ, ਟੂਲ ਪੈਰਾਮੀਟਰ, ਡੌਕੂਮੈਂਟ ਵਰਜ਼ਨ)। - TTLs ਉਸ ਦਰ ਤੇ ਸੈੱਟ ਕਰੋ ਜੋ ਅਧਾਰਭੂਤ ਡੇਟਾ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦਾ ਹੈ।ਛੋਟਾ TTL-ਸਮਝਦਾਰ ਲਾਜ਼ਮੀ ਤਰੀਕੇ ਨਾਲ ਵਧੀਆ ਹੈ।
- ਜਦੋਂ ਸਹੀਤਾ ਤੇਜ਼ੀ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇ ਤਾਂ ਕੈਸ਼ ਨੂੰ ਬਾਈਪਾਸ ਕਰੋ: ਜਿਵੇਂ ਯੂਜ਼ਰ ਡੌਕੁਮੈਂਟ ਅਪਡੇਟ ਕਰਦਾ ਹੈ, ਅਨੁਮਤੀਆਂ ਬਦਲਦੀਆਂ ਹਨ, ਜਾਂ ਰੀਫ੍ਰੈਸ਼ ਮੰਗੀਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ ਕਿ ਕਦੋਂ ਇੱਕ ਕੈਸ਼ ਐਂਟਰੀ ਗਲਤ ਹੋ ਜਾਵੇਗੀ, ਤਾਂ ਇਸ ਨੂੰ ਕੈਸ਼ ਨਾ ਕਰੋ।
ਸਾਂਝੇ ਕੈਸ਼ ਵਿੱਚ ਰਾਜ਼ ਜਾਂ ਨਿੱਜੀ ਡੇਟਾ ਨਾ ਰੱਖੋ
API ਕੀਜ਼, ਅਥੇਂਟੀਕੇਸ਼ਨ ਟੋਕਨ, ਕੱਚੇ ਪ੍ਰੌਮਪਟ ਜੋ ਸੰਵੇਦਨਸ਼ੀਲ ਟੈਕਸਟ ਰੱਖਦੇ ਹਨ, ਜਾਂ ਯੂਜ਼ਰ-ਵਿਸ਼ੇਸ਼ ਸਮੱਗਰੀ ਨੂੰ CDN ਵਰਗੇ ਸਾਂਝੇ ਪੱਧਰਾਂ ਵਿੱਚ ਨਾ ਰੱਖੋ। ਜੇ ਤੁਹਾਨੂੰ ਯੂਜ਼ਰ ਡੇਟਾ ਕੈਸ਼ ਕਰਨੀ ਪੈਂਦੀ ਹੈ, ਤਾਂ ਯੂਜ਼ਰ ਅਨੁਸਾਰ ਅਲੱਗ ਕਰੋ ਅਤੇ ਐਟ-ਰੇਸਟ ਇਨਕ੍ਰਿਪਟ ਕਰੋ—ਜਾਂ ਇਸਨੂੰ ਆਪਣੇ ਪ੍ਰਾਇਮਰੀ ਡੇਟਾਬੇਸ ਵਿੱਚ ਰੱਖੋ।
ਪ੍ਰਭਾਵ ਮਾਪੋ: ਤੇਜ਼ੀ ਵਿਰੁੱਧ ਪੁਰਾਣੀ UI
ਕੈਸ਼ਿੰਗ ਨੂੰ ਪਰਖਿਆ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਮੰਨਿਆ। p95 ਲੈਟੈਂਸੀ ਪਹਿਲਾਂ/ਬਾਅਦ ਵਿੱਚ ਟਰੈਕ ਕਰੋ, ਕੈਸ਼ ਹਿਟ ਰੇਟ, ਅਤੇ ਯੂਜ਼ਰ-ਦਿਖਾਈ ਦੇਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਜਿਵੇਂ “ਸੁਨੇਹਾ ਰੇਂਡਰ ਕਰਨ ਮਗਰੋਂ ਅਪਡੇਟ ਹੋ ਗਿਆ।” ਇੱਕ ਤੇਜ਼ ਜਵਾਬ ਜੋ ਬਾਅਦ ਵਿੱਚ UI ਨਾਲ ਵਿਰੋਧ ਕਰਦਾ ਹੈ, ਅਕਸਰ ਥੋੜਾ ਧੀਮਾਂ ਪਰ ਸਥਿਰ ਜਵਾਬ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਖਰਾਬ ਹੁੰਦਾ ਹੈ।
ਪਾਇਦਾਰੀ ਅਤੇ ਲੰਬੇ-ਚੱਲਣ ਵਾਲਾ ਕੰਮ: ਜੌਬਸ, ਕਿਊਜ਼, ਅਤੇ ਸਥਿਤੀ ਸਟੇਟ
ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬਸ ਜੋੜੋ
queued-running-succeeded ਫਲੋ ਮਾਡਲ ਕਰੋ ਅਤੇ UI ਵਿੱਚ ਭਰੋਸੇਯੋਗ ਪ੍ਰਗਤੀ ਦਰਸਾਓ।
ਕੁਝ ਏਆਈ ਫੀਚਰ ਇੱਕ ਸਕਿੰਟ ਵਿੱਚ ਮੁਕੰਮਲ ਹੋ ਜਾਂਦੇ ਹਨ। ਹੋਰ ਮਿੰਟਾਂ ਲੈਂਦੇ ਹਨ: PDF ਅੱਪਲੋਡ ਅਤੇ ਪਾਰਸ ਕਰਨਾ, ਨੋਲੇਜ ਬੇਸ ਦਾ ਐਮਬੈੱਡਿੰਗ ਅਤੇ ਇੰਡੈਕਸਿੰਗ, ਜਾਂ ਮਲਟੀ-ਸਟੈਪ ਟੂਲ ਵਰਕਫਲੋ। ਐਸੇ ਲਾਇਨਾਂ ਲਈ, “ਸਟੇਟ” ਸਿਰਫ ਸਕ੍ਰੀਨ 'ਤੇ ਜੋ ਹੈ ਨਹੀਂ—ਇਹ ਉਹ ਹੈ ਜੋ ਰੀਫ੍ਰੇਸ਼, ਰੀਟ੍ਰਾਈ ਅਤੇ ਸਮੇਂ ਵਿੱਚ ਬਚ ਕੇ ਰਹਿੰਦਾ ਹੈ।
ਕੀ ਪਾਇਸਤ ਕਰਨਾ (ਅਤੇ ਕਿਉਂ)
ਸਿਰਫ ਉਹੀ ਚੀਜ਼ ਪਾਇਸਤ ਕਰੋ ਜੋ ਵਾਸਤਵਿਕ ਉਤਪਾਦ ਮੁੱਲ ਅਨਲੌਕ ਕਰਦੀ ਹੋਵੇ।
ਗੱਲਬਾਤ ਇਤਿਹਾਸ ਸਭ ਤੋਂ ਸਾਫ਼: ਸੁਨੇਹੇ, ਟਾਈਮਸਟੈਂਪ, ਯੂਜ਼ਰ ਪਛਾਣ, ਅਤੇ ਅਕਸਰ ਕਿ ਕਿਸ ਮਾਡਲ/ਟੂਲ ਦਾ ਉਪਯੋਗ ਕੀਤਾ ਗਿਆ। ਇਹ “ਬਾਅਦ ਵਿੱਚ ਜਾਰੀ ਰੱਖੋ”, ਆਡੀਟ ਟ੍ਰੇਲ, ਅਤੇ ਸਹਾਇਤਾ ਲਈ ਜਰੂਰੀ ਹੈ।
ਯੂਜ਼ਰ ਅਤੇ ਵਰਕਸਪੇਸ ਸੈਟਿੰਗਜ਼ ਡੇਟਾਬੇਸ ਵਿੱਚ ਰਹਿਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਪਸੰਦੀਦਾ ਮਾਡਲ, ਟੈਮਪਰੇਚਰ ਡੀਫੌਲਟ, ਫੀਚਰ ਟੋਗਲ, ਸਿਸਟਮ ਪ੍ਰੌਮਪਟ, ਅਤੇ UI ਪਸੰਦਾਂ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਡਿਵਾਈਸਾਂ 'ਤੇ ਫਾਲੋ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।
ਫਾਇਲਾਂ ਅਤੇ ਆਰਟੀਫੈਕਟ (ਅਪਲੋਡ, ਨਿਕਲਿਆ ਹੋਇਆ ਟੈਕਸਟ, ਜਨਰੇਟ ਕੀਤੇ ਰਿਪੋਰਟ) ਆਮ ਤੌਰ 'ਤੇ ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਵਿੱਚ ਰੱਖੇ ਜਾਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਡੇਟਾਬੇਸ ਰਿਕਾਰਡ ਪੌਇੰਟ ਕਰਦੇ ਹਨ। ਡੇਟਾਬੇਸ ਮੈਟਾ ਡੇਟਾ ਰਖਦਾ ਹੈ (ਓਨਰ, ਸਾਈਜ਼, ਕੰਟੈਂਟ ਟਾਈਪ, ਪ੍ਰੋਸੈਸਿੰਗ ਸਟੇਟ), ਜਦਕਿ ਬਲੋਬ ਸਟੋਰ ਬਾਈਟਸ ਰੱਖਦਾ ਹੈ।
ਲੰਬੇ ਟਾਸਕਾਂ ਲਈ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬਸ
ਜੇ ਕੋਈ ਬੇਨਤੀ ਆਮ HTTP ਟਾਇਮਆਉਟ ਦੀ ਮਿਆਦ ਵਿੱਚ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਖਤਮ ਨਹੀਂ ਹੋ ਸਕਦੀ, ਤਾਂ ਕੰਮ ਨੂੰ ਕਿਊ ਵਿਚ ਭੇਜੋ।
ਇੱਕ ਆਮ ਪੈਟਰਨ:
- ਫਰੰਟਐਂਡ
POST /jobsਵਰਗਾ API ਕਾਲ ਕਰਦਾ ਹੈ ਇਨਪੁੱਟ (ਫਾਇਲ id, conversation id, ਪੈਰਾਮੀਟਰ) ਦੇ ਕੇ। - ਬੈਕਐਂਡ ਇੱਕ ਜੌਬ ਏਨਕਿਊ ਕਰਦਾ ਹੈ (extraction, indexing, batch tool runs) ਅਤੇ ਤੁਰੰਤ
job_idਵਾਪਸ ਦੇਂਦਾ ਹੈ। - ਵਰਕਰਸ ਅਸਿੰਕ੍ਰੋਨਸ ਤਰੀਕੇ ਨਾਲ ਜੌਬਸ ਪ੍ਰੋਸੈਸ ਕਰਦੇ ਹਨ ਅਤੇ ਨਤੀਜੇ ਪਾਇਦਾਰ ਸਟੋਰੇਜ ਵਿੱਚ ਲਿਖਦੇ ਹਨ।
ਇਸ ਨਾਲ UI ਤੇਜ਼ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਰੀਟ੍ਰਾਈਜ਼ ਸੁਰੱਖਿਅਤ ਹੁੰਦੇ ਹਨ।
UI ਲਈ ਭਰੋਸੇਯੋਗ ਸਥਿਤੀ
ਜੌਬ ਸਥਿਤੀ ਨੂੰ explicit ਅਤੇ ਕਵੈਰੀਯੋਗ ਬਣਾਓ: queued → running → succeeded/failed (ਵਿਕਲਪਿਕ ਤੌਰ 'ਤੇ canceled). ਇਹ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਸਰਵਰ-ਸਾਈਡ ਤੇ ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਏਰਰ ਵੇਰਵਿਆਂ ਨਾਲ ਸਟੋਰ ਕਰੋ।
ਫਰੰਟਐਂਡ ਤੇ ਸਥਿਤੀ ਸਾਫ਼ ਦਰਸਾਓ:
- Queued/running: ਸਪਿੰਨਰ ਦਿਖਾਓ ਅਤੇ ਡੁਪਲਿਕੇਟ ਕਾਰਵਾਈਆਂ ਨੂੰ ਡਿਸੇਬਲ ਕਰੋ।
- Failed: ਸੰਖੇਪ ਐਰਰ ਦਿਖਾਓ, ਨਾਲ ਹੀ Retry ਬਟਨ ਦਿਓ।
- Succeeded: ਨਤੀਜਾ ਲੋਡ ਕਰੋ ਜਾਂ ਗੱਲਬਾਤ ਅਪਡੇਟ ਕਰੋ।
GET /jobs/{id} (polling) ਜਾਂ SSE/WebSocket ਵਰਗੇ ਸਟ੍ਰੀਮ ਅਪਡੇਟ ਨੂੰ ਏਕਸਪੋਜ਼ ਕਰੋ ਤਾਂ ਜੋ UI ਨਿਰਧਾਰਤ ਤੌਰ 'ਤੇ ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਵੇ।
Idempotency keys: ਰੀਟ੍ਰਾਈ ਬਿਨਾਂ ਡੁਪਲਿਕੇਟ ਲਿਖਾਈ
ਨੈੱਟਵਰਕ ਟਾਇਮਆਉਟ ਹੁੰਦੇ ਹਨ। ਜੇ ਫਰੰਟਐਂਡ POST /jobs ਰੀਟ੍ਰਾਈ ਕਰੇ, ਤੁਸੀਂ ਦੋ ਇਕੋ ਜੌਬ ਨਹੀਂ ਚਾਹੁੰਦੇ।
ਹਰ ਲਾਜ਼ਮੀ ਕਾਰਵਾਈ ਲਈ Idempotency-Key ਲਾਜ਼ਮੀ ਕਰੋ। ਬੈਕਐਂਡ ਕੀ ਨੂੰ ਨਤੀਜੇ/job_id ਨਾਲ ਸਟੋਰ ਕਰਦਾ ਹੈ ਅਤੇ ਦੁਹਰਾਈਆਂ ਬੇਨਤੀਆਂ ਲਈ ਉਹੀ ਨਤੀਜਾ ਵਾਪਸ ਕਰਦਾ ਹੈ।
ਸਾਫਾਈ ਅਤੇ ਮਿਆਦ ਨੀਤੀਆਂ
ਲੰਬੇ ਸਮੇਂ ਚੱਲਣ ਵਾਲੀਆਂ ਏਆਈ ਐਪ ਤੇਜ਼ੀ ਨਾਲ ਡੇਟਾ ਇਕੱਤਰ ਕਰ ਲੈਂਦੀਆਂ ਹਨ। ਸ਼ੁਰੂ ਵਿੱਚ ਰੀਟੇਨਸ਼ਨ ਨੀਤੀਆਂ ਨਿਰਧਾਰਤ ਕਰੋ:
- ਪੁਰਾਣੀਆਂ ਗੱਲਬਾਤਾਂ N ਦਿਨਾਂ ਤੋਂ ਬਾਅਦ ਮਿਟਾ ਦਿਓ (ਜਾਂ ਯੂਜ਼ਰ ਨੂ ਸੁਚਤ ਕਰੋ)
- ਸਰੋਤ ਮਿਟਾਉਣ 'ਤੇ ਡੈਰੀਵਡ ਆਰਟੀਫੈਕਟ ਮਿਟਾ ਦਿਓ
- ਨਾਕਾਮ ਜੌਬਸ ਅਤੇ ਅੰਤਰਿਮ ਫਾਇਲਾਂ ਨੂੰ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਪੁਰਜ ਕਰੋ
ਸਾਫਾਈ ਨੂੰ ਸਟੇਟ ਪ੍ਰਬੰਧਨ ਦਾ ਹਿੱਸਾ ਮੰਨੋ: ਇਹ ਖ਼ਤਰੇ, ਕ਼ੀਮਤ, ਅਤੇ ਉਲਝਣ ਘਟਾਉਂਦਾ ਹੈ।
ਸਟ੍ਰੀਮਿੰਗ ਜਵਾਬ ਅਤੇ ਰੀਅਲ-ਟਾਈਮ ਅਪਡੇਟ: ਅੰਸ਼ਿਕ ਸਟੇਟ ਦਾ ਪ੍ਰਬੰਧ
ਸਟ੍ਰੀਮਿੰਗ ਨਾਲ ਸਟੇਟ ਹੋਰ ਜ਼ਿਆਦਾ ਜਟਿਲ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ “ਜਵਾਬ” ਹੁਣ ਇਕਲੇ ਬਲੱਬ ਦੇ ਰੂਪ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦਾ। ਤੁਸੀਂ ਅੰਸ਼ਿਕ ਟੋਕਨ (ਸ਼ਬਦ-ਸ਼ਬਦ ਆਉਂਦੇ ਟੈਕਸਟ) ਅਤੇ ਕਈ ਵਾਰ ਅੰਸ਼ਿਕ ਟੂਲ ਵਰਕ ਦੇ ਨਾਲ ਨਜਿੱਠ ਰਹੇ ਹੋ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ UI ਅਤੇ ਬੈਕਐਂਡ ਨੂੰ ਤੈਅ ਕਰਨਾ ਪੈਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਅਸਥਾਈ ਹੈ ਅਤੇ ਕੀ ਫਾਈਨਲ।
ਬੈਕਐਂਡ: ਸਿਰਫ ਟੈਕਸਟ ਨਹੀਂ, ਟਾਈਪ ਕੀਤੇ ਇਵੈਂਟ ਸਟ੍ਰੀਮ ਕਰੋ
ਇੱਕ ਸਾਫ਼ ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ ਛੋਟੇ-ਛੋਟੇ ਇਵੈਂਟ ਸਟ੍ਰੀਮ ਕਰੋ, ਹਰ ਇੱਕ ਦੇ ਨਾਵ ਅਤੇ ਪੇਲੋਡ ਦੇ ਨਾਲ। ਉਦਾਹਰਨ:
token: ਇੰਕ੍ਰੀਮੈਂਟਲ ਟੈਕਸਟ (ਜਾਂ ਇੱਕ ਛੋਟਾ ਹਿੱਸਾ)tool_start: ਇੱਕ ਟੂਲ ਕਾਲ ਸ਼ੁਰੂ ਹੋ ਗਿਆ (ਮਿਸਾਲ ਲਈ “Searching…”, ਇੱਕ id ਨਾਲ)tool_result: ਟੂਲ ਆਉਟਪੁੱਟ ਤਿਆਰ ਹੈ (ਉਸੇ id ਨਾਲ)done: ਸਹਾਇਕ ਸੁਨੇਹਾ ਮੁਕੰਮਲ ਹੈerror: ਕੁਝ ਫੇਲ੍ਹ ਹੋਇਆ (ਇੱਕ ਯੂਜ਼ਰ-ਸੁਰੱਖਿਅਤ ਸੰਦੇਸ਼ ਅਤੇ ਇੱਕ ਡੀਬੱਗ id ਸ਼ਾਮਲ ਕਰੋ)
ਇਹ ਇਵੈਂਟ ਸਟ੍ਰੀਮ ਰੌ-ਟੈਕਸਟ ਸਟ੍ਰੀਮਿੰਗ ਨਾਲੋਂ ਵਧੇਰੇ ਵਰਜਨਿੰਗ ਅਤੇ ਡੀਬੱਗ ਕਰਨ ਯੋਗ ਹੈ, ਕਿਉਂਕਿ ਫਰੰਟਐਂਡ ਬਿਨਾਂ ਅਨੁਮਾਨ ਲਗਾਏ ਪ੍ਰਗਤੀ ਨੂੰ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਦਰਸਾ ਸਕਦਾ ਹੈ (ਅਤੇ ਟੂਲ ਸਥਿਤੀ ਦਿਖਾ ਸਕਦਾ ਹੈ)।
ਫਰੰਟਐਂਡ: ਐਪੈਂਡ-ਓਨਲੀ ਅਪਡੇਟ, ਫਿਰ ਆਖਰੀ ਕਮੇਟ
ਕਲਾਇੰਟ 'ਤੇ ਸਟ੍ਰੀਮਿੰਗ ਨੂੰ ਐਪੈਂਡ-ਓਨਲੀ ਸਮਝੋ: ਇੱਕ “ਡ੍ਰਾਫਟ” ਸਹਾਇਕ ਸੁਨੇਹਾ ਬਣਾਓ ਅਤੇ ਜਿਵੇਂ ਜਿਵੇਂ token ਈਵੈਂਟ ਆਉਂਦੇ ਹਨ ਇਸਨੂੰ ਵਧਾਈਏ। ਜਦੋਂ done ਮਿਲ ਜਾਵੇ, ਇੱਕ ਕਮੇਟ ਕਰੋ: ਸੁਨੇਹੇ ਨੂੰ ਫਾਇਨਲ ਅੱਖਾਰ ਦਿੱਤੀ ਜਾਵੇ, ਇਸਨੂੰ ਪਾਇਸਤ ਕਰੋ (ਜੇ ਤੁਸੀਂ ਲੋਕਲ ਸਟੋਰ ਵੀ ਰੱਖਦੇ ਹੋ), ਅਤੇ ਕਾਪੀ/ਰੇਟ/ਰੀਜੈਨਰੇਟ ਵਰਗੀਆਂ ਕਾਰਵਾਈਆਂ ਖੁਲ੍ਹ ਜਾਣ।
ਇਸ ਨਾਲ ਇਤਿਹਾਸ ਨੂੰ ਸਟ੍ਰੀਮ ਦੌਰਾਨ ਦੁਬਾਰਾ ਲਿਖਣ ਤੋਂ ਬਚਿਆ ਜਾਦਾ ਹੈ ਅਤੇ UI ਪੇਸ਼ਗੋਈਯੋਗ ਰਹਿੰਦਾ ਹੈ।
ਰੁਕਾਵਟਾਂ ਦਾ ਹੱਲ (ਰੱਦ, ਡਰਾਪਸ, ਟਾਇਮਆਉਟ)
ਸਟ੍ਰੀਮਿੰਗ ਅਧ-ਪੂਰਨ ਕੰਮਾਂ ਦੀ ਸੰਭਾਵਨਾ ਵਧਾਉਂਦਾ ਹੈ:
- ਯੂਜ਼ਰ ਰੱਦ ਕਰਦਾ ਹੈ: ਇੱਕ cancel signaled ਭੇਜੋ; ਟੋਕਨ rendering ਰੋਕ ਦਿਓ; ਡ੍ਰਾਫਟ ਨੂੰ ਵਿਜ਼ੂਅਲੀ ਤੌਰ ਤੇ ਰੱਦ ਦਿਖਾਓ।
- ਨੈੱਟਵਰਕ ਡ੍ਰਾਪ: ਸਟ੍ਰੀਮ ਰੁਕ ਜਾਵੇ; “reconnecting…” ਦਿਖਾਓ ਅਤੇ ਮੁਕੰਮਲ ਹੋਣ ਦਾ ਅਨੁਮਾਨ ਨਾ ਕਰੋ।
- ਸਰਵਰ ਟਾਇਮਆਉਟ/ਐਰਰ: ਡ੍ਰਾਫਟ ਨੂੰ ਫੇਲਡ ਦੇ ਰੂਪ ਵਿੱਚ ਫਾਈਨਲ ਕਰੋ, ਅਤੇ ਇੱਕ ਰੀਟ੍ਰਾਈ ਦੀ ਚੋਣ ਦਿਓ ਜੋ ਨਵੀਂ ਬੇਨਤੀ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ (ਸਟ੍ਰੀਮਾਂ ਨੂੰ ਖ਼ੁਫੀਆ ਤਰੀਕੇ ਨਾਲ ਜੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ)।
ਰਿਹਾਈਡਰੇਸ਼ਨ: ਲੋਡ ਦੁਬਾਰਾ ਅਤੇ ਸਥਿਰ ਸਟੇਟ ਦੀ ਪੁਨਰ-ਥਾਪਨਾ
ਜੇ ਪੇਜ ਮਿਡ-ਸਟ੍ਰੀਮ ਰੀਲੋਡ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਨਵੀਨੀਤ ਸਥਿਰ ਸਟੇਟ ਤੋਂ ਪੁਨਰ-ਨਿਰਮਾਣ ਕਰੋ: ਆਖਰੀ ਕਮੇਟ ਕੀਤੇ ਸੁਨੇਹਿਆਂ ਨਾਲ ਹੀ ਕੋਈ ਸਟੋਰਡ ਡ੍ਰਾਫਟ ਮੈਟਾ (message id, ਇਕੱਠਾ ਟੈਕਸਟ, ਟੂਲ ਸਥਿਤੀਆਂ)। ਜੇ ਤੁਸੀਂ ਸਟ੍ਰੀਮ ਦੁਬਾਰਾ ਰੀਜ਼ਿਊਮ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਡ੍ਰਾਫਟ ਨੂੰ ਬਿਚਿੱਤਰ ਰੂਪ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰੋ ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਰੀਟ੍ਰਾਈ ਕਰਨ ਦਿਓ, ਬਜਾਏ ਇਸਦੇ ਕਿ ਤੁਸੀਂ ਉਸਨੂੰ ਮੁਕੰਮਲ ਦਿਖਾਓ।
ਸੁਰੱਖਿਆ ਅਤੇ ਨਿੱਜਤਾ: ਸਟੇਟ ਨੂੰ ਆਖ਼ਿਰ ਤੱਕ ਸੁਰੱਖਿਅਤ ਰੱਖਣਾ
ਸਟ੍ਰੀਮਿੰਗ ਬੈਕਐਂਡ ਬਣਾਓ
ਸਰਲ ਚੈਟ ਬ੍ਰੀਫ ਤੋਂ typed SSE ਇਵੈਂਟ, ਜੌਬ ਸਥਿਤੀ ਅਤੇ idempotent APIs ਬਣਾਓ।
ਸਟੇਟ ਸਿਰਫ ਉਹ ਡੇਟਾ ਨਹੀਂ ਹੈ ਜੋ ਤੁਸੀਂ ਸਟੋਰ ਕਰਦੇ ਹੋ—ਇਹ ਯੂਜ਼ਰ ਦੇ ਪ੍ਰੌਮਪਟ, ਅਪਲੋਡ, ਪਸੰਦਾਂ, ਜਨਰੇਟ ਕੀਤਾ ਆਉਟਪੁੱਟ, ਅਤੇ ਉਹ ਮੈਟਾਡੇਟਾ ਹੈ ਜੋ ਸਭ ਕੁਝ ਜੋੜਦਾ ਹੈ। ਏਆਈ ਐਪਾਂ ਵਿੱਚ ਇਹ ਸਟੇਟ ਅਸਧਾਰਣ ਤੌਰ 'ਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਹੋ ਸਕਦੀ ਹੈ (ਨਿੱਜੀ ਜਾਣਕਾਰੀ, ਪ੍ਰੋਪ੍ਰਾਇਟਰੀ ਡੌਕਸ, ਅਨਤਰਕਿਰਿਆ ਦੇ ਫੈਸਲੇ), ਇਸ ਲਈ ਸੁਰੱਖਿਆ ਨੂੰ ਹਰ ਪਰਤ ਵਿੱਚ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਰਾਜ਼ ਸਰਵਰ 'ਤੇ ਰੱਖੋ
ਕੋਈ ਵੀ ਚੀਜ਼ ਜੋ ਕਿਸੇ ਕਲਾਇੰਟ ਨੂੰ ਤੁਹਾਡੇ ਐਪ ਦੀ ਨਕਲ ਕਰਨ ਦੀ ਆਗਿਆ ਦੇਵੇ, ਸਰਵਰ-ਕੇਵਲ ਰਹੇ: API ਕੀਜ਼, ਨਿੱਜੀ ਕਨੈਕਟਰ (Slack/Drive/DB ਪ੍ਰਮਾਣ-ਪੱਤਰ), ਅਤੇ ਅੰਦਰੂਨੀ ਸਿਸਟਮ ਪ੍ਰੌਮਪਟ ਜਾਂ ਰੂਟਿੰਗ ਲੌਜਿਕ। ਫਰੰਟਐਂਡ ਕਾਰਵਾਈ ਮੰਗ ਸਕਦਾ ਹੈ (“ਇਸ ਫਾਇਲ ਦਾ ਸੰਖੇਪ ਬਣਾਓ”), ਪਰ ਬੈਕਐਂਡ ਨਿਰਣ੍ਹ ਕਰੇ ਕਿ ਇਹ ਕਿਵੇਂ ਚੱਲੇਗਾ ਅਤੇ ਕਿਹੜੇ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਵਰਤੇ ਜਾਣ।
ਹਰ ਲਿਖਾਈ (ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਪੜ੍ਹਾਈ) ਨੂੰ ਅਧਿਕਾਰ ਦਿਓ
ਹਰ ਸਟੇਟ ਮਿਉਟੇਸ਼ਨ ਨੂੰ ਇੱਕ ਅਧਿਕਾਰਤ ਓਪਰੇਸ਼ਨ ਵਜੋਂ ਦੇਖੋ। ਜਦੋਂ ਕਲਾਇੰਟ ਸੁਨੇਹਾ ਬਣਾਉਣ, ਗੱਲਬਾਤ ਦਾ ਨਾਮ ਬਦਲਣ, ਜਾਂ ਫਾਇਲ ਅਟੈਚ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇ, ਤਬ ਬੈਕਐਂਡ ਜਾਂਚੇ:
- ਯੂਜ਼ਰ authenticate ਹੈ।
- ਯੂਜ਼ਰ ਰਿਕੋਰਡ ਦਾ ਮਾਲਕ ਹੈ (conversation, workspace, project)।
- ਯੂਜ਼ਰ ਇਸ ਕਾਰਵਾਈ ਲਈ ਅਧਿਕਾਰਤ ਹੈ (ਰੋਲ, ਯੋਜਨਾ ਸੀਮਾ, ਆਰਗ ਨੀਤੀ)।
ਇਸ ਨਾਲ “ID guessing” ਹਮਲਿਆਂ ਤੋਂ ਬਚਾਅ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਕੋਈ conversation_id ਬਦਲ ਕੇ ਦੂਜੇ ਯੂਜ਼ਰ ਇਤਿਹਾਸ ਤੱਕ ਪਹੁੰਚ ਲੈ ਲੈਂਦਾ ਹੈ।
ਬਰਾਊਜ਼ਰ 'ਤੇ ਭਰੋਸਾ ਕਦੇ ਨਾ ਕਰੋ: ਵੈਧਤਾ ਅਤੇ ਸੈਨਾਈਟਾਈਜ਼ ਕਰੋ
ਹਰ ਕਲਾਇੰਟ-ਪਹੁੰਚੀ ਸਟੇਟ ਨੂੰ ਅਨਭਰੋਸਾ ਮੰਨੋ। ਸਕੀਮਾ ਅਤੇ ਸੀਮਾਵਾਂ (ਟਾਈਪ, ਲੰਬਾਈ, ਆসਕ ਐਨਮ) ਨੂੰ ਵੈਧ ਕਰੋ, ਅਤੇ ਲਕੜੀ ਲਈ sanitize ਕਰੋ (SQL/NoSQL, ਲਾਗ, HTML rendering)। ਜੇ ਤੁਸੀਂ “ਸਟੇਟ ਅਪਡੇਟ” ਸਵੀਕਾਰ ਕਰਦੇ ਹੋ (ਜਿਵੇਂ ਸੈਟਿੰਗਜ਼, ਟੂਲ ਪੈਰਾਮੀਟਰ), ਤਾਂ ਮਨਜ਼ੂਰ ਕੀਤੇ ਫੀਲਡਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ ਅਤੇ arbitrary JSON ਮਰਜ ਕਰਨ ਤੋਂ ਬਚੋ।
ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈਆਂ ਲਈ ਆਡੀਟ ਟ੍ਰੇਲ
ਜੋ ਕਾਰਵਾਈਆਂ ਟਿਕਾਉ ਸਟੇਟ ਨੂੰ ਬਦਲਦੀਆਂ ਹਨ—ਸ਼ੇਅਰ, ਐਕਸਪੋਰਟ, ਡਿਲੀਟ, ਕਨੈਕਟਰ ਪਹੁੰਚ—ਉਨ੍ਹਾਂ ਲਈ ਕਿਸ ਨੇ ਕਿੱਤਾ ਅਤੇ ਕਦੋਂ ਕੀਤਾ, ਇਹ ਦਰਜ ਕਰੋ। ਇੱਕ ਹਲਕੀ-ਫੁੱਲੀ ਆਡੀਟ ਲਾਗ ਘਟਨਾਵਲੀਆਂ ਅਤੇ ਅਨੁਸੂੰਧਾਨ ਲਈ ਮਦਦ ਕਰਦੀ ਹੈ।
ਡੇਟਾ ਘੱਟੋ-ਘੱਟ ਰੱਖੋ ਅਤੇ ਇਨਕ੍ਰਿਪਟ ਕਰੋ
ਉਸ ਲਈ ਸਿਰਫ ਉਹੀ ਡੇਟਾ ਰੱਖੋ ਜੋ ਫੀਚਰ ਦੇਣ ਲਈ ਜ਼ਰੂਰੀ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਸਦਾ ਲਈ ਪੂਰੇ ਪ੍ਰੌਮਪਟ ਦੀ ਲੋੜ ਨਹੀਂ, ਤਾਂ ਰੀਟੇਸ਼ਨ ਵਿਂਡੋਜ਼ ਜਾਂ ਰੈਡੈਕਸ਼ਨ 'ਤੇ ਵਿਚਾਰ ਕਰੋ। ਸੰਵੇਦਨਸ਼ੀਲ ਸਟੇਟ (ਟੋਕਨ, ਕਨੈਕਟਰ ਸਆਕਸ) ਨੂੰ ਟਿਕਾਊ ਰੱਖਣ ਸਮੇਂ ਇਨਕ੍ਰਿਪਟ ਕਰੋ ਅਤੇ ਟ੍ਰਾਂਜ਼ਿਟ ਵਿੱਚ TLS ਵਰਤੋ। آپਰੇਸ਼ਨਲ ਮੈਟਾਡੇਟਾ ਨੂੰ ਸਮੱਗਰੀ ਤੋਂ ਅਲੱਗ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਜ਼ਿਆਦਾ ਸਖ਼ਤ ਪਹੁੰਚ ਨੀਤੀਆਂ ਲਗਾ ਸਕੋ।
ਪ੍ਰਯੋਗਿਕ ਰੇਫਰੈਂਸ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਬਿਲਡ ਚੈਕਲਿਸਟ
ਏਆਈ ਐਪਾਂ ਲਈ ਇੱਕ ਉਪਯੋਗ ਡਿਫ਼ੌਲਟ ਸਧਾਰਨ ਹੈ: ਬੈਕਐਂਡ ਸਤ੍ਹਾ-of-truth ਹੈ, ਅਤੇ ਫਰੰਟਐਂਡ ਤੇਜ਼, optimistic ਕੈਸ਼ ਹੈ। UI ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰ ਸਕਦੀ ਹੈ, ਪਰ ਜੋ ਕੁਝ ਤੁਸੀਂ ਗੁਆਣਾ ਨਹੀਂ ਚਾਹੁੰਦੇ (ਸੁਨੇਹੇ, ਜੌਬ ਸਥਿਤੀ, ਟੂਲ ਆਉਟਪੁੱਟ, ਬਿਲਿੰਗ ਸੰਬੰਧੀ ਘਟਨਾਵਾਂ) ਉਹ ਸਰਵਰ-ਸਾਈਡ ਪੁਸ਼ਟੀ ਅਤੇ ਸਟੋਰ ਹੋਵਣੇ ਚਾਹੀਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ “vibe-coding” ਵਰਕਫਲੋ ਨਾਲ ਬਿਲਡ ਕਰ ਰਹੇ ਹੋ—ਜਿੱਥੇ ਉਤਪਾਦ ਦਾ ਕਾਫ਼ਾ ਹਿੱਸਾ ਤੇਜ਼ੀ ਨਾਲ ਬਣਦਾ ਹੈ—ਤਾਂ ਸਟੇਟ ਮਾਡਲ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਬਣ ਜਾਂਦਾ ਹੈ। ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai ਟੀਮਾਂ ਨੂੰ ਚੈਟ ਤੋਂ ਪੂਰੇ ਵੈੱਬ, ਬੈਕਐਂਡ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਉਹੀ ਨਿਯਮ ਲਾਗੂ ਹੁੰਦੇ ਹਨ: ਤੇਜ਼ ਇਤਰੇਸ਼ਨ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਸਰੋਤ-of-truth, ID, ਅਤੇ ਸਥਿਤੀ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਪਹਿਲਾਂ ਤੋਂ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਹੋਣ।
ਰੇਫਰੈਂਸ ਆਰਕੀਟੈਕਚਰ (ਇਕ ਜਿਸਨੂੰ ਤੁਸੀਂ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹੋ)
ਫਰੰਟਐਂਡ (ਬਰਾਊਜ਼ਰ/ਮੋਬਾਈਲ)
- UI ਸਟੇਟ: ਖੁੱਲ੍ਹੀਆਂ ਪੈਨਲ, ਡ੍ਰਾਫਟ ਪ੍ਰੌਮਪਟ ਟੈਕਸਟ, ਚੁਣਿਆ ਮਾਡਲ, ਅਸਥਾਈ “ਟਾਈਪਿੰਗ” ਇੰਡਿਕੇਟਰ।
- ਕੈਸ਼ ਕੀਤਾ ਸਰਵਰ ਸਟੇਟ: ਹਾਲੀਆ ਗੱਲਬਾਤ, ਆਖਰੀ ਜਾਣੀ ਜੌਬ ਸਥਿਤੀ, ਅੰਸ਼ਿਕ ਸਟਰੀਮ ਬਫਰ।
- ਇੱਕ ਸਿੰਗਲ ਰਿਕਵੇਸਟ ਪਾਈਪਲਾਈਨ ਜੋ ਹਮੇਸ਼ਾਂ ਜੋੜਦਾ ਹੈ:
session_id,conversation_id, ਅਤੇ ਨਵਾਂrequest_id।
ਬੈਕਐਂਡ (API + ਵਰਕਰਸ)
- API ਸਰਵਿਸ: ਇਨਪੁੱਟ ਵੈਧਤਾ ਕਰਦੀ, ਰਿਕਾਰਡ ਬਣਾਉਂਦੀ, ਸਟ੍ਰੀਮਿੰਗ ਜਵਾਬ ਜਾਰੀ ਕਰਦੀ।
- ਟਿਕਾਉ ਸਟੋਰ (SQL/NoSQL): ਗੱਲਬਾਤ, ਸੁਨੇਹੇ, ਟੂਲ ਕਾਲ, ਜੌਬ ਸਥਿਤੀ।
- ਕਿਊ + ਵਰਕਰਸ: ਲੰਬੇ ਸਮੇਂ ਵਾਲੇ ਟਾਸਕ (RAG ਇੰਡੈਕਸਿੰਗ, ਫਾਇਲ ਪਾਰਸਿੰਗ, ਇਮੇਜ ਜਨਰੇਸ਼ਨ)।
- ਕੈਸ਼ (ਵਿਕਲਪਿਕ): ਹਾਟ ਰੀਡਜ਼ (ਗੱਲਬਾਤ ਸੰਖੇਪ, ਐਮਬੈੱਡਿੰਗ ਮੈਟਾ), ਹਮੇਸ਼ਾਂ ਵਰਜ਼ਨ/ਟਾਈਮਸਟੈਂਪ ਨਾਲ ਕੀਡ ਕੀਤਾ।
ਨੋਟ: ਇਸਨੂੰ ਸੰਗਠਿਤ ਰੱਖਣ ਲਈ ਆਪਣੇ ਬੈਕਐਂਡ ਸਟੈਕ ਨੂੰ ਪਹਿਲਾਂ standardize ਕਰਨਾ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, Koder.ai-ਜਨਰੇਟ ਕੀਤੇ ਬੈਕਐਂਡ ਆਮ ਤੌਰ 'ਤੇ Go ਨਾਲ PostgreSQL ਵਰਤਦੇ ਹਨ (ਅਤੇ ਫਰੰਟਐਂਡ 'ਤੇ React), ਜੋ SQL ਵਿੱਚ authoritative state ਕੇਂਦਰਿਤ ਕਰਨ ਅਤੇ ਕਲਾਇੰਟ ਕੈਸ਼ ਨਸ਼ਟਿਯੋਗ ਰੱਖਣ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਪਹਿਲਾਂ ਆਪਣਾ ਸਟੇਟ ਮਾਡਲ ਡਿਜ਼ਾਈਨ ਕਰੋ
ਸਕ੍ਰੀਨ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਫੀਲਡ ਨਿਰਧਾਰਤ ਕਰੋ ਜਿਨ੍ਹਾਂ 'ਤੇ ਤੁਸੀਂ ਹਰ ਪਰਤ ਵਿੱਚ ਨਿਰਭਰ ਹੋਵੋਗੇ:
- IDs ਅਤੇ ਮਾਲਕੀ:
user_id,org_id,conversation_id,message_id,request_id. - ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਆਰਡਰਿੰਗ:
created_at,updated_at, ਅਤੇ ਸੁਨੇਹਿਆਂ ਲਈ ਇੱਕ ਸਪਸ਼ਟsequence. - ਸਥਿਤੀ ਫੀਲਡ:
queued | running | streaming | succeeded | failed | canceled(jobs ਅਤੇ tool calls ਲਈ). - ਵਰਜ਼ਨਿੰਗ:
etagਜਾਂversionਤਾ ਕਿ ਸੰਘਰਸ਼-ਸੁਰੱਖਿਅਤ ਅਪਡੇਟ ਹੋ ਸਕਣ।
ਇਸ ਨਾਲ ਉਹ ਆਮ ਬੱਗ ਰੁਕਦੇ ਹਨ ਜਿੱਥੇ UI “ਸਹੀ ਦਿਖਦੀ” ਪਰ ਰੀਟ੍ਰਾਈ, ਰੀਫ੍ਰੈਸ਼, ਜਾਂ ਸਮਕਾਲੀ ਸੋਧਾਂ ਨੂੰ ਮਿਲਾ ਨਹੀਂ ਪਾਉਂਦੀ।
ਸਥਿਰ API ਸ਼ੇਪ ਵਰਤੋ
ਫੀਚਰਜ਼ ਵਿੱਚ endpoints predictable ਰੱਖੋ:
GET /conversations(list)GET /conversations/{id}(get)POST /conversations(create)POST /conversations/{id}/messages(append)PATCH /jobs/{id}(update status)GET /streams/{request_id}ਜਾਂPOST .../stream(stream)
ਹਰ ਜਗ੍ਹਾ ਇੱਕੋ ਜਿਹੀ envelope ਸ਼ੈਲੀ ਵਾਪਸ ਕਰੋ (ਏਰਰ ਸਮੇਤ) ਤਾਂ ਕਿ ਫਰੰਟਐਂਡ ਸਟੇਟ ਨੂੰ ਇਕਸਾਰ ਅਪਡੇਟ ਕਰ ਸਕੇ।
ਉਹਨਾਂ ਥਾਵਾਂ 'ਤੇ ਪ੍ਰਬੇਭਤਾ ਜੋ ਸਟੇਟ ਨੂੰ ਤੋੜ ਸਕਦੇ ਹਨ
ਹਰ ਏਆਈ ਕਾਲ ਲਈ request_id ਲਾਗ ਕਰੋ ਅਤੇ ਵਾਪਸ ਕਰੋ। ਟੂਲ-ਕਾਲ ਇਨਪੁੱਟ/ਆਉਟਪੁੱਟ (redaction ਸਮੇਤ), ਲੈਟੈਂਸੀ, ਰੀਟ੍ਰਾਈਜ਼, ਅਤੇ ਆਖਰੀ ਸਥਿਤੀ ਦਰਜ ਕਰੋ। ਇਹ ਸੌਖਾ ਬਣਾਵੇ ਕਿ “ਮਾਡਲ ਨੇ ਕੀ ਵੇਖਿਆ, ਕਿਹੜੇ ਟੂਲ ਚੱਲੇ, ਅਤੇ ਅਸੀਂ ਕੀ ਸਟੋਰ ਕੀਤਾ?” ਦਾ ਜਵਾਬ ਦਿੱਤਾ ਜਾ ਸਕੇ।
ਬਿਲਡ ਚੈਕਲਿਸਟ (ਆਮ ਸਟੇਟ ਬੱਗ ਤੋਂ ਬਚਣ ਲਈ)
- ਬੈਕਐਂਡ ਸਰੋਤ-of-truth ਹੈ; ਫਰੰਟਐਂਡ ਕੈਸ਼ ਸਪਸ਼ਟ ਅਤੇ ਨਸ਼ਟਿਯੋਗ ਹੈ।
- ਹਰ ਲਿਖਾਈ idempotent ਹੋਵੇ (ਰਿਟ੍ਰਾਈ ਲਈ ਸੁਰੱਖਿਅਤ)
request_id(ਅਤੇ/ਜਾਂ Idempotency-Key) ਦੀ ਵਰਤੋਂ ਕਰਕੇ। - ਸਥਿਤੀ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ explicit ਅਤੇ ਵੈਧ ਹੋਣ (ਕੋਈ ਚੁਪਚਾਪ
queuedਤੋਂsucceededਨਹੀਂ)। - ਸਟ੍ਰੀਮਿੰਗ ਅਪਡੇਟ ID/sequence ਨਾਲ ਮਿਲਾਏ ਜਾਣ ("ਆਖਰੀ ਸੁਨੇਹਾ ਜਿੱਤਦਾ ਹੈ" ਨਾਲ ਨਹੀਂ)।
- ਸੰਘਰਸ਼
version/etagਜਾਂ ਸਰਵਰ-ਸਾਈਡ ਮਰਜ ਨੀਤੀਆਂ ਨਾਲ ਹੱਲ ਕੀਤੇ ਜਾਣ। - PII ਅਤੇ ਸਿਕ੍ਰੇਟ ਕਦੇ ਵੀ ਕਲਾਇੰਟ ਸਟੇਟ ਵਿੱਚ ਨਹੀਂ; ਲਾਗਜ਼ by default redact ਹੋਣ।
- ਡੀਬੱਗ ਲਈ ਇੱਕ ਡੈਸ਼ਬੋਰਡ: ਰਿਕਵੇਸਟ, ਟੂਲ ਕਾਲ, ਜੌਬ ਸਥਿਤੀ, ਅਤੇ ਐਰਰ।
ਜਦੋਂ ਤੁਸੀਂ ਤੇਜ਼ ਬਿਲਡ ਸਾਈਕਲ (ਸ਼ਾਮਿਲ ਕਰਕੇ ਏਆਈ-ਸਹਾਇਤ) ਅਪਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਨ੍ਹਾਂ ਚੈਕਲਿਸਟ ਆਈਟਮਾਂ ਨੂੰ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕਰਨ ਵਾਲੇ ਗਾਰਡਰੇਲ ਜੋੜੋ—ਸਕੇਮਾ ਵੈਧਤਾ, idempotency, ਅਤੇ ইਵੈਂਟਡ ਸਟ੍ਰੀਮਿੰਗ—ਤਾਂ ਜੋ “ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣਾ” ਸਟੇਟ ਡ੍ਰਿਫਟ ਵਿੱਚ ਨਾਂ ਬਦਲ ਜਾਵੇ। ਅਮਲ ਵਿੱਚ, ਇਹੀ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ Koder.ai ਵਰਗਾ end-to-end ਪਲੇਟਫਾਰਮ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ: ਇਹ ਡਿਲਿਵਰੀ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ, ਜਦੋਂਕਿ ਤੁਹਾਨੂੰ ਸਰੋਤ ਕੋਡ ਨਿਕਾਸ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਵੀ ਦਿੰਦਾ ਹੈ ਅਤੇ ਵੈੱਬ, ਬੈਕਐਂਡ, ਅਤੇ ਮੋਬਾਈਲ ਬਿਲਡਾਂ ਵਿੱਚ ਸਟੇਟ-ਹੈਂਡਲਿੰਗ ਪੈਟਰਨ ਇਕਸਾਰ ਰੱਖਦਾ ਹੈ।