GraphQL API रेट लिमिटिंग के लिए व्यावहारिक रणनीतियाँ

REST API पर दर सीमा लागू करना अपेक्षाकृत सरल है, क्योंकि हम आमतौर पर विशिष्ट API संसाधनों का प्रतिनिधित्व करने के लिए URI पथों और संसाधनों पर संचालन का संकेत देने के लिए HTTP विधियों का उपयोग करते हैं। प्रॉक्सी परत इस जानकारी के आधार पर पूर्वनिर्धारित दर-सीमित नियमों को आसानी से लागू कर सकती है।

हालांकि, जब GraphQL API की बात आती है, तो परिदृश्य काफी जटिल हो जाता है। आइए इन चुनौतियों को कैसे दूर किया जाए, इस पर विस्तार से चर्चा करें।

सरल परिदृश्य

REST API के विपरीत, GraphQL एक स्वामित्व वाली क्वेरी भाषा का उपयोग करता है। यह अब संसाधनों को पुनः प्राप्त करने और उन पर संचालन करने के लिए पथ और HTTP विधियों पर निर्भर नहीं करता है, बल्कि डेटा क्वेरी और संचालन को Query और Mutation के तहत एकीकृत करता है, जहां Query डेटा प्राप्त करता है, और mutation डेटा पर संचालन जैसे कि बनाना, अद्यतन करना और हटाना करता है।

GET /users
GET /users/1
POST /users
PUT /users/1
DELETE /users/1

query { users { fullName } }
query { user(id: 1) { fullName } }
mutation { createUser(user: { lastName: "Jack" }) { id, fullName } }
mutation { updateUser (id: 1, update: { lastName: "Marry" }) { fullName } }
mutation { deleteUser (id: 1) }

उपरोक्त उदाहरण API क्वेरी विधियों में बदलाव को उजागर करते हैं। REST के विपरीत, GraphQL संसाधनों पर फ़ंक्शन कॉल करने जैसा है, जहां आवश्यक इनपुट पैरामीटर पास किए जाते हैं, और प्रतिक्रिया में क्वेरी किए गए डेटा शामिल होते हैं। क्वेरी विधियों में अंतर के अलावा, GraphQL आमतौर पर एकल एंडपॉइंट (जैसे, /graphql) के माध्यम से API को एक्सपोज़ करता है, और क्वेरी और इनपुट पैरामीटर POST बॉडी के माध्यम से भेजे जाते हैं।

निम्नलिखित उदाहरण पर विचार करें:

query {
    users {
        fullName
    }
    photos {
        url
        uploadAt
    }
}

इस परिदृश्य में, एक एल्बम के होमपेज का अनुकरण करते हुए, /graphql एंडपॉइंट पर एक API कॉल एक साथ उपयोगकर्ता और फोटो सूचियों को क्वेरी करता है। अब, विचार करें कि क्या पारंपरिक रिवर्स प्रॉक्सी रणनीतियाँ, जो अनुरोध स्तर पर निष्पादित होती हैं, GraphQL API पर लागू होती हैं।

उत्तर है नहीं। पारंपरिक रिवर्स प्रॉक्सी सर्वर GraphQL API कॉल को प्रभावी ढंग से संभाल नहीं सकते हैं जिनमें क्वेरी स्वयं शामिल होती हैं, जिससे दर सीमित करने जैसी नीतियों को लागू करना असंभव हो जाता है। GraphQL API के लिए, "HTTP अनुरोध" की ग्रैन्युलैरिटी बहुत मोटी प्रतीत होती है।

हालांकि, API गेटवे, Apache APISIX में GraphQL से HTTP क्षमताओं के लिए अंतर्निहित समर्थन शामिल है। प्रशासक एक क्वेरी स्टेटमेंट को पूर्व-कॉन्फ़िगर कर सकते हैं, जिससे क्लाइंट इसे सीधे HTTP POST के माध्यम से कॉल कर सकते हैं, GraphQL विवरण को समझे बिना, केवल आवश्यक इनपुट पैरामीटर प्रदान करते हुए। यह न केवल सुरक्षा को बढ़ाता है, बल्कि इस संदर्भ में HTTP API नीतियों को लागू करने की भी अनुमति देता है।

प्रभावी रूप से, यह डायनामिक GraphQL क्वेरी को API प्रदाताओं द्वारा प्रदान की गई ज्ञान-संचालित स्थिर क्वेरी में बदल देता है, जिसके फायदे और नुकसान दोनों हैं। कभी-कभी, हम GraphQL की डायनामिक क्वेरी सुविधा को त्यागना नहीं चाहते हैं। आइए अन्य परिदृश्यों की चर्चा जारी रखें।

