रेट लिमिटिंग
यह सीमित करें कि एक पाठक असिस्टेंट, API प्लेग्राउंड प्रॉक्सी और सर्वर-साइड सर्च को कितनी बार कॉल कर सकता है। यह सुविधा डिफ़ॉल्ट रूप से चालू रहती है, और गिनती मेमोरी, Upstash या Cloudflare में रखी जाती है।
पाठक जिन सर्वर रूट्स को कॉल कर सकते हैं, उनकी हर कॉल पर आपका कुछ खर्च होता है। असिस्टेंट मॉडल टोकन खर्च करता है, API प्लेग्राउंड प्रॉक्सी अनुरोधों को आपके API तक पहुँचाता है और Mixedbread सर्च एक सशुल्क क्वेरी चलाता है। Blume पाठक को उसके IP पते से पहचानता है और यह सीमित करता है कि वह इनमें से हर रूट को कितनी बार कॉल कर सकता है। सीमा पार करने वाले पाठक को Retry-After हेडर के साथ 429 Too Many Requests मिलता है, और असिस्टेंट उनसे कुछ मिनट बाद फिर से प्रयास करने के लिए कहता है।
रेट लिमिटिंग डिफ़ॉल्ट रूप से चालू रहती है। इसकी सीमा हर 10 मिनट में प्रति पाठक, प्रति रूट 30 अनुरोध है। यह इतनी पर्याप्त है कि किसी सामान्य व्यक्ति को कभी इसका सामना न करना पड़े, और इतनी कम भी है कि किसी स्क्रिप्ट को रोका जा सके। यह केवल सर्वर बिल्ड में लागू होती है, क्योंकि स्टैटिक साइट में सीमित करने के लिए कोई सर्वर रूट नहीं होता।
import { defineConfig } from "blume";
import { upstash } from "blume/ratelimit";
export default defineConfig({
rateLimit: upstash({ requests: 30, window: 600 }), // window in seconds
});
हर रूट अपनी अलग गिनती रखता है। इसलिए प्लेग्राउंड का लंबा उपयोग पाठक के असिस्टेंट प्रश्नों की सीमा को ख़त्म नहीं करता।
गिनती कहाँ रखी जाती है
| एडैप्टर | गिनती का स्थान | सीमा कैसे लागू होती है |
|---|---|---|
memory() |
सर्वर की मेमोरी (डिफ़ॉल्ट) | एक सर्वर पर सटीक रूप से; सर्वरलेस होस्ट पर प्रति इंस्टेंस |
upstash() |
Upstash Redis | हर होस्ट पर सटीक रूप से |
cloudflare() |
Cloudflare की Workers रेट लिमिटिंग | प्रति Cloudflare लोकेशन |
मेमोरी
memory() के लिए किसी सेटअप की आवश्यकता नहीं है। deployment: node() जैसे एक ही प्रोसेस में चलने वाले सर्वर पर गिनती सटीक होती है। Vercel, Netlify और Cloudflare कई अल्पकालिक इंस्टेंस चलाते हैं और हर इंस्टेंस अपनी अलग गिनती रखता है। इसलिए इन होस्ट पर यह सीमा को सटीक रूप से लागू नहीं करता, बल्कि किसी एक पाठक के अचानक आए बहुत सारे अनुरोधों को रोकता है। इन होस्ट पर सटीक सीमा के लिए नीचे दिए गए साझा स्टोर में से किसी एक का उपयोग करें।
import { memory } from "blume/ratelimit";
rateLimit: memory({ requests: 60, window: 600 }),
Upstash
upstash() गिनती को Upstash Redis में रखता है, जिसे सभी इंस्टेंस साझा करते हैं। पहले एक डेटाबेस बनाएँ। Vercel पर आप Marketplace से Upstash जोड़ सकते हैं। फिर उसके REST एंडपॉइंट और टोकन को UPSTASH_REDIS_REST_URL और UPSTASH_REDIS_REST_TOKEN के रूप में सेट करें। Blume सीधे Upstash के REST API का उपयोग करता है, इसलिए आपको कुछ भी इंस्टॉल करने की आवश्यकता नहीं है। जब तक ये दोनों सेट नहीं होते, तब तक रूट्स मेमोरी में गिनती करते हैं और blume build चेतावनी देता है।
import { upstash } from "blume/ratelimit";
rateLimit: upstash(),
Cloudflare
cloudflare() एडैप्टर deployment: cloudflare() से डिप्लॉय की गई साइट के लिए है और Workers रेट लिमिटिंग से गिनती करता है। Blume बिल्ड के समय Worker के कॉन्फ़िग में बाइंडिंग घोषित कर देता है, इसलिए आपको कुछ भी सेट अप करने की आवश्यकता नहीं है। Cloudflare प्रति लोकेशन गिनती करता है और केवल 10 या 60 सेकंड की विंडो स्वीकार करता है। इसलिए इसकी डिफ़ॉल्ट सीमा 60 सेकंड में 10 अनुरोध है।
import { cloudflare } from "blume/deploy";
import { cloudflare as cloudflareRateLimit } from "blume/ratelimit";
export default defineConfig({
deployment: cloudflare(),
rateLimit: cloudflareRateLimit({ requests: 10, window: 60 }),
});
बाइंडिंग का नेमस्पेस Worker के नाम से लिया जाता है, इसलिए एक ही खाते की दो साइटें अपनी गिनती साझा नहीं करतीं। नेमस्पेस स्वयं चुनने के लिए namespaceId सेट करें।
इसे बंद करना
हर अनुरोध को बिना सीमा के आने देने के लिए rateLimit: false सेट करें। यह तब उपयोगी है जब, उदाहरण के लिए, आपके होस्ट का फ़ायरवॉल पहले से इन रूट्स को सीमित करता हो। अगर होस्ट किसी अनुरोध का पता नहीं पहचान पाता, तो उस अनुरोध को हमेशा आने दिया जाता है। यही उस अनुरोध के साथ भी होता है जिसे कोई साझा स्टोर गिन नहीं पाता। ऐसी विफलता लॉग की जाती है, इसलिए स्टोर के आउटेज के कारण पाठक कभी ब्लॉक नहीं होते।
असिस्टेंट के लिए रेट लिमिटिंग के साथ बॉट जाँच भी इस्तेमाल करें। इससे वे स्क्रिप्ट भी रुकती हैं जो अपने अनुरोध कई अलग-अलग पतों से भेजती हैं।