प्रॉम्प्ट और संदर्भ
आप एक स्थापित REST API वाले B2B SaaS के ओनर हैं। बड़े ग्राहक क्रॉस-रिसोर्स क्वेरीज़ को कंपोज़ करने के लिए GraphQL चाहते हैं, जबकि इंजीनियरिंग टीम क्वेरी लागत, प्राधिकरण सीमाओं (authorization boundaries), कैशिंग और दीर्घकालिक शासन को लेकर चिंतित है। तय करें कि GraphQL लॉन्च करना चाहिए या नहीं और इसके स्कोप, मेट्रिक्स, जोखिमों और माइग्रेशन योजना की व्याख्या करें।
यह एक API प्रोडक्ट निर्णय है, न कि GraphQL सर्वर को लागू (implement) करने का निमंत्रण। GraphQL विनिर्देश (specification) डेटा-मॉडल क्षमताओं और आवश्यकताओं के लिए एक क्वेरी भाषा और निष्पादन इंजन (execution engine) का वर्णन करता है; GitHub का पब्लिक API क्वेरीज़ और म्यूटेशन दोनों का समर्थन करता है। आपका काम उन क्षमताओं को एक परीक्षण योग्य प्रोडक्ट विकल्प में बदलना है।
इंटरव्यूअर क्या जांच रहा है
- केवल फैशन में होने के कारण GraphQL चुनने के बजाय ग्राहकों के वर्कफ़्लो और मापने योग्य समस्याओं से शुरुआत करना।
- डिस्कवरी, राउंड ट्रिप्स, प्राधिकरण (authorization), कैशिंग और ऑब्जर्वेबिलिटी पर REST, GraphQL और एक एग्रीगेशन लेयर की तुलना करना।
- स्कीमा, क्वेरी जटिलता, पेजिनेशन और म्यूटेशन सीमाओं को प्रोडक्ट बाधाओं (constraints) में बदलना।
- एक चरणबद्ध पायलट, अनुकूलता योजना (compatibility plan), मूल्य निर्धारण दृष्टिकोण और डेवलपर-अनुभव मेट्रिक्स को डिज़ाइन करना।
पहले स्पष्ट करने योग्य प्रश्न
- क्या समस्या कम राउंड ट्रिप्स, कम ओवर-फेचिंग, या क्रॉस-रिसोर्स कंपोजिशन है? क्या मौजूदा REST एग्रीगेशन इसे हल कर सकता है?
- कितने उपभोक्ता, लैंग्वेज स्टैक, अनुपालन क्षेत्र (compliance regions), और लक्षित SLO स्कोप में हैं? क्या पार्टनर स्थिर अनुबंधों (stable contracts) पर निर्भर हैं?
- क्या केवल पढ़ने योग्य (read-only) क्वेरीज़ पर्याप्त हैं, या राइट्स (writes) भी आवश्यक हैं? क्या राइट्स के लिए ट्रांज़ैक्शन, इडेम्पोटेंसी (idempotency) और अनुमोदन (approval) की आवश्यकता होगी?
- कौन से संसाधन और फ़ील्ड टेनेंट सीमा को परिभाषित करते हैं? गहराई (depth), रिस्पॉन्स आकार और प्रति-टेनेंट बजट को कैसे सीमित किया जाएगा?
30-सेकंड का उत्तर
मैं ग्राहकों के साथ बार-बार होने वाली कंपोजिशन समस्या को मान्य करूँगा और एक छोटे केवल-पढ़ने योग्य (read-only) संसाधन सेट के साथ पायलट करूँगा। यदि REST एग्रीगेशन पहले से ही उच्च-मूल्य वाले वर्कफ़्लो को कम लागत में हल करता है, तो मैं केवल प्रोटोकॉल के लिए GraphQL लॉन्च नहीं करूँगा। यदि कई ग्राहकों को अलग-अलग फ़ील्ड संयोजनों की आवश्यकता है और कस्टम एंडपॉइंट्स को बनाए रखना महंगा है, तो मैं एक सीमित GraphQL प्रोडक्ट लॉन्च करूँगा। पहली रिलीज़ एक स्थिर क्वेरी स्कीमा, पेजिनेशन और जटिलता बजट को प्रदर्शित करेगी, मौजूदा पहचान और टेनेंट प्राधिकरण का पुन: उपयोग करेगी, और मनमाने म्यूटेशन को टाल देगी। मैं एक्टिवेशन, सफलता दर, P95 लेटेंसी, क्वेरी लागत, सपोर्ट लोड और REST माइग्रेशन के आधार पर इसे स्केल या बंद करूँगा।
चरण-दर-चरण गहन विश्लेषण
पहले ग्राहक मूल्य और विकल्पों को परिभाषित करें
अनुरोध को कम नेटवर्क राउंड ट्रिप्स, कम ओवर-फेचिंग और क्रॉस-रिसोर्स कंपोजिशन में विभाजित करें। प्रत्येक के लिए, वर्तमान REST कॉल ग्राफ़, एंड-टू-एंड लेटेंसी, बीस्पोक (कस्टम) एंडपॉइंट्स की संख्या और ग्राहक-निर्मित प्रॉक्सी लागत को रिकॉर्ड करें। यदि एक REST एग्रीगेशन एंडपॉइंट अधिकांश मूल्यवान वर्कफ़्लो को हल करता है, तो केवल अनुरोधों की गिनती करने के बजाय तुलना में GraphQL गवर्नेंस लागत को शामिल करें।
डेटाबेस को उजागर करने के बजाय एक प्रोडक्ट सीमा निर्धारित करें
पहला स्कीमा स्थिर सिमेंटिक्स, स्पष्ट टेनेंट स्वामित्व और देखने योग्य (observable) व्यवहार वाले संसाधनों को कवर करना चाहिए। संवेदनशीलता, प्राधिकरण नियमों, संस्करण वादों और ताजगी (freshness) के साथ प्रत्येक फ़ील्ड को टैग करें। क्वेरीज़ और म्यूटेशन की अलग-अलग समीक्षा करें: पहले रीड वैल्यू को मान्य करें, फिर इडेम्पोटेंसी, ऑडिट और त्रुटि सिमेंटिक्स परिपक्व होने के बाद राइट्स पर विचार करें।
क्वेरी लागत को एक लागू करने योग्य बजट बनाएं
GraphQL का लचीला चयन सेट (selection set) लागत को एंडपॉइंट गणना से क्वेरी आकार में स्थानांतरित करता है। अधिकतम गहराई (depth), नोड संख्या, पेज आकार और टाइमआउट को सीमित करें, और स्कीमा फ़ील्ड या रिज़ॉल्वर द्वारा लागत का अनुमान लगाएं। टेनेंट, ऑपरेशन का नाम, अनुमानित लागत और वास्तविक संसाधन उपयोग को रिकॉर्ड करते हुए कार्रवाई योग्य त्रुटियों के साथ बजट से अधिक के अनुरोधों को अस्वीकार करें।
पहचान, प्राधिकरण और टेनेंट सीमाओं को सुरक्षित रखें
GraphQL अनुरोध का आकार बदलता है; इसे मौजूदा OAuth, सर्विस अकाउंट्स, टेनेंट आइसोलेशन या फ़ील्ड-स्तरीय अनुमतियों को बायपास नहीं करना चाहिए। केवल रूट क्वेरी के बजाय रिज़ॉल्वर या साझा डेटा-एक्सेस लेयर में प्राधिकरण लागू करें। बैच रीड्स को क्रॉस-टेनेंट जॉइन्स, अनधिकृत कैश पुन: उपयोग और त्रुटियों के माध्यम से जानकारी लीक होने से रोकना चाहिए।
डेवलपर अनुभव और अनुकूलता की योजना बनाएं
स्कीमा दस्तावेज़ीकरण, उदाहरण क्वेरीज़, त्रुटि मार्गदर्शन, पेजिनेशन परंपराएं, ऑपरेशन-नाम आवश्यकताएं और एक चेंजलॉग प्रदान करें। ब्रेकिंग स्कीमा परिवर्तनों के लिए एक मूल्यह्रास विंडो (deprecation window), कॉलर स्कैनिंग और नामित संपर्कों की आवश्यकता होती है। REST और GraphQL डोमेन मॉडल साझा कर सकते हैं, लेकिन हमेशा के लिए वन-टू-वन फ़ील्ड समानता का वादा न करें।
एक पायलट, मेट्रिक्स और निकास मानदंड परिभाषित करें
2 से 3 प्रतिनिधि ग्राहकों और निश्चित संसाधनों और बजट के साथ केवल-पढ़ने योग्य वर्कफ़्लो चुनें। सक्रिय ऐप्स, वैध-क्वेरी दर, P95/P99 लेटेंसी, प्रति क्वेरी लागत, अवरुद्ध प्राधिकरण प्रयास, सपोर्ट टिकट और ग्राहक कार्यों को पूरा करने के समय को ट्रैक करें। कम अपनाने, उच्च लागत, या बढ़ती गवर्नेंस घटनाओं के कारण फ़ील्ड जोड़कर छिपाने के बजाय स्कीमा को छोटा करना चाहिए या विस्तार को रोकना चाहिए।
{
"pilot": {"tenants": 3, "mode": "read-only", "maxDepth": 6, "costBudget": 100},
"exit": {"p95LatencyMs": 400, "errorRate": 0.01, "supportTicketsPerTenant": 2}
}एक मजबूत उत्तर का उदाहरण
मैं GraphQL को REST के अपरिहार्य प्रतिस्थापन के रूप में नहीं देखूँगा। मैं यह पुष्टि करने के लिए ग्राहक साक्ष्य का उपयोग करूँगा कि कंपोजिशन, ओवर-फेचिंग, या बीस्पोक एंडपॉइंट रखरखाव काफी बड़ा है या नहीं, और इसकी तुलना REST एग्रीगेशन लेयर की डिलीवरी लागत से करूँगा। यदि पायलट अपनी जगह बनाता है, तो मैं GraphQL को एक शासित API के रूप में प्रोडक्टाइज़ करूँगा: एक स्थिर केवल-पढ़ने योग्य स्कीमा, मौजूदा OAuth और टेनेंट प्राधिकरण, आवश्यक ऑपरेशन नाम, गहराई, नोड, पेजिनेशन और लागत सीमाएं, साथ ही स्कीमा दस्तावेज़ और एक डेप्रिकेशन विंडो। Google Apigee एक API प्रोडक्ट को संसाधनों, विधियों, एक्सेस स्तरों और कोटा के बंडल के रूप में मॉडल करता है, जो GraphQL एक्सेस कंट्रोल, सीमाओं और योजनाओं को एक साथ डिज़ाइन करने के लिए एक उपयोगी अनुस्मारक है। मैं विस्तार करने का निर्णय लेने के लिए सक्रिय ग्राहकों, सफलता दर, P95, यूनिट क्वेरी लागत और सपोर्ट भार का उपयोग करूँगा; केवल तभी मैं संसाधनों और संकीर्ण रूप से स्कोप किए गए म्यूटेशन को जोड़ूँगा।
सामान्य गलतियाँ
- ग्राहक मूल्य को साबित किए बिना या REST एग्रीगेशन से तुलना किए बिना यह कहना कि "फ़्रंटएंड अधिक लचीला है"।
- GraphQL स्कीमा को सीधे डेटाबेस तालिकाओं में मैप करना और डोमेन सिमेंटिक्स, प्राधिकरण और संवेदनशील फ़ील्ड की अनदेखी करना।
- लागत मॉडल और अस्वीकृति रणनीति के बिना असीमित गहराई, पेजिनेशन या नेस्टिंग की अनुमति देना।
- इडेम्पोटेंसी, ऑडिट, अनुमोदन या रोलबैक सीमाओं के बिना क्वेरीज़ और म्यूटेशन को एक साथ लॉन्च करना।
- लेटेंसी, लागत, अवरुद्ध प्राधिकरण और सपोर्ट भार की अनदेखी करते हुए केवल अपनाने (adoption) को ट्रैक करना।
- दोहरे ट्रैक वाले दस्तावेज़ों, डेप्रिकेशन और रोलबैक की अनदेखी करते हुए प्रत्येक REST ग्राहक के लिए एकमुश्त माइग्रेशन का वादा करना।
फॉलो-अप और प्रतिक्रियाएं
यदि ग्राहक केवल कम अनुरोध चाहते हैं, तो REST एग्रीगेशन क्यों न बनाएं?
कॉल ग्राफ़ और रखरखाव लागत के साथ दोनों विकल्पों को मापें। स्पष्ट सीमाओं वाले निश्चित, लगातार वर्कफ़्लो एक एग्रीगेशन एंडपॉइंट के पक्ष में होते हैं; कई ग्राहकों में लगातार बदलते संयोजन सीमित GraphQL को अधिक मूल्यवान बनाते हैं। प्रोटोकॉल सतह चुनने से पहले उन्हीं वर्कफ़्लो का पायलट करें।
आप GraphQL क्वेरीज़ को बैकएंड को डाउन करने से कैसे रोकते हैं?
एज (edge) पर गहराई, नोड, पेजिनेशन और टाइमआउट सीमाओं को लागू करें; स्कीमा में फ़ील्ड लागत भार बनाए रखें; रिज़ॉल्वर में बैच और कैश करें; और टेनेंट और प्राथमिकता के आधार पर दर-सीमा (rate-limit) तय करें। एक अस्पष्ट सर्वर त्रुटि वापस करने के बजाय अस्वीकृत क्वेरीज़ के लिए ऑपरेशन का नाम, अनुमानित लागत और संसाधन उपयोग लॉग करें।
आप म्यूटेशन कब पेश करेंगे?
केवल तभी जब केवल-पढ़ने योग्य प्राधिकरण, त्रुटियां, ऑडिटिंग और ऑब्जर्वेबिलिटी स्थिर हों। कम जोखिम वाले, इडेम्पोटेंट, क्षतिपूर्ति योग्य राइट्स से शुरुआत करें। प्रत्येक म्यूटेशन को इनपुट सत्यापन, संघर्ष सिमेंटिक्स, अनुमतियों, ऑडिट घटनाओं और पुनः प्रयास (retry) व्यवहार की आवश्यकता होती है; वित्तीय, विलोपन और क्रॉस-टेनेंट क्रियाएं समर्पित वर्कफ़्लो बनी रहनी चाहिए।
REST और GraphQL एक साथ कैसे सह-अस्तित्व में रहेंगे?
REST को स्थिर अनुकूलता सतह के रूप में रखें और फ़ील्ड-दर-फ़ील्ड समानता की आवश्यकता के बिना नए वर्कफ़्लो के लिए GraphQL का उपयोग करें। कॉलर माइग्रेशन और प्रत्येक सतह की लागत को अलग-अलग मापते हुए पहचान, डोमेन प्राधिकरण, ऑडिट और SLO साझा करें। REST डेप्रिकेशन पर केवल तभी चर्चा करें जब ग्राहक मूल्य, परिचालन लागत और अनुकूलता जोखिम साक्ष्य द्वारा समर्थित हों।