ਇੱਕ ਨਵਾਂ Laravel-ਕੇਂਦ੍ਰਿਤ ਗਾਈਡ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਵੈੱਬਹੂਕ (webhook) ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਕੇ, idempotency ਲਈ Redis ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਤੇ ਭਾਰੀ ਕੰਮਾਂ ਨੂੰ queues 'ਤੇ ਪੁਸ਼ ਕਰਕੇ Telegram bots ਨੂੰ ਟਾਈਮ-ਆਊਟ ਹੋਣ, ਐਕਸ਼ਨਾਂ ਨੂੰ ਡੁਪਲੀਕੇਟ ਕਰਨ ਜਾਂ ਲੋਡ ਹੇਠ ਕ੍ਰੈਸ਼ ਹੋਣ ਤੋਂ ਕਿਵੇਂ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ।

Telegram webhooks ਲਈ ਇੱਕ ਸਧਾਰਨ ਰੂਟ ਤੋਂ ਵੱਧ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ

Telegram ਹਰੇਕ ਯੂਜ਼ਰ ਇੰਟਰੈਕਸ਼ਨ ਨੂੰ ਡਿਵੈਲਪਰ ਦੁਆਰਾ ਨਿਰਧਾਰਤ URL 'ਤੇ HTTP POST ਵਜੋਂ ਬੋਟ ਨੂੰ ਭੇਜਦਾ ਹੈ। ਪਲੇਟਫਾਰਮ ਕੁਝ ਸਕਿੰਟਾਂ ਦੇ ਅੰਦਰ 200 OK ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ; ਜੇਕਰ ਇਸ ਵਿੱਚੋਂ ਵੱਧ ਸਮਾਂ ਲੱਗਦਾ ਹੈ, ਤਾਂ ਇਹ ਰਿਕਵੈਸਟ ਨੂੰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ (retry) ਕਰਦਾ ਹੈ। ਰਿਟ੍ਰਾਈਜ਼ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕੋ update_id ਕਈ ਵਾਰ ਆ ਸਕਦਾ ਹੈ, ਅਤੇ ਜੇਕਰ ਬੋਟ ਰਿਕਵੈਸਟ ਦੇ ਅੰਦਰ ਡਾਟਾਬੇਸ ਵਿੱਚ ਲਿਖਦਾ ਹੈ ਜਾਂ ਬਾਹਰੀ APIs ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਡੁਪਲੀਕੇਟ ਰੋਅਜ਼ (rows), ਦੋਹਰੇ ਸੁਨੇਹੇ, ਜਾਂ race conditions ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। ਉਹਨਾਂ ਬੋਟਾਂ ਲਈ ਜੋ ਪ੍ਰਤੀ ਸਕਿੰਟ ਦਰਜਨਾਂ ਜਾਂ ਸੈਂਕੜੇ ਸੁਨੇਹੇ ਸੰਭਾਲਦੇ ਹਨ, ਉਹ ਲੇਟੈਂਸੀ (latency) ਜਲਦੀ ਹੀ ਇੱਕ ਰੁਕਾਵਟ ਬਣ ਜਾਂਦੀ ਹੈ।

1. ਇੱਕ ਸੀਕਰੇਟ ਹੈਡਰ ਨਾਲ ਐਂਡਪੁਆਇੰਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰੋ

Telegram ਹਰੇਕ webhook ਕਾਲ ਵਿੱਚ X-Telegram-Bot-Api-Secret-Token ਹੈਡਰ ਜੋੜਦਾ ਹੈ। ਉਸ ਹੈਡਰ ਦੀ ਤੁਲਨਾ ਸਰਵਰ 'ਤੇ ਸਟੋਰ ਕੀਤੇ ਇੱਕ ਸੀਕਰੇਟ ਨਾਲ ਕਰੋ—timing attacks ਤੋਂ ਬਚਣ ਲਈ PHP ਦੇ hash_equals ਫੰਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰੋ—ਅਤੇ ਕਿਸੇ ਵੀ ਅਜਿਹੀ ਰਿਕਵੈਸਟ ਨੂੰ ਰੱਦ ਕਰ ਦਿਓ ਜੋ Telegram ਤੋਂ ਨਹੀਂ ਆ ਰਹੀ। Laravel ਵਿੱਚ, ਇਸ ਚੈੱਕ ਨੂੰ middleware ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਜੋ controller ਦੁਆਰਾ payload ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਵੈਰੀਫਿਕੇਸ਼ਨ ਹੋ ਜਾਵੇ।

2. Redis ਨਾਲ ਹਰੇਕ update ਨੂੰ idempotent ਬਣਾਓ

ਹਰੇਕ ਆਉਣ ਵਾਲੇ payload ਵਿੱਚ ਇੱਕ ਵਿਲੱਖਣ update_id ਹੁੰਦਾ ਹੈ। ਗਾਈਡ ਉਸ ID ਨੂੰ NX (set-if-not-exists) ਫਲੈਗ ਦੇ ਨਾਲ Redis ਵਿੱਚ ਲਿਖਣ ਦਾ ਸੁਝਾਅ ਦਿੰਦੀ ਹੈ। ਇਹ ਕਾਰਵਾਈ ਸਿਰਫ ਪਹਿਲੀ ਵਾਰ ਹੋਣ 'ਤੇ ਸਫਲ ਹੁੰਦੀ ਹੈ; ਰਿਟ੍ਰਾਈ (retry) ਕਰਨ 'ਤੇ ਕੀ (key) ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਮਿਲਦੀ ਹੈ ਅਤੇ webhook ਤੁਰੰਤ 200 OK ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ, ਜੋ Telegram ਨੂੰ ਸੰਕੇਤ ਦਿੰਦਾ ਹੈ ਕਿ update ਨੂੰ ਸੰਭਾਲ ਲਿਆ ਗਿਆ ਹੈ। ਕਿਉਂਕਿ Redis ਮੈਮੋਰੀ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਇਸ ਚੈੱਕ ਨਾਲ ਲਗਭਗ ਕੋਈ ਲੇਟੈਂਸੀ ਨਹੀਂ ਵਧਦੀ, ਅਤੇ ਡੁਪਲੀਕੇਟਾਂ ਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ ਕੀ (key) ਉੱਥੇ ਹੀ ਰਹਿੰਦੀ ਹੈ।

3. ਭਾਰੀ ਕੰਮਾਂ ਨੂੰ background jobs ਨੂੰ ਸੌਂਪ ਦਿਓ

ਇੱਕ ਤੇਜ਼ Redis ਚੈੱਕ ਦੇ ਨਾਲ ਵੀ, ਬੋਟ ਦਾ business logic—ਡਾਟਾਬੇਸ ਲਿਖਣਾ, third-party API ਕਾਲ, ਸੁਨੇਹਾ ਤਿਆਰ ਕਰਨਾ—ਕਦੇ ਵੀ webhook ਰਿਕਵੈਸਟ ਦੇ ਅੰਦਰ ਨਹੀਂ ਚੱਲਣਾ ਚਾਹੀਦਾ। ਜਿਵੇਂ ਹੀ webhook ਵੈਰੀਫਾਈ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ update_id ਸਟੋਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਤੁਰੰਤ ਇੱਕ Laravel queued job ਡਿਸਪੈਚ ਕਰੋ। HTTP ਰਿਸਪਾਂਸ ਤੁਰੰਤ ਭੇਜੋ, ਅਤੇ worker ਨੂੰ ਆਪਣੀ ਗਤੀ ਨਾਲ job ਪ੍ਰੋਸੈਸ ਕਰਨ ਦਿਓ। ਇਹ ਬੋਟ ਨੂੰ Telegram ਦੀ ਰਿਸਪਾਂਸ ਡੈੱਡਲਾਈਨ ਦੇ ਅੰਦਰ ਰੱਖਦਾ ਹੈ ਅਤੇ ਪਲੇਟਫਾਰਮ ਨੂੰ ਰਿਟ੍ਰਾਈ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।

Production-grade ਸੁਧਾਰ

  • Rate limits ਦਾ ਸਤਿਕਾਰ ਕਰੋ। ਜਦੋਂ ਕੋਈ ਬੋਟ ਆਪਣੀ ਪ੍ਰਤੀ-ਸਕਿੰਟ ਸੀਮਾ ਤੋਂ ਵੱਧ ਜਾਂਦਾ ਹੈ, ਤਾਂ Telegram Retry-After ਹੈਡਰ ਦੇ ਨਾਲ 429 Too Many Requests ਵਾਪਸ ਕਰਦਾ ਹੈ। Queue workers ਨੂੰ ਉਹ ਹੈਡਰ ਪੜ੍ਹਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਅਸਫਲ job ਨੂੰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰੁਕਣਾ ਚਾਹੀਦਾ ਹੈ।
  • ਜਵਾਬ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਡਾਟਾ ਸੇਵ ਕਰੋ। ਕਿਸੇ ਵੀ ਯੂਜ਼ਰ ਡਾਟਾ ਨੂੰ ਪਹਿਲਾਂ ਡਾਟਾਬੇਸ ਵਿੱਚ ਲਿਖੋ; ਸਿਰਫ ਇੱਕ ਸਫਲ commit ਤੋਂ ਬਾਅਦ ਹੀ ਬੋਟ ਨੂੰ ਪੁਸ਼ਟੀਕਰਨ ਸੁਨੇਹਾ ਭੇਜਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਤਰਤੀਬ ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ ਜਿੱਥੇ ਸੁਨੇਹਾ ਯੂਜ਼ਰ ਤੱਕ ਪਹੁੰਚ ਜਾਂਦਾ ਹੈ ਪਰ ਉਸ ਨਾਲ ਸਬੰਧਤ ਰਿਕਾਰਡ ਕਦੇ ਬਣਦਾ ਹੀ ਨਹੀਂ।
  • Callback payloads ਨੂੰ ਛੋਟਾ ਰੱਖੋ। Telegram callback_data ਨੂੰ 64 bytes ਤੱਕ ਸੀਮਤ ਰੱਖਦਾ ਹੈ। ਸੀਮਾ ਦੇ ਅੰਦਰ ਰਹਿਣ ਲਈ ਵੱਡੇ blobs ਨੂੰ ਡਾਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕਰੋ ਅਤੇ ਬਟਨ payload ਵਿੱਚ ਸਿਰਫ ਇੱਕ reference ID ਪਾਸ ਕਰੋ।

ਸਿੱਟਾ: ਰਿਕਵੈਸਟ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ (authentication) ਕਰਨਾ, Redis ਨਾਲ ਡੁਪਲੀਕੇਟਾਂ ਨੂੰ ਰੋਕਣਾ ਅਤੇ ਕੰਮ ਨੂੰ queues 'ਤੇ ਸੌਂਪਣਾ Laravel ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਅਜਿਹੇ Telegram bots ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜੋ ਤੁਰੰਤ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, rate limits ਦੇ ਅੰਦਰ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਯੂਜ਼ਰ ਦੀ ਮੰਗ ਵਧਣ ਨਾਲ ਆਸਾਨੀ ਨਾਲ ਵਧ (scale) ਸਕਦੇ ਹਨ।