जटिल परिदृश्य

GraphQL डेटा मॉडलिंग और API विवरण के लिए अपनी विशेष भाषा का उपयोग करता है, जो नेस्टेड डेटा संरचनाओं की अनुमति देता है। पिछले उदाहरण को विस्तारित करते हुए:

query {
    photos(first: 10) {
        url
        uploadAt
        publisher {
            fullName
            avatar
        }
        comments(first: 10) {
            content
            sender {
                fullName
                avatar
            }
        }
    }
    // users...
}

इस मामले में, पहले 10 फोटो को पुनः प्राप्त करने का अनुकरण करते हुए, प्रत्येक फोटो के प्रकाशक और पहले 10 टिप्पणियों को उनके प्रेषकों के साथ शामिल करते हुए, बैकएंड सेवा को कई डेटाबेस टेबल या माइक्रोसर्विसेस के कॉल शामिल करने वाले क्वेरी को संभालना होगा। ऐसे नेस्टेड क्वेरी परिदृश्यों में, जैसे-जैसे डेटा की मात्रा और नेस्टिंग स्तर बढ़ते हैं, बैकएंड सेवाओं और डेटाबेस पर कम्प्यूटेशनल तनाव तेजी से बढ़ता है।

जटिल क्वेरी से सेवा को अभिभूत होने से रोकने के लिए, हम प्रॉक्सी परत पर ऐसी क्वेरी का निरीक्षण और ब्लॉक करना चाह सकते हैं। इस रणनीति को लागू करने के लिए, प्रॉक्सी घटक को क्वेरी स्टेटमेंट को संरचित डेटा में पार्स करना होगा, उन्हें ट्रैवर्स करके प्रत्येक परत में नेस्टेड फ़ील्ड प्राप्त करना होगा, और GraphQL के सामान्य अभ्यास के अनुसार फ़ील्ड को क्वेरी लागत के रूप में जटिलता मान निर्दिष्ट करना होगा। फिर समग्र क्वेरी जटिलता पर वैश्विक सीमाएं लागू की जा सकती हैं। उपरोक्त क्वेरी के लिए, यह मानते हुए कि प्रत्येक व्यक्तिगत फ़ील्ड की लागत 1 है:

10 * photo (url + uploadAt + publisher.fullName + publisher.avatar + 10 * comment (content + sender.fullName + sender.avatar))

10 * (1 + 1 + 1 + 1 + 10 * (1 + 1 + 1)) = 340

कुल क्वेरी लागत 340 है, जो स्वीकार्य प्रतीत होती है, और हम ऐसे नियमों के आधार पर API क्वेरी लागत सीमाएं कॉन्फ़िगर कर सकते हैं। हालांकि, यदि एक दुर्भावनापूर्ण क्लाइंट एक ही क्वेरी में 100 फोटो के डेटा को प्राप्त करने का प्रयास करता है, तो क्वेरी लागत 3400 तक बढ़ जाएगी, जो पूर्वनिर्धारित सीमा से अधिक होगी, और अनुरोध अस्वीकार कर दिया जाएगा।

प्रति क्लाइंट क्वेरी की अधिकतम लागत को प्रतिबंधित करने के अलावा, समय अंतराल पर अतिरिक्त सीमाएं, जैसे कि क्लाइंट को प्रति मिनट कुल 2000 क्वेरी की अनुमति देना और अतिरिक्त क्वेरी को अस्वीकार करना, दुर्भावनापूर्ण क्रॉलर को रोक सकता है।

ऐसी क्षमताओं को लागू करने के लिए, प्रॉक्सी घटक को क्वेरी लागत को पार्स और गणना करनी होगी। API7 Enterprise इन सुविधाओं का समर्थन करता है, जो GraphQL क्वेरी को डायनामिक रूप से पार्स करने और कॉन्फ़िगरेशन के आधार पर उपयोगकर्ता दर सीमाएं लागू करने में सक्षम बनाता है।

GraphQL API को प्रॉक्सी परत पर चुनौतियों का सामना करना पड़ता है, जहां पारंपरिक रिवर्स प्रॉक्सी GraphQL क्वेरी स्टेटमेंट के भीतर जटिलता और नेस्टिंग संबंधों को प्रभावी ढंग से समझने और संभालने में संघर्ष करते हैं। इसके विपरीत, API गेटवे प्रौद्योगिकियां इन चुनौतियों को दूर करने में अमूल्य साबित होती हैं, जहां API7 Enterprise एक बेहतरीन विकल्प हो सकता है।