23 ਅਕਤੂ 2025·6 ਮਿੰਟ
ਸਰਵਰ-ਪਾਸੇ ਵਿਰੁੱਧ ਕਲਾਇੰਟ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ: ਫੈਸਲਾ ਕਰਨ ਲਈ ਚੈੱਕਲਿਸਟ
ਡੇਟਾ ਦੇ ਆਕਾਰ, ਲੇਟੈਂਸੀ, ਅਧਿਕਾਰ ਅਤੇ ਕੈਸ਼ਿੰਗ ਦੇ ਆਧਾਰ 'ਤੇ ਸਰਵਰ-ਵਿਰੁੱਧ ਕਲਾਇੰਟ ਫਿਲਟਰਿੰਗ ਲਈ ਚੈੱਕਲਿਸਟ — ਬਿਨਾਂ UI ਲੀਕ ਜਾਂ ਲੈਗ ਦੇ।
ਅਸਲ ਸਮੱਸਿਆ: ਲੀਕ, ਲੈਗ, ਅਤੇ ਅਸੰਗਤ ਨਤੀਜੇ
UI ਵਿੱਚ ਫਿਲਟਰਿੰਗ ਸਿਰਫ਼ ਇੱਕ ਖੋਜ ਬਾਕਸ ਤੋਂ ਵੱਧ ਹੁੰਦੀ ਹੈ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਸੰਬੰਧਿਤ ਕਾਰਵਾਈਆਂ ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ ਜੋ ਇਸਦੇ ਨਾਲ ਦਿੱਖ ਨੂੰ ਬਦਲਦੀਆਂ ਹਨ: ਟੈਕਸਟ ਖੋਜ (ਨਾਂ, ਈਮੇਲ, ਆਰਡਰ ID), ਫੇਸੈਟਸ (ਸਥਿਤੀ, ਮਾਲਕ, ਤਾਰੀਖ ਸੀਮਾ, ਟੈਗ), ਅਤੇ ਸੋਰਟਿੰਗ (ਨਵੀਂ, ਵੱਡੀ ਕੀਮਤ, ਆਖਰੀ ਸਰਗਰਮੀ)।
ਮੁੱਖ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ ਕਿਹੜੀ ਤਕਨੀਕ "ਵਧੀਆ" ਹੈ। ਇਹ ਇਸ ਗੱਲ 'ਤੇ ਹੈ ਕਿ ਪੂਰਾ ਡੇਟਾਸੈਟ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਕੌਣ ਉਸ ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਬ੍ਰਾਉਜ਼ਰ ਨੂੰ ਉਹ ਰਿਕਾਰਡ ਮਿਲਦੇ ਹਨ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਨਹੀਂ ਦੇਖਣੇ ਚਾਹੀਦੇ, ਤਾਂ UI ਦਿੱਖ ਵਿੱਚ ਲੁਕਾਉਣ ਦੇ ਬਾਵਜੂਦ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਪ੍ਰਗਟ ਕਰ ਸਕਦਾ ਹੈ।
ਜਿਆਦਾਤਰ ਸਰਵਰ-ਵਿਰੁੱਧ ਕਲਾਇੰਟ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ 'ਤੇ ਚਰਚਾਵਾਂ ਦਰਅਸਲ ਦੋ ਤਰ੍ਹਾਂ ਦੀਆਂ ਨਾਕਾਮੀਆਂ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਹੁੰਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਯੂਜ਼ਰ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ:
- ਲੀਕ: ਡਾਟਾ ਨੈਟਵਰਕ ਪੇਲੋਡ, ਕੈਸ਼ਡ ਜਵਾਬਾਂ, ਜਾਂ ਅਣਛਾਹੇ ਫਿਲਟਰਾਂ ਰਾਹੀਂ ਦਿਖਾਈ ਦੇ ਸਕਦਾ ਹੈ।
- ਲੈਗ: ਸਕ੍ਰੀਨ ਧੀਮੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਡਾਟਾ ਭੇਜਦੇ ਹੋ ਅਤੇ ਫਿਰ ਹਰ ਕੀਸਟਰੋਕ 'ਤੇ ਡਿਵਾਈਸ ਨੂੰ ਭਾਰ ਸੌਂਪਦੇ ਹੋ।
ਇੱਕ ਤੀਜਾ ਮੁੱਦਾ ਜੋ ਬੇਅੰਤ ਬੱਗ ਰਿਪੋਰਟਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ: ਅਸੰਗਤ ਨਤੀਜੇ। ਜੇ ਕੁਝ ਫਿਲਟਰ ਕਲਾਇੰਟ 'ਤੇ ਚੱਲ ਰਹੇ ਹਨ ਅਤੇ ਹੋਰ ਸਰਵਰ 'ਤੇ, ਤਾਂ ਯੂਜ਼ਰ ਗਿਣਤੀਆਂ, ਪੰਨੇ, ਅਤੇ ਟੋਟਲ ਵੇਖਦੇ ਹਨ ਜੋ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ। ਇਹ ਖਾਸ ਕਰਕੇ ਪੇਜੀਨੇਟਡ ਲਿਸਟਾਂ 'ਤੇ ਭਰੋਸਾ ਤੋੜ ਦੇਂਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਡਿਫੌਲਟ ਸਾਦਾ ਹੈ: ਜੇ ਯੂਜ਼ਰ ਨੂੰ ਪੂਰਾ ਡੇਟਾਸੈਟ ਵੇਖਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ, ਤਾਂ ਸਰਵਰ 'ਤੇ ਫਿਲਟਰ ਕਰੋ। ਜੇ ਉਹ ਵੇਖ ਸਕਦਾ ਹੈ ਅਤੇ ਡੇਟਾ ਛੋਟਾ ਹੈ ਤਾਂ ਕਲਾਇੰਟ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਠੀਕ ਰਹਿ ਸਕਦੀ ਹੈ।
ਸਾਧਾਰਣ ਪਰਿਭਾਸ਼ਾਵਾਂ ਆਸਾਨ ਸ਼ਬਦਾਂ ਵਿੱਚ
ਫਿਲਟਰਿੰਗ ਸਿਰਫ਼ "ਉਹ ਆਈਟਮ ਦਿਖਾਓ ਜੋ ਮਿਲਦੇ ਹਨ" ਹੈ। ਮੁੱਖ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਮੈਚ ਕਿੱਥੇ ਹੁੰਦਾ ਹੈ: ਯੂਜ਼ਰ ਦੇ ਬ੍ਰਾਉਜ਼ਰ ਵਿੱਚ (ਕਲਾਇੰਟ) ਜਾਂ ਤੁਹਾਡੇ ਬੈਕਐਂਡ 'ਤੇ (ਸਰਵਰ)।
ਕਲਾਇੰਟ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਬ੍ਰਾਉਜ਼ਰ ਵਿੱਚ ਚੱਲਦੀ ਹੈ। ਐਪ ਕੁਝ ਰਿਕਾਰਡ (ਅਕਸਰ JSON) ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ, ਫਿਰ ਲੋਕਲ ਤੌਰ 'ਤੇ ਫਿਲਟਰ ਲਗਾਉਂਦਾ ਹੈ। ਡਾਟਾ ਲੋਡ ਹੋਣ ਤੋਂ ਬਾਅਦ ਇਹ ਤੁਰੰਤ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਸਿਰਫ਼ ਉਦੋਂਕ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਡੇਟਾਸੈਟ ਛੋਟਾ ਹੋਵੇ ਅਤੇ ਖੁਲਾਸਾ ਕਰਨ ਲਈ ਸੁਰੱਖਿਅਤ ਹੋਵੇ।
ਸਰਵਰ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਤੁਹਾਡੇ ਬੈਕਐਂਡ 'ਤੇ ਚੱਲਦੀ ਹੈ। ਬ੍ਰਾਉਜ਼ਰ ਫਿਲਟਰ ਇਨਪੁਟ ਭੇਜਦਾ ਹੈ (ਜਿਵੇਂ status=open, owner=me, createdAfter=Jan 1), ਅਤੇ ਸਰਵਰ ਸਿਰਫ਼ ਉਹੀ ਮੈਚਿੰਗ ਨਤੀਜੇ ਵਾਪਸ ਭੇਝਦਾ ਹੈ। ਅਮਲੀ ਤੌਰ 'ਤੇ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ API ਐਂਡਪੌਇੰਟ ਹੁੰਦਾ ਹੈ ਜੋ ਫਿਲਟਰ ਲੈਂਦਾ ਹੈ, ਡਾਟਾਬੇਸ ਕੁਐਰੀ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਪੇਜਿਨੇਟਡ ਲਿਸਟ ਅਤੇ ਟੋਟਲ ਵਾਪਸ ਕਰਦਾ ਹੈ।
ਸਧਾਰਨ ਮਾਨਸਿਕ ਮਾਡਲ:
- ਕਲਾਇੰਟ-ਪਾਸੇ: ਬਹੁਤ ਡਾਊਨਲੋਡ ਕਰੋ, ਇੱਥੇ ਫਿਲਟਰ ਕਰੋ।
- ਸਰਵਰ-ਪਾਸੇ: ਜੋ ਚਾਹੀਦਾ ਹੈ ਉਹੀ ਮੰਗੋ।
ਹਾਈਬ੍ਰਿਡ ਸੈਟਅਪ ਆਮ ਹਨ। ਇੱਕ ਵਧੀਆ ਰੀਤੀ ਇਹ ਹੈ ਕਿ ਬੜੇ ਫਿਲਟਰ (ਅਧਿਕਾਰ, ਮਾਲਕੀਅਤ, ਤਾਰੀਖ ਸੀਮਾ, ਖੋਜ) ਸਰਵਰ 'ਤੇ ਲਾਗੂ ਕਰੋ, ਫਿਰ ਛੋਟੇ UI-ਕੇਵਲ ਟੋਗਲ (ਹਾਈਡ ਆਰਕਾਈਵਡ ਆਈਟਮ, ਫਾਸਟ ਟੈਗ ਚਿਪਸ, ਕਾਲਮ ਵਿਸ਼ੀਬਿਲਟੀ) ਲੋਕਲ ਤੌਰ 'ਤੇ ਬਿਨਾਂ ਹੋਰ ਰਿਕਵੇਸਟ ਦੇ ਵਰਤੋ।
ਸੋਰਟਿੰਗ, ਪੇਜਿਨੇਸ਼ਨ, ਅਤੇ ਖੋਜ ਆਮ ਤੌਰ 'ਤੇ ਉਸੇ ਫੈਸਲੇ ਨਾਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ। ਉਹ ਪੇਲੋਡ ਆਕਾਰ, ਯੂਜ਼ਰ ਅਨੁਭਵ, ਅਤੇ ਤੁਹਾਡੇ ਦੁਆਰਾ ਖੁਲਾਸਾ ਹੋ ਰਹੇ ਡਾਟਾ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ।
ਫੈਸਲਾ ਕਾਰਕ 1: ਡੇਟਾ ਆਕਾਰ ਅਤੇ ਪੇਲੋਡ ਲਾਗਤ
ਸਭ ਤੋਂ ਪ੍ਰਾਇਕਟਿਕ ਸਵਾਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਜੇ ਤੁਸੀਂ ਕਲਾਇੰਟ 'ਤੇ ਫਿਲਟਰ ਕਰੋ ਤਾਂ ਤੁਸੀਂ ਬ੍ਰਾਉਜ਼ਰ ਨੂੰ ਕਿੰਨਾ ਡਾਟਾ ਭੇਜੋਗੇ? ਜੇ ਸਚਾ ਉੱਤਰ "ਕੁਝ ਸਕ੍ਰੀਨਾਂ ਤੋਂ ਵੱਧ" ਹੈ, ਤਾਂ ਤੁਸੀਂ ਡਾਊਨਲੋਡ ਸਮੇਂ, ਮੇਮੋਰੀ ਖਪਤ, ਅਤੇ ਧੀਮੀ ਇੰਟਰੈਕਸ਼ਨ 'ਤੇ ਦੀ ਕੀਮਤ ਭਰੋਂਗੇ।
ਤੁਹਾਨੂੰ ਬਿਲਕੁਲ ਸਹੀ ਅਨੁਮਾਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਸਿਰਫ਼ ਆਕਾਰ ਦਾ ਆੰਦਾਜ਼ ਲਾਓ: ਯੂਜ਼ਰ ਕਿੰਨੀ ਕਤਾਰਾਂ ਦੇਖ ਸਕਦਾ ਹੈ, ਅਤੇ ਪ੍ਰਤੀ ਕਤਾਰ ਦਾ ਆਮ ਆਕਾਰ ਕੀ ਹੈ? 500 ਆਈਟਮਾਂ ਦੀ ਲਿਸਟ ਛੋਟੇ ਖੇਤਰਾਂ ਨਾਲ ਬਹੁਤ ਵੱਖਰੀ ਹੋ ਸਕਦੀ ਹੈ ਉਸ ਤੋਂ 50,000 ਆਈਟਮਾਂ ਦੇ ਜਿਥੇ ਹਰ ਕਤਾਰ ਵਿੱਚ ਲੰਮੇ ਨੋਟਸ, ਰਿਚ ਟੈਕਸਟ, ਜਾਂ ਨੈਸਟਡ ਓਬਜੈਕਟ ਹੋਣ।
ਵਿਆਪਕ ਰਿਕਾਰਡ ਸ਼ਾਂਤ ਪੇਲੋਡ ਕਤਲਹੰਦੇ ਹਨ। ਇੱਕ ਟੇਬਲ ਦਰਸਣ ਵਿੱਚ ਕਤਾਰ ਗਿਣਤੀ ਨਾਲ ਛੋਟੀ ਲੱਗ ਸਕਦੀ ਹੈ ਪਰ ਭਾਰਤੀ ਹੋ ਸਕਦੀ ਹੈ ਜੇ ਹਰ ਕਤਾਰ ਵਿੱਚ ਘਣੇ ਫੀਲਡ, ਲੰਬੇ ਸਤਰ, ਜਾਂ ਜੋੜੀ ਹੋਈ ਡੇਟਾ ਹੋਵੇ (ਸੰਪਰਕ + ਕੰਪਨੀ + ਆਖਰੀ ਸਰਗਰਮੀ + ਪੂਰਾ ਪਤਾ + ਟੈਗ)। ਅਕਸਰ ਦਿਖਾਉਣ ਲਈ ਸਿਰਫ਼ ਤਿੰਨ ਕਾਲਮ ਹੀ ਚਾਹੀਦੇ ਹੋਣ, ਪਰ ਟੀਮ "ਸਭ ਕੁਝ ਭੇਜ ਦਿੰਦੀ ਹੈ, ਸੁਰੱਖਿਆ ਲਈ" ਅਤੇ ਪੇਲੋਡ ਫੂਲ ਹੋ ਜਾਂਦਾ ਹੈ।
ਵੱਧਣ ਬਾਰੇ ਵੀ ਸੋਚੋ। ਅਜਿਹਾ ਡੇਟਾ ਜਿਹੜਾ ਅੱਜ ਠੀਕ ਹੈ, ਕੁਝ ਮਹੀਨਿਆਂ ਵਿੱਚ ਦੁੱਖਦਾਈ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਡੇਟਾ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧਦਾ ਹੈ, ਤਾਂ ਕਲਾਇੰਟ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਨੂੰ ਅਸਥਾਈ ਛੇਤੀ ਰਾਹ ਸਮਝੋ, ਡਿਫੌਲਟ ਨਹੀਂ।
ਨਿਯਮ-ਹਥਿਆਰ:
- ਜੇ ਤੁਸੀਂ ਆਮ ਮੋਬਾਈਲ ਕਨੈਕਸ਼ਨ 'ਤੇ ਪੂਰਾ ਡੇਟਾ ਆਸਾਨੀ ਨਾਲ ਨਹੀਂ ਭੇਜ ਸਕਦੇ, ਤਾਂ ਸਰਵਰ 'ਤੇ ਫਿਲਟਰ ਕਰੋ।
- ਜੇ ਯੂਜ਼ਰ ਸਿਰਫ਼ ਛੋਟਾ ਹਿੱਸਾ ਹੀ ਨੇੜੇ ਦੇਖਦੇ ਹਨ, ਉਹ ਹਿੱਸਾ ਫੇਚ ਕਰੋ ਅਤੇ ਸਰਵਰ-ਪਾਸੇ ਫਿਲਟਰ ਕਰੋ।
- ਜੇ ਡੇਟਾ ਛੋਟਾ, ਸਥਿਰ, ਅਤੇ ਵਾਸਤਵ ਵਿੱਚ ਖੁਲਾਸਾ ਕਰਨ ਲਈ ਸੁਰੱਖਿਅਤ ਹੈ, ਤਾਂ ਕਲਾਇੰਟ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਸਾਰੀ ਅਨੁਭੂਤੀ ਨੂੰ ਛੇਤੀ ਕਰ ਸਕਦੀ ਹੈ।
ਇਹ ਆਖਰੀ ਗੱਲ ਪ੍ਰਦਰਸ਼ਨ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ। "ਕੀ ਅਸੀਂ ਪੂਰਾ ਡੇਟਾਸੈਟ ਬ੍ਰਾਉਜ਼ਰ ਨੂੰ ਭੇਜ ਸਕਦੇ ਹਾਂ?" ਇਹ ਵੀ ਇੱਕ ਸੁਰੱਖਿਆ ਸਵਾਲ ਹੈ। ਜੇ ਉੱਤਰ ਪੱਕਾ ਨਹੀਂ ਹੈ, ਤਾਂ ਨਾ ਭੇਜੋ।
ਫੈਸਲਾ ਕਾਰਕ 2: ਲੇਟੈਂਸੀ ਅਤੇ ਯੂਜ਼ਰ ਅਨੁਭਵ
ਫਿਲਟਰਿੰਗ ਦੇ ਫੈਸਲੇ ਅਕਸਰ ਸਹੀਤਾ ਦੀ ਨਾ ਕਰਕੇ ਅਨੁਭਵ 'ਤੇ ਫੇਲ ਹੁੰਦੇ ਹਨ। ਯੂਜ਼ਰ ਮਿਲੀਸੈਕਿੰਡਾਂ ਨੂੰ ਨਹੀਂ ਮਾਪਦੇ। ਉਹ ਠਹਿਰਾਅ, ਫਲਿਕਰ, ਅਤੇ ਟਾਈਪ ਕਰਦਿਆਂ ਨਤੀਜਿਆਂ ਦੇ ਦੁਬਾਰਾ-ਉਛਲਦੇ ਦੇਖਦੇ ਹਨ।
ਸਮਾਂ ਵੱਖ-ਵੱਖ ਜਗ੍ਹਾਂ ਖਰਚ ਹੁੰਦਾ ਹੈ:
- ਨੈਟਵਰਕ: ਰਿਕਵੇਸਟ/ਜਵਾਬ ਦੀ ਸਮਾਂ ਅਤੇ ਪੇਲੋਡ ਆਕਾਰ
- ਸਰਵਰ: ਡੇਟਾਬੇਸ ਕੁਐਰੀਜ਼, ਜੋਇਨ, ਸੋਰਟਿੰਗ, ਅਧਿਕਾਰ ਜਾਂਚ
- ਬ੍ਰਾਉਜ਼ਰ: JSON ਪਾਰਸਿੰਗ, ਰੋਜ਼ ਰੇਂਡਰਿੰਗ, ਵੱਡੀਆਂ ਸ਼੍ਰੇਣੀਆਂ 'ਤੇ ਫਿਲਟਰਿੰਗ
ਇਸ ਸਕ੍ਰੀਨ ਲਈ "ਤੇਜ਼ ਕਿੰਨਾ ਤੇਜ਼" ਹੈ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਇੱਕ ਲਿਸਟ ਵਿਊ ਨੂੰ ਟਾਈਪਿੰਗ ਦੇ ਦੌਰਾਨ ਜਵਾਬਦੇਹ ਅਤੇ ਸਹਿਜ ਸਕ੍ਰੋਲਿੰਗ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਜਦਕਿ ਇੱਕ ਰਿਪੋਰਟ ਪੇਜ਼ ਛੋਟੀ ਉਡੀਕ ਬਰਦਾਸ਼ਤ ਕਰ ਸਕਦਾ ਹੈ ਜੇ ਪਹਿਲਾ ਨਤੀਜਾ ਤੁਰੰਤ ਆ ਜਾਵੇ।
ਸਿਰਫ਼ ਦਫ਼ਤਰ Wi-Fi 'ਤੇ ਮਾਪ ਨਾ ਕਰੋ। ਧੀਮਿਆਂ ਕਨੈਕਸ਼ਨਾਂ 'ਤੇ, ਕਲਾਇੰਟ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਪਹਿਲੀ ਲੋਡ ਤੋਂ ਬਾਅਦ ਵਧੀਆ ਲੱਗ ਸਕਦੀ ਹੈ, ਪਰ ਉਹ ਪਹਿਲੀ ਲੋਡ ਸਭ ਤੋਂ ਧੀਮਾ ਹਿੱਸਾ ਹੋ ਸਕਦੀ ਹੈ। ਸਰਵਰ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਪੇਲੋਡ ਛੋਟੇ ਰੱਖਦੀ ਹੈ, ਪਰ ਜੇ ਤੁਸੀਂ ਹਰ ਕੀਸਟਰੋਕ 'ਤੇ ਰਿਕਵੇਸਟ ਭੇਜੋ ਤਾਂ ਇਹ ਧੀਮੀ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ।
ਇंसਾਨੀ ਇਨਪੁੱਟ ਦੇ ਆਧਾਰ 'ਤੇ ਡਿਜ਼ਾਇਨ ਕਰੋ। ਟਾਈਪ ਕਰਨ ਦੌਰਾਨ ਡੀਬਾਊਂਸ ਕਰੋ। ਵੱਡੇ ਰਿਜ਼ਲਟ ਸੈੱਟ ਲਈ ਪ੍ਰੋਗਰੇਸਿਵ ਲੋਡਿੰਗ ਵਰਤੋਂ ਤਾਂ ਕਿ ਪੇਜ਼ ਤੁਰੰਤ ਕੁਝ ਦਿਖਾਏ ਅਤੇ ਯੂਜ਼ਰ ਸਕ੍ਰੋਲ ਕਰਦਿਆਂ ਸਾਫ਼ ਰਹੇ।
ਫੈਸਲਾ ਕਾਰਕ 3: ਅਧਿਕਾਰ ਅਤੇ ਡਾਟਾ ਖੁਲਾਸਾ
ਗਿਣਤੀਆਂ ਅਤੇ ਪੰਨੇ ਮੇਲ ਖਾਂਦੇ ਬਣਾੋ
ਸਰਵਰ 'ਤੇ ਸੋਰਟਿੰਗ ਅਤੇ ਪੇਜਿਨੇਸ਼ਨ ਰੱਖ ਕੇ ਸਥਿਰ ਟੋਟਲ ਅਤੇ ਪੇਜ ਬਣਾਓ.
ਅਧਿਕਾਰਾਂ ਨੂੰ ਤੁਹਾਡੇ ਫਿਲਟਰਿੰਗ ਤਰੀਕੇ ਨੂੰ ਗਤੀਸ਼ੀਲਤਾ ਨਾਲ ਨਹੀਂ, ਬਲਕਿ ਤਰਜੀਹ ਨਾਲ ਨਿਰਧਾਰਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਬ੍ਰਾਉਜ਼ਰ ਨੂੰ ਕਦੇ ਵੀ ਉਹ ਡੇਟਾ ਮਿਲਦਾ ਹੈ ਜਿਸਨੂੰ ਯੂਜ਼ਰ ਵੇਖਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ, ਤਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਸਮੱਸਿਆ ਵਿੱਚ ਹੋ, ਭਾਵੇਂ ਤੁਸੀਂ UI ਵਿੱਚ ਉਸਨੂੰ ਲੁਕਾਈ ਵੀ ਦਿਓ।
ਇਸ ਸਕ੍ਰੀਨ 'ਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਕੀ ਹੈ ਇਹ ਨਾਮ ਦੇ ਕੇ ਸ਼ੁਰੂ ਕਰੋ। ਕੁਝ ਫੀਲਡ ਸਪਸ਼ਟ ਹੁੰਦੇ ਹਨ (ਈਮੇਲ, ਫੋਨ ਨੰਬਰ, ਪਤੇ)। ਹੋਰ ਆਸਾਨੀ ਨਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਹੋ ਸਕਦੇ ਹਨ: ਅੰਦਰੂਨੀ ਨੋਟਸ, ਲਾਗਤ ਜਾਂ ਮਾਰਜਿਨ, ਖਾਸ ਕੀਮਤ ਨਿਯਮ, ਰਿਸਕ ਸਕੋਰ, ਮੋਡਰੇਸ਼ਨ ਫਲੈਗ।
ਵੱਡਾ ਫੰਦ ਇਹ ਹੈ: "ਅਸੀਂ ਕਲਾਇੰਟ 'ਤੇ ਫਿਲਟਰ ਕਰਦੇ ਹਾਂ, ਪਰ ਸਿਰਫ਼ ਮਨਜ਼ੂਰ ਕੀਤੀਆਂ ਕਤਾਰਾਂ ਦਿਖਾਈਆਂ ਜਾਵਣਗੀਆਂ." ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਪੂਰਾ ਡੇਟਾ ਡਾਊਨਲੋਡ ਹੋਇਆ। ਕੋਈ ਵੀ ਨੈਟਵਰਕ ਜਵਾਬ ਇੰਸਪੈਕਟ ਕਰ ਸਕਦਾ ਹੈ, ਡਿਵ ਟੂਲ ਖੋਲ ਕੇ ਜਾਂ ਪੇਲੋਡ ਸੇਵ ਕਰਕੇ। UI ਵਿੱਚ ਕਾਲਮ ਲੁਕਾਉਣਾ ਐਕਸੈਸ ਕੰਟਰੋਲ ਨਹੀਂ ਹੈ।
ਜਦੋਂ ਸਰਵਰ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ ਹੈ
ਜਦੋਂ ਅਧਿਕਾਰ ਯੂਜ਼ਰ ਦੁਆਰਾ ਵੱਖਰੇ-ਵੱਖਰੇ ਹੋ ਸਕਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਵੱਖ-ਵੱਖ ਯੂਜ਼ਰ ਵੱਖ-ਵੱਖ ਕਤਾਰਾਂ ਜਾਂ ਫੀਲਡਾਂ ਵੇਖ ਸਕਦੇ ਹਨ, ਤਦ ਸਰਵਰ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਝਟਪਟ ਜਾਂਚ:
- ਕੀ ਵੱਖ-ਵੱਖ ਭੂਮਿਕਾਵਾਂ ਵੱਖ-ਵੱਖ ਕਤਾਰਾਂ ਵੇਖਦੀਆਂ ਹਨ (ਟੀਮ-ਕੇਵਲ, ਖੇਤਰ-ਕੇਵਲ, assigned-to-me)?
- ਕੀ ਵੱਖ-ਵੱਖ ਭੂਮਿਕਾਵਾਂ ਵੱਖ-ਵੱਖ ਫੀਲਡ ਵੇਖਦੀਆਂ ਹਨ (ਨੋਟਸ, ਕੀਮਤ, PII)?
- ਕੀ ਰੋ-ਲੈਵਲ ਨਿਯਮ ਹਨ (account owner, deal stage, “private” ਫਲੈਗ)?
- ਕੀ ਨਿਰਯਾਤ, ਸੋਰਟਿੰਗ, ਜਾਂ ਟੋਟਲ ਸੀਮਤ ਜਾਣਕਾਰੀ ਨੂੰ ਰਿਹਾ ਕਰ ਸਕਦੇ ਹਨ?
- ਕੀ ਇੱਕ ਲੀਕ ਹੋਏ ਪੇਲੋਡ ਨਾਲ ਅਨੁਸੂਚਨ ਸਮੱਸਿਆ ਹੋ ਸਕਦੀ ਹੈ?
ਜੇ ਕਿਸੇ ਵੀ ਸਵਾਲ ਦਾ ਉੱਤਰ ਹਾਂ ਹੈ, ਤਾਂ ਫਿਲਟਰ ਅਤੇ ਫੀਲਡ ਚੋਣ ਸਰਵਰ-ਪਾਸੇ ਰੱਖੋ। ਜੋ ਕੁਝ ਯੂਜ਼ਰ ਦੇਖ ਸਕਦੇ ਹਨ ਉਹੀ ਭੇਜੋ, ਅਤੇ ਖੋਜ, ਸੋਰਟ, ਪੇਜਿਨੇਸ਼ਨ ਅਤੇ ਨਿਰਯਾਤ 'ਤੇ ਉਹੀ ਨਿਯਮ ਲਾਗੂ ਕਰੋ।
ਉਦਾਹਰਨ: ਇੱਕ CRM ਸੰਪਰਕ ਲਿਸਟ ਵਿੱਚ, ਰੈਪ्स ਆਪਣੀਆਂ ਖਾਤਿਆਂ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹਨ ਜਦਕਿ ਮੈਨੇਜਰ ਸਾਰੀ ਟੀਮ ਦੇਖ ਸਕਦੇ ਹਨ। ਜੇ ਬ੍ਰਾਉਜ਼ਰ ਸਾਰੇ ਸੰਪਰਕ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ ਅਤੇ ਲੋਕਲ ਤੌਰ 'ਤੇ ਫਿਲਟਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਰੈਪ ਛੁਪੇ ਹੋਏ ਖਾਤਿਆਂ ਨੂੰ ਜਵਾਬ ਤੋਂ ਬਾਹਰ ਵੀ ਕੱਢ ਸਕਦਾ ਹੈ। ਸਰਵਰ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਇਹ ਰੋਕਦੀ ਹੈ ਕਿਉਂਕਿ ਉਹ ਉਹ ਰਿਕਾਰਡ ਕਦੇ ਹੀ ਨਹੀਂ ਭੇਜਦਾ।
ਫੈਸਲਾ ਕਾਰਕ 4: ਕੈਸ਼ਿੰਗ ਅਤੇ ਤਾਜਗੀ
ਕੈਸ਼ਿੰਗ ਇੱਕ ਸਕ੍ਰੀਨ ਨੂੰ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਵਾ ਸਕਦੀ ਹੈ। ਇਹ ਗਲਤ ਸੱਚ ਵੀ ਦਿਖਾ ਸਕਦੀ ਹੈ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਮੁੜ ਵਰਤ ਸਕਦੇ ਹੋ, ਕਿੰਨੀ ਦੇਰ ਲਈ, ਅਤੇ ਕਿਹੜੇ ਘਟਨਾਵਾਂ ਇਸਨੂੰ ਰੀਫ੍ਰੈਸ਼ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਨਗੇ।
ਕੈਸ਼ ਯੂਨਿਟ ਚੁਣ ਕੇ ਸ਼ੁਰੂ ਕਰੋ। ਪੂਰੀ ਲਿਸਟ ਕੈਸ਼ ਕਰਨਾ ਸਾਦਾ ਹੈ ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਫ਼ਜ਼ੂਲ ਬੈਂਡਵਿਡਥ ਖਰਚ ਕਰਦਾ ਹੈ ਅਤੇ ਜਲਦੀ ਸਟੇਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਅਨੰਤ ਸਕ੍ਰੋਲ ਲਈ ਪੇਜ ਕੈਸ਼ ਕਰਨਾ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ। ਕਵੈਰੀ ਨਤੀਜੇ (ਫਿਲਟਰ + ਸੋਰਟ + ਖੋਜ) ਕੈਸ਼ ਕਰਨਾ ਸਹੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਜੇ ਯੂਜ਼ਰ ਬਹੁਤ ਸਾਰੇ ਕੰਬੀਨੇਸ਼ਨ ਟ੍ਰਾਈ ਕਰਨਗੇ ਤਾਂ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧ ਸਕਦਾ ਹੈ।
ਤਾਜਗੀ ਕੁਝ ਡੋਮੇਨਾਂ ਵਿੱਚ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀ ਹੈ। ਜੇ ਡੇਟਾ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦਾ ਹੈ (ਸਟੌਕ ਲੈਵਲ, ਬੈਲੰਸ, ਡਿਲਿਵਰੀ ਸਟੇਟਸ), ਤਾਂ ਇੱਥੇ 30 ਸਕਿੰਟ ਦਾ ਕੈਸ਼ ਵੀ ਯੂਜ਼ਰ ਨੂੰ ਗੁੰਝਲਦਾਰ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਡੇਟਾ ਸਲੋ-ਚੇਂਜਿੰਗ ਹੈ (ਆਰਕਾਈਵ ਰਿਕਾਰਡ, ਰੈਫਰੈਂਸ ਡਾਟਾ), ਲੰਬਾ ਕੈਸ਼ ਠੀਕ ਰਹੇਗਾ।
ਕੋਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਨਵੈਲਿਡੇਸ਼ਨ ਦੀ ਯੋਜਨਾ ਬਣਾਓ। ਸਮਾਂ ਬੀਤਣ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕਿਹੜੀਆਂ ਘਟਨਾਵਾਂ ਰੀਫ੍ਰੈਸ਼ ਜ਼ਰੂਰੀ ਬਣਾਉਂਦੀਆਂ ਹਨ: ਬਣਾਉਣਾ/ਸੰਪਾਦਨ/ਮਿਟਾਉਣਾ, ਅਧਿਕਾਰ ਬਦਲਾਅ, ਬਲਕ ਇੰਪੋਰਟ ਜਾਂ ਮਰਜ, ਸਥਿਤੀ ਬਦਲਾਅ, ਅਨਡੂ/ਰੋਲਬੈਕ, ਅਤੇ ਪਿੱਛੇ ਚੱਲ ਰਹੇ ਜੌਬ ਜੋ ਫੀਲਡਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦੇ ਹਨ।
ਇਹ ਵੀ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੈਸ਼ ਕਿੱਥੇ ਰਹੇਗਾ। ਬ੍ਰਾਉਜ਼ਰ ਮੇਮੋਰੀ ਬੈਕ/ਫਾਰਵਰ ਨੇਵੀਗੇਸ਼ਨ ਨੂੰ ਤੇਜ਼ ਬਣਾਉਂਦੀ ਹੈ, ਪਰ ਜੇ ਤੁਸੀਂ ਇਹ ਯੂਜ਼ਰ ਅਤੇ ਆਰਗ ਦੁਆਰਾ ਕੀ ਹੀ ਕੀ-ਕਿਵੇਂ ਨਹੀਂ ਕਰਦੇ ਤਾਂ ਇਹ ਖਾਤਿਆਂ ਵਿਚ ਡੇਟਾ ਲੀਕ ਕਰ ਸਕਦੀ ਹੈ। ਬੈਕਐਂਡ ਕੈਸ਼ਿੰਗ ਅਧਿਕਾਰਾਂ ਅਤੇ ਸਥਿਰਤਾ ਲਈ ਸੁਰੱਖਿਅਤ ਹੈ, ਪਰ ਇਹ ਪੂਰੇ ਫਿਲਟਰ ਸਿਗਨੇਚਰ ਅਤੇ ਕਾਲਰ ਪਛਾਣ ਸ਼ਾਮਲ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਜੋ ਨਤੀਜੇ ਮਿਲ ਨਾ ਜਾਣ۔
ਕਦਮ-ਦਰ-कਦਮ: ਨਵੀਂ ਸਕ੍ਰੀਨ ਲਈ ਕਿਵੇਂ ਚੁਣੋ
ਲਕੜੀ ਦੇ ਸਾਰੇ ਨਿਰਣਾ ਅਟੱਲ ਹਨ: ਸਕ੍ਰੀਨ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੋਵੇ ਬਿਨਾਂ ਡਾਟਾ ਲੀਕ ਦੇ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਫੈਸਲਾ ਫਲੋ
- ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਪਾਬੰਦੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਅਕਸੇਸ ਭੂਮਿਕਾ, ਟੀਮ, ਖੇਤਰ, ਆਰਗ, ਜਾਂ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਦੁਆਰਾ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ ਤਾਂ ਅਧਿਕਾਰ ਜਿੱਤਦੇ ਹਨ। ਜੇ ਡੇਟਾਸੈਟ ਵੱਡਾ ਜਾਂ ਤੇਜ਼ ਵਧ ਰਿਹਾ ਹੈ, ਤਾਂ ਆਕਾਰ ਜਿੱਤਦਾ ਹੈ।
- ਜਦੋਂ ਡੇਟਾ ਵੱਡਾ ਜਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਹੋਵੇ ਤਾਂ ਡਿਫੌਲਟ ਸਰਵਰ-ਪਾਸੇ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਬ੍ਰਾਉਜ਼ਰ ਕੰਸੋਲ ਵਿੱਚ ਪੂਰਾ ਡੇਟਾ ਲਾਡ਼ ਕੇ ਸੁਖਦ ਨਹੀਂ ਮਹਿਸੂਸ ਕਰਦੇ, ਤਾਂ ਭੇਜੋ ਨਹੀਂ।
- ਕਲਾਇੰਟ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਸਿਰਫ ਛੋਟੇ, ਸੁਰੱਖਿਅਤ, ਦੁਬਾਰਾ ਵਰਤਣਯੋਗ ਲਿਸਟਾਂ ਲਈ ਵਰਤੋ। ਸਥਿਤੀ ਡ੍ਰੌਪਡਾਊਨ, ਛੋਟੇ ਟੈਗ ਲਿਸਟ, ਪਹਿਲਾਂ-ਮੰਜ਼ੂਰ ਨਤੀਜੇ ਦਾ ਇੱਕ ਪੰਨਾ।
- UI ਤੋਂ ਪਹਿਲਾਂ API ਆਕਾਰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਫਿਲਟਰ, ਸੋਰਟਿੰਗ, ਪੇਜਿਨੇਸ਼ਨ, ਅਤੇ ਡਿਫੌਲਟ ਲਿਖੋ ਤਾਂ ਜੋ ਸਰਵਰ ਅਤੇ UI ਵਿਚ ਵਿਵਾਦ ਨਾ ਹੋਵੇ।
- ਗਾਰਡਰੇਲਸ ਜੋੜੋ। ਮੈਕਸ ਪੇਜ ਸਾਈਜ਼ ਲਾਗੂ ਕਰੋ, ਟਾਈਮਆਉਟ ਸੈੱਟ ਕਰੋ, ਅਤੇ ਇਹ਼ ਫੈਸਲਾ ਕਰੋ ਕਿ ਜਦੋਂ ਫਿਲਟਰਿੰਗ ਧੀਮੀ ਹੋਵੇ UI ਕਿਵੇਂ ਬਰਤਾਓ (ਸਪੀਨਰ ਦਿਖਾਓ, ਪੁਰਾਣੇ ਨਤੀਜੇ ਰੱਖੋ, ਰੀਟ੍ਰਾਈ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰੋ)।
ਆਮ ਗਲਤੀਆਂ ਜੋ ਲੀਕ ਜਾਂ ਲੈਗ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ
ਮੂਲਭੂਤ ਤੌਰ 'ਤੇ ਡਾਟਾ ਲੀਕ ਰੋਕੋ
ਸੰਵੇਦਨਸ਼ੀਲ ਰਿਕਾਰਡਾਂ ਨੂੰ ਕਲਾਇੰਟ 'ਤੇ ਜਾਣ ਤੋਂ ਰੋਕੋ — ਫਿਲਟਰ ਅਤੇ ਫੀਲਡ ਚੋਣ ਸਰਵਰ 'ਤੇ ਲਾਗੂ ਕਰੋ.
ਅਕਸਰ ਟੀਮਾਂ ਇੱਕੋ ਜਿਹੇ ਪੈਟਰਨਾਂ ਨਾਲ ਡਾਂਟੀਆਂ ਜਾਂਦੀਆਂ ਹਨ: ਇੱਕ UI ਜੋ ਡੈਮੋ ਵਿੱਚ ਵਧੀਆ ਲੱਗਦੀ ਹੈ, ਪਰ ਅਸਲ ਡੇਟਾ, ਅਸਲ ਅਧਿਕਾਰ, ਅਤੇ ਅਸਲ ਨੈਟਵਰਕ ਸਪੀਡ ਨੇ ਉਹਦੇ ਦਰਾਰਾਂ ਨੂੰ ਖੋਲ੍ਹ ਦਿੱਤਾ।
ਉਹ ਗਲਤੀਆਂ ਜੋ ਡਾਟਾ ਲੀਕ ਕਰਦੀਆਂ ਹਨ
ਸਭ ਤੋਂ ਭਾਰੀ ਨਾਕਾਮੀ ਫਿਲਟਰਿੰਗ ਨੂੰ ਪ੍ਰਸਤੁਤੀ ਸਮਝਣਾ ਹੈ। ਜੇ ਬ੍ਰਾਉਜ਼ਰ ਨੂੰ ਉਹ ਰਿਕਾਰਡ ਮਿਲ ਰਹੇ ਹਨ ਜੋ ਉਹ ਨਹੀਂ ਦੇਖ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਹਾਰ ਗਏ।
ਦੋ ਆਮ ਕਾਰਨ:
- ਦੁਆਰਾ ਬ੍ਰਾਉਜ਼ਰ ਨੂੰ ਪੂਰਾ ਡੇਟਾ ਭੇਜਣਾ ਅਤੇ ਸੇਵਾ ਵਿੱਚ ਲੋਕਲ ਤੌਰ 'ਤੇ ਫਿਲਟਰ ਕਰਨਾ "ਤੇਜ਼ੀ ਲਈ"। ਕੋਈ ਵੀ ਨੈਟਵਰਕ ਜਵਾਬ ਜਾਂ ਮੈਮੋਰੀ ਵਿੱਚ ਡਾਟਾ ਵੇਖ ਸਕਦਾ ਹੈ।
- ਫਿਲਟਰ ਕੀਤੇ ਜਵਾਬਾਂ ਨੂੰ ਕੈਸ਼ ਕਰਨਾ ਬਿਨਾਂ ਕੈਸ਼ ਕੀ ਨੂੰ ਯੂਜ਼ਰ ਪਛਾਣ, ਆਰਗ, ਭੂਮਿਕਾ, ਜਾਂ ਨੀਤੀ ਵਰਜ਼ਨ ਨਾਲ ਜੋੜੇ। ਅਧਿਕਾਰ ਵਿੱਚ ਬਦਲਾਅ ਪੁਰਾਣਾ ਡੇਟਾ ਰਾਹੀਂ ਚੁਪਚਾਪ ਖੁਲਾਸਾ ਕਰ ਸਕਦਾ ਹੈ।
ਉਦਾਹਰਨ: ਇੰਟਰਨਸਾਂ ਨੂੰ ਸਿਰਫ਼ ਆਪਣੇ ਖੇਤਰ ਦੇ ਲੀਡ ਵੇਖਣੇ ਚਾਹੀਦੇ ਹਨ। ਜੇ API ਸਾਰੇ ਖੇਤਰ ਵਾਪਸ ਕਰਦਾ ਹੈ ਅਤੇ ਡ੍ਰੌਪਡਾਊਨ React ਵਿੱਚ ਲੋਡ ਹੋ ਕੇ ਫਿਲਟਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਇੰਟਰਨ ਪੂਰਾ ਲਿਸਟ ਕੱਢ ਸਕਦਾ ਹੈ।
ਉਹ ਗਲਤੀਆਂ ਜੋ ਸਕ੍ਰੀਨ ਨੂੰ ਧੀਮਾ ਬਣਾਉਂਦੀਆਂ ਹਨ
ਲੈਗ ਅਕਸਰ ਅਨੁਮਾਨਾਂ ਤੋਂ ਆਉਂਦਾ ਹੈ:
- ਇਹ ਸੋਚਣਾ ਕਿ ਕਲਾਇੰਟ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਹਮੇਸ਼ਾ ਤੇਜ਼ ਹੈ। 50,000 ਕਤਾਰਾਂ ਨਾਲ ਡਾਊਨਲੋਡ ਅਤੇ ਪਾਰਸ ਕਰਨਾ ਇੱਕ ਕੇਂਦ੍ਰਿਤ ਕੁਐਰੀ ਨਾਲੋਂ ਲੰਮਾ ਲੱਗ ਸਕਦਾ ਹੈ।
- ਪੇਜਿਨੇਸ਼ਨ ਅਤੇ ਲੋਡਿੰਗ ਸਟੇਟਾਂ ਨੂੰ ਭੁੱਲ ਜਾਣਾ। ਇੱਕ ਸਕ੍ਰੀਨ ਜੋ ਵੱਡੀ ਸੂਚੀ ਰੇਂਡਰ ਕਰਦਿਆਂ ਰੁਕ ਜਾਂਦਾ ਹੈ ਉਹ ਟੁੱਟਿਆ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਭਾਵੇਂ ਕੁਐਰੀ ਸਹੀ ਹੋਵੇ।
ਇੱਕ ਨਜ਼ਰਅੰਦਾਜ਼ ਪਰ ਦਰਦਨਾਕ ਸਮੱਸਿਆ ਮਿਸਮੇਚਡ ਨਿਯਮ ਹੈ। ਜੇ ਸਰਵਰ 'ਤੇ "starts with" ਨੂੰ ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਟ੍ਰੀਟ ਕਰਦਾ ਹੈ ਇਹ UI ਕਰਕੇ, ਤਾਂ ਯੂਜ਼ਰ ਗਿਣਤੀਆਂ ਦੇਖਦੇ ਹਨ ਜੋ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀਆਂ, ਜਾਂ ਨਤੀਜੇ ਰਿਫ੍ਰੈਸ਼ 'ਤੇ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ।
ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ
ਇੱਕ ਜਿਗਿਆਸੂ ਯੂਜ਼ਰ ਅਤੇ ਇੱਕ ਖਰਾਬ ਨੈਟਵਰਕ ਦਿਨ ਦੇ ਦੋ ਮਨੋਭਾਵਾਂ ਨਾਲ ਅਖੀਰਲਾ ਪਾਸਾ ਕਰੋ।
- ਪੇਲੋਡ ਸਮਝਦਾਰੀ: ਯਕੀਨ ਕਰੋ ਕਿ ਜਵਾਬਾਂ ਕਦੇ ਵੀ ਉਹ ਕਤਾਰਾਂ ਜਾਂ ਫੀਲਡ ਸ਼ਾਮਲ ਨਹੀਂ ਕਰਦੀਆਂ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਨਹੀਂ ਦੇਖਣੀਆਂ ਚਾਹੀਦੀਆਂ, ਭਾਵੇਂ UI ਉਨ੍ਹਾਂ ਨੂੰ ਲੁਕਾਉਂਦਾ ਹੋਵੇ। ਟੋਟਲ, ਗਰੁੱਪ ਗਿਣਤੀਆਂ, ਜਾਂ ID ਉਸੇ ਰਾਹੀਂ ਸੀਮਤ ਡੇਟਾ ਬਾਰੇ ਅਨੁਮਾਨ ਲਗਾ ਸਕਦੇ ਹਨ।
- ਸੁਰੱਖਿਅਤ ਲਾਗਿੰਗ: ਫਿਲਟਰ ਅਕਸਰ ਈਮੇਲ, ਨਾਂ, ਜਾਂ ID ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ। ਸੰਵੇਦਨਸ਼ੀਲ ਫਿਲਟਰ ਮੁੱਲ, ਪੂਰੇ SQL, ਜਾਂ ਪੂਰੇ ਬੋਡੀਜ਼ ਨੂੰ ਐਸੇ ਸਥਾਨਾਂ ਤੇ ਰਿਕਾਰਡ ਨਾ ਕਰੋ ਜਿੱਥੇ ਬਹੁਤ ਲੋਕਾਂ ਦੀ ਪਹੁੰਚ ਹੋਵੇ।
- ਡਿਵਾਈਸਾਂ 'ਤੇ ਇੱਕਸਾਰਤਾ: ਡੈਸਕਟਾਪ ਅਤੇ ਮੋਬਾਈਲ 'ਤੇ ਉਹੇ ਫਿਲਟਰ ਲਾਗੂ ਕਰੋ। ਫਰਕ ਆਮ ਤੌਰ 'ਤੇ ਕਲਾਇੰਟ-ਸਾਈਡ ਸੋਰਟਿੰਗ, ਲੋਕੇਲ ਨਿਯਮ (ਕੇਸ, ਅਕਸੈਂਟ), ਜਾਂ ਡਿਫੌਲਟ ਮੁੱਲਾਂ ਤੋਂ ਆਉਂਦੇ ਹਨ।
- ਸਪਸ਼ਟ ਸਥਿਤੀਆਂ: ਲੋਡ ਹੋ ਰਿਹਾ, ਖਾਲੀ, ਅਤੇ ਐਰਰ ਸਥਿਤੀਆਂ ਸਪਸ਼ਟ ਹੋਣ। ਤੇਜ਼ ਬਦਲਾਅ (ਟਾਈਪ, ਬੈਕਸਪੇਸ, ਟੌਗਲ) ਦਾ ਟੈਸਟ ਕਰੋ ਤਾਂ ਕਿ UI ਫਲਿਕਰ ਨਾ ਕਰੇ ਜਾਂ ਪੁਰਾਣੇ ਨਤੀਜੇ ਨਾ ਦਿਖਾਏ।
- ਵਰਸਟ-ਕੇਸ ਗਾਰਡਰੇਲਸ: ਮੈਕਸ ਪੇਜ ਸਾਈਜ਼, ਮੈਕਸ ਤਾਰੀਖ ਸੀਮਾ, ਅਤੇ ਟਾਈਮਆਉਟ. ਮਹਿੰਗੀਆਂ ਕੁਐਰੀਜ਼ (ਵਾਈਲਡਕਾਰਡ, ਬਹੁਤ ਸਾਰੇ OR ਸ਼ਰਤਾਂ, ਅਣ-ਇੰਡੈਕਸਡ ਫੀਲਡ) ਤੋਂ ਬਚਾਓ।
ਇਕ ਸਧਾਰਨ ਟੈਸਟ: ਇੱਕ ਸੀਮਤ ਰਿਕਾਰਡ ਬਣਾਓ ਅਤੇ ਯਕੀਨ ਕਰੋ ਕਿ ਇਹ ਕਦੇ ਵੀ ਪੇਲੋਡ, ਗਿਣਤੀ, ਜਾਂ ਕੈਸ਼ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦਾ, ਭਾਵੇਂ ਤੁਸੀਂ ਵਿਸਤਾਰ ਨਾਲ ਫਿਲਟਰ ਕਰੋ ਜਾਂ ਫਿਲਟਰ ਸਾਫ਼ ਕਰ ਦਿਉ।
ਉਦਾਹਰਨ ਸਨਾਰਿਓ: ਇੱਕ CRM ਸੰਪਰਕ ਲਿਸਟ
ਬਦਲਾਅ ਟੈਸਟ ਕਰੋ ਬਿਨਾਂ ਡਰ ਤੋਂ
ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਫਿਲਟਰਿੰਗ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰੋ, ਫਿਰ snapshots ਅਤੇ ਰੋਲਬੈਕ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸ ਜਾਓ.
ਸੋਚੋ ਇੱਕ CRM ਜਿਸ ਵਿੱਚ 200,000 ਸੰਪਰਕ ਹਨ। ਸੇਲਜ਼ ਰੈਪਸ ਸਿਰਫ਼ ਆਪਣੇ ਖਾਤਿਆਂ ਨੂੰ ਵੇਖ ਸਕਦੇ ਹਨ, ਮੈਨੇਜਰ ਆਪਣੀ ਟੀਮ ਦੇਖ ਸਕਦੇ ਹਨ, ਅਤੇ ਐਡਮਿਨ ਸਭ ਨੂੰ ਵੇਖ ਸਕਦੇ ਹਨ। ਸਕ੍ਰੀਨ 'ਤੇ ਖੋਜ, ਫਿਲਟਰ (ਸਥਿਤੀ, ਮਾਲਕ, ਆਖਰੀ ਸਰਗਰਮੀ) ਅਤੇ ਸੋਰਟਿੰਗ ਹੈ।
ਇੱਥੇ ਕਲਾਇੰਟ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਜਲਦੀ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ। ਪੇਲੋਡ ਭਾਰੀ ਹੈ, ਪਹਿਲੀ ਲੋਡ ਧੀਮੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਡਾਟਾ ਲੀਕ ਦਾ ਖਤਰਾ ਉੱਚਾ ਹੈ। ਭਾਵੇਂ UI ਕਤਾਰਾਂ ਨੂੰ ਛੁਪਾਓ, ਬ੍ਰਾਉਜ਼ਰ ਹਾਲੇ ਵੀ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰ ਚੁੱਕਾ ਹੋਵੇਗਾ। ਤੁਸੀਂ ਡਿਵਾਈਸ 'ਤੇ ਦਬਾਅ ਪਾਉਂਦੇ ਹੋ: ਵੱਡੀਆਂ ਐਰੇਜ਼, ਭਾਰੀ ਸੋਰਟਿੰਗ, ਬਾਰ-ਬਾਰ ਫਿਲਟਰ ਚਲਾਉਣਾ, ਬੁਜ਼ੁਰਗ ਫੋਨਾਂ 'ਤੇ ਮੈਮੋਰੀ ਇਸਤਮਾਲ ਅਤੇ ਕ੍ਰੈਸ਼।
ਇੱਕ ਸੁਰੱਖਿਅਤ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਸਰਵਰ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਨਾਲ ਪੇਜਿਨੇਸ਼ਨ ਹੈ। ਕਲਾਇੰਟ ਫਿਲਟਰ ਚੋਣਾਂ ਅਤੇ ਖੋਜ ਟੈੱਕਸਟ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਸਿਰਫ਼ ਉਹੀ ਰਿਕਾਰਡ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਦੇਖਣ ਦੀ ਆਗਿਆ ਹੈ ਭੇਜਦਾ ਹੈ, ਪਹਿਲਾਂ ਹੀ ਫਿਲਟਰ ਅਤੇ ਸੋਰਟ ਕੀਤੇ ਹੋਏ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਪੈਟਰਨ:
- ਪਹਿਲਾਂ ਅਧਿਕਾਰ ਲਗਾਓ, ਫਿਰ ਫਿਲਟਰ ਅਤੇ ਸੋਰਟ.
- ਹਰ ਵਾਰੀ ਇੱਕ ਪੇਜ ਵਾਪਸ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ 50 ਰਿਕਾਰਡ) ਨਾਲ ਇੱਕ ਟੋਟਲ ਗਿਣਤੀ.
- ਧਿਆਨ ਨਾਲ ਕੈਸ਼ ਕਰੋ (ਯੂਜ਼ਰ ਜਾਂ ਭੂਮਿਕਾ ਦਰਜਾ) ਤਾਂ ਜੋ ਅਧਿਕਾਰਾਂ ਵਿਚ ਰੁਕਾਵਟ ਆ ਕੇ ਨਤੀਜੇ ਮਿਲ ਨਾ ਜਾਣ।
ਇੱਕ ਛੋਟਾ ਛੁਟਕਾਰਾ ਜਿੱਥੇ ਕਲਾਇੰਟ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਠੀਕ ਹੈ: ਨਿੱਕੀ, ਸਥਿਰ ਡੇਟਾ। "Contact status" ਲਈ ਡ੍ਰੌਪਡਾਊਨ ਜਿਸ ਵਿੱਚ 8 ਮੁੱਲ ਹਨ, ਇੱਕ ਵਾਰੀ ਲੋਡ ਕਰਕੇ ਲੋਕਲ ਤੌਰ 'ਤੇ ਫਿਲਟਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਜ਼ਿਆਦਾ ਖ਼ਤਰੇ ਜਾਂ ਲਾਗਤ ਦੇ।
ਅਗਲੇ ਕਦਮ: ਫੈਸਲੇ ਦਸਤਾਵੇਜ਼ੀ ਕਰੋ ਅਤੇ ਘੱਟ ਰੀ-ਰਾਇਟਸ ਨਾਲ ਬਣਾਓ
ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਵਾਰੀ ਗਲਤ ਚੋਣ ਕਰਨ ਨਾਲ ਜ਼ਿਆਦਾ ਨਹੀਂ ਜ਼ਖਮੀ ਹੁੰਦੀਆਂ। ਉਹ ਨੇਹਾਂ ਇੱਥੇ ਜ਼ਖਮੀ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਹਰ ਸਕ੍ਰੀਨ 'ਤੇ ਵੱਖਰਾ ਫੈਸਲਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਅੰਤ 'ਤੇ ਲੀਕ ਅਤੇ ਧੀਮੇ ਪੇਜ਼ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ।
ਹਰ ਸਕ੍ਰੀਨ ਲਈ ਇੱਕ ਛੋਟਾ ਫੈਸਲਾ ਨੋਟ ਲਿਖੋ: ਫਿਲਟਰ, ਡੇਟਾਸੈਟ ਆਕਾਰ, ਬ੍ਰਾਉਜ਼ਰ 'ਤੇ ਭੇਜਣ ਦੀ ਲਾਗਤ, "ਤੇਜ਼ ਕਿੰਨਾ ਤੇਜ਼" ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਕਿਹੜੇ ਫੀਲਡ ਸੰਵੇਦਨਸ਼ੀਲ ਹਨ, ਅਤੇ ਨਤੀਜੇ ਕਿਵੇਂ ਕੈਸ਼ ਹੋਣ (ਯਾ ਨਹੀਂ)। ਸਰਵਰ ਅਤੇ UI ਨੂੰ ਲਾਈਨ ਤੇ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਦੋ ਵੱਖਰੀਆਂ ਸਚਾਈਆਂ ਵਾਲੀ ਫਿਲਟਰਿੰਗ ਨਾਲ ਨਾ ਰਹਿ ਜਾਓ।
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਸਕ੍ਰੀਨ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਅੱਗੇ ਐਨ ਸਮਝੋ ਕਿ ਕਿਹੜੇ ਫਿਲਟਰ ਬੈਕਐਂਡ 'ਤੇ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਲਾਗੂ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ (ਅਧਿਕਾਰ ਅਤੇ ਰੋ-ਲੈਵਲ ਐਕਸੈਸ) ਅਤੇ ਕਿਹੜੇ ਛੋਟੇ UI-ਕੇਵਲ ਟੌਗਲ React ਲੇਅਰ ਵਿੱਚ ਰਹਿ ਸਕਦੇ ਹਨ। ਇਹ ਇੱਕ ਚੋਣ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਮਹਿੰਗੀ ਰੀ-ਰਾਇਟਜ਼ ਰੋਕਦੀ ਹੈ।
ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ
ਮੈਨੂੰ ਸਰਵਰ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਕਦੋਂ ਵਰਤਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਕਦੋਂ ਕਲਾਇੰਟ-ਪਾਸੇ?
ਜਦੋਂ ਯੂਜ਼ਰਾਂ ਦੇ ਅਧਿਕਾਰ ਵੱਖ-ਵੱਖ ਹੋਣ, ਡੇਟਾਸੈਟ ਵੱਡਾ ਹੋਵੇ, ਜਾਂ ਤੁਸੀਂ ਪੇਜਿਨੇਸ਼ਨ ਅਤੇ ਟੋਟਲਸ ਦੀ ਸਥਿਰਤਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਰਵਰ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਕਰੋ। ਸਿਰਫ਼ ਉਹੀ ਸਮਾਂ ਕਲਾਇੰਟ-ਪਾਸੇ ਵਰਤੋ ਜਦੋਂ ਪੂਰਾ ਡੇਟਾਸੈਟ ਛੋਟਾ, ਸੁਰੱਖਿਅਤ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਡਾਊਨਲੋਡ ਹੋ ਸਕੇ।
ਜੇ ਮੈਂ UI ਵਿੱਚ ਕਤਾਰਾਂ ਲੁਕਾਉਂਦਾ/ਲੁਕਾਉਂਦੀ ਹਾਂ ਤਾਂ ਵੀ ਕਲਾਇੰਟ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਕਿਉਂ ਸੁਰੱਖਿਆ ਜੋਖਮ ਹੈ?
ਕਿਉਂਕਿ ਬ੍ਰਾਉਜ਼ਰ ਨੂੰ ਜੋ ਕੁਝ ਵੀ ਮਿਲਦਾ ਹੈ ਉਹ ਇੰਸਪੈਕਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਭਾਵੇਂ UI ਵਿੱਚ ਕਤਾਰਾਂ ਜਾਂ ਕਾਲਮ ਲੁਕਾਏ ਗਏ ਹੋਣ, ਯੂਜ਼ਰ ਨੈਟਵਰਕ ਜਵਾਬ, ਕੈਸ਼ਡ ਪੇਲੋਡ ਜਾਂ ਮੈਮੋਰੀ ਵਿੱਚ ਉਪਲਬਧ ਆਬਜੈਕਟ ਦੇਖ ਸਕਦਾ ਹੈ।
ਯੂਜ਼ਰਾਂ ਲਈ ਫਿਲਟਰਿੰਗ ਕਦੇ ਧੀਮੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ?
ਅਕਸਰ ਇਹ ਤਦ੍ਹਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰਾ ਡਾਟਾ ਭੇਜਦੇ ਹੋ ਅਤੇ ਫਿਰ ਹਰ ਕੀਸਟਰੋਕ 'ਤੇ ਵੱਡੀਆਂ ਐਰੇਜ਼ ਤੇ ਫਿਲਟਰ/ਸੋਰਟ ਚਲਾਉਂਦੇ ਹੋ, ਜਾਂ ਜਦੋਂ ਹਰ ਕੀਸਟਰੋਕ 'ਤੇ ਸਰਵਰ ਰਿਕਵੇਸਟ ਭੇਜੀ ਜਾਵੇ ਬਿਨਾਂ ਡੀਬਾਊਂਸ ਦੇ। ਪੇਲੋਡ ਛੋਟੇ ਰੱਖੋ ਅਤੇ ਹਰ ਇਨਪੁੱਟ ਚੇਂਜ 'ਤੇ ਭਾਰੀ ਕੰਮ ਤੋਂ ਬਚੋ।
ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਫਿਲਟਰਿੰਗ ਮਿਲਾਉਣ 'ਤੇ ਅਸੰਗਤ ਨਤੀਜਿਆਂ ਤੋਂ ਕਿਵੇਂ ਬਚਾ ਜਾ ਸਕਦਾ ਹੈ?
ਇੱਕ ਸੱਚਾ ਸਰੋਤ ਰੱਖੋ: ਅਧਿਕਾਰ, ਖੋਜ, ਸੋਰਟਿੰਗ ਅਤੇ ਪੇਜਿਨੇਸ਼ਨ ਨੂੰ ਇਕੱਠੇ ਸਰਵਰ 'ਤੇ ਲਾਗੂ ਕਰੋ। ਫਿਰ ਕਲਾਇੰਟ-ਸਾਈਡ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਛੋਟੇ UI-ਟੋਗਲ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ ਜੋ ਅਧਾਰਭੂਤ ਡੇਟਾਸੈਟ ਨੂੰ ਨਹੀਂ ਬਦਲਦੇ।
ਫਿਲਟਰ ਕੀਤੀਆਂ ਲਿਸਟਾਂ ਨੂੰ ਕਿਵੇਂ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕੈਸ਼ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?
ਕਲਾਇੰਟ-ਪਾਸੇ ਕੈਸ਼ਿੰਗ ਸਟੇਲ ਜਾਂ ਗਲਤ ਡੇਟਾ ਦਿਖਾ ਸਕਦੀ ਹੈ ਅਤੇ ਜੇ ਨੀਤੀ ਵਿੱਚ ਕੀ ਹੋਇਆ ਹੈ ਤਾਂ ਖਾਤਿਆਂ ਵਿਚ ਲੀਕ ਕਰ ਸਕਦੀ ਹੈ। ਸਰਵਰ-ਸਾਈਡ ਕੈਸ਼ਿੰਗ ਅਧਿਕਾਰਾਂ ਲਈ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਹੈ, ਪਰ ਇਹ ਪੂਰੇ ਫਿਲਟਰ ਸਿਗਨੇਚਰ ਅਤੇ ਕਾਲਰ ਦੀ ਪਹਚਾਨ ਸਮੇਤ ਕੀ ਹੋਈ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਜੋ ਨਤੀਜੇ ਮਿਲ ਨਾ ਜਾਣ।
ਮੈਂ ਕਿਸ ਤਰ੍ਹਾਂ ਅੰਦਾਜ਼ਾ ਲਗਾਾਂ ਕਿ ਡੇਟਾਸੈਟ ਕਲਾਇੰਟ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਲਈ “ਛੋਟਾ” ਹੈ?
ਦੋ ਸਵਾਲ ਪੁੱਛੋ: ਯੂਜ਼ਰ ਵਾਸਤਵਿਕਤਾਪੂਰਕ ਕਿੰਨੀ ਕਤਾਰਾਂ ਰੱਖ ਸਕਦਾ ਹੈ, ਅਤੇ ਪ੍ਰਤੀ ਕਤਾਰ ਬਾਈਟ ਵਿੱਚ ਕਿੰਨਾ ਵਜ਼ਨ ਹੈ। ਜੇ ਤੁਸੀਂ ਆਮ ਮੋਬਾਈਲ ਕਨੈਕਸ਼ਨ 'ਤੇ ਆਰਾਮ ਨਾਲ ਲੋਡ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਫਿਲਟਰਿੰਗ ਨੂੰ ਸਰਵਰ 'ਤੇ ਧੱਕੋ ਅਤੇ ਪੇਜਿਨੇਟ ਕਰੋ।
ਜੇ ਵੱਖ-ਵੱਖ ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਕਤਾਰਾਂ ਜਾਂ ਫੀਲਡਾਂ ਦੇਖਣਾਂ ਦਾ ਅਧਿਕਾਰ ਹੈ ਤਾਂ ਕੀ ਕਰਣਾ ਚਾਹੀਦਾ ਹੈ?
ਸਰਵਰ-ਪਾਸੇ. ਜੇ ਭੂਮਿਕਾ, ਟੀਮ, ਖੇਤਰ ਜਾਂ ਮਲਕੀਅਤ ਨਿਯਮ ਇਹ ਤਾਇਨ ਕਰਦੇ ਹਨ ਕਿ ਕਿਸਨੂੰ ਕਿਹੜੀਆਂ ਕਤਾਰਾਂ ਜਾਂ ਫੀਲਡਾਂ ਵੇਖਣ ਦੀ ਆਗਿਆ ਹੈ, ਤਾਂ ਸਰਵਰ ਨੂੰ ਕਤਾਰ ਅਤੇ ਫੀਲਡ ਪਹੁੰਚ ਲਾਗੂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਕਲਾਇੰਟ ਨੂੰ ਸਿਰਫ਼ ਉਹੀ ਡੇਟਾ ਭੇਜੋ ਜੋ ਯੂਜ਼ਰ ਦੇਖ ਸਕਦਾ ਹੈ।
ਸਰਵਰ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਲਈ API ਨੂੰ ਮੈਂ ਕਿਵੇਂ ਡਿਜ਼ਾਇਨ ਕਰਾਂ?
ਪਹਿਲਾਂ ਫਿਲਟਰ ਅਤੇ ਸੋਰਟ ਕੰਟਰੈਕਟ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: ਕਿਹੜੇ ਫਿਲਟਰ ਿਖ਼ਾਂ ਮਨਜ਼ੂਰ ਹਨ, ਡਿਫੌਲਟ ਸੋਰਟਿੰਗ, ਪੇਜਿਨੇਸ਼ਨ ਨਿਯਮ ਅਤੇ ਖੋਜ ਕਿਵੇਂ ਮਿਲਦੀ ਹੈ (ਕੇਸ, ਅੱਖਰ ਚਿੰਨ੍ਹ). ਫਿਰ ਇੱਕੋ ਲਾਜਿਕ ਬੈਕਐਂਡ 'ਤੇ ਲਾਗੂ ਕਰੋ ਅਤੇ ਟੈਸਟ ਕਰੋ ਕਿ ਟੋਟਲ ਅਤੇ ਪੇਜ ਮੇਲ ਖਾਂਦੇ ਹਨ।
ਸਰਵਰ-ਪਾਸੇ ਫਿਲਟਰਿੰਗ ਨੂੰ UI ਵਿੱਚ ਤੇਜ਼ ਕਿਵੇਂ ਮਹਿਸੂਸ ਕਰਵਾਇਆ ਜਾ ਸਕਦਾ ਹੈ?
ਟਾਈਪਿੰਗ ਲਈ ਡੀਬਾਊਂਸ ਕਰੋ ਤਾਂ ਜੋ ਹਰ ਕੀਸਟਰੋਕ 'ਤੇ ਰਿਕਵੇਸਟ ਨਾ ਜਾਵੇ, ਅਤੇ ਨਵੇਂ ਨਤੀਜੇ ਆਉਣ ਤੱਕ ਪੁਰਾਣੇ ਨਤੀਜੇ ਦਿਖਾਓ ਤਾਂ ਕਿ ਫਲਿਕਰ ਘਟੇ। ਪੇਜਿਨੇਸ਼ਨ ਜਾਂ ਪ੍ਰੋਗਰੇਸਿਵ ਲੋਡਿੰਗ ਵਰਤੋਂ ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਚੀਜ਼ਾਂ ਤੁਰੰਤ ਦਿੱਸਣ ਲੱਗਣ।
ਬਹੁਤ ਸਾਰੇ ਰਿਕਾਰਡ ਅਤੇ ਕਠੋਰ ਅਧਿਕਾਰਾਂ ਵਾਲੀ CRM ਲਿਸਟ ਲਈ ਚੰਗੀ ਦਿਸ਼ਾ ਕੀ ਹੈ?
ਪਹਿਲਾਂ ਅਧਿਕਾਰ ਲਗਾਓ, ਫਿਰ ਫਿਲਟਰ ਅਤੇ ਸੋਰਟ. ਇਕ ਪੇਜ ਹੀ ਵਾਪਸ ਭੇਜੋ (ਉਦਾਹਰਨ ਵਜੋਂ 50 ਕਤਾਰਾਂ) ਅਤੇ ਇੱਕ ਟੋਟਲ ਗਿਣਤੀ. "ਜ਼ਰੂਰਤ ਪੈਣ 'ਤੇ ਵਾਧੂ ਫੀਲਡ" ਨਾ ਭੇਜੋ ਅਤੇ ਕੈਸ਼ ਕੀ ਵਿਚ ਯੂਜ਼ਰ/ਆਰਗ/ਭੂਮਿਕਾ ਸ਼ਾਮਲ ਹੋਣ ਦੀ ਯਕੀਨੀ ਬਣਾਓ ਤਾਂ ਕਿ ਰੈਪ ਖਾਤੇ ਲਈ ਮੈਨੇਜਰ ਲਈ ਮੰਤੂਕ ਡਾਟਾ ਕਦੇ ਨਾ ਮਿਲੇ।