Requests की गिनती कैसे होती है
प्रत्येक निष्पादित root operation फ़ील्ड एक API call है। चार root फ़ील्ड्स माँगने वाली GraphQL request का शुल्क चार API calls के रूप में लिया जाता है, ठीक वैसे ही जैसे आपने चार REST requests की हों। Root पर aliases अलग-अलग गिने जाते हैं क्योंकि प्रत्येक एक ऑपरेशन dispatch करता है। किसी typed response से चुने गए nested फ़ील्ड्स API calls नहीं बढ़ाते।- आपकी मौजूदा plan सीमाएँ बिना बदलाव के लागू होती हैं। अपने plan की सीमा के लिए API सीमाएँ देखें।
- ऐसा root operation माँगना जिसकी आपको आवश्यकता नहीं है, उतना ही खर्च करता है जितना उसे REST पर कॉल करना। अपनी ज़रूरत के nested response फ़ील्ड्स चुनने से calls नहीं बढ़तीं।
- कोई request बीच में ही rate limit हो सकती है। जो root फ़ील्ड्स पूरे हो चुके हैं उनका डेटा बना रहता है, और केवल throttled root फ़ील्ड्स errors लौटाते हैं — आंशिक सफलता देखें।
Query सीमाएँ
Endpoint किसी query के आकार और साइज़ पर कुछ सीमाएँ लागू करता है। ये इसलिए हैं ताकि एक अकेली request हमारी क्षमता का अनुचित हिस्सा न ले सके, और इन्हें सामान्य उपयोग की आवश्यकता से काफ़ी ऊपर रखा गया है — यदि आप किसी सीमा तक पहुँच रहे हैं, तो यह आमतौर पर वास्तविक आवश्यकता के बजाय गलती से generate हुई query का संकेत होता है।
अस्वीकृत query HTTP 400 लौटाती है यदि आप
Accept: application/graphql-response+json भेजते हैं, और अन्यथा HTTP 200, दोनों स्थितियों में errors array के साथ और बिना data के। त्रुटियाँ देखें।
प्रति request API calls
यह महत्वपूर्ण है। एक अकेली request अधिकतम 5 API calls ट्रिगर कर सकती है, इसलिए ऊपर का चार-root-फ़ील्ड वाला उदाहरण ठीक है लेकिन बीस-root-फ़ील्ड वाला नहीं। पाँच dispatches शुरू हो जाने के बाद, अतिरिक्त root फ़ील्ड्स सीमा को समझाते हुए 429 लौटाते हैं; पहले से dispatch हो चुके फ़ील्ड्स फिर भी अपना डेटा लौटा सकते हैं। यदि आपको अधिक की आवश्यकता है, तो query को कई requests में बाँट दें। यदि आप किसी वैध workload के लिए नियमित रूप से ऐसा कर रहे हैं, तो हमसे संपर्क करें — launch के लिए यह सीमा जानबूझकर सावधानीपूर्वक रखी गई है और इसे बढ़ाना आसान है, जबकि बाद में इसे घटाने से integrations टूट जाएँगे, इसलिए यह छोटी शुरू होती है।Depth, फ़ील्ड्स, aliases और directives
इन्हें कुछ भी चलने से पहले जाँचा जाता है, इसलिए किसी एक को पार करने पर आपकी कोई API call खर्च नहीं होती। ये पूरी introspection query से भी आराम से ऊपर हैं, जो लगभग 180 फ़ील्ड्स और 12 स्तर गहरी होती है और जिसमें कोई aliases या directives नहीं होते, इसलिए startup पर पूरा schema fetch करने वाला client सामान्य रूप से काम करता है।Request body का आकार
64 KB, जो किसी query के लिए पर्याप्त है और किसी फ़ाइल के लिए बहुत छोटा। यही कारण है कि मीडिया को GraphQL के माध्यम से अपलोड नहीं किया जा सकता — समर्थित तरीके के लिए मीडिया अपलोड करना देखें।Timeouts
एक request को कुल मिलाकर अधिकतम 120 सेकंड दिए जाते हैं। किसी query के root फ़ील्ड्स समवर्ती रूप से चल सकते हैं, इसलिए इसकी अवधि आमतौर पर इसकी सबसे धीमी dependency से निर्धारित होती है। किसी mutation के root फ़ील्ड्स क्रमिक रूप से चलते हैं, इसलिए कई धीमे mutations मिलकर timeout तक पहुँच सकते हैं। दोनों ही रूप backend पर अधिकतम पाँच समवर्ती या क्रमिक dispatches जितना लोड डाल सकते हैं; उचित होने पर ज्ञात-धीमे काम को बाँट दें।किन चीज़ों पर सीमा नहीं है
- Schema पढ़ना। Introspection बिना authentication के और बिना मीटरिंग के है। क्या-क्या मौजूद है, यह ब्राउज़ करना मुफ़्त है; कोई ऑपरेशन चलाना नहीं।
- Malformed queries। GraphQL द्वारा अस्वीकृत query — अज्ञात फ़ील्ड, गलत type, अमान्य enum value — कभी हमारे API तक नहीं पहुँचती और उसका कभी शुल्क नहीं लिया जाता।