ਸਿੱਖੋ ਕਿ ਏਆਈ ਐਪਾਂ ਵਿੱਚ UI, ਸੈਸ਼ਨ ਅਤੇ ਡੇਟਾ ਸਟੇਟ ਫਰੰਟਐਂਡ ਅਤੇ ਬੈਕਐਂਡ ਵਿੱਚ ਕਿਵੇਂ ਸਾਂਝੇ ਕੀਤੇ ਜਾਂਦੇ ਹਨ — ਸਿੰਕਿੰਗ, ਪਾਇਦਾਰੀ, ਕੈਸ਼ਿੰਗ ਅਤੇ ਸੁਰੱਖਿਆ ਲਈ ਵਰਤੋਂਯੋਗ ਨਮੂਨੇ ਸਮੇਤ।

“ਸਟੇਟ” ਉਹ ਸਭ ਕੁਝ ਹੈ ਜੋ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਇੱਕ ਪਲ ਤੋਂ ਦੂਜੇ ਪਲ ਤੱਕ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਯਾਦ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜੇ ਇੱਕ ਯੂਜ਼ਰ ਚੈਟ UI ਵਿੱਚ Send ਤੇ ਕਲਿਕ ਕਰਦਾ ਹੈ, ਤਾਂ ਐਪ ਨੂੰ ਇਹ ਨਹੀਂ ਭੁੱਲਣਾ ਚਾਹੀਦਾ ਕਿ ਉਸने ਕੀ ਲਿਖਿਆ, ਸਹਾਇਕ ਨੇ ਪਹਿਲਾਂ ਕੀ ਜਵਾਬ ਦਿੱਤਾ, ਕੀ ਕੋਈ ਬੇਨਤੀ ਅਜੇ ਚਲ ਰਹੀ ਹੈ, ਜਾਂ ਕਿਹੜੀਆਂ ਸੈਟਿੰਗਜ਼ (ਟੋਨ, ਮਾਡਲ, ਟੂਲ) ਐਨੇਬਲ ਹਨ। ਇਹ ਸਭ ਸਟੇਟ ਹੈ।
ਸਟੇਟ ਬਾਰੇ ਸੋਚਣ ਦਾ ਇਕ ਫਾਇਦੇਮੰਦ ਤਰੀਕਾ ਹੈ: ਐਪ ਦੀ ਮੌਜੂਦਾ ਹਕੀਕਤ—ਉਹ ਮੁੱਲ ਜੋ ਦੇਖਣ ਅਤੇ ਅਗਲਾ ਕਦਮ ਕਰਨ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦੇ ਹਨ। ਇਸ ਵਿੱਚ ਆਮ ਗੱਲਾਂ ਜਿਵੇਂ ਫਾਰਮ ਇਨਪੁੱਟਸ ਸ਼ਾਮਲ ਹਨ, ਪਰ ਇੱਥੇ ਕੁਝ “ਅਦ੍ਰਿਸ਼ਟ” ਤੱਥ ਵੀ ਹਨ, ਜਿਵੇਂ:
ਪ੍ਰੰਪਰਾਗਤ ਐਪ ਅਕਸਰ ਡੇਟਾ ਪੜ੍ਹਦੇ, ਦਿਖਾਉਂਦੇ ਅਤੇ ਅਪਡੇਟ ਸੇਵ ਕਰਦੇ ਹਨ। ਏਆਈ ਐਪ ਇਸ ਵਿੱਚ ਵਾਧੂ ਕਦਮ ਅਤੇ ਅੰਤਰਿਮ ਆਉਟਪੁੱਟ ਜੋੜਦੇ ਹਨ:
ਇਹ ਵਾਧੂ ਗਤੀ ਕਾਰਨ ਹੀ ਸਟੇਟ ਪ੍ਰਬੰਧਨ ਅਕਸਰ ਏਆਈ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਛੁਪਾ ਹੋਇਆ ਜਟਿਲਤਾ ਬਣ ਜਾਂਦਾ ਹੈ।
ਅੱਗੇ ਵਾਲੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਅਸੀਂ ਸਟੇਟ ਨੂੰ ਪ੍ਰਯੋਗਿਕ ਵਰਗਾਂ ਵਿੱਚ ਵੰਡਾਂਗੇ (UI ਸਟੇਟ, ਸੈਸ਼ਨ ਸਟੇਟ, ਪਾਇਦਾਰ ਡੇਟਾ, ਅਤੇ ਮਾਡਲ/ਰਨਟਾਈਮ ਸਟੇਟ), ਅਤੇ ਦਿਖਾਵਾਂਗੇ ਕਿ ਹਰ ਇੱਕ ਕਿੱਥੇ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ (ਫਰੰਟਐਂਡ ਵਿਰੁੱਧ ਬੈਕਐਂਡ)। ਅਸੀਂ ਸਿੰਕਿੰਗ, ਕੈਸ਼ਿੰਗ, ਲੰਮੀ ਚੱਲਣ ਵਾਲੀਆਂ ਨੌਕਰੀਆਂ, ਸਟ੍ਰੀਮਿੰਗ ਅਪਡੇਟ ਅਤੇ ਸੁਰੱਖਿਆ ਵੀ ਕਵਰ ਕਰਾਂਗੇ—ਕਿਉਂਕਿ ਸਟੇਟ ਤਦ ਹੀ ਲਾਭਦਾਇਕ ਹੈ ਜਦੋਂ ਇਹ ਸਹੀ ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੋਵੇ।
ਕਲਪਨਾ ਕਰੋ ਇੱਕ ਚੈਟ ਐਪ ਦੀ ਜਿੱਥੇ ਯੂਜ਼ਰ ਪੁੱਛਦਾ ਹੈ: “ਪਿਛਲੇ ਮਹੀਨੇ ਦੇ ਇਨਵੌਇਸ ਸੰਖੇਪ ਕਰੋ ਅਤੇ ਕੋਈ ਅਸਾਧਾਰਣ ਚੀਜ਼ ਚਿੰਨ੍ਹਿਤ ਕਰੋ।” ਬੈਕਐਂਡ ਹੋ ਸਕਦਾ ਹੈ (1) ਇਨਵੌਇਸ ਲਿਆਵੇ, (2) ਇਕ ਵਿਸ਼ਲੇਸ਼ਣ ਟੂਲ ਚੱਲਾਏ, (3) ਸੰਖੇਪ UI ਨੂੰ ਸਟ੍ਰੀਮ ਕਰਕੇ ਭੇਜੇ, ਅਤੇ (4) ਅਖੀਰਕਾਰ ਰਿਪੋਰਟ ਸੇਵ ਕਰ ਦੇਵੇ।
ਇਹ ਸਹੀ ਤਰ੍ਹਾਂ seamless ਮਹਿਸੂਸ ਕਰਨ ਲਈ, ਐਪ ਨੂੰ ਸੁਨੇਹਿਆਂ, ਟੂਲ ਨਤੀਜਿਆਂ, ਪ੍ਰਗਤੀ, ਅਤੇ ਸੇਵ ਕੀਤੇ ਆਉਟਪੁੱਟ ਦਾ ਟ੍ਰੈਕ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ—ਬਿਨਾਂ ਗੱਲਬਾਤਾਂ ਨੂੰ ਗਲਤ ਮਿਲਾਉਣ ਜਾਂ ਯੂਜ਼ਰਾਂ ਵਿਚਕਾਰ ਡੇਟਾ ਲੀਕ ਕਰਨ ਦੇ।
ਲੋਕ ਜਦੋਂ ਇੱਕ ਏਆਈ ਐਪ ਵਿੱਚ “ਸਟੇਟ” ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਨ, ਉਹ ਅਕਸਰ ਬਹੁਤ ਵੱਖ-ਵੱਖ ਚੀਜ਼ਾਂ ਨੂੰ ਮਿਲਾ ਦਿੰਦੇ ਹਨ। ਸਟੇਟ ਨੂੰ ਚਾਰ ਪਰਤਾਂ ਵਿੱਚ ਵੰਡਣਾ—UI, ਸੈਸ਼ਨ, ਡੇਟਾ, ਅਤੇ ਮਾਡਲ/ਰਨਟਾਈਮ—ਇਹ ਧਾਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਕਿਸ ਚੀਜ਼ ਨੂੰ ਕਿੱਥੇ ਰੱਖਣਾ ਹੈ, ਕੌਣ ਬਦਲ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਿਵੇਂ ਸਟੋਰ ਕੀਤਾ ਜਾਵੇ।
UI ਸਟੇਟ ਬ੍ਰਾਾਊਜ਼ਰ ਜਾਂ ਮੋਬਾਈਲ ਐਪ ਵਿੱਚ ਜਿਓਂ-ਦੀ-ਜਿਓਂ ਰਹਿਣ ਵਾਲੀ ਸਥਿਤੀ ਹੁੰਦੀ ਹੈ: ਟੈਕਸਟ ਇਨਪੁੱਟ, ਟੋਗਲ, ਚੁਣੇ ਹੋਏ ਆਈਟਮ, ਖੁੱਲ੍ਹੀ ਟੈਬ, ਅਤੇ ਕਿ ਬਟਨ ਡਿਸੇਬਲ ਹੈ ਜਾਂ ਨਹੀਂ।
ਏਆਈ ਐਪ ਕੁਝ UI-ਖਾਸ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜੋੜਦੇ ਹਨ:
UI ਸਟੇਟ ਨੂੰ ਰੀਸੈਟ ਕਰਨਾ ਆਸਾਨ ਅਤੇ ਖੋ ਜਾਣ ਲਈ ਸੁਰੱਖਿਅਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਯੂਜ਼ਰ ਪੇਜ ਰੀਫ੍ਰੇਸ਼ ਕਰ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਹ ਗੁਆ ਸਕਦੇ ਹੋ—ਅਕਸਰ ਇਹ ਠੀਕ ਹੁੰਦਾ ਹੈ।
ਸੈਸ਼ਨ ਸਟੇਟ ਯੂਜ਼ਰ ਨੂੰ ਇਕ ਚੱਲ ਰਹੀ ਇੰਟਰੈਕਸ਼ਨ ਨਾਲ ਜੋੜਦਾ ਹੈ: ਯੂਜ਼ਰ ਪਛਾਣ, ਇੱਕ ਗੱਲਬਾਤ ID, ਅਤੇ ਸੁਨੇਹਾ ਇਤਿਹਾਸ ਦੀ ਇਕ ਸੰਗਤ ਦ੍ਰਿਸ਼ਟੀ।
ਏਆਈ ਐਪ ਵਿੱਚ, ਇਹ ਅਕਸਰ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ:
ਇਹ ਪੱਧਰ ਆਮ ਤੌਰ 'ਤੇ ਫਰੰਟਐਂਡ ਅਤੇ ਬੈਕਐਂਡ ਦੋਹਾਂ 'ਚ ਫੈਲਿਆ ਹੁੰਦਾ ਹੈ: ਫਰੰਟਐਂਡ ਹਲਕੇ-ਫੁਲਕੇ ਆਈਡੈਂਟੀਫਾਇਰ ਰੱਖਦਾ ਹੈ, ਜਦਕਿ ਬੈਕਐਂਡ ਸੈਸ਼ਨ ਲਗਾਤਾਰਤਾ ਅਤੇ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਲਈ ਪ੍ਰਮਾਣਿਕ ਹੁੰਦਾ ਹੈ।
ਡੇਟਾ ਸਟੇਟ ਉਹ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਜਾਣਬੂਝ ਕੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕਰਦੇ ਹੋ: ਪ੍ਰੋਜੈਕਟ, ਡੌਕੂਮੈਂਟ, ਐਮਬੈੱਡਿੰਗ, ਪ੍ਰੈਫਰੰਸ, ਆਡੀਟ ਲਾਗ, ਬਿਲਿੰਗ ਘਟਨਾਵਾਂ, ਅਤੇ ਸੇਵ ਕੀਤੇ ਗੱਲਬਾਤ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ।
UI ਅਤੇ ਸੈਸ਼ਨ ਸਟੇਟ ਦੇ ਉਲਟ, ਡੇਟਾ ਸਟੇਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਮਾਡਲ/ਰਨਟਾਈਮ ਸਟੇਟ ਉਹ ਆਪਰੇਸ਼ਨਲ ਸੈਟਅਪ ਹੈ ਜੋ ਜਵਾਬ ਬਣਾਉਂਦਾ ਹੈ: ਸਿਸਟਮ ਪ੍ਰੌਮਪਟ, ਐਨੇਬਲਡ ਟੂਲ, ਟੈਮਪਰੇਚਰ/ਮੈਕਸ ਟੋਕਨ, ਸੇਫਟੀ ਸੈਟਿੰਗਜ਼, ਰੇਟ ਲਿਮਿਟ ਅਤੇ ਅਸਥਾਈ ਕੈਸ਼।
ਇਸ ਦਾ ਕੁਝ ਹਿੱਸਾ ਕੰਫਿਗਰੇਸ਼ਨ ਹੁੰਦਾ ਹੈ (ਸਥਿਰ ਡੀਫੌਲਟ); ਕੁਝ ਅਸਥਾਈ ਹੁੰਦਾ ਹੈ (ਛੋਟੇ ਸਮੇਂ ਵਾਲੇ ਕੈਸ਼ ਜਾਂ ਪ੍ਰਤੀ-ਅਨੁਰੋਧ ਟੋਕਨ ਬਜਟ)। ਜ਼ਿਆਦਾਤਰ ਇਹ ਬੈਕਐਂਡ 'ਤੇ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਇਸ ਨੂੰ ਸਥਿਰਤਾ ਨਾਲ ਕੰਟਰੋਲ ਕੀਤਾ ਜਾ ਸਕੇ ਅਤੇ ਜ਼ਰੂਰਤ ਤੋਂ ਵੱਧ ਖੁਲਾਸਾ ਨਾ ਹੋਵੇ।
ਜਦੋਂ ਇਹ ਪੱਧਰ ਗੁੰਝਲੇ ਹੋ ਜਾਂਦੇ ਹਨ, ਤੁਹਾਨੂੰ ਆਮ ਫੇਲੀਆਂ ਮਿਲਦੀਆਂ ਹਨ: UI ਉਹ ਦਿਖਾ ਰਿਹਾ ਹੈ ਜੋ ਸੇਵ ਨਹੀਂ ਹੋਇਆ, ਬੈਕਐਂਡ ਵੱਖਰਾ ਪ੍ਰੌਮਪਟ ਸੈਟ ਕਰਦਾ ਹੈ ਜਿੰਨਾ ਫਰੰਟਐਂਡ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਜਾਂ ਗੱਲਬਾਤ ਮੈਮੋਰੀ ਇੱਕ ਯੂਜ਼ਰ ਤੋਂ ਦੂਜੇ ਵਿੱਚ ਲੀਕ ਹੋ ਜਾਂਦੀ ਹੈ। ਸਾਫ ਹੱਦਬੰਦੀ ਇਕ ਸਪਸ਼ਟ ਸਤ੍ਹਾ-of-truth ਬਣਾਉਂਦੀ ਹੈ—ਅਤੇ ਇਹ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਕੀ ਸਥਿਰ ਰਹਿਣਾ ਹੈ, ਕੀ ਦੁਬਾਰਾ ਗਣਨਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੀ ਸੁਰੱਖਿਅਤ ਰੱਖਣਾ ਹੈ।
ਏਆਈ ਐਪਾਂ ਵਿੱਚ ਤਰੁਟੀਆਂ ਘਟਾਉਣ ਦਾ ਇੱਕ ਭਰੋਸੇਯੋਗ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਹਰ ਇੱਕ ਸਟੇਟ ਟੁਕੜੇ ਲਈ ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ ਇਹ ਕਿੱਥੇ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ: ਬ੍ਰਾਉਜ਼ਰ (ਫਰੰਟਐਂਡ), ਸਰਵਰ (ਬੈਕਐਂਡ), ਜਾਂ ਦੋਹਾਂ ਵਿੱਚ। ਇਹ ਚੋਣ ਭਰੋਸੇਯੋਗਤਾ, ਸੁਰੱਖਿਆ, ਅਤੇ ਇਸ ਗੱਲ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦੀ ਹੈ ਕਿ ਯੂਜ਼ਰ ਜਦੋਂ ਰੀਫ੍ਰੇਸ਼ ਕਰਦਾ ਹੈ, ਨਵੀਂ ਟੈਬ ਖੋਲ੍ਹਦਾ ਹੈ, ਜਾਂ ਨੈੱਟਵਰਕ ਗੁਆ ਦਿੰਦਾ ਹੈ ਤਾਂ ਐਪ ਕਿੰਨਾ “ਹੈਰਾਨ” ਮਹਿਸੂਸ ਹੋਵੇਗਾ।
ਫਰੰਟਐਂਡ ਸਟੇਟ ਉਹ ਚੀਜ਼ਾਂ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੀਆਂ ਹਨ ਅਤੇ ਰੀਫ੍ਰੈਸ਼ ਸਹਿਣੀ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇਸ ਨੂੰ ਲੋਕਲ ਰੱਖਣ ਨਾਲ UI ਤੇਜ਼ ਬਣਦੀ ਹੈ ਅਤੇ ਜ਼ਰੂਰੀ API ਕਾਲਾਂ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਆਮ ਫਰੰਟਐਂਡ-ਕੇਵਲ ਉਦਾਹਰਣ:
ਜੇ ਤੁਸੀਂ ਇਹ ਸਟੇਟ ਰੀਫ੍ਰੇਸ਼ 'ਤੇ ਗੁਆ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਕਬੂਲੀਯੋਗ ਹੁੰਦਾ ਹੈ।
ਬੈਕਐਂਡ ਸਟੇਟ ਉਹ ਸਮਭਾਲੇ ਕਿ ਜਿਹੜੀ ਚੀਜ਼ ਭਰੋਸੇਯੋਗ, ਆਡੀਟਯੋਗ ਜਾਂ ਲਾਗੂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਉਹ ਸਟੇਟ ਆਉਂਦਾ ਹੈ ਜੋ ਹੋਰ ਡਿਵਾਈਸ/ਟੈਬ ਵੀ ਦੇਖਣ ਚਾਹੀਦੇ ਹਨ, ਜਾਂ ਜੋ ਕਲਾਇੰਟ ਬਦਲਣ 'ਤੇ ਸਹੀ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ।
ਆਮ ਬੈਕਐਂਡ-ਕੇਵਲ ਉਦਾਹਰਣ:
ਇੱਕ ਵਧੀਆ ਮਨੋਭਾਵ: ਜੇ ਗਲਤ ਸਟੇਟ ਪੈਸਾ ਖ਼ਰਚ ਹੋਵਾ ਸਕਦਾ ਹੈ, ਡੇਟਾ ਲੀਕ ਹੋ ਸਕਦੀ ਹੈ, ਜਾਂ ਪਹੁੰਚ ਟੁੱਟ ਸਕਦੀ ਹੈ, ਤਾਂ ਇਹ ਬੈਕਐਂਡ 'ਤੇ ਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਕੁਝ ਸਟੇਟ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਸਾਂਝੇ ਹੁੰਦੇ ਹਨ:
ਜਦੋਂ ਸਾਂਝਾ ਹੋ, ਤਬ ਵੀ ਇੱਕ “ਸਰੋਤ-of-truth” ਚੁਣੋ। ਆਮ ਤੌਰ 'ਤੇ ਬੈਕਐਂਡ ਪ੍ਰਮਾਣਿਕ ਹੁੰਦਾ ਹੈ ਅਤੇ ਫਰੰਟਐਂਡ ਤੇਜ਼ੀ ਲਈ ਕੈਸ਼ ਰੱਖਦਾ ਹੈ।
ਸਟੇਟ ਨੂੰ ਉਸ ਥਾਂ ਨੇੜੇ ਰੱਖੋ ਜਿੱਥੇ ਇਸਦੀ ਲੋੜ ਹੈ, ਪਰ ਜੋ ਕਈ ਡਿਵਾਈਸ/ਰੀਫ੍ਰੇਸ਼/ਰੁਕਾਵਟ ਤੋਂ ਬਾਅਦ ਬਣਿਆ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਉਸਨੂੰ ਪਾਇਦਾਰ ਰੱਖੋ।
ਇਕ ਆਮ ਗਲਤੀ: ਪ੍ਰਮਾਣਿਕ ਜਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਸਟੇਟ ਸਿਰਫ ਬਰਾਊਜ਼ਰ ਵਿੱਚ ਰੱਖਣਾ (ਉਦਾਹਰਣ ਲਈ, ਕਲਾਇੰਟ-ਸਾਈਡ isAdmin ਫਲੈਗ, ਯੋਜਨਾ ਟੀਅਰ, ਜਾਂ ਨੌਕਰੀ ਸਫਲਤਾ ਸਟੇਟ) ਨੂੰ ਸੱਚ ਮੰਨਣਾ। UI ਇਹ ਮੁੱਲ ਦਿਖਾ ਸਕਦਾ ਹੈ, ਪਰ ਬੈਕਐਂਡ ਨੂੰ ਇਹ ਵੇਰਫਾਈ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਏਆਈ ਫੀਚਰ ਇੱਕ ਕਾਰਵਾਈ ਵਾਂਗ ਨਹੀਂ ਹੁੰਦੀ; ਇਹ ਦਰਅਸਲ ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਸਰਵਰ ਵਿੱਚ ਸਾਂਝੇ ਸਟੇਟ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨਾਂ ਦੀ ਇੱਕ ਲੜੀ ਹੁੰਦੀ ਹੈ। ਲਾਈਫਸਾਇਕਲ ਨੂੰ ਸਮਝਣਾ ਮਿਸ਼ਮੈਚਡ UI, ਗੁੰਮ ਸੰਦਰਭ, ਅਤੇ ਡੁਪਲਿਕੇਟ ਚਾਰਜਾਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਯੂਜ਼ਰ Send 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ। UI ਤੁਰੰਤ ਲੋਕਲ ਸਟੇਟ ਅਪਡੇਟ ਕਰਦਾ ਹੈ: ਇੱਕ “ਪੈਂਡਿੰਗ” ਸੁਨੇਹਾ ਬਬਲ ਜੋੜ ਸਕਦਾ ਹੈ, ਸੈਂਡ ਬਟਨ ਡਿਸੇਬਲ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਮੌਜੂਦਾ ਇਨਪੁੱਟ (ਟੈਕਸਟ, ਅਟੈਚਮੈਂਟ, ਚੁਣੇ ਹੋਏ ਟੂਲ) ਕੈਪਚਰ ਕਰ ਲੈਂਦਾ ਹੈ।
ਇਸ ਵੇਲੇ ਫਰੰਟਐਂਡ ਨੂੰ ਕੋਰੈਲੇਸ਼ਨ ਆਈਡੀ ਜਨਰੇਟ ਜਾਂ ਅਟੈਚ ਕਰ ਲੈਣੇ ਚਾਹੀਦੇ ਹਨ:
conversation_id: ਇਹ ਕਿਸ ਥ੍ਰੈਡ ਨਾਲ ਸਬੰਧਿਤ ਹੈmessage_id: ਕਲਾਇੰਟ ਦੀ ਨਵੀਂ ਯੂਜ਼ਰ ਸੁਨੇਹੇ ਲਈ IDrequest_id: ਹਰ ਕੋਸ਼ਿਸ਼ ਲਈ ਵਿਲੱਖਣ (ਰੀਟ੍ਰਾਈ ਲਈ ਲਾਭਦਾਇਕ)ਇਹ ID ਦੋਹਾਂ ਪਾਸਿਆਂ ਨੂੰ ਇਕੋ ਘਟਨਾ ਬਾਰੇ ਗੱਲ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾ ਦਿੰਦੇ ਹਨ—ਭਾਵੇਂ ਜਵਾਬ ਦੇਰੀ ਨਾਲ ਆਏ ਜਾਂ ਦੋ ਵਾਰੀ ਆ ਜਾਵੇ।
ਫਰੰਟਐਂਡ ਇੱਕ API ਬੇਨਤੀ ਭੇਜਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਯੂਜ਼ਰ ਸੁਨੇਹਾ ਅਤੇ ID ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਸਰਵਰ ਅਧਿਕਾਰ, ਰੇਟ ਲਿਮਿਟ, ਅਤੇ ਪੇਲੋਡ ਸ਼ੇਪ ਵੇਰਿਫ਼ਾਈ ਕਰਦਾ ਹੈ, ਫਿਰ ਯੂਜ਼ਰ ਸੁਨੇਹੇ ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ (ਜਾਂ ਘੱਟੋ ਘੱਟ ਇੱਕ ਅਪਰਿਵਰਤਨਸ਼ੀਲ ਲਾਗ ਰਿਕਾਰਡ) ਜੋ conversation_id ਅਤੇ message_id ਨਾਲ ਕੀਡ ਕੀਤਾ ਗਿਆ ਹੁੰਦਾ ਹੈ।
ਇਹ ਪਾਇਸਤ ਕਦਮ “ਫੈਂਟਮ ਇਤਿਹਾਸ” ਤੋਂ ਰੋਕਦਾ ਹੈ ਜਦੋਂ ਯੂਜ਼ਰ ਮੱਧ-ਬੇਨਤੀ ਰਿਹਰਫਰੇਸ਼ ਕਰਦਾ ਹੈ।
ਮਾਡਲ ਨੂੰ ਕਾਲ ਕਰਨ ਲਈ, ਸਰਵਰ ਆਪਣੇ ਸਰੋਤ-of-truth ਤੋਂ ਸੰਦਰਭ ਦੁਬਾਰਾ ਬਣਾਉਂਦਾ ਹੈ:
conversation_id ਲਈ ਹਾਲੀਆ ਸੁਨੇਹੇ ਫੈਚ ਕਰੋਮੁੱਖ ਵਿਚਾਰ: ਕਲਾਇੰਟ 'ਤੇ ਪੂਰਾ ਇਤਿਹਾਸ ਭਰੋਸਾ ਨਾ ਕਰੋ। ਕਲਾਇੰਟ ਪੁਰਾਣਾ ਹੋ ਸਕਦਾ ਹੈ।
ਸਰਵਰ ਮਾਡਲ ਕਾਲ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂ ਦੌਰਾਨ ਟੂਲ (ਸਰਚ, ਡੇਟਾਬੇਸ ਲੁੱਕਅਪ) ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ। ਹਰ ਟੂਲ ਕਾਲ ਅੰਤਰਿਮ ਸਟੇਟ ਪੈਦਾ ਕਰਦੀ ਹੈ ਜਿਸਨੂੰ request_id ਨਾਲ ਟ੍ਰੈਕ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਇਸਨੂੰ ਆਡੀਟ ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਰੀਪਲੇ/ਰੀਟ੍ਰਾਈ ਕੀਤਾ ਜਾ ਸਕੇ।
ਸਟ੍ਰੀਮਿੰਗ ਨਾਲ, ਸਰਵਰ ਹਿੱਸੇ-ਹਿੱਸੇ ਟੋਕਨ/ਈਵੈਂਟ ਭੇਜਦਾ ਹੈ। UI ਪੈਂਡਿੰਗ ਸਹਾਇਕ ਸੁਨੇਹਾ ਨੂੰ ਧੀਰੇ-ਧੀਰੇ ਅਪਡੇਟ ਕਰਦਾ ਹੈ, ਪਰ ਅਜੇ ਵੀ ਇਸਨੂੰ “ਚੱਲ ਰਿਹਾ” ਸਮਝਦਾ ਹੈ ਜਦ ਤੱਕ ਇੱਕ ਅਖੀਰੀ ਈਵੈਂਟ ਮੁਕੰਮਲ ਹੋਣ ਦਾ ਪਤਾ ਨਾ ਦੱਸੇ।
ਰੀਟ੍ਰਾਈਜ਼, ਡਬਲ-ਸਬਮਿਟਸ, ਅਤੇ ਆਉਟ-ਆਫ-ਆਰਡਰ ਜਵਾਬ ਹੁੰਦੇ ਹਨ। ਸਰਵਰ 'ਤੇ dedupe ਲਈ request_id ਵਰਤੋ, ਅਤੇ UI ਵਿੱਚ reconcile ਲਈ message_id ਵਰਤੋ (ਐਕਟਿਵ ਰਿਕਵੇਸਟ ਨਾਲ ਮਿਲਦੇ ਨਾ ਹੋਏ ਵਲਦੇ ਚੰਕਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰੋ)। ਹਮੇਸ਼ਾਂ ਇੱਕ ਸਾਫ਼ “ਫੇਲਡ” ਸਥਿਤੀ ਦਿਖਾਓ ਅਤੇ ਇੱਕ ਸੁਰੱਖਿਅਤ ਰੀਟ੍ਰਾਈ ਦਿਓ ਜੋ ਡੁਪਲਿਕੇਟ ਸੁਨੇਹੇ ਨਾ ਬਣਾਵੇ।
ਇੱਕ ਸੈਸ਼ਨ ਉਹ “ਥ੍ਰੈਡ” ਹੈ ਜੋ ਯੂਜ਼ਰ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਜੋੜਦਾ ਹੈ: ਉਹ ਵਰਕਸਪੇਸ ਜਿਸ ਵਿੱਚ ਉਹ ਹਨ, ਉਹਨਾਂ ਨੇ ਆਖਿਰਕਾਰ ਕੀ ਖੋਜਿਆ, ਕਿਹੜਾ ਡ੍ਰਾਫਟ ਉਹ ਸੋਧ ਰਹੇ ਸਨ, ਅਤੇ ਕਿ ਕਿਹੜੀ ਗੱਲਬਾਤ ਨੂੰ ਏਆਈ ਉੱਤਰ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। ਚੰਗੀ ਸੈਸ਼ਨ ਸਟੇਟ ਐਪ ਨੂੰ ਪੰਨਿਆਂ ਪਾਰ ਲਗਾਤਾਰ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ ਹੈ—ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਡਿਵਾਈਸਾਂ 'ਤੇ ਵੀ—ਬਿਨਾਂ ਤੁਹਾਡੇ ਬੈਕਐਂਡ ਨੂੰ ਯੂਜ਼ਰ ਦੀ ਹਰ ਗੱਲ ਬੇਕਾਰ ਤੌਰ 'ਤੇ ਸਾਂਭਣ ਵਾਲਾ ਬਣਾਉਣ ਦੇ।
ਲਕਸ਼ ਹੋਣ ਚਾਹੀਦੇ ਹਨ: (1) ਲਗਾਤਾਰਤਾ (ਯੂਜ਼ਰ ਛੱਡ ਕੇ ਵਾਪਸ ਆ ਸਕੇ), (2) ਸਹੀਤਾ (ਏਆਈ ਸਹੀ ਗੱਲਬਾਤ ਲਈ ਸਹੀ ਸੰਦਰਭ ਵਰਤਦਾ ਹੈ), ਅਤੇ (3) ਸੰਚਾਰ containment (ਇੱਕ ਸੈਸ਼ਨ ਦੂਜੇ ਵਿੱਚ ਲੀਕ ਨਾ ਹੋਵੇ)। ਜੇ ਤੁਸੀਂ ਕਈ ਡਿਵਾਈਸ ਸਹਾਇਤਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਸੈਸ਼ਨਾਂ ਨੂੰ ਯੂਜ਼ਰ-ਸਕੋਪ ਕੀਤਾ ਅਤੇ ਡਿਵਾਈਸ-ਸਕੋਪ ਵੀ ਸੋਚੋ: “ਉਹੀ ਅਕਾਊਂਟ” ਮਤਲਬ ਹਮੇਸ਼ਾਂ “ਉਹੀ ਖੁੱਲ੍ਹਾ ਵਰਕ” ਨਹੀਂ ਹੁੰਦਾ।
ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਢੰਗ ਚੁਣਦੇ ਹੋ ਜਿਨ੍ਹਾਂ ਨਾਲ ਸੈਸ਼ਨ ਦੀ ਪਹਿਚਾਣ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:
HttpOnly, Secure, SameSite) ਅਤੇ CSRF ਹੈਂਡਲਿੰਗ ਨੂੰ ਹੱਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।“ਮੈਮੋਰੀ” ਸਿਰਫ ਉਹ ਸਟੇਟ ਹੈ ਜੋ ਤੁਸੀਂ ਮਾਡਲ ਵਿੱਚ ਵਾਪਸ ਭੇਜਣਾ ਚੁਣਦੇ ਹੋ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਪੈਟਰਨ ਹੈ ਸੰਖੇਪ + ਵਿੰਡੋ: ਇਹ ਪੇਸ਼ਗੋਈਯੋਗ ਹੈ ਅਤੇ ਮਾਡਲ ਦੇ ਹੈਰਾਨ ਕਰਨ ਵਾਲੇ ਵਿਹਾਰ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਜੇ ਏਆਈ ਟੂਲ ਵਰਤਦਾ ਹੈ (ਸਰਚ, ਡੇਟਾਬੇਸ ਕ੍ਵੈਰੀ, ਫਾਇਲ ਰੀਡ), ਹਰ ਟੂਲ ਕਾਲ ਨੂੰ ਇੰਪੁੱਟ, ਟਾਈਮਸਟੈਂਪ, ਟੂਲ ਵੇਰਜ਼ਨ, ਅਤੇ ਵਾਪਸ ਆਏ ਨਤੀਜੇ (ਜਾਂ ਉਸਦਾ ਰੈਫਰੈਂਸ) ਨਾਲ ਸਟੋਰ ਕਰੋ। ਇਸ ਨਾਲ ਤੁਸੀਂ ਦਿਖਾ ਸਕਦੇ ਹੋ “ਏਆਈ ਨੇ ਕਿਉਂ ਇਹ ਕਿਹਾ”, ਡੀਬੱਗ ਲਈ ਰਨ ਰੀਪਲੇ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਨਤੀਜੇ तबਦੀਲ ਹੋਏ ਹਨ ਕਿਉਂਕਿ ਟੂਲ ਜਾਂ ਡੇਟਾਸੈੱਟ ਬਦਲ ਗਿਆ।
ਲੰਬੇ ਸਮੇਂ ਦੀ ਮੈਮੋਰੀ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਸਟੋਰ ਨਾ ਕਰੋ। ਸਿਰਫ ਓਹੀ ਰੱਖੋ ਜੋ ਲਗਾਤਾਰਤਾ ਲਈ ਲੋੜੀਂਦਾ ਹੈ (ਗੱਲਬਾਤ IDs, ਸੰਖੇਪ, ਅਤੇ ਟੂਲ ਲਾਗ), ਰੀਟੇਂਸ਼ਨ ਸੀਮਾਵਾਂ ਸੈੱਟ ਕਰੋ, ਅਤੇ ਕੱਚਾ ਯੂਜ਼ਰ ਟੈਕਸਟ ਸੇਵ ਕਰਨ ਤੋਂ ਬਚੋ ਜਦ ਤੱਕ ਸਪੱਸ਼ਟ ਉਤਪਾਦ ਕਾਰਨ ਅਤੇ ਯੂਜ਼ਰ ਦੀ ਸਹਿਮਤੀ ਨਾ ਹੋਵੇ।
ਜਦੋਂ ਇੱਕੋ “ਚੀਜ਼” ਨੂੰ ਕਈ ਥਾਵਾਂ 'ਤੇ ਸੋਧਿਆ ਜਾ ਸਕਦਾ ਹੈ—ਤੁਹਾਡਾ UI, ਦੂਜੀ ਬਰਾਊਜ਼ਰ ਟੈਬ, ਜਾਂ ਇੱਕ ਬੈਕਗ੍ਰਾਊਂਡ ਨੌਕਰੀ—ਤਦ ਸਟੇਟ ਖ਼ਤਰਨਾਕ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਸਦਾ ਹੱਲ ਬਹੁਤ ਵਧੀਆ ਕੋਡ ਤੋਂ ਵੱਧ ਸਪਸ਼ਟ ਮਾਲਕੀਅਤ ਵਿੱਚ ਹੈ।
ਹਰ ਸਟੇਟ ਟੁਕੜੇ ਲਈ ਨਿਸ਼ਚਤ ਕਰੋ ਕਿ ਕਿਹੜੀ ਪ੍ਰਣਾਲੀ ਪ੍ਰਮਾਣਿਕ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਏਆਈ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਬੈਕਐਂਡ ਉਹ canonical ਰਿਕਾਰਡ ਰੱਖਦਾ ਹੈ: ਗੱਲਬਾਤ ਸੈਟਿੰਗਜ਼, ਟੂਲ ਅਨੁਮਤੀਆਂ, ਸੁਨੇਹਾ ਇਤਿਹਾਸ, ਬਿਲਿੰਗ ਸੀਮਾਵਾਂ, ਅਤੇ ਨੌਕਰੀ ਸਥਿਤੀ। ਫਰੰਟਐਂਡ ਤੇਜ਼ੀ ਲਈ ਕੈਸ਼ ਰੱਖ ਸਕਦਾ ਹੈ (ਚੁਣੀ ਟੈਬ, ਡ੍ਰਾਫਟ ਟੈਕਸਟ, “ਲਿਖ ਰਿਹਾ ਹੈ” ਸੰਕੇਤ), ਪਰ ਜਦੋਂ ਗ਼ਲਤ ਹੋਵੇ ਤਾਂ ਬੈਕਐਂਡ ਸਹੀ ਮੰਨੋ।
ਇਕ ਪ੍ਰਯੋਗਿਕ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਰੀਫ੍ਰੇਸ਼ 'ਤੇ ਇਸਨੂੰ ਖੋ ਦੇਣ 'ਤੇ ਉਦਾਸ ਹੋਵੋਗੇ, ਤਾਂ ਇਹ ਸੰਭਵਤ: ਬੈਕਐਂਡ 'ਤੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
Optimistic ਅਪਡੇਟ ਐਪ ਨੂੰ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੇ ਹਨ: ਸੈਟਿੰਗ ਟੌਗਲ ਕਰੋ, UI ਤੁਰੰਤ ਅਪਡੇਟ ਹੋ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਸਰਵਰ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ। ਇਹ ਘੱਟ-ਖਤਰਨਾਕ ਅਤੇ ਵਾਪਸ-ਲੈਣਯੋਗ ਕਾਰਵਾਈਆਂ (ਜਿਵੇਂ conversation ਨੂੰ starring) ਲਈ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ।
ਜਦੋਂ ਸਰਵਰ ਰਿਜੈਕਟ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਬਦਲ ਸਕਦਾ ਹੈ (ਅਧਿਕਾਰ ਜਾਂ ਕੋਟਾ ਜਾਂ ਵੈਧਤਾ), ਤਾਂ ਇਹ ਉਲਝਣ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਐਸੇ ਮਾਮਲਿਆਂ ਵਿੱਚ “saving…” ਸਥਿਤੀ ਦਿਖਾਓ ਅਤੇ ਸਿਰਫ ਪੁਸ਼ਟੀ ਹੋਣ ਉੱਪਰ UI ਅਪਡੇਟ ਕਰੋ।
ਸੰਘਰਸ਼ ਹੋਂਦੇ ਹਨ ਜਦੋਂ ਦੋ ਕਲਾਇੰਟ ਇੱਕੋ ਰਿਕਾਰਡ ਨੂੰ ਵੱਖ-ਵੱਖ ਸ਼ੁਰੂਆਤੀ ਵਰਜ਼ਨ 'ਤੇ ਅਪਡੇਟ ਕਰਦੇ ਹਨ। ਆਮ ਉਦਾਹਰਨ: Tab A ਅਤੇ Tab B ਦੋਹਾਂ model temperature ਬਦਲਦੇ ਹਨ।
ਹਲ: ਹਲਕੇ-ਫੁੱਲੇ ਵਰਜ਼ਨਿੰਗ ਵਰਤੋ ਤਾਂ ਕਿ ਬੈਕਐਂਡ stale writes ਪਛਾਣ ਸਕੇ:
updated_at ਟਾਈਮਸਟੈਂਪਸ (ਸਧਾਰਨ, ਮਨੁੱਖ-ਪੜ੍ਹਨਯੋਗ)If-Match ਹੇਡਰ (HTTP-ਨੈਟਿਵ)ਜੇ ਵਰਜ਼ਨ ਮਿਲਦਾ ਨਹੀਂ, ਤਾਂ ਇੱਕ conflict ਜਵਾਬ (ਅਕਸਰ HTTP 409) ਵਾਪਸ ਕਰੋ ਅਤੇ ਨਵਾਂ ਸਰਵਰ ਆਬਜੈਕਟ ਭੇਜੋ।
ਕਿਸੇ ਵੀ ਲਿਖਾਈ ਤੋਂ ਬਾਅਦ, API ਸੇਵ ਕੀਤਾ ਹੋਇਆ ਆਬਜੈਕਟ ਵਾਪਸ ਭੇਜੇ (ਸਰਵਰ-ਜਨਰੇਟ ਕੀਤੇ ਡੀਫੌਲਟ, ਨਾਰਮਲਾਈਜ਼ਡ ਫੀਲਡ, ਅਤੇ ਨਵਾਂ ਵਰਜ਼ਨ ਸਮੇਤ)। ਇਸ ਨਾਲ ਫਰੰਟਐਂਡ ਆਪਣੀ ਕੈਸ਼ ਕੀ ਤੁਰੰਤ ਬਦਲ ਸਕਦਾ ਹੈ—ਇੱਕ ਸਰੋਤ-ਆਫ-ਟ੍ਰੂਥ ਅਪਡੇਟ ਬਣਦਾ ਹੈ ਬਜਾਏ ਇਸਦੇ ਕਿ ਅਨੁਮਾਨ ਲਾਇਆ ਜਾਵੇ ਕਿ ਕੀ ਬਦਲਿਆ।
ਕੈਸ਼ਿੰਗ ਉਹ ਜਲਦੀ ਤਰੀਕਾ ਹੈ ਜੋ ਐਪ ਨੂੰ ਤੇਜ਼ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ ਹੈ, ਪਰ ਇਹ ਦੂਜੀ ਨਕਲ ਦਾ ਰੂਪ ਵੀ ਬਣਾਉਂਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਗਲਤ ਚੀਜ਼ ਕੈਸ਼ ਕਰੋ ਜਾਂ ਗਲਤ ਥਾਂ 'ਤੇ ਰੱਖੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਤੇਜ਼ ਪਰ ਉਲਝਣ ਭਰੀ UI ਭੇਜੋਗੇ।
ਕਲਾਇੰਟ-ਸਾਈਡ ਕੈਸ਼ਾਂ ਅਨੁਭਵ 'ਤੇ ਧਿਆਨ ਦੇਣ: ਚੰਗੇ ਉਮੀਦਵਾਰ ਹਨ ਹਾਲੀਆ ਗੱਲਬਾਤ ਪ੍ਰੀਵਿਊ (ਸਿਰਲੇਖ, ਆਖਰੀ ਸੁਨੇਹਾ), UI ਪਸੰਦਾਂ (ਥੀਮ, ਚੁਣਿਆ ਮਾਡਲ, ਸਾਇਡਬਾਰ ਸਟੇਟ), ਅਤੇ optimistic UI ਸਟੇਟ (ਜੋ ਸੁਨੇਹੇ “ਭੇਜੇ ਜਾ ਰਹੇ” ਦਿਖਦੇ ਹਨ)।
ਕਲਾਇੰਟ ਕੈਸ਼ ਨੂੰ ਛੋਟਾ ਅਤੇ ਨਸ਼ਟਿਯੋਗ ਰੱਖੋ: ਜੇ ਇਹ ਸਾਫ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਐਪ ਸਰਵਰ ਤੋਂ ਫੇਰੋਂ ਫੈਚ ਕਰਕੇ ਵੀ ਕੰਮ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।
ਸਰਵਰ ਕੈਸ਼ ਉਹ ਮਹਿੰਗਾ ਜਾਂ ਬਾਰ-ਬਾਰ ਹੋਣ ਵਾਲੇ ਕੰਮ ਲਈ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਇੱਥੇ ਤੁਸੀਂ ਡੈਰੀਵਡ ਸਟੇਟ ਵੀ ਕੈਸ਼ ਕਰ ਸਕਦੇ ਹੋ ਜਿਵੇਂ ਕਿ ਟੋਕਨ ਗਿਣਤੀ, ਮੋਡਰੇਸ਼ਨ ਫੈਸਲੇ, ਜਾਂ ਡੌਕ ਪਾਰਸਿੰਗ ਆਉਟਪੁੱਟ—ਕੁਝ ਵੀ ਜੋ ਨਿਰਧਾਰਿਤ ਅਤੇ ਮਹਿੰਗਾ ਹੋ।
ਤੀਨ ਵਰਤੋਂਯੋਗ ਨਿਯਮ:
user_id, ਮਾਡਲ, ਟੂਲ ਪੈਰਾਮੀਟਰ, ਡੌਕੂਮੈਂਟ ਵਰਜ਼ਨ)।ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ ਕਿ ਕਦੋਂ ਇੱਕ ਕੈਸ਼ ਐਂਟਰੀ ਗਲਤ ਹੋ ਜਾਵੇਗੀ, ਤਾਂ ਇਸ ਨੂੰ ਕੈਸ਼ ਨਾ ਕਰੋ।
API ਕੀਜ਼, ਅਥੇਂਟੀਕੇਸ਼ਨ ਟੋਕਨ, ਕੱਚੇ ਪ੍ਰੌਮਪਟ ਜੋ ਸੰਵੇਦਨਸ਼ੀਲ ਟੈਕਸਟ ਰੱਖਦੇ ਹਨ, ਜਾਂ ਯੂਜ਼ਰ-ਵਿਸ਼ੇਸ਼ ਸਮੱਗਰੀ ਨੂੰ CDN ਵਰਗੇ ਸਾਂਝੇ ਪੱਧਰਾਂ ਵਿੱਚ ਨਾ ਰੱਖੋ। ਜੇ ਤੁਹਾਨੂੰ ਯੂਜ਼ਰ ਡੇਟਾ ਕੈਸ਼ ਕਰਨੀ ਪੈਂਦੀ ਹੈ, ਤਾਂ ਯੂਜ਼ਰ ਅਨੁਸਾਰ ਅਲੱਗ ਕਰੋ ਅਤੇ ਐਟ-ਰੇਸਟ ਇਨਕ੍ਰਿਪਟ ਕਰੋ—ਜਾਂ ਇਸਨੂੰ ਆਪਣੇ ਪ੍ਰਾਇਮਰੀ ਡੇਟਾਬੇਸ ਵਿੱਚ ਰੱਖੋ।
ਕੈਸ਼ਿੰਗ ਨੂੰ ਪਰਖਿਆ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਮੰਨਿਆ। p95 ਲੈਟੈਂਸੀ ਪਹਿਲਾਂ/ਬਾਅਦ ਵਿੱਚ ਟਰੈਕ ਕਰੋ, ਕੈਸ਼ ਹਿਟ ਰੇਟ, ਅਤੇ ਯੂਜ਼ਰ-ਦਿਖਾਈ ਦੇਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਜਿਵੇਂ “ਸੁਨੇਹਾ ਰੇਂਡਰ ਕਰਨ ਮਗਰੋਂ ਅਪਡੇਟ ਹੋ ਗਿਆ।” ਇੱਕ ਤੇਜ਼ ਜਵਾਬ ਜੋ ਬਾਅਦ ਵਿੱਚ UI ਨਾਲ ਵਿਰੋਧ ਕਰਦਾ ਹੈ, ਅਕਸਰ ਥੋੜਾ ਧੀਮਾਂ ਪਰ ਸਥਿਰ ਜਵਾਬ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਖਰਾਬ ਹੁੰਦਾ ਹੈ।
ਕੁਝ ਏਆਈ ਫੀਚਰ ਇੱਕ ਸਕਿੰਟ ਵਿੱਚ ਮੁਕੰਮਲ ਹੋ ਜਾਂਦੇ ਹਨ। ਹੋਰ ਮਿੰਟਾਂ ਲੈਂਦੇ ਹਨ: PDF ਅੱਪਲੋਡ ਅਤੇ ਪਾਰਸ ਕਰਨਾ, ਨੋਲੇਜ ਬੇਸ ਦਾ ਐਮਬੈੱਡਿੰਗ ਅਤੇ ਇੰਡੈਕਸਿੰਗ, ਜਾਂ ਮਲਟੀ-ਸਟੈਪ ਟੂਲ ਵਰਕਫਲੋ। ਐਸੇ ਲਾਇਨਾਂ ਲਈ, “ਸਟੇਟ” ਸਿਰਫ ਸਕ੍ਰੀਨ 'ਤੇ ਜੋ ਹੈ ਨਹੀਂ—ਇਹ ਉਹ ਹੈ ਜੋ ਰੀਫ੍ਰੇਸ਼, ਰੀਟ੍ਰਾਈ ਅਤੇ ਸਮੇਂ ਵਿੱਚ ਬਚ ਕੇ ਰਹਿੰਦਾ ਹੈ।
ਸਿਰਫ ਉਹੀ ਚੀਜ਼ ਪਾਇਸਤ ਕਰੋ ਜੋ ਵਾਸਤਵਿਕ ਉਤਪਾਦ ਮੁੱਲ ਅਨਲੌਕ ਕਰਦੀ ਹੋਵੇ।
ਗੱਲਬਾਤ ਇਤਿਹਾਸ ਸਭ ਤੋਂ ਸਾਫ਼: ਸੁਨੇਹੇ, ਟਾਈਮਸਟੈਂਪ, ਯੂਜ਼ਰ ਪਛਾਣ, ਅਤੇ ਅਕਸਰ ਕਿ ਕਿਸ ਮਾਡਲ/ਟੂਲ ਦਾ ਉਪਯੋਗ ਕੀਤਾ ਗਿਆ। ਇਹ “ਬਾਅਦ ਵਿੱਚ ਜਾਰੀ ਰੱਖੋ”, ਆਡੀਟ ਟ੍ਰੇਲ, ਅਤੇ ਸਹਾਇਤਾ ਲਈ ਜਰੂਰੀ ਹੈ।
ਯੂਜ਼ਰ ਅਤੇ ਵਰਕਸਪੇਸ ਸੈਟਿੰਗਜ਼ ਡੇਟਾਬੇਸ ਵਿੱਚ ਰਹਿਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਪਸੰਦੀਦਾ ਮਾਡਲ, ਟੈਮਪਰੇਚਰ ਡੀਫੌਲਟ, ਫੀਚਰ ਟੋਗਲ, ਸਿਸਟਮ ਪ੍ਰੌਮਪਟ, ਅਤੇ UI ਪਸੰਦਾਂ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਡਿਵਾਈਸਾਂ 'ਤੇ ਫਾਲੋ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।
ਫਾਇਲਾਂ ਅਤੇ ਆਰਟੀਫੈਕਟ (ਅਪਲੋਡ, ਨਿਕਲਿਆ ਹੋਇਆ ਟੈਕਸਟ, ਜਨਰੇਟ ਕੀਤੇ ਰਿਪੋਰਟ) ਆਮ ਤੌਰ 'ਤੇ ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਵਿੱਚ ਰੱਖੇ ਜਾਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਡੇਟਾਬੇਸ ਰਿਕਾਰਡ ਪੌਇੰਟ ਕਰਦੇ ਹਨ। ਡੇਟਾਬੇਸ ਮੈਟਾ ਡੇਟਾ ਰਖਦਾ ਹੈ (ਓਨਰ, ਸਾਈਜ਼, ਕੰਟੈਂਟ ਟਾਈਪ, ਪ੍ਰੋਸੈਸਿੰਗ ਸਟੇਟ), ਜਦਕਿ ਬਲੋਬ ਸਟੋਰ ਬਾਈਟਸ ਰੱਖਦਾ ਹੈ।
ਜੇ ਕੋਈ ਬੇਨਤੀ ਆਮ HTTP ਟਾਇਮਆਉਟ ਦੀ ਮਿਆਦ ਵਿੱਚ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਖਤਮ ਨਹੀਂ ਹੋ ਸਕਦੀ, ਤਾਂ ਕੰਮ ਨੂੰ ਕਿਊ ਵਿਚ ਭੇਜੋ।
ਇੱਕ ਆਮ ਪੈਟਰਨ:
POST /jobs ਵਰਗਾ API ਕਾਲ ਕਰਦਾ ਹੈ ਇਨਪੁੱਟ (ਫਾਇਲ id, conversation id, ਪੈਰਾਮੀਟਰ) ਦੇ ਕੇ।job_id ਵਾਪਸ ਦੇਂਦਾ ਹੈ।ਇਸ ਨਾਲ UI ਤੇਜ਼ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਰੀਟ੍ਰਾਈਜ਼ ਸੁਰੱਖਿਅਤ ਹੁੰਦੇ ਹਨ।
ਜੌਬ ਸਥਿਤੀ ਨੂੰ explicit ਅਤੇ ਕਵੈਰੀਯੋਗ ਬਣਾਓ: queued → running → succeeded/failed (ਵਿਕਲਪਿਕ ਤੌਰ 'ਤੇ canceled). ਇਹ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਸਰਵਰ-ਸਾਈਡ ਤੇ ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਏਰਰ ਵੇਰਵਿਆਂ ਨਾਲ ਸਟੋਰ ਕਰੋ।
ਫਰੰਟਐਂਡ ਤੇ ਸਥਿਤੀ ਸਾਫ਼ ਦਰਸਾਓ:
GET /jobs/{id} (polling) ਜਾਂ SSE/WebSocket ਵਰਗੇ ਸਟ੍ਰੀਮ ਅਪਡੇਟ ਨੂੰ ਏਕਸਪੋਜ਼ ਕਰੋ ਤਾਂ ਜੋ UI ਨਿਰਧਾਰਤ ਤੌਰ 'ਤੇ ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਵੇ।
ਨੈੱਟਵਰਕ ਟਾਇਮਆਉਟ ਹੁੰਦੇ ਹਨ। ਜੇ ਫਰੰਟਐਂਡ POST /jobs ਰੀਟ੍ਰਾਈ ਕਰੇ, ਤੁਸੀਂ ਦੋ ਇਕੋ ਜੌਬ ਨਹੀਂ ਚਾਹੁੰਦੇ।
ਹਰ ਲਾਜ਼ਮੀ ਕਾਰਵਾਈ ਲਈ Idempotency-Key ਲਾਜ਼ਮੀ ਕਰੋ। ਬੈਕਐਂਡ ਕੀ ਨੂੰ ਨਤੀਜੇ/job_id ਨਾਲ ਸਟੋਰ ਕਰਦਾ ਹੈ ਅਤੇ ਦੁਹਰਾਈਆਂ ਬੇਨਤੀਆਂ ਲਈ ਉਹੀ ਨਤੀਜਾ ਵਾਪਸ ਕਰਦਾ ਹੈ।
ਲੰਬੇ ਸਮੇਂ ਚੱਲਣ ਵਾਲੀਆਂ ਏਆਈ ਐਪ ਤੇਜ਼ੀ ਨਾਲ ਡੇਟਾ ਇਕੱਤਰ ਕਰ ਲੈਂਦੀਆਂ ਹਨ। ਸ਼ੁਰੂ ਵਿੱਚ ਰੀਟੇਨਸ਼ਨ ਨੀਤੀਆਂ ਨਿਰਧਾਰਤ ਕਰੋ:
ਸਾਫਾਈ ਨੂੰ ਸਟੇਟ ਪ੍ਰਬੰਧਨ ਦਾ ਹਿੱਸਾ ਮੰਨੋ: ਇਹ ਖ਼ਤਰੇ, ਕ਼ੀਮਤ, ਅਤੇ ਉਲਝਣ ਘਟਾਉਂਦਾ ਹੈ।
ਸਟ੍ਰੀਮਿੰਗ ਨਾਲ ਸਟੇਟ ਹੋਰ ਜ਼ਿਆਦਾ ਜਟਿਲ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ “ਜਵਾਬ” ਹੁਣ ਇਕਲੇ ਬਲੱਬ ਦੇ ਰੂਪ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦਾ। ਤੁਸੀਂ ਅੰਸ਼ਿਕ ਟੋਕਨ (ਸ਼ਬਦ-ਸ਼ਬਦ ਆਉਂਦੇ ਟੈਕਸਟ) ਅਤੇ ਕਈ ਵਾਰ ਅੰਸ਼ਿਕ ਟੂਲ ਵਰਕ ਦੇ ਨਾਲ ਨਜਿੱਠ ਰਹੇ ਹੋ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ UI ਅਤੇ ਬੈਕਐਂਡ ਨੂੰ ਤੈਅ ਕਰਨਾ ਪੈਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਅਸਥਾਈ ਹੈ ਅਤੇ ਕੀ ਫਾਈਨਲ।
ਇੱਕ ਸਾਫ਼ ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ ਛੋਟੇ-ਛੋਟੇ ਇਵੈਂਟ ਸਟ੍ਰੀਮ ਕਰੋ, ਹਰ ਇੱਕ ਦੇ ਨਾਵ ਅਤੇ ਪੇਲੋਡ ਦੇ ਨਾਲ। ਉਦਾਹਰਨ:
token: ਇੰਕ੍ਰੀਮੈਂਟਲ ਟੈਕਸਟ (ਜਾਂ ਇੱਕ ਛੋਟਾ ਹਿੱਸਾ)tool_start: ਇੱਕ ਟੂਲ ਕਾਲ ਸ਼ੁਰੂ ਹੋ ਗਿਆ (ਮਿਸਾਲ ਲਈ “Searching…”, ਇੱਕ id ਨਾਲ)tool_result: ਟੂਲ ਆਉਟਪੁੱਟ ਤਿਆਰ ਹੈ (ਉਸੇ id ਨਾਲ)done: ਸਹਾਇਕ ਸੁਨੇਹਾ ਮੁਕੰਮਲ ਹੈerror: ਕੁਝ ਫੇਲ੍ਹ ਹੋਇਆ (ਇੱਕ ਯੂਜ਼ਰ-ਸੁਰੱਖਿਅਤ ਸੰਦੇਸ਼ ਅਤੇ ਇੱਕ ਡੀਬੱਗ id ਸ਼ਾਮਲ ਕਰੋ)ਇਹ ਇਵੈਂਟ ਸਟ੍ਰੀਮ ਰੌ-ਟੈਕਸਟ ਸਟ੍ਰੀਮਿੰਗ ਨਾਲੋਂ ਵਧੇਰੇ ਵਰਜਨਿੰਗ ਅਤੇ ਡੀਬੱਗ ਕਰਨ ਯੋਗ ਹੈ, ਕਿਉਂਕਿ ਫਰੰਟਐਂਡ ਬਿਨਾਂ ਅਨੁਮਾਨ ਲਗਾਏ ਪ੍ਰਗਤੀ ਨੂੰ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਦਰਸਾ ਸਕਦਾ ਹੈ (ਅਤੇ ਟੂਲ ਸਥਿਤੀ ਦਿਖਾ ਸਕਦਾ ਹੈ)।
ਕਲਾਇੰਟ 'ਤੇ ਸਟ੍ਰੀਮਿੰਗ ਨੂੰ ਐਪੈਂਡ-ਓਨਲੀ ਸਮਝੋ: ਇੱਕ “ਡ੍ਰਾਫਟ” ਸਹਾਇਕ ਸੁਨੇਹਾ ਬਣਾਓ ਅਤੇ ਜਿਵੇਂ ਜਿਵੇਂ token ਈਵੈਂਟ ਆਉਂਦੇ ਹਨ ਇਸਨੂੰ ਵਧਾਈਏ। ਜਦੋਂ done ਮਿਲ ਜਾਵੇ, ਇੱਕ ਕਮੇਟ ਕਰੋ: ਸੁਨੇਹੇ ਨੂੰ ਫਾਇਨਲ ਅੱਖਾਰ ਦਿੱਤੀ ਜਾਵੇ, ਇਸਨੂੰ ਪਾਇਸਤ ਕਰੋ (ਜੇ ਤੁਸੀਂ ਲੋਕਲ ਸਟੋਰ ਵੀ ਰੱਖਦੇ ਹੋ), ਅਤੇ ਕਾਪੀ/ਰੇਟ/ਰੀਜੈਨਰੇਟ ਵਰਗੀਆਂ ਕਾਰਵਾਈਆਂ ਖੁਲ੍ਹ ਜਾਣ।
ਇਸ ਨਾਲ ਇਤਿਹਾਸ ਨੂੰ ਸਟ੍ਰੀਮ ਦੌਰਾਨ ਦੁਬਾਰਾ ਲਿਖਣ ਤੋਂ ਬਚਿਆ ਜਾਦਾ ਹੈ ਅਤੇ UI ਪੇਸ਼ਗੋਈਯੋਗ ਰਹਿੰਦਾ ਹੈ।
ਸਟ੍ਰੀਮਿੰਗ ਅਧ-ਪੂਰਨ ਕੰਮਾਂ ਦੀ ਸੰਭਾਵਨਾ ਵਧਾਉਂਦਾ ਹੈ:
ਜੇ ਪੇਜ ਮਿਡ-ਸਟ੍ਰੀਮ ਰੀਲੋਡ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਨਵੀਨੀਤ ਸਥਿਰ ਸਟੇਟ ਤੋਂ ਪੁਨਰ-ਨਿਰਮਾਣ ਕਰੋ: ਆਖਰੀ ਕਮੇਟ ਕੀਤੇ ਸੁਨੇਹਿਆਂ ਨਾਲ ਹੀ ਕੋਈ ਸਟੋਰਡ ਡ੍ਰਾਫਟ ਮੈਟਾ (message id, ਇਕੱਠਾ ਟੈਕਸਟ, ਟੂਲ ਸਥਿਤੀਆਂ)। ਜੇ ਤੁਸੀਂ ਸਟ੍ਰੀਮ ਦੁਬਾਰਾ ਰੀਜ਼ਿਊਮ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਡ੍ਰਾਫਟ ਨੂੰ ਬਿਚਿੱਤਰ ਰੂਪ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰੋ ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਰੀਟ੍ਰਾਈ ਕਰਨ ਦਿਓ, ਬਜਾਏ ਇਸਦੇ ਕਿ ਤੁਸੀਂ ਉਸਨੂੰ ਮੁਕੰਮਲ ਦਿਖਾਓ।
ਸਟੇਟ ਸਿਰਫ ਉਹ ਡੇਟਾ ਨਹੀਂ ਹੈ ਜੋ ਤੁਸੀਂ ਸਟੋਰ ਕਰਦੇ ਹੋ—ਇਹ ਯੂਜ਼ਰ ਦੇ ਪ੍ਰੌਮਪਟ, ਅਪਲੋਡ, ਪਸੰਦਾਂ, ਜਨਰੇਟ ਕੀਤਾ ਆਉਟਪੁੱਟ, ਅਤੇ ਉਹ ਮੈਟਾਡੇਟਾ ਹੈ ਜੋ ਸਭ ਕੁਝ ਜੋੜਦਾ ਹੈ। ਏਆਈ ਐਪਾਂ ਵਿੱਚ ਇਹ ਸਟੇਟ ਅਸਧਾਰਣ ਤੌਰ 'ਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਹੋ ਸਕਦੀ ਹੈ (ਨਿੱਜੀ ਜਾਣਕਾਰੀ, ਪ੍ਰੋਪ੍ਰਾਇਟਰੀ ਡੌਕਸ, ਅਨਤਰਕਿਰਿਆ ਦੇ ਫੈਸਲੇ), ਇਸ ਲਈ ਸੁਰੱਖਿਆ ਨੂੰ ਹਰ ਪਰਤ ਵਿੱਚ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਕੋਈ ਵੀ ਚੀਜ਼ ਜੋ ਕਿਸੇ ਕਲਾਇੰਟ ਨੂੰ ਤੁਹਾਡੇ ਐਪ ਦੀ ਨਕਲ ਕਰਨ ਦੀ ਆਗਿਆ ਦੇਵੇ, ਸਰਵਰ-ਕੇਵਲ ਰਹੇ: API ਕੀਜ਼, ਨਿੱਜੀ ਕਨੈਕਟਰ (Slack/Drive/DB ਪ੍ਰਮਾਣ-ਪੱਤਰ), ਅਤੇ ਅੰਦਰੂਨੀ ਸਿਸਟਮ ਪ੍ਰੌਮਪਟ ਜਾਂ ਰੂਟਿੰਗ ਲੌਜਿਕ। ਫਰੰਟਐਂਡ ਕਾਰਵਾਈ ਮੰਗ ਸਕਦਾ ਹੈ (“ਇਸ ਫਾਇਲ ਦਾ ਸੰਖੇਪ ਬਣਾਓ”), ਪਰ ਬੈਕਐਂਡ ਨਿਰਣ੍ਹ ਕਰੇ ਕਿ ਇਹ ਕਿਵੇਂ ਚੱਲੇਗਾ ਅਤੇ ਕਿਹੜੇ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਵਰਤੇ ਜਾਣ।
ਹਰ ਸਟੇਟ ਮਿਉਟੇਸ਼ਨ ਨੂੰ ਇੱਕ ਅਧਿਕਾਰਤ ਓਪਰੇਸ਼ਨ ਵਜੋਂ ਦੇਖੋ। ਜਦੋਂ ਕਲਾਇੰਟ ਸੁਨੇਹਾ ਬਣਾਉਣ, ਗੱਲਬਾਤ ਦਾ ਨਾਮ ਬਦਲਣ, ਜਾਂ ਫਾਇਲ ਅਟੈਚ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇ, ਤਬ ਬੈਕਐਂਡ ਜਾਂਚੇ:
ਇਸ ਨਾਲ “ID guessing” ਹਮਲਿਆਂ ਤੋਂ ਬਚਾਅ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਕੋਈ conversation_id ਬਦਲ ਕੇ ਦੂਜੇ ਯੂਜ਼ਰ ਇਤਿਹਾਸ ਤੱਕ ਪਹੁੰਚ ਲੈ ਲੈਂਦਾ ਹੈ।
ਹਰ ਕਲਾਇੰਟ-ਪਹੁੰਚੀ ਸਟੇਟ ਨੂੰ ਅਨਭਰੋਸਾ ਮੰਨੋ। ਸਕੀਮਾ ਅਤੇ ਸੀਮਾਵਾਂ (ਟਾਈਪ, ਲੰਬਾਈ, ਆসਕ ਐਨਮ) ਨੂੰ ਵੈਧ ਕਰੋ, ਅਤੇ ਲਕੜੀ ਲਈ sanitize ਕਰੋ (SQL/NoSQL, ਲਾਗ, HTML rendering)। ਜੇ ਤੁਸੀਂ “ਸਟੇਟ ਅਪਡੇਟ” ਸਵੀਕਾਰ ਕਰਦੇ ਹੋ (ਜਿਵੇਂ ਸੈਟਿੰਗਜ਼, ਟੂਲ ਪੈਰਾਮੀਟਰ), ਤਾਂ ਮਨਜ਼ੂਰ ਕੀਤੇ ਫੀਲਡਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ ਅਤੇ arbitrary JSON ਮਰਜ ਕਰਨ ਤੋਂ ਬਚੋ।
ਜੋ ਕਾਰਵਾਈਆਂ ਟਿਕਾਉ ਸਟੇਟ ਨੂੰ ਬਦਲਦੀਆਂ ਹਨ—ਸ਼ੇਅਰ, ਐਕਸਪੋਰਟ, ਡਿਲੀਟ, ਕਨੈਕਟਰ ਪਹੁੰਚ—ਉਨ੍ਹਾਂ ਲਈ ਕਿਸ ਨੇ ਕਿੱਤਾ ਅਤੇ ਕਦੋਂ ਕੀਤਾ, ਇਹ ਦਰਜ ਕਰੋ। ਇੱਕ ਹਲਕੀ-ਫੁੱਲੀ ਆਡੀਟ ਲਾਗ ਘਟਨਾਵਲੀਆਂ ਅਤੇ ਅਨੁਸੂੰਧਾਨ ਲਈ ਮਦਦ ਕਰਦੀ ਹੈ।
ਉਸ ਲਈ ਸਿਰਫ ਉਹੀ ਡੇਟਾ ਰੱਖੋ ਜੋ ਫੀਚਰ ਦੇਣ ਲਈ ਜ਼ਰੂਰੀ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਸਦਾ ਲਈ ਪੂਰੇ ਪ੍ਰੌਮਪਟ ਦੀ ਲੋੜ ਨਹੀਂ, ਤਾਂ ਰੀਟੇਸ਼ਨ ਵਿਂਡੋਜ਼ ਜਾਂ ਰੈਡੈਕਸ਼ਨ 'ਤੇ ਵਿਚਾਰ ਕਰੋ। ਸੰਵੇਦਨਸ਼ੀਲ ਸਟੇਟ (ਟੋਕਨ, ਕਨੈਕਟਰ ਸਆਕਸ) ਨੂੰ ਟਿਕਾਊ ਰੱਖਣ ਸਮੇਂ ਇਨਕ੍ਰਿਪਟ ਕਰੋ ਅਤੇ ਟ੍ਰਾਂਜ਼ਿਟ ਵਿੱਚ TLS ਵਰਤੋ। آپਰੇਸ਼ਨਲ ਮੈਟਾਡੇਟਾ ਨੂੰ ਸਮੱਗਰੀ ਤੋਂ ਅਲੱਗ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਜ਼ਿਆਦਾ ਸਖ਼ਤ ਪਹੁੰਚ ਨੀਤੀਆਂ ਲਗਾ ਸਕੋ।
ਏਆਈ ਐਪਾਂ ਲਈ ਇੱਕ ਉਪਯੋਗ ਡਿਫ਼ੌਲਟ ਸਧਾਰਨ ਹੈ: ਬੈਕਐਂਡ ਸਤ੍ਹਾ-of-truth ਹੈ, ਅਤੇ ਫਰੰਟਐਂਡ ਤੇਜ਼, optimistic ਕੈਸ਼ ਹੈ। UI ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰ ਸਕਦੀ ਹੈ, ਪਰ ਜੋ ਕੁਝ ਤੁਸੀਂ ਗੁਆਣਾ ਨਹੀਂ ਚਾਹੁੰਦੇ (ਸੁਨੇਹੇ, ਜੌਬ ਸਥਿਤੀ, ਟੂਲ ਆਉਟਪੁੱਟ, ਬਿਲਿੰਗ ਸੰਬੰਧੀ ਘਟਨਾਵਾਂ) ਉਹ ਸਰਵਰ-ਸਾਈਡ ਪੁਸ਼ਟੀ ਅਤੇ ਸਟੋਰ ਹੋਵਣੇ ਚਾਹੀਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ “vibe-coding” ਵਰਕਫਲੋ ਨਾਲ ਬਿਲਡ ਕਰ ਰਹੇ ਹੋ—ਜਿੱਥੇ ਉਤਪਾਦ ਦਾ ਕਾਫ਼ਾ ਹਿੱਸਾ ਤੇਜ਼ੀ ਨਾਲ ਬਣਦਾ ਹੈ—ਤਾਂ ਸਟੇਟ ਮਾਡਲ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਬਣ ਜਾਂਦਾ ਹੈ। ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai ਟੀਮਾਂ ਨੂੰ ਚੈਟ ਤੋਂ ਪੂਰੇ ਵੈੱਬ, ਬੈਕਐਂਡ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਉਹੀ ਨਿਯਮ ਲਾਗੂ ਹੁੰਦੇ ਹਨ: ਤੇਜ਼ ਇਤਰੇਸ਼ਨ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਸਰੋਤ-of-truth, ID, ਅਤੇ ਸਥਿਤੀ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਪਹਿਲਾਂ ਤੋਂ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਹੋਣ।
ਫਰੰਟਐਂਡ (ਬਰਾਊਜ਼ਰ/ਮੋਬਾਈਲ)
session_id, conversation_id, ਅਤੇ ਨਵਾਂ request_id।ਬੈਕਐਂਡ (API + ਵਰਕਰਸ)
ਨੋਟ: ਇਸਨੂੰ ਸੰਗਠਿਤ ਰੱਖਣ ਲਈ ਆਪਣੇ ਬੈਕਐਂਡ ਸਟੈਕ ਨੂੰ ਪਹਿਲਾਂ standardize ਕਰਨਾ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, Koder.ai-ਜਨਰੇਟ ਕੀਤੇ ਬੈਕਐਂਡ ਆਮ ਤੌਰ 'ਤੇ Go ਨਾਲ PostgreSQL ਵਰਤਦੇ ਹਨ (ਅਤੇ ਫਰੰਟਐਂਡ 'ਤੇ React), ਜੋ SQL ਵਿੱਚ authoritative state ਕੇਂਦਰਿਤ ਕਰਨ ਅਤੇ ਕਲਾਇੰਟ ਕੈਸ਼ ਨਸ਼ਟਿਯੋਗ ਰੱਖਣ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਸਕ੍ਰੀਨ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਫੀਲਡ ਨਿਰਧਾਰਤ ਕਰੋ ਜਿਨ੍ਹਾਂ 'ਤੇ ਤੁਸੀਂ ਹਰ ਪਰਤ ਵਿੱਚ ਨਿਰਭਰ ਹੋਵੋਗੇ:
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 “ਸਹੀ ਦਿਖਦੀ” ਪਰ ਰੀਟ੍ਰਾਈ, ਰੀਫ੍ਰੈਸ਼, ਜਾਂ ਸਮਕਾਲੀ ਸੋਧਾਂ ਨੂੰ ਮਿਲਾ ਨਹੀਂ ਪਾਉਂਦੀ।
ਫੀਚਰਜ਼ ਵਿੱਚ 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 ਸਮੇਤ), ਲੈਟੈਂਸੀ, ਰੀਟ੍ਰਾਈਜ਼, ਅਤੇ ਆਖਰੀ ਸਥਿਤੀ ਦਰਜ ਕਰੋ। ਇਹ ਸੌਖਾ ਬਣਾਵੇ ਕਿ “ਮਾਡਲ ਨੇ ਕੀ ਵੇਖਿਆ, ਕਿਹੜੇ ਟੂਲ ਚੱਲੇ, ਅਤੇ ਅਸੀਂ ਕੀ ਸਟੋਰ ਕੀਤਾ?” ਦਾ ਜਵਾਬ ਦਿੱਤਾ ਜਾ ਸਕੇ।
request_id (ਅਤੇ/ਜਾਂ Idempotency-Key) ਦੀ ਵਰਤੋਂ ਕਰਕੇ।queued ਤੋਂ succeeded ਨਹੀਂ)।version/etag ਜਾਂ ਸਰਵਰ-ਸਾਈਡ ਮਰਜ ਨੀਤੀਆਂ ਨਾਲ ਹੱਲ ਕੀਤੇ ਜਾਣ।ਜਦੋਂ ਤੁਸੀਂ ਤੇਜ਼ ਬਿਲਡ ਸਾਈਕਲ (ਸ਼ਾਮਿਲ ਕਰਕੇ ਏਆਈ-ਸਹਾਇਤ) ਅਪਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਨ੍ਹਾਂ ਚੈਕਲਿਸਟ ਆਈਟਮਾਂ ਨੂੰ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕਰਨ ਵਾਲੇ ਗਾਰਡਰੇਲ ਜੋੜੋ—ਸਕੇਮਾ ਵੈਧਤਾ, idempotency, ਅਤੇ ইਵੈਂਟਡ ਸਟ੍ਰੀਮਿੰਗ—ਤਾਂ ਜੋ “ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣਾ” ਸਟੇਟ ਡ੍ਰਿਫਟ ਵਿੱਚ ਨਾਂ ਬਦਲ ਜਾਵੇ। ਅਮਲ ਵਿੱਚ, ਇਹੀ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ Koder.ai ਵਰਗਾ end-to-end ਪਲੇਟਫਾਰਮ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ: ਇਹ ਡਿਲਿਵਰੀ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ, ਜਦੋਂਕਿ ਤੁਹਾਨੂੰ ਸਰੋਤ ਕੋਡ ਨਿਕਾਸ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਵੀ ਦਿੰਦਾ ਹੈ ਅਤੇ ਵੈੱਬ, ਬੈਕਐਂਡ, ਅਤੇ ਮੋਬਾਈਲ ਬਿਲਡਾਂ ਵਿੱਚ ਸਟੇਟ-ਹੈਂਡਲਿੰਗ ਪੈਟਰਨ ਇਕਸਾਰ ਰੱਖਦਾ ਹੈ।