ఒక కొత్త Laravel-కేంద్రీకృత గైడ్, వెబ్హుక్ను (webhook) సురక్షితం చేయడం, ఐడెంపోటెన్సీ (idempotency) కోసం Redisని ఉపయోగించడం మరియు భారీ పనులను క్యూలకు (queues) పంపడం ద్వారా, టెలిగ్రామ్ బాట్లు టైమ్ అవుట్ కాకుండా, పనులను డూప్లికేట్ చేయకుండా లేదా లోడ్ కింద క్రాష్ కాకుండా డెవలపర్లు ఎలా చూసుకోవాలో చూపుతుంది.
టెలిగ్రామ్ వెబ్హుక్లకు కేవలం ఒక సాధారణ రూట్ (route) మాత్రమే ఎందుకు సరిపోదు
టెలిగ్రామ్ ప్రతి యూజర్ ఇంటరాక్షన్ను డెవలపర్ సూచించిన URLకి HTTP POST ద్వారా బాట్కు పంపుతుంది. ఈ ప్లాట్ఫారమ్ కొన్ని సెకన్లలోపు 200 OK ని ఆశిస్తుంది; అంతకంటే ఎక్కువ సమయం తీసుకుంటే అది రిక్వెస్ట్ను మళ్ళీ పంపుతుంది (retry). రిట్రైలు అంటే ఒకే update_id బహుళసార్లు రావచ్చు, మరియు బాట్ రిక్వెస్ట్ లోపల డేటాబేస్కు రాసినా లేదా ఎక్స్టర్నల్ APIలను కాల్ చేసినా, అది డూప్లికేట్ రోస్, డబుల్ మెసేజ్లు లేదా రేస్ కండిషన్స్కు దారితీయవచ్చు. సెకనుకు డజన్ల కొద్దీ లేదా వందల కొద్దీ మెసేజ్లను హ్యాండిల్ చేసే బాట్లకు, ఆ లేటెన్సీ (latency) త్వరగా ఒక అడ్డంకిగా మారుతుంది.
1. సీక్రెట్ హెడర్తో ఎండ్పాయింట్ను సురక్షితం చేయండి
టెలిగ్రామ్ ప్రతి వెబ్హుక్ కాల్కి X-Telegram-Bot-Api-Secret-Token హెడర్ను జోడిస్తుంది. టైమింగ్ అటాక్లను (timing attacks) నివారించడానికి PHP యొక్క hash_equals ఫంక్షన్ను ఉపయోగించి, ఆ హెడర్ను సర్వర్లో నిల్వ చేసిన సీక్రెట్తో పోల్చండి—మరియు టెలిగ్రామ్ నుండి కాకుండా ఇతర మూలాల నుండి వచ్చే ఏ రిక్వెస్ట్నైనా తిరస్కరించండి. Laravelలో, ఈ చెక్ను మిడిల్వేర్ (middleware)లో ఉంచండి, తద్వారా కంట్రోలర్ పేలోడ్ను (payload) తాకకముందే వెరిఫికేషన్ పూర్తవుతుంది.
2. Redisతో ప్రతి అప్డేట్ను ఐడెంపోటెంట్ (idempotent) చేయండి
ప్రతి ఇన్కమింగ్ పేలోడ్ ఒక ప్రత్యేకమైన update_idని కలిగి ఉంటుంది. ఆ IDని NX (set-if-not-exists) ఫ్లాగ్తో Redisలో రాయాలని ఈ గైడ్ సూచిస్తుంది. ఈ ఆపరేషన్ మొదటిసారి మాత్రమే విజయవంతమవుతుంది; రిట్రై చేసినప్పుడు ఆ కీ ఇప్పటికే ఉన్నట్లు కనిపిస్తుంది మరియు వెబ్హుక్ వెంటనే 200 OK ని తిరిగి పంపవచ్చు, తద్వారా అప్డేట్ హ్యాండిల్ చేయబడిందని టెలిగ్రామ్కు సంకేతం అందుతుంది. Redis మెమరీలో ఉండటం వల్ల, ఈ చెక్ వల్ల దాదాపుగా ఎటువంటి లేటెన్సీ పెరగదు మరియు డూప్లికేట్లను గుర్తించడానికి ఆ కీ అలాగే ఉంటుంది.
3. భారీ పనులను బ్యాక్గ్రౌండ్ జాబ్స్కు అప్పగించండి
వేగవంతమైన Redis చెక్ ఉన్నప్పటికీ, బాట్ యొక్క బిజినెస్ లాజిక్—డేటాబేస్ రైట్స్, థర్డ్-పార్టీ API కాల్స్, మెసేజ్ కాంపోజిషన్—ఎప్పుడూ వెబ్హుక్ రిక్వెస్ట్ లోపల రన్ కాకూడదు. వెబ్హుక్ వెరిఫై చేయబడిన వెంటనే మరియు update_id స్టోర్ చేయబడిన వెంటనే ఒక Laravel క్యూడ్ జాబ్ (queued job)ను డిస్పాచ్ చేయండి. HTTP రెస్పాన్స్ను తక్షణమే పంపండి, తద్వారా వర్కర్ తన వేగంతో జాబ్ను ప్రాసెస్ చేయగలదు. ఇది బాట్ను టెలిగ్రామ్ రెస్పాన్స్ డెడ్లైన్ లోపల ఉంచుతుంది మరియు ప్లాట్ఫారమ్ రిట్రై చేయకుండా నిరోధిస్తుంది.
ప్రొడక్షన్-గ్రేడ్ (Production-grade) మార్పులు
- రేట్ లిమిట్లను (rate limits) గౌరవించండి. బాట్ సెకనుకు నిర్ణయించిన పరిమితిని మించినప్పుడు, టెలిగ్రామ్
Retry-Afterహెడర్తో 429 Too Many Requests ని తిరిగి పంపుతుంది. క్యూ వర్కర్లు ఆ హెడర్ను చదివి, విఫలమైన జాబ్ను మళ్ళీ ప్రయత్నించే ముందు కొంత సమయం ఆగాలి. - సమాధానం ఇచ్చే ముందు డేటాను సేవ్ చేయండి. ఏదైనా యూజర్ డేటాను మొదట డేటాబేస్లో రాయండి; సక్సెస్ఫుల్ కమిట్ అయిన తర్వాత మాత్రమే బాట్ కన్ఫర్మేషన్ మెసేజ్ను పంపాలి. ఈ క్రమాన్ని పాటించడం వల్ల, మెసేజ్ యూజర్కు చేరుతుంది కానీ దానికి సంబంధించిన రికార్డు డేటాబేస్లో ఉండదు అనే పరిస్థితిని నివారించవచ్చు.
- కాల్బ్యాక్ పేలోడ్లను (callback payloads) తగ్గించండి. టెలిగ్రామ్
callback_dataను 64 bytes వద్ద పరిమితం చేస్తుంది. పరిమితిలో ఉండటానికి పెద్ద డేటాను (blobs) డేటాబేస్లో నిల్వ చేయండి మరియు బటన్ పేలోడ్లో కేవలం రిఫరెన్స్ IDని మాత్రమే పంపండి.
ముగింపు: రిక్వెస్ట్ను అథెంటికేట్ చేయడం, Redisతో డూప్లికేట్లను తొలగించడం మరియు పనులను క్యూలకు అప్పగించడం ద్వారా, Laravel డెవలపర్లు తక్షణమే స్పందించే, రేట్ లిమిట్ల లోపల ఉండే మరియు యూజర్ డిమాండ్ పెరిగే కొద్దీ సులభంగా స్కేల్ అయ్యే టెలిగ్రామ్ బాట్లను నిర్మించవచ్చు.