GraphQL विवरण: क्या, कैसे, और क्यों

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

GraphQL क्या है?

GraphQL डेटा के साथ काम करने के लिए क्लाइंट एप्लिकेशन द्वारा उपयोग की जाने वाली क्वेरी भाषा है। ग्राफकॉल इस तरह की अवधारणा के साथ एक "योजना" के रूप में जुड़ा हुआ है - यह वह है जो आपको अपने एप्लिकेशन में डेटा के निर्माण, पढ़ने, अपडेट और विलोपन को व्यवस्थित करने की अनुमति देता है (अर्थात, हमारे पास डेटा वेयरहाउस के साथ काम करते समय उपयोग किए जाने वाले चार बुनियादी कार्य हैं, जिन्हें आमतौर पर संक्षिप्त सीआरयूडी द्वारा संदर्भित किया जाता है। - बनाएं, पढ़ें, अपडेट करें, हटाएं)।

यह ऊपर कहा गया था कि ग्राफकैल का उपयोग "आपके एप्लिकेशन" में डेटा के साथ काम करने के लिए किया जाता है, न कि "आपके डेटाबेस में"। तथ्य यह है कि ग्राफकॉल डेटा स्रोतों से स्वतंत्र एक प्रणाली है, अर्थात्, यह कोई फर्क नहीं पड़ता कि यह अपने काम को व्यवस्थित करने के लिए कहां आयोजित किया जाता है।

यदि आप देखें, तो इस तकनीक के नाम पर ग्राफकॉल के बारे में कुछ भी जाने बिना, ऐसा लग सकता है कि हमारा सामना किसी बहुत जटिल और उलझी हुई चीज से है। प्रौद्योगिकी के नाम में "ग्राफ" शब्द है। क्या इसका मतलब यह है कि इसे मास्टर करने के लिए, आपको ग्राफ़ डेटाबेस के साथ काम करना सीखना होगा? और तथ्य यह है कि नाम में "QL" (जिसका अर्थ "क्वेरी भाषा" हो सकता है, अर्थात "क्वेरी भाषा"), क्या इसका मतलब यह है कि जो लोग ग्राफ़िकल का उपयोग करना चाहते हैं, उन्हें पूरी तरह से नई प्रोग्रामिंग भाषा सीखनी होगी?

ये आशंकाएं पूरी तरह से उचित नहीं हैं। आपको आश्वस्त करने के लिए - यह इस तकनीक के बारे में क्रूर सत्य है: यह केवल GET या POST अनुरोधों को अलंकृत करता है। जबकि ग्राफक, सामान्य तौर पर, डेटा संगठन से संबंधित कुछ नई अवधारणाओं और इसके साथ सहभागिता का परिचय देता है, इस तकनीक के आंतरिक तंत्र अच्छे पुराने HTTP अनुरोधों पर भरोसा करते हैं।

रिथिंकिंग रेस्ट टेक्नोलॉजी

लचीलापन वही है जो जाने-माने REST तकनीक के अलावा ग्राफकॉल तकनीक को सेट करता है। REST का उपयोग करते समय, यदि सब कुछ सही ढंग से किया जाता है, तो एंडपॉइंट आमतौर पर एक निश्चित संसाधन या एप्लिकेशन डेटा प्रकार की विशेषताओं को ध्यान में रखते हुए बनाए जाते हैं।

उदाहरण के लिए, जब समापन बिंदु /api/v1/flavors लिए एक GET अनुरोध करते /api/v1/flavors तो यह उम्मीद की जाती है कि यह एक प्रतिक्रिया भेजेगा जो कुछ इस तरह दिखता है:

 [ {  "id": 1,   "name": "The Lazy Person's Movie Theater",   "description": "That elusive flavor that you begrudgingly carted yourself to the theater for, now in the comfort of your own home, you slob!" }, {   "id": 2,   "name": "What's Wrong With You Caramel",   "description": "You're a crazy person that likes sweet popcorn. Congratulations." }, {   "id": 3,   "name": "Gnarly Chili Lime",   "description": "The kind of popcorn you make when you need a good smack in the face."} ] 

इस उत्तर के साथ कुछ भी गलत नहीं है, लेकिन आइए हम उपयोगकर्ता इंटरफ़ेस के बारे में सोचते हैं, या यूँ कहें कि हम इस डेटा का उपभोग कैसे करते हैं।

यदि हम इंटरफ़ेस में एक सरल सूची प्रदर्शित करना चाहते हैं जिसमें केवल उपलब्ध प्रकार के पॉपकॉर्न (और कुछ नहीं) के नाम शामिल हैं, तो यह सूची नीचे दिखाए गए की तरह दिख सकती है।


पॉपकॉर्न के प्रकारों की सूची

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

वास्तव में, यह तथ्य कि सर्वर क्लाइंट अनुरोध के जवाब में अनावश्यक डेटा भेजता है, पूरी तरह से हमारी गलती नहीं है। REST एक डेटा अधिग्रहण तंत्र है जिसकी तुलना एक रेस्तरां से की जा सकती है जिसमें वेटर आगंतुक से पूछता है: "आप क्या चाहते हैं?", और, और विशेष रूप से उसकी इच्छाओं पर ध्यान नहीं देते हुए, वह उससे कहता है: "मैं तुम्हें वही लाऊंगा जो हमारे पास है" ।

यदि हम एक तरफ चुटकुले फेंकते हैं, तो वास्तविक अनुप्रयोगों में यह समस्या की स्थिति पैदा कर सकता है। उदाहरण के लिए, हम प्रत्येक प्रकार के पॉपकॉर्न के बारे में विभिन्न अतिरिक्त जानकारी प्रदर्शित कर सकते हैं, जैसे कि कीमत की जानकारी, निर्माता या पोषण संबंधी जानकारी ("शाकाहारी पॉपकॉर्न!") के बारे में। इसी समय, अनम्य आरईएस एंडपॉइंट्स को विशिष्ट प्रकार के पॉपकॉर्न के बारे में विशिष्ट डेटा प्राप्त करना बहुत मुश्किल हो जाता है, जो सिस्टम पर अनुचित रूप से उच्च भार की ओर जाता है और इस तथ्य के परिणामस्वरूप कि समाधान उन लोगों से बहुत दूर हैं जिन पर डेवलपर्स को गर्व हो सकता है।

कैसे रेखाकृति प्रौद्योगिकी में सुधार करता है कि किस प्रकार की प्रौद्योगिकी का उपयोग किया गया था

ऊपर वर्णित स्थिति का एक सतही विश्लेषण लग सकता है कि हम केवल एक छोटी सी समस्या हैं। "ग्राहक को अनावश्यक डेटा भेजने में क्या गलत है?" यह समझने के लिए कि "अनावश्यक डेटा" किस हद तक एक बड़ी समस्या हो सकती है, याद रखें कि ग्राफकॉल को फेसबुक द्वारा विकसित किया गया था। इस कंपनी को प्रति सेकंड लाखों अनुरोध करने होंगे।

इसका क्या मतलब है? और तथ्य यह है कि ऐसे संस्करणों के साथ हर छोटी चीज मायने रखती है।

अगर हम "आगंतुक" को "ले जाने" के बजाय, ग्राफ़िक्स के साथ सादृश्य जारी रखते हैं, तो ग्राफक्यूएल, विज़िटर के आदेशों को ठीक से बताता है।

हम ग्राफ़िकल से एक प्रतिक्रिया प्राप्त कर सकते हैं जो उस संदर्भ पर केंद्रित है जिसमें डेटा का उपयोग किया जाता है। इस मामले में, हमें सिस्टम में "वन-टाइम" एक्सेस पॉइंट्स जोड़ने की ज़रूरत नहीं है, कई अनुरोध करने या बहु-मंजिला सशर्त संरचनाओं को लिखने की आवश्यकता है।

GraphQL कैसे काम करता है?

जैसा कि हमने पहले ही कहा है, ग्राफकलाइन ग्राहक को डेटा प्रसारित करने और उससे प्राप्त करने के लिए सरल GET या POST अनुरोधों पर निर्भर करता है। यदि हम इस विचार पर अधिक विस्तार से विचार करते हैं, तो यह पता चलता है कि ग्राफकॉल में दो प्रकार के प्रश्न हैं। पहले प्रकार में डेटा पढ़ने के लिए अनुरोध शामिल हैं, जिसमें ग्राफकॉल शब्दावली में केवल प्रश्नों को कहा जाता है और संक्षिप्त सीआरयूडी के पत्र आर (पढ़ना, पढ़ना) को संदर्भित करता है। दूसरी तरह की क्वेरीज़ डेटा संशोधन अनुरोध हैं, जिन्हें ग्राफक्यूएल में म्यूटेशन कहा जाता है। वे एक्सल बॉक्स C, U, और D के परिचितक CRUD से संबंधित हैं, अर्थात वे रिकॉर्ड बनाने, बनाने, अपडेट करने और हटाने के लिए उनका उपयोग करते हैं।

इन सभी अनुरोधों और म्यूटेशनों को ग्राफकलाइन सर्वर के URL पर भेजा जाता है, जो उदाहरण के लिए, GET या POST अनुरोधों के रूप में https://myapp.com/graphql तरह लग सकता है। हम इसके बारे में नीचे बात करेंगे।

रेखांकन क्वेरी

कुछ डेटा प्राप्त करने के लिए सर्वर से एक अनुरोध का प्रतिनिधित्व करने वाली इकाइयां हैं। उदाहरण के लिए, हमारे पास एक निश्चित उपयोगकर्ता इंटरफ़ेस है जिसे हम डेटा से भरना चाहते हैं। इस डेटा के लिए, हम अनुरोध को निष्पादित करते हुए सर्वर की ओर मुड़ते हैं। पारंपरिक REST API का उपयोग करते समय, हमारा अनुरोध GET अनुरोध का रूप ले लेता है। ग्राफक्लाइन के साथ काम करते समय, एक नया क्वेरी सिंटैक्स उपयोग किया जाता है:

 { flavors {   name } } 

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

 { //    ,   . } 

सभी अनुरोध एक "रूट अनुरोध" से शुरू होते हैं, और अनुरोध के निष्पादन के दौरान आपको जो कुछ भी प्राप्त करने की आवश्यकता होती है, उसे फ़ील्ड कहा जाता है। अपने आप को भ्रम से बचाने के लिए, इन संस्थाओं को "स्कीमा में क्वेरी फ़ील्ड" कहना सबसे अच्छा है। यदि ऐसा नाम आपको समझ में नहीं आता है, तो थोड़ा इंतजार करें - नीचे हम योजना के बारे में अधिक बात करेंगे। यहां हम, रूट क्वेरी में, flavors फ़ील्ड का अनुरोध करते flavors ।

 { flavors {   //  ,        flavor. } } 

एक निश्चित क्षेत्र का अनुरोध करते समय, हमें नेस्टेड फ़ील्ड्स को भी इंगित करना चाहिए जो अनुरोध के जवाब में आने वाले प्रत्येक ऑब्जेक्ट के लिए प्राप्त करने की आवश्यकता है (भले ही यह उम्मीद की जाए कि अनुरोध के जवाब में केवल एक ही वस्तु आएगी)।

 { flavors {   name } } 

इसका परिणाम क्या होगा? ग्राफक्लाइन सर्वर से इस तरह का अनुरोध भेजने के बाद, हमें निम्नलिखित की तरह एक अच्छी तरह से गठित स्वच्छ उत्तर मिलेगा:

 { "data": {   "flavors": [     { "name": "The Lazy Person's Movie Theater" },     { "name": "What's Wrong With You Caramel" },     { "name": "Gnarly Chili Lime" }   ] } } 

कृपया ध्यान दें कि कुछ भी नहीं है। इसे स्पष्ट करने के लिए, यहां एक और अनुरोध है जिसे एप्लिकेशन के किसी अन्य पृष्ठ पर डेटा प्राप्त करने के लिए निष्पादित किया जाता है:

 { flavors {   id   name   description } } 

इस अनुरोध के जवाब में, हमें निम्नलिखित मिलते हैं:

 { "data": {   "flavors": [     { "id": 1, "name": "The Lazy Person's Movie Theater", description: "That elusive flavor that you begrudgingly carted yourself to the theater for, now in the comfort of your own home, you slob!" },     { "id": 2, "name": "What's Wrong With You Caramel", description: "You're a crazy person that likes sweet popcorn. Congratulations." },     { "id": 3, "name": "Gnarly Chili Lime", description: "A friend told me this would taste good. It didn't. It burned my kernels. I haven't had the heart to tell him." }   ] } } 

जैसा कि आप देख सकते हैं, GraphQL एक बहुत शक्तिशाली तकनीक है। हम उसी समापन बिंदु की ओर मुड़ते हैं, और अनुरोधों के उत्तर ठीक उसी तरह से मेल खाते हैं जिसके लिए उस पृष्ठ को भरने की आवश्यकता होती है जिससे ये अनुरोध निष्पादित होते हैं।

यदि हमें केवल एक flavor ऑब्जेक्ट प्राप्त करने की आवश्यकता है, तो हम इस तथ्य का लाभ उठा सकते हैं कि ग्राफकॉलेज तर्क के साथ काम कर सकता है:

 { flavors(id: "1") {   id   name   description } } 

यहां हम कोड में ऑब्जेक्ट की विशिष्ट पहचानकर्ता ( id ) को सख्ती से सेट करते हैं, जिसके बारे में हमें जानकारी चाहिए, लेकिन ऐसे मामलों में हम गतिशील पहचानकर्ताओं का उपयोग कर सकते हैं:

 query getFlavor($id: ID) { flavors(id: $id) {   id   name   description } } 

यहां, पहली पंक्ति में, हम अनुरोध को एक नाम देते हैं (नाम को मनमाने ढंग से चुना जाता है, getFlavor को pizza जैसी किसी चीज़ से बदला जा सकता है, और अनुरोध चालू रहेगा) और चर की घोषणा करते हैं जो अनुरोध की अपेक्षा करता है। इस मामले में, यह माना जाता है कि अदिश प्रकार ID की पहचानकर्ता ( id ) अनुरोध को पारित कर दी जाएगी (हम नीचे दिए गए प्रकारों के बारे में बात करेंगे)।

भले ही किसी अनुरोध को निष्पादित करते समय एक स्थिर या गतिशील id उपयोग किया जाता है, यहां एक समान अनुरोध की प्रतिक्रिया इस तरह दिखाई देगी:

 { "data": {   "flavors": [     { "id": 1, "name": "The Lazy Person's Movie Theater", description: "That elusive flavor that you begrudgingly carted yourself to the theater for, now in the comfort of your own home, you slob!" }   ] } } 

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

 { flavors {   id   name   nutrition {     calories     fat     sodium   } } } 

ऐसा लग सकता है कि हमारे डेटा वेयरहाउस में, प्रत्येक flavor ऑब्जेक्ट में नेस्टेड nutrition ऑब्जेक्ट होगा। लेकिन यह पूरी तरह सच नहीं है। GraphQL का उपयोग करके, आप कॉल को एक ही क्वेरी में स्वतंत्र, लेकिन संबंधित डेटा स्रोतों से जोड़ सकते हैं, जो आपको उत्तर प्राप्त करने की अनुमति देता है जो डेटाबेस को असामान्य बनाने की आवश्यकता के बिना एम्बेडेड डेटा के साथ काम करने की सुविधा प्रदान करता है:

 { "data": {   "flavors": [     {       "id": 1,       "name": "The Lazy Person's Movie Theater",       "nutrition": {         "calories": 500,         "fat": 12,         "sodium": 1000       }     },     ...   ] } } 

यह प्रोग्रामर की उत्पादकता और सिस्टम की गति को महत्वपूर्ण रूप से बढ़ा सकता है।

अब तक हमने रीड रिक्वेस्ट के बारे में बात की है। डेटा अपडेट अनुरोधों के बारे में क्या? क्या उनका उपयोग करने से हमें वही सुविधा मिलती है?

रेखांकन म्यूटेशन

जबकि ग्राफ़कॉल क्वेरी डेटा लोड करती है, म्यूटेशन डेटा में परिवर्तन करने के लिए जिम्मेदार होते हैं। विभिन्न कार्यों को हल करने के लिए मूल आरपीसी (दूरस्थ प्रक्रिया कॉल) तंत्र के रूप में म्यूटेशन का उपयोग किया जा सकता है, जैसे कि उपयोगकर्ता डेटा को तृतीय-पक्ष एपीआई में भेजना।

म्यूटेशन का वर्णन करते समय, एक सिंटैक्स का उपयोग किया जाता है जो प्रश्नों को उत्पन्न करते समय हमारे द्वारा उपयोग किए जाने वाले जैसा दिखता है:

 mutation updateFlavor($id: ID!, $name: String, $description: String) { updateFlavor(id: $id, name: $name, description: $description) {   id   name   description } } 

यहां हम कुछ वेरिएबल्स - id , name और description निर्दिष्ट करते हुए updateFlavor म्यूटेशन की घोषणा करते हैं। उसी योजना के अनुसार कार्य करना, जिसका उपयोग प्रश्नों का वर्णन करने के लिए किया जाता है, हम mutation कीवर्ड का उपयोग करके परिवर्तनशील फ़ील्ड्स (रूट म्यूटेशन) का उपयोग करते हैं, इसके बाद म्यूटेशन का वर्णन करने वाला नाम और वैरिएबल का एक सेट जिसे संबंधित डेटा अनुरोध को बनाने की आवश्यकता होती है।

इन चरों में वे शामिल हैं जिन्हें हम बदलने की कोशिश कर रहे हैं, या क्या उत्परिवर्तन चाहते हैं। कृपया ध्यान दें कि उत्परिवर्तन के बाद, हम कुछ क्षेत्रों की वापसी का अनुरोध कर सकते हैं।

इस मामले में, हमें रिकॉर्ड, id , name और description फ़ील्ड बदलने के बाद प्राप्त करने की आवश्यकता है। यह तब आ सकता है जब आशावादी इंटरफेस जैसी किसी चीज को विकसित करने, उसे बदलने के बाद बदले हुए डेटा प्राप्त करने के अनुरोध को पूरा करने की आवश्यकता को समाप्त कर दिया जाए।

एक स्कीमा डिजाइन करना और इसे एक ग्राफकॉल सर्वर से जोड़ना

अब तक, हम इस बारे में बात कर चुके हैं कि ग्राफ़कॉक क्लाइंट पर कैसे काम करता है, और वे प्रश्नों का निष्पादन कैसे करते हैं। अब आइए इन अनुरोधों पर कैसे प्रतिक्रिया दें।

▍GraphQL सर्वर

एक ग्राफक्यूएल क्वेरी को निष्पादित करने के लिए, आपको एक ग्राफक सर्वर की आवश्यकता होती है, जिसमें आप ऐसी क्वेरी भेज सकते हैं। ग्राफक्लाइन सर्वर एक नियमित एचटीटीपी सर्वर है (यदि आप जावास्क्रिप्ट में लिखते हैं, तो यह एक्सप्रेस या हापी का उपयोग करके बनाया गया सर्वर हो सकता है), जिसके लिए ग्राफकॉग आरेख संलग्न है।

 import express from 'express' import graphqlHTTP from 'express-graphql' import schema from './schema' const app = express() app.use('/graphql', graphqlHTTP({ schema: schema, graphiql: true })) app.listen(4000) 

किसी योजना में शामिल होने से हमारा मतलब है कि एक ऐसा तंत्र जो ग्राहक से प्राप्त अनुरोधों को योजना के माध्यम से पारित करता है और उसके उत्तर देता है। यह एक एयर फिल्टर की तरह है जिसके माध्यम से हवा कमरे में प्रवेश करती है।

"फ़िल्टरिंग" की प्रक्रिया क्लाइंट द्वारा सर्वर को भेजे गए अनुरोधों या उत्परिवर्तन से जुड़ी है। दोनों क्वेरी और म्यूटेशन को रूट क्वेरी या स्कीमा के रूट म्यूटेशन में परिभाषित फ़ील्ड से संबंधित फ़ंक्शन का उपयोग करके हल किया जाता है।

उपरोक्त एक उदाहरण है जो जावास्क्रिप्ट जावास्क्रिप्ट लाइब्रेरी का उपयोग करके बनाया गया HTTP सर्वर फ्रेमवर्क है। फेसबुक से express-graphql से graphqlHTTP फ़ंक्शन का उपयोग करते हुए, हम योजना को "संलग्न करते हैं" (यह माना जाता है कि यह एक अलग फ़ाइल में वर्णित है) और सर्वर को पोर्ट 4000 पर चलाएं। अर्थात, क्लाइंट, इस सर्वर के स्थानीय उपयोग के बारे में बोलते हुए, अनुरोधों को भेजने में सक्षम होंगे। पता http://localhost:4000/graphql ।

Res डेटा प्रकार और रिसोल्वर

GraphQL सर्वर के संचालन को सुनिश्चित करने के लिए, आपको स्कीमा तैयार करने और इसे संलग्न करने की आवश्यकता है।

याद रखें कि हमने रूट क्वेरी में या उपरोक्त रूट म्यूटेशन में फ़ील्ड घोषित करने की बात की थी।

 import gql from 'graphql-tag' import mongodb from '/path/to/mongodb' //  -  . ,  `mongodb`     MongoDB. const schema = { typeDefs: gql`   type Nutrition {     flavorId: ID     calories: Int     fat: Int     sodium: Int   }   type Flavor {     id: ID     name: String     description: String     nutrition: Nutrition   }   type Query {     flavors(id: ID): [Flavor]   }   type Mutation {     updateFlavor(id: ID!, name: String, description: String): Flavor   } `, resolvers: {   Query: {     flavors: (parent, args) => {       // ,  args  ,  { id: '1' }       return mongodb.collection('flavors').find(args).toArray()     },   },   Mutation: {     updateFlavor: (parent, args) => {       // ,  args    { id: '1', name: 'Movie Theater Clone', description: 'Bring the movie theater taste home!' }       //  .       mongodb.collection('flavors').update(args)       //  flavor  .       return mongodb.collection('flavors').findOne(args.id)     },   },   Flavor: {     nutrition: (parent) => {       return mongodb.collection('nutrition').findOne({         flavorId: parent.id,       })     }   }, }, } export default schema 

एक ग्राफकाइ स्कीमा में खेतों की परिभाषा में दो भाग होते हैं - प्रकार की घोषणाओं ( typeDefs ) और resolver । typeDefs में अनुप्रयोग में उपयोग किए जाने वाले डेटा के लिए प्रकार की घोषणाएँ होती हैं। उदाहरण के लिए, पहले हमने सर्वर से flavor वस्तुओं की एक सूची प्राप्त करने के अनुरोध के बारे में बात की थी। हमारे सर्वर से समान अनुरोध करने के लिए, आपको निम्नलिखित तीन चरण करने होंगे:

1. स्कीमा को बताएं कि flavor ऑब्जेक्ट डेटा कैसा दिखता है (ऊपर के उदाहरण में, यह एक type Flavor जैसा दिखता है)।
2. type Query के मूल फ़ील्ड में फ़ील्ड को डिक्लेयर करें (यह type Query के type Query की flavors संपत्ति है)।
3. एक type Query के मूल क्षेत्र में घोषित क्षेत्रों के अनुसार एक resolvers.Query ऑब्जेक्ट पहचानकर्ता फ़ंक्शन को घोषित करें।

अब आइए typeDefs ध्यान typeDefs । यहां हम स्कीमा को अपने डेटा के आकार के बारे में जानकारी देते हैं। दूसरे शब्दों में, हम ग्राफक्यूएल को विभिन्न गुणों के बारे में बताते हैं जो संबंधित प्रकार की संस्थाओं में निहित हो सकते हैं।

 type Flavor { id: ID name: String description: String nutrition: Nutrition } 

एक type Flavor घोषणा से संकेत मिलता है कि एक flavor वस्तु में id एक id फ़ील्ड, टाइप String का एक name फ़ील्ड, टाइप String description फ़ील्ड और प्रकार का nutrition क्षेत्र हो सकता है।

nutrition के मामले में nutrition हम यहां typeDefs में घोषित एक अलग प्रकार के नाम का उपयोग करते हैं। यहाँ, type Nutrition निर्माण पॉपकॉर्न के पोषण संबंधी डेटा फॉर्म का वर्णन करता है।

इस तथ्य पर ध्यान दें कि यहां, इस सामग्री की शुरुआत में, हम एक "एप्लिकेशन" के बारे में बात कर रहे हैं, न कि एक "डेटाबेस" के बारे में। उपरोक्त उदाहरण में, यह माना जाता है कि हमारे पास एक डेटाबेस है, लेकिन एप्लिकेशन में डेटा किसी भी स्रोत से आ सकता है। यह एक तृतीय-पक्ष एपीआई या एक स्थिर फ़ाइल भी हो सकती है।

जिस तरह हमने type Flavor डिक्लेरेशन में किया था, यहाँ हम उन फील्ड्स के नाम दर्शाते हैं जो इन ऑब्जेक्ट्स (प्रॉपर्टीज) के डेटा टाइप्स के तौर पर nutrition ऑब्जेक्ट्स में समाहित होंगे, जो कि ग्राफक्यूएल में स्केलर डेटा टाइप्स कहलाते हैं। इस लेखन के समय, ग्राफकैल ने 5 बिल्ट-इन स्केलर डेटा प्रकारों का समर्थन किया :

• Int : 32-बिट पूर्णांक पर हस्ताक्षर किए।
• Float : एक संकेत के साथ एक डबल-सटीक फ़्लोटिंग-पॉइंट संख्या।
• String : UTF-8 में एन्कोड किए गए वर्णों का एक क्रम।
• Boolean : बूलियन true या false ।
• ID : एक विशिष्ट पहचानकर्ता का उपयोग अक्सर वस्तुओं को बार-बार लोड करने या कैश में एक कुंजी के रूप में किया जाता है। टाइप ID मूल्यों को तार के समान तरीके से क्रमबद्ध किया जाता है, हालांकि, एक संकेत है कि एक ID प्रकार का एक मूल्य है इस तथ्य पर जोर दिया जाता है कि यह मान लोगों को दिखाने के लिए नहीं है, लेकिन कार्यक्रमों में उपयोग के लिए है।

इन अदिश प्रकारों के अतिरिक्त, हम उन प्रकारों को भी गुण प्रदान कर सकते हैं जिन्हें हम स्वयं परिभाषित करते हैं। यह ठीक उसी प्रकार है जैसा हमने जायके में वर्णित nutrition गुण को असाइन करके किया था, प्रकार का Nutrition निर्माण।

 type Query { flavors(id: ID): [Flavor] } 

type Query निर्माण में, जो type Query के मूल प्रकार का वर्णन करता है ("रूट क्वेरी" जिसके बारे में हमने पहले बात की थी), हम उस फ़ील्ड का नाम घोषित करते हैं जिसे अनुरोध किया जा सकता है। इस फ़ील्ड को घोषित करके, हम, इसके अलावा, डेटा प्रकार के साथ जिसे हम वापस करने की उम्मीद करते हैं, अनुरोध में आने वाले तर्कों को निर्दिष्ट कर सकते हैं।

इस उदाहरण में, हम एक स्केलर id के id तर्क की संभावित प्राप्ति की उम्मीद करते हैं। इस तरह के अनुरोध के जवाब में, वस्तुओं की एक सरणी की उम्मीद की जाती है, जिसका उपकरण Flavor प्रकार के उपकरण जैसा दिखता है।

▍ क्वेरी पहचानकर्ता को काटना

, type Query field , , -.

— , GraphQL, , «». resolvers , Query , , flavors , . flavors , type Query .

 typeDefs: gql`…`, resolvers: { Query: {   flavors: (parent, args) => {     // ,  args    { id: '1' }     return mongodb.collection('flavors').find(args).toArray()   }, }, … }, 

- . parent — , , args , . context , . «» ( — , ).

, , . GraphQL « » . , , .

GraphQL , , . JSON-, JSON-, ( GraphQL ).

- flavors MongoDB, args ( ) .find() , , .

▍

-, GraphQL, , , , nutrition . , , Nutrition , , , , flavor . , / .

GraphQL , type Flavor nutrition type Nutrition , . , , flavor .

 typeDefs: gql`   type Nutrition {     flavorId: ID     calories: Int     fat: Int     sodium: Int   }   type Flavor {     […]     nutrition: Nutrition   }   type Query {…}   type Mutation {…} `, resolvers: {   Query: {     flavors: (parent, args) => {…},   },   Mutation: {…},   Flavor: {     nutrition: (parent) => {       return mongodb.collection('nutrition').findOne({         flavorId: parent.id,       })     }   }, }, 

resolvers , , Query , Mutation Flavor . , typeDefs .

Flavors , , nutrition -. , Flavor . , : « , nutrition , type Flavor ».

MongoDB, , parent , -. , parent , , , flavors . , flavor , :

 { flavors {   id   name   nutrition {     calories   } } } 

flavor , flavors , nutrition , parent . , , , MongoDB, parent.id , id flavor , .

parent.id , nutrition flavorId , flavor .

▍

, , . , . type Mutation , , updateFlavor , , .

 type Mutation { updateFlavor(id: ID!, name: String, description: String): Flavor } 

: « , updateFlavor id ID ( , ! , GraphQL , ), name String description String ». , , Flavor ( — , id , name , description , , , nutrition ).

 { typeDefs: gql`…`, resolvers: {   Mutation: {     updateFlavor: (parent, args) => {       // ,  args    { id: '1', name: 'Movie Theater Clone', description: 'Bring the movie theater taste home!' }       //  .       mongodb.collection('flavors').update(         { id: args.id },         {           $set: {             ...args,           },         },       )       //  flavor  .       return mongodb.collection('flavors').findOne(args.id)     },   }, }, } 

- updateFlavor , : , , — , flavor .

, , flavor . ?

, , . , flavor , .

args ? , . , , , 100% , . , , , , , .

GraphQL?

, , , , , GraphQL-API.

, GraphQL , . , . , . , , , GraphQL REST . , , , GraphQL.

▍ ,

, HTTP-, , , , — . GraphQL , , , , ( ).

, , ( — ), GraphQL .

▍ , ,

, , « ». , , , . . GraphQL .

▍ ,

REST API, : , . , -, iOS Android, API . , , , , « » .

, , , HTTP, API (, , ).

▍ GraphQL — ? REST API GraphQL?

, . . , , GraphQL . GraphQL, . , , , . , , .

, GraphQL , , , . GraphQL , Apollo Relay, .

GraphQL — , , . graphql ( express-graphql , ) — . , GraphQL - . , -, , , , .

परिणाम

, GraphQL , . GraphQL , , , . , , , , GraphQL.

, : GraphQL . GraphQL . , GraphQL, , , , , , , .

— , GraphQL — , , . GraphQL , . , GraphQL — , , , . . , , , , , , GraphQL.

प्रिय पाठकों! GraphQL — , .