graphql - नुकसान

शायद कोई सही तकनीक नहीं हैं। ग्राफकल कोई अपवाद नहीं है। यदि आपके पास इस तकनीक के साथ अनुभव नहीं है, तो आपको एक अच्छा विचार रखने की आवश्यकता है कि आपके पास क्या समस्याएं हैं और उनके लिए पहले से तैयारी कर सकते हैं।

इसके साथ शुरू करने के लिए, मैं कहूंगा कि मैं जहां संभव हो, आसपास ग्राफ़िकल का उपयोग करने की तुलना में अधिक समर्थक हूं। और मैं इस तकनीक का उपयोग करने की उपयुक्तता के बारे में किसी को भी मना नहीं करने जा रहा हूं। और यही कारण है कि मैं ऐसे प्रश्न उठाता हूं जो ग्रेफिक प्रौद्योगिकी के ढांचे में अनसुलझे मुद्दों से संबंधित हैं।

उदाहरण के लिए, किसी के लिए यह अप्रत्याशित हो सकता है कि ग्राफकल में प्रत्येक वस्तु को कम से कम दो बार वर्णित किया जाना होगा: एक बार वस्तु के वापसी प्रकार के रूप में, और एक बार फिर वस्तु के इनपुट प्रकार के रूप में (देखें ग्राफक्ल.ओआर / ऑग्राफिकल-ईएस / म्यूटेशन- और इनपुट-प्रकार )। हालांकि, मैंने इसे शुरू करने के लिए कहा और इसे एक महत्वपूर्ण कमी भी नहीं माना। आज हम ऐसे मुद्दों पर ध्यान केंद्रित करेंगे, जिन्हें एक नियम के रूप में, ग्राफिकल तकनीक का उपयोग करते हुए एक अनुप्रयोग विकसित करते समय हल करना होगा:

1. उपयोगकर्ताओं और उपयोगकर्ता समूहों के लिए पहुंच का पृथक्करण।
2. हैंडलिंग में त्रुटि।
3. N + 1 समस्या का चयन करें

उपयोगकर्ताओं और उपयोगकर्ता समूहों के लिए पहुंच का पृथक्करण

graphql उपयोगकर्ताओं और समूहों के बीच पहुंच साझा करने के बारे में कुछ भी नहीं जानता है। इस प्रकार, शेयरिंग एक्सेस का सारा काम एप्लीकेशन डेवलपर की जिम्मेदारी है। तीसरा पैरामीटर रिज़ॉल्वर फ़ंक्शन के लिए एप्लिकेशन संदर्भ ऑब्जेक्ट पास करता है। इसलिए, यदि आप, उदाहरण के लिए, ग्राफकल जावास्क्रिप्ट + एक्सप्रेस के कार्यान्वयन के साथ काम करते हैं, तो संदर्भ पैरामीटर में आप अनुरोध एक्सप्रेस से वर्तमान उपयोगकर्ता प्राप्त कर सकते हैं। जेएस ऑब्जेक्ट। लेकिन एक्सेस कंट्रोल पर आगे काम सीधे प्रत्येक रिज़ॉल्वर में किया जाना चाहिए:

function(root, {id}, ctx) { return DB.Lists.get(id) .then( list => { if(list.owner_id && list.owner_id != ctx.userId){ throw new Error("Not authorized to see this list"); } else { return list; } }); } 

स्वाभाविक रूप से, यह दृष्टिकोण पहुँच नियंत्रण को जटिल बनाता है क्योंकि एक घोषणात्मक तरीके से एक्सेस अधिकारों को सेट करने का कोई तरीका नहीं है, और अधिकारों का नियंत्रण दर्जनों से अधिक (कुछ बड़ी प्रणालियों के लिए, हजारों से अधिक) रिज़ॉल्वर फ़ंक्शंस में फैलाया जाता है। इसलिए, कई पुस्तकालय हैं जो इस समस्या को हल करते हैं। उनमें से कुछ काफी लोकप्रिय हैं (github.com पर सितारों की संख्या को देखते हुए), उदाहरण के लिए github.com/maticzav/graphql-shield ।

हैंडलिंग में त्रुटि

यदि आपके दृश्यपटल को इनपुट सत्यापन की आवश्यकता है और प्रत्येक क्षेत्र के लिए विस्तृत संदेशों की पीढ़ी जो सत्यापन से पारित नहीं हुई है, तो ग्राफिकल में त्रुटि से निपटने की संभावना आपको सबसे अधिक लचीली प्रतीत होगी। उदाहरण के लिए, यदि इनपुट पैरामीटर को एक स्ट्रिंग के रूप में वर्णित किया गया था, और एक संख्यात्मक मान प्राप्त हुआ था, तो त्रुटि संदेश इसके लिए बहुत कम उपयोग होगा:

 { "errors": [ { "message": "Expected type String, found 1.", "locations": [ { "line": 2, "column": 15 } ] } ] } 

यदि इनपुट पैरामीटर के प्रकार में कोई सकल त्रुटि है, तो एक त्रुटि संदेश स्वचालित रूप से उत्पन्न होगा और इस प्रक्रिया को नियंत्रित करने का कोई तरीका नहीं है। यदि इनपुट पैरामीटर के प्रकार द्वारा सत्यापन सफल रहा, तो ग्राहक को एक new Error ('custom message ...') वस्तु new Error ('custom message ...') फेंककर कस्टम त्रुटि संदेश भेजना संभव है। यह कस्टम ऑब्जेक्ट्स को एरर ऑब्जेक्ट में जोड़ने के लिए काम नहीं करेगा (अपोलो-सर्वर-एक्सप्रेस और अपोलो-एरर्स लाइब्रेरी में त्रुटि अनुकूलन को लागू किया जाता है)। बेशक, हमेशा सर्वर पर एक message स्ट्रिंग में वस्तु को क्रमबद्ध करने और क्लाइंट पर इसे डीरियलाइज़ करने का अवसर होता है। लेकिन क्या ऐसा करना जरूरी है?

N + 1 समस्या का चयन करें

संदेश में इस समस्या पर विस्तार से चर्चा की गई थी ।

graphql को रिसॉल्वर फ़ंक्शंस पर बनाया गया है। इसका अर्थ है कि डेटाबेस से डेटा प्राप्त करना SELECT N + 1 नामक समस्या का कारण बन सकता है। मान लीजिए कि रिज़ॉल्वर फ़ंक्शन में वस्तुओं की एक सूची प्राप्त की गई थी जिसमें इस ऑब्जेक्ट से जुड़े डेटा को पहचानकर्ताओं (विदेशी कुंजी) द्वारा दर्शाया गया है। ऐसे प्रत्येक पहचानकर्ता के लिए, अपना स्वयं का फ़ंक्शन रिज़ॉल्वर कहा जाएगा, जिसमें (प्रत्येक में) डेटाबेस के लिए एक अतिरिक्त अनुरोध किया जाएगा। इस प्रकार, एकल डेटाबेस क्वेरी (SQL JOIN के साथ) के बजाय, कई प्रश्नों को निष्पादित किया जाएगा, जो डेटाबेस को क्वेरी के साथ अधिभारित करता है।

इस समस्या को हल करने के लिए, facebook ने github.com/graphql/dataloader लाइब्रेरी विकसित की, जो एक लंबित अनुरोध रणनीति का उपयोग करता है। फ़ंक्शन रिज़ॉल्वर में सीधे अनुरोध को निष्पादित करने के बजाय, यह सरणी में पहचानकर्ताओं (द्वितीयक कुंजी) को जमा करने का प्रस्ताव है, और फिर उन्हें तुरंत एक अनुरोध के साथ प्राप्त करें।

apapacy@gmail.com
13 मई, 2019