GraphQL - एक नए तरीके से एपीआई

GraphQL क्वेरी भाषा क्या है? यह तकनीक क्या लाभ प्रदान करती है और इसका उपयोग करते समय डेवलपर्स को किन समस्याओं का सामना करना पड़ेगा? प्रभावी ढंग से GraphQL का उपयोग कैसे करें? कटौती के तहत यह सब के बारे में।



लेख जोकर 2017 सम्मेलन से व्लादिमीर त्सुकुर ( वलोडिमिरत्सुकुर ) द्वारा परिचयात्मक स्तर की रिपोर्ट पर आधारित है।


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



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

सिंपल एपीआई और उसकी समस्याएं

आइए कल्पना करें कि सामान्य-प्रयोजन एपीआई (जो कि, मंच के शीर्ष पर सभी दुकानों के लिए एक एपीआई) हम स्टोर कार्यक्षमता प्रदान करने के लिए बना सकते हैं। आइए हम पूरी तरह से डेटा प्राप्त करने पर ध्यान केंद्रित करते हैं।

ऐसी साइट पर उत्पाद पृष्ठ के लिए, उत्पाद का नाम, मूल्य, चित्र, विवरण, अतिरिक्त जानकारी और बहुत कुछ वापस किया जाना चाहिए। विज़िटर पर स्टोर के लिए एक पूर्ण समाधान में, दो दर्जन से अधिक ऐसे डेटा फ़ील्ड हैं। HTTP API के शीर्ष पर इस तरह के कार्य के लिए मानक समाधान /products/:id संसाधन का वर्णन करना है, जो GET अनुरोध पर उत्पाद डेटा लौटाता है। निम्नलिखित प्रतिक्रिया डेटा का एक उदाहरण है:

 { "id": "59eb83c0040fa80b29938e3f", "title": "Combo Pack with Dreamy Eyes 12\" (Pink) Soft Toy", "price": 26.99, "description": "Spread Unicorn love amongst your friends and family by purchasing a Unicorn adoption combo pack today. You'll receive your very own fabulous adoption pack and a 12\" Dreamy Eyes (Pink) cuddly toy. It makes the perfect gift for loved ones. Go on, you know you want to, adopt today!", "sku":"010", "images": [   "http://localhost:8080/img/918d8d4cc83d4e5f8680ca4edfd5b6b2.jpg",   "http://localhost:8080/img/f343889c0bb94965845e65d3f39f8798.jpg",   "http://localhost:8080/img/dd55129473e04f489806db0dc6468dd9.jpg",   "http://localhost:8080/img/64eba4524a1f4d5d9f1687a815795643.jpg",   "http://localhost:8080/img/5727549e9131440dbb3cd707dce45d0f.jpg",   "http://localhost:8080/img/28ae9369ec3c442dbfe6901434ad15af.jpg" ] } 

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



मान लीजिए, सादगी के लिए, हम संसाधनों /products और /products/:id लिए एक ही उत्पाद डेटा मॉडल का उपयोग करने का निर्णय लेते हैं। ऐसे उत्पादों के संग्रह के मामले में संभावित रूप से कई होंगे। प्रतिक्रिया योजना का प्रतिनिधित्व इस प्रकार किया जा सकता है:

 GET /products [ {   title   price   images   description   info   ... } ] 

अब उत्पाद संग्रह के लिए सर्वर से प्रतिक्रिया के "पेलोड" को देखें। यहाँ दो दर्जन से अधिक क्षेत्रों के बीच ग्राहक द्वारा वास्तव में उपयोग किया जाता है:

{
"id": "59eb83c0040fa80b29938e3f",
"title": "Combo Pack with Dreamy Eyes 12\" (Pink) Soft Toy",
"price": 26.99,
"info": "Spread Unicorn love amongst your friends and family by purchasing a Unicorn adoption combo pack today. You'll receive your very own fabulous adoption pack and a 12\" Dreamy Eyes (Pink) cuddly toy. It makes the perfect gift for loved ones. Go on, you know you want to, adopt todayl",
" description": "Your fabulous Unicorn adoption combo pack contains:\nA 12\" Dreamy Eyes (Pink) Unicorn Soft Toy\nA blank Unicorn adoption certificate — name your Unicorn!\nA confirmation letter\nA Unicorn badge\nA Unicorn key ring\nA Unicorn face mask (self assembly)\nA Unicorn bookmark\nA Unicorn colouring in sheet\nA A4 Unicorn posters\n2 x Unicorn postcards\n3 x Unicorn stickers",
"images": [
"http://localhost:8080/img/918d8d4cc83d4e5f8680ca4edfd5b6b2.jpg",
"http://localhost:8080/img/f343889c0bb94965845e65d3f39f8798.jpg",
"http://localhost:8080/img/dd55129473604f489806db0dC6468dd9.jpg",
"http://localhost:8080/img/64eba4524a1f4d5d9f1687a815795643.jpg",
"http://localhost:8080/img/5727549e9l3l440dbb3cd707dce45d0f.jpg",
"http://localhost:8080/img/28ae9369ec3c442dbfe6901434ad15af.jpg"
],
...
}

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

आइए अब कार्ट पेज देखें। टोकरी में, स्वयं उत्पादों के अलावा, उनकी मात्रा (इस टोकरी में), मूल्य, साथ ही पूरे ऑर्डर की कुल लागत भी है:



यदि हम HTTP एपीआई के सरल मॉडलिंग के दृष्टिकोण को जारी रखते हैं, तो टोकरी को संसाधन / कार्ट / / आईडी के माध्यम से दर्शाया जा सकता है, जिसकी प्रस्तुति इस टोकरी में जोड़े गए उत्पादों के संसाधनों को संदर्भित करती है:

 { "id": 1, "items": [   {     "product": "/products/59eb83c0040fa80b29938e3f",     "quantity": 1,     "total": 26.99   },   {     "product": "/products/59eb83c0040fa80b29938e40",     "quantity": 2,     "total": 25.98   },   {     "product": "/products/59eb88bd040fa8125aa9c400",     "quantity": 1,     "total": 26.99   } ], "subTotal": 79.96 } 

अब, उदाहरण के लिए, सामने के छोर पर तीन उत्पादों के साथ एक टोकरी खींचने के लिए, आपको चार अनुरोध करने की आवश्यकता है: एक टोकरी को खुद लोड करने के लिए, और तीन अनुरोध उत्पाद डेटा (नाम, मूल्य और SKU नंबर) को लोड करने के लिए।

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

बेशक, यह समाधान उत्पादन के लिए उपयुक्त नहीं है। समस्या से छुटकारा पाने का एक तरीका टोकरी के लिए प्रक्षेपण समर्थन को जोड़ना है। ऐसे अनुमानों में से एक टोकरी के डेटा के अलावा, उत्पादों पर डेटा लौटा सकता है। इसके अलावा, यह प्रक्षेपण बहुत विशिष्ट होगा, क्योंकि यह टोकरी पृष्ठ पर है कि आपको उत्पाद की सूची संख्या (SKU) की आवश्यकता है। कहीं और नहीं SKU की जरूरत थी।

 GET /carts/1?projection=with-products 

विशिष्ट यूआई के लिए संसाधनों का ऐसा "फिट" आमतौर पर समाप्त नहीं होता है, और हम अन्य अनुमानों को उत्पन्न करना शुरू करते हैं: टोकरी पर संक्षिप्त जानकारी, मोबाइल वेब के लिए टोकरी प्रक्षेपण, और उसके बाद यूनिकॉर्न के लिए प्रक्षेपण।



(सामान्य तौर पर, विज़िटर डिज़ाइनर में, आप एक उपयोगकर्ता के रूप में कॉन्फ़िगर कर सकते हैं कि आप किस उत्पाद का डेटा उत्पाद पृष्ठ पर प्रदर्शित करना चाहते हैं और टोकरी में कौन सा डेटा दिखाना है)

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

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

"केक पर चेरी" के रूप में, आइए एक और महत्वपूर्ण मुद्दे को देखें। एक साधारण HTTP एपीआई के मामले में, सर्वर डेवलपर को पता नहीं है कि क्लाइंट किस तरह का डेटा उपयोग कर रहा है। क्या मूल्य का उपयोग किया जाता है? विवरण? एक या सभी चित्र?



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

GraphQL। शुरुआत

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



GraphQL सर्वर के साथ काम करने के लिए एक विशिष्ट दृष्टिकोण पर विचार करें।

हम योजना का वर्णन करते हैं

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



बेशक, ग्राफ उपयोगी होने के लिए, तथाकथित "प्रवेश बिंदु" भी आवश्यक हैं। उदाहरण के लिए, इस तरह के प्रवेश बिंदु को उपयोगकर्ता नाम से प्राप्त कर सकता है।

डेटा का अनुरोध करें

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

 { user(name: "Vanya Unicorn") {   friends {     name   }   city {     name     population   } } } 

और यहाँ ग्राफक्यूएल सर्वर से उत्तर आता है:

 { "data": {   "user": {     "friends": [       { "name": "Lena" },       { "name": "Stas" }     ]     "city": {       "name": "Kyiv",       "population": 2928087     }   } } } 

ध्यान दें कि प्रतिक्रिया फॉर्म के साथ अनुरोध फ़ॉर्म "व्यंजन" कैसा है। एक भावना है कि यह क्वेरी भाषा JSON के लिए बनाई गई थी। मजबूत टाइपिंग के साथ। और यह सब एक HTTP POST अनुरोध में किया जाता है - सर्वर को कई कॉल करने की आवश्यकता नहीं है।

आइए देखें कि यह व्यवहार में कैसा दिखता है। आइए ग्राफकॉल सर्वर के लिए मानक कंसोल खोलें, जिसे ग्राफ आई क्यूएल ("ग्राफ") कहा जाता है। एक टोकरी का अनुरोध करने के लिए, मैं निम्नलिखित अनुरोध को पूरा करूंगा: “मैं पहचानकर्ता 1 द्वारा एक टोकरी प्राप्त करना चाहता हूं, मुझे इस टोकरी और उत्पाद जानकारी के सभी पदों में दिलचस्पी है। जानकारी से, नाम, मूल्य, सूची संख्या और चित्र महत्वपूर्ण हैं (और केवल पहले)। मुझे इन उत्पादों की मात्रा में भी दिलचस्पी है, उनकी कीमत और टोकरी में कुल लागत क्या है । "

 { cart(id: 1) {   items {     product {       title       price       sku       images(limit: 1)     }     quantity     total   }   subTotal } } 

अनुरोध के सफल समापन के बाद, हमें वही मिलता है जो पूछा गया था:

मुख्य लाभ

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

आज, ग्राफ़िकल सर्वर लगभग किसी भी भाषा में बनाया जा सकता है। GraphQL सर्वर का सबसे पूर्ण संस्करण, नोड प्लेटफॉर्म के लिए GraphQL.js है। जावा समुदाय में, संदर्भ कार्यान्वयन ग्राफकॉल जावा है ।

GraphQL एपीआई बनाएँ

आइए देखें कि एक ठोस जीवन उदाहरण पर एक ग्राफक्यूएल सर्वर कैसे बनाया जाए।

दो घटकों के साथ एक microservice वास्तुकला पर आधारित एक ऑनलाइन स्टोर के सरलीकृत संस्करण पर विचार करें:

• कस्टम टोकरी के साथ काम करने वाली कार्ट सेवा। डेटा को एक रिलेशनल डेटाबेस में संग्रहीत करता है और डेटा तक पहुंचने के लिए SQL का उपयोग करता है। बहुत सरल जादू के बिना बहुत सरल सेवा :)
  
• उत्पाद-सेवा उत्पाद कैटलॉग तक पहुंच प्रदान करती है, जिससे वास्तव में, टोकरी भर जाती है। उत्पाद डेटा तक पहुँचने के लिए एक HTTP एपीआई प्रदान करता है।
  

दोनों सेवाओं को क्लासिक स्प्रिंग बूट के शीर्ष पर लागू किया गया है और पहले से ही सभी बुनियादी तर्क शामिल हैं।



हम कार्ट सेवा के शीर्ष पर GraphQL एपीआई बनाने का इरादा रखते हैं। यह एपीआई टोकरी डेटा और इसमें जोड़े गए उत्पादों तक पहुंच प्रदान करने के लिए डिज़ाइन किया गया है।

पहला संस्करण

Java इकोसिस्टम के लिए GraphQL संदर्भ कार्यान्वयन, जिसका हमने पहले उल्लेख किया था - GraphQL जावा, हमारी मदद करेगा।

कुछ निर्भरता pom.xml: जोड़ें pom.xml:

 <dependency>   <groupId>com.graphql-java</groupId>   <artifactId>graphql-java</artifactId>   <version>9.3</version> </dependency> <dependency>   <groupId>com.graphql-java</groupId>   <artifactId>graphql-java-tools</artifactId>   <version>5.2.4</version> </dependency> <dependency>   <groupId>com.graphql-java</groupId>   <artifactId>graphql-spring-boot-starter</artifactId>   <version>5.0.2</version> </dependency> <dependency>   <groupId>com.graphql-java</groupId>   <artifactId>graphiql-spring-boot-starter</artifactId>   <version>5.0.2</version> </dependency> 

पहले बताए गए graphql-java हमें graphql-java-tools, एक graphql-java-tools, लाइब्रेरी के साथ-साथ स्प्रिंग बूट "स्टार्टर्स" की आवश्यकता होगी, जो कि ग्राफकॉल सर्वर बनाने के लिए पहले चरणों को बहुत सरल करेगा:

• ग्राफकल-स्प्रिंग-बूट-स्टार्टर, ग्राफ़िकल जावा को स्प्रिंग बूट से जोड़ने के लिए एक तंत्र प्रदान करता है;
  
• graphiql- वसंत-बूट-स्टार्टर ग्राफक्लाइन प्रश्नों को चलाने के लिए एक इंटरैक्टिव ग्राफ i QL वेब कंसोल जोड़ता है।
  

अगला महत्वपूर्ण कदम ग्राफकॉल सेवा योजना, हमारे ग्राफ का निर्धारण करना है। इस ग्राफ़ के नोड्स को खेतों का उपयोग करके प्रकारों , और किनारों का वर्णन किया गया है। एक खाली ग्राफ़ परिभाषा इस तरह दिखती है:

 schema { } 

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

 schema { query: EntryPoints } 

हम इसे पहले प्रवेश बिंदु के रूप में पहचानकर्ता द्वारा एक टोकरी खोज में परिभाषित करते हैं:

 type EntryPoints { cart(id: Long!): Cart } 

ग्राफक्लाइन शब्दों में कार्ट एक फील्ड से ज्यादा कुछ नहीं है। id इस क्षेत्र का एक मापक है जिसमें स्केलर टाइप Long । विस्मयादिबोधक चिह्न ! प्रकार निर्दिष्ट करने के बाद इसका मतलब है कि पैरामीटर की आवश्यकता है।

यह पहचान करने और Cart टाइप करने का समय है:

 type Cart { id: Long! items: [CartItem!]! subTotal: BigDecimal! } 

मानक id अलावा, टोकरी में इसके आइटम तत्व और सभी subTotal उत्पादों के लिए राशि शामिल है। ध्यान दें कि आइटम को एक सूची के रूप में परिभाषित किया गया है, जैसा कि वर्ग कोष्ठक द्वारा इंगित किया गया है [] । इस सूची के तत्व CartItem प्रकार हैं। फ़ील्ड प्रकार के नाम के बाद विस्मयादिबोधक चिह्न की उपस्थिति ! इंगित करता है कि फ़ील्ड आवश्यक है। इसका मतलब यह है कि सर्वर इस क्षेत्र के लिए एक गैर-रिक्त मान वापस करने के लिए सहमत है, अगर कोई अनुरोध किया गया था।

यह CartItem प्रकार की परिभाषा को देखने के लिए रहता है, जिसमें उत्पाद ( productId ) का लिंक शामिल होता है, इसे कितनी बार टोकरी ( quantity ) और उत्पाद की मात्रा, संख्या ( total ) पर परिकलित किया जाता है:

 type CartItem { productId: String! quantity: Int! total: BigDecimal! } 

यहां सब कुछ सरल है - अदिश प्रकार के सभी क्षेत्र अनिवार्य हैं।

इस योजना को संयोग से नहीं चुना गया था। कार्ट सेवा ने कार्ट बास्केट और इसके CartItem तत्वों को पहले से ही उसी क्षेत्र के नाम और प्रकार के साथ परिभाषित किया है जैसा कि ग्राफलाइन स्कीमा में है। कार्ट मॉडल ऑटो-जनरेटिंग गेटर्स / सेटर, कंस्ट्रक्टर और अन्य तरीकों के लिए लोम्बोक लाइब्रेरी का उपयोग करता है। JPA का उपयोग डेटाबेस में दृढ़ता के लिए किया जाता है।

Cart क्लास:

 import lombok.Data; import javax.persistence.*; import java.math.BigDecimal; import java.util.ArrayList; import java.util.List; @Entity @Data public class Cart {   @Id   @GeneratedValue   private Long id;   @ElementCollection(fetch = FetchType.EAGER)   private List<CartItem> items = new ArrayList<>();   public BigDecimal getSubTotal() {       return getItems().stream()               .map(Item::getTotal)               .reduce(BigDecimal.ZERO, BigDecimal::add);   } } 

CartItem क्लास:

 import lombok.AllArgsConstructor; import lombok.Data; import javax.persistence.Column; import javax.persistence.Embeddable; import java.math.BigDecimal; @Embeddable @Data @AllArgsConstructor public class CartItem {   @Column(nullable = false)   private String productId;   @Column(nullable = false)   private int quantity;   @Column(nullable = false)   private BigDecimal total; } 

तो, बास्केट ( Cart ) और बास्केट एलिमेंट्स ( CartItem ) को ग्राफक्यूएल आरेख और कोड दोनों में वर्णित किया गया है, और खेतों और उनके प्रकारों के सेट के अनुसार एक-दूसरे के साथ "संगत" हैं। लेकिन यह अभी भी हमारी सेवा के लिए काम करने के लिए पर्याप्त नहीं है।

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

 @Bean public GraphQLQueryResolver queryResolver() {   return new GraphQLQueryResolver () {       public Cart cart(Long id) {           return cartService.findCart(id);       }   } } 

ये बदलाव हमारे लिए काम करने के लिए पर्याप्त हैं। ग्राफिइक्यू कंसोल में कार्ट सेवा को पुनरारंभ करने के बाद, निम्नलिखित क्वेरी सफलतापूर्वक निष्पादित करना शुरू कर देगी:

 { cart(id: 1) {   items {     productId     quantity     total   }   subTotal } } 

टिप्पणी

• हम स्केलर प्रकार का उपयोग करते हैं टोकरी और उत्पाद के लिए अद्वितीय पहचानकर्ता के रूप में Long और String । इस तरह के प्रयोजनों के लिए एक विशेष प्रकार का है ग्राफिकल - ID । शब्दार्थ, यह वास्तविक एपीआई के लिए एक बेहतर विकल्प है। कैशिंग के लिए टाइप ID मूल्यों को एक कुंजी के रूप में इस्तेमाल किया जा सकता है।
  
• हमारे आवेदन के विकास में इस स्तर पर, आंतरिक और बाहरी डोमेन मॉडल पूरी तरह से समान हैं। हम Cart और Cart CartItem बारे में बात कर रहे हैं और उनका सीधा उपयोग ग्राफकॉल रिसोल्वर में है। युद्ध अनुप्रयोगों में, इन मॉडलों को अलग करने की सिफारिश की जाती है। GraphQL रिज़ॉल्वर के लिए, आंतरिक विषय क्षेत्र से अलग एक मॉडल मौजूद होना चाहिए।
  

एपीआई को उपयोगी बनाना

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

 type Product { id: String! title: String! price: BigDecimal! description: String sku: String! images: [String!]! } 

CartItem में आवश्यक फ़ील्ड जोड़ें, और CartItem क्षेत्र को productId रूप में productId :

 type Item { quantity: Int! product: Product! productId: String! @deprecated(reason: "don't use it!") total: BigDecimal! } 

हमने योजना का पता लगाया। और अब यह वर्णन करने का समय है कि product क्षेत्र के लिए चयन कैसे काम करेगा। हम पहले Cart और Cart CartItem पर भरोसा करते थे, जो ग्राफलाइन जावा को स्वचालित रूप से मानों को बांधने की अनुमति देता था। लेकिन यहाँ यह याद किया जाना चाहिए कि सिर्फ CartItem वर्ग में product गुण नहीं है:

 @Embeddable @Data @AllArgsConstructor public class CartItem {   @Column(nullable = false)   private String productId;   @Column(nullable = false)   private int quantity;   @Column(nullable = false)   private BigDecimal total; } 

हमारे पास एक विकल्प है:

1. CartItem में उत्पाद गुण जोड़ें और उत्पाद डेटा प्राप्त करने के लिए इसे "कैसे सिखाएं";
   
2. निर्धारित करें कि कार्टिइम वर्ग को बदलने के बिना उत्पाद कैसे प्राप्त करें।
   

दूसरा तरीका बेहतर है, क्योंकि इस मामले में आंतरिक डोमेन ( CartItem वर्ग) के विवरण का मॉडल ग्राफ i QL एपीआई के कार्यान्वयन के विवरण के साथ कवर नहीं किया जाएगा।

इस लक्ष्य को प्राप्त करने के लिए, ग्राफकैलिस्कॉल्वर मार्कर इंटरफ़ेस मदद करेगा। इसे लागू करने से, आप निर्धारित कर सकते हैं (या ओवरराइड) कि टाइप T लिए फ़ील्ड मान कैसे प्राप्त करें T वसंत विन्यास में इसी सेम की तरह दिखता है:

 @Bean public GraphQLResolver<CartItem> cartItemResolver() {   return new GraphQLResolver<CartItem>() {       public Product product(CartItem item) {           return http.getForObject("http://localhost:9090/products/{id}",                   Product.class,                   item.getProductId());       }   }; } 

product विधि का नाम यादृच्छिक नहीं है। GraphQL जावा क्षेत्र के नाम से डेटा डाउनलोडर विधियों की तलाश में है, और हमें केवल product क्षेत्र के लिए लोडर को परिभाषित करने की आवश्यकता है! एक पैरामीटर के रूप में टाइप की गई CartItem एक ऑब्जेक्ट उस संदर्भ को परिभाषित करता है जिसमें उत्पाद का चयन किया जाता है। आगे तकनीक का मामला है। RestTemplate जैसे http क्लाइंट का उपयोग करके RestTemplate हम उत्पाद सेवा के लिए एक GET अनुरोध करते हैं और परिणाम को Product परिवर्तित करते हैं, जो इस प्रकार है:

 @Data public class Product {   private String id;   private String title;   private BigDecimal price;   private String description;   private String sku;   private List<String> images; } 

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

एप्लिकेशन को पुनरारंभ करने के बाद, आप ग्राफ I QL कंसोल में एक नई क्वेरी की कोशिश कर सकते हैं।

 { cart(id: 1) {   items {     product {       title       price       sku       images     }     quantity     total   }   subTotal } } 

और यहाँ क्वेरी निष्पादन का परिणाम है:



हालाँकि productId @deprecated के रूप में चिह्नित productId गया है, लेकिन इस क्षेत्र को इंगित करने वाले प्रश्न काम करना जारी रखेंगे। लेकिन ग्राफ I QL कंसोल ऐसे क्षेत्रों के लिए स्वत: पूर्ण नहीं होगा और विशेष तरीके से उनके उपयोग को उजागर करेगा:



यह दस्तावेज़ एक्सप्लोरर, ग्राफ़ आई क्यूएल कंसोल के हिस्से को दिखाने का समय है, जो ग्राफकाइ स्कीमा के आधार पर बनाया गया है और सभी परिभाषित प्रकारों पर जानकारी प्रदर्शित करता है। CartItem प्रकार के लिए दस्तावेज़ एक्सप्लोरर कैसा दिखता है:



लेकिन उदाहरण के लिए वापस। पहले ही डेमो के समान कार्यक्षमता प्राप्त करने के लिए, लौटे चित्रों की संख्या के लिए अभी भी पर्याप्त सीमा नहीं है। दरअसल, एक टोकरी के लिए, उदाहरण के लिए, आपको प्रत्येक उत्पाद के लिए केवल एक छवि चाहिए:

 images(limit: 1) 

ऐसा करने के लिए, योजना बदलें और उत्पाद प्रकार के लिए चित्र फ़ील्ड के लिए एक नया पैरामीटर जोड़ें:

 type Product { id: ID! title: String! price: BigDecimal! description: String sku: String! images(limit: Int = 0): [String!]! } 

और एप्लिकेशन कोड में हम इसे फिर से उपयोग करेंगे GraphQLResolver, केवल इस बार टाइप करके Product:

 @Bean public GraphQLResolver<Product> productResolver() {   return new GraphQLResolver<Product>() {       public List<String> images(Product product, int limit) {           List<String> images = product.getImages();           int normalizedLimit = limit > 0 ? limit : images.size();           return images.subList(0, Math.min(normalizedLimit, images.size()));       }   }; } 

फिर से मैं इस तथ्य पर ध्यान आकर्षित करता हूं कि विधि का नाम आकस्मिक नहीं है: यह क्षेत्र के नाम के साथ मेल खाता है images। संदर्भ ऑब्जेक्ट Productछवियों तक पहुंच प्रदान करता है, और limitस्वयं क्षेत्र का एक पैरामीटर है।

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

हम प्रोजेक्ट को संकलित करते हैं और सर्वर के पुनरारंभ होने तक प्रतीक्षा करते हैं। कंसोल में सर्किट को पुनरारंभ करना और अनुरोध को निष्पादित करना, हम देखते हैं कि एक पूर्ण अनुरोध वास्तव में काम करता है।

 { cart(id: 1) {   items {     product {       title       price       sku       images(limit: 1)     }     quantity     total   }   subTotal } } 

सहमत हूँ, यह सब बहुत अच्छा है। थोड़े समय में, हमने न केवल सीखा कि ग्राफकॉल क्या है, बल्कि इस तरह के एपीआई का समर्थन करने के लिए एक सरल माइक्रोसर्विस प्रणाली भी स्थानांतरित की गई है। और यह हमारे लिए मायने नहीं रखता था कि डेटा कहाँ से आया है: SQL और HTTP एपीआई दोनों एक ही छत के नीचे अच्छी तरह से फिट होते हैं।

कोड- First और GraphQL SPQR दृष्टिकोण

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

ग्राफक्लीन जावा की केवल मूल विशेषताएं ही हमारे लिए पर्याप्त नहीं हैं, हमें ग्राफकैल एसपीक्यूआर पुस्तकालय की भी आवश्यकता होगी। अच्छी खबर यह है कि ग्राफक्यूएल एसपीक्यूआर ग्राफकॉल जावा के लिए एक ऐड-ऑन है, और जावा में ग्राफकॉल सर्वर का वैकल्पिक कार्यान्वयन नहीं है।

वांछित निर्भरता इसमें जोड़ें pom.xml:

 <dependency>   <groupId>io.leangen.graphql</groupId>   <artifactId>spqr</artifactId>   <version>0.9.8</version> </dependency> 

यहां वह कोड दिया गया है जो बास्केट के लिए समान ग्राफक्यूएल SPQR- आधारित कार्यक्षमता को लागू करता है:

 @Component public class CartGraph {   private final CartService cartService;   @Autowired   public CartGraph(CartService cartService) {       this.cartService = cartService;   }   @GraphQLQuery(name = "cart")   public Cart cart(@GraphQLArgument(name = "id") Long id) {       return cartService.findCart(id);   } } 

और उत्पाद के लिए:

 @Component public class ProductGraph {   private final RestTemplate http;   @Autowired   public ProductGraph(RestTemplate http) {       this.http = http;   }   @GraphQLQuery(name = "product")   public Product product(@GraphQLContext CartItem cartItem) {       return http.getForObject(               "http://localhost:9090/products/{id}",               Product.class,               cartItem.getProductId()       );   }   @GraphQLQuery(name = "images")   public List<String> images(@GraphQLContext Product product,                              @GraphQLArgument(name = "limit", defaultValue = "0") int limit) {       List<String> images = product.getImages();       int normalizedLimit = limit > 0 ? limit : images.size();       return images.subList(0, Math.min(normalizedLimit, images.size()));   } } 

फ़ील्ड लोडर विधियों को फ़्लैग करने के लिए @GraphQLQuery एनोटेशन का उपयोग किया जाता है। एनोटेशन @GraphQLContextक्षेत्र के लिए चयन के प्रकार को परिभाषित करता है। और एनोटेशन @GraphQLArgumentस्पष्ट रूप से तर्क मापदंडों को चिह्नित करता है। ये सभी एक तंत्र के हिस्से हैं जो ग्राफिका SPQR को एक स्कीमा को स्वचालित रूप से उत्पन्न करने में मदद करता है। अब, यदि आप पुराने जावा कॉन्फ़िगरेशन और स्कीमा को हटाते हैं, तो ग्राफक्यूएल एसपीक्यूआर से नए चिप्स का उपयोग करके कार्ट सेवा को पुनरारंभ करें, आप यह सुनिश्चित कर सकते हैं कि सब कुछ पहले की तरह ही कार्यात्मक रूप से काम करता है।

हम एन + 1 की समस्या को हल करते हैं

यह समय ख को देखने के लिए है पर lshih विस्तार पूरे अनुरोध "उन्नत" के कार्यान्वयन। हमने जल्दी से ग्राफकलाइन एपीआई बनाया, लेकिन क्या यह कुशलता से काम कर रहा है?

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



टोकरी प्राप्त cartकरना डेटाबेस में एक SQL-क्वेरी में होता है। डेटा पर itemsऔर subtotalवापस लौटा दिया जाता है, क्योंकि टोकरी तत्वों को पूरे संग्रह के साथ लोड किया जाता है, जो उत्सुक जेपीए रणनीति के आधार पर होता है:

 @Data public class Cart {   @ElementCollection(fetch = FetchType.EAGER)   private List<Item> items = new ArrayList<>();   ... } 

जब उत्पादों पर डेटा डाउनलोड करने की बात आती है, तो उत्पादों की इस टोकरी में उत्पाद सेवा के अनुरोधों को बिल्कुल उसी तरह निष्पादित किया जाएगा। यदि टोकरी में तीन अलग-अलग उत्पाद हैं, तो हमें उत्पाद सेवा के HTTP एपीआई को तीन अनुरोध प्राप्त होंगे, और यदि उनमें से दस हैं, तो उसी सेवा को ऐसे दस अनुरोधों का जवाब देना होगा।



यहां चार्ल्स प्रॉक्सी में कार्ट सेवा और उत्पाद सेवा के बीच संचार है:



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

मैं एक अनुरोध में सभी सही उत्पाद प्राप्त करके इस समस्या को हल करना चाहता हूं। सौभाग्य से, उत्पाद सेवा पहले से ही idsसंग्रह संसाधन में एक पैरामीटर के माध्यम से इस सुविधा का समर्थन करती है:

 GET /products?ids=:id1,:id2,...,:idn 

आइए देखें कि आप उत्पाद क्षेत्र के लिए नमूना विधि कोड को कैसे संशोधित कर सकते हैं । पिछला संस्करण:

 @GraphQLQuery(name = "product") public Product product(@GraphQLContext CartItem cartItem) {   return http.getForObject(           "http://localhost:9090/products/{id}",           Product.class,           cartItem.getProductId()   ); } 

एक अधिक प्रभावी के साथ बदलें:

 @GraphQLQuery(name = "product") @Batched public List<Product> products(@GraphQLContext List<Item> items) {   String productIds = items.stream()           .map(Item::getProductId)           .collect(Collectors.joining(","));   return http.getForObject(           "http://localhost:9090/products?ids={ids}",           Products.class,           productIds   ).getProducts(); } 

हमने ठीक तीन काम किए:

• @Batched एनोटेशन के साथ बूटलोडर विधि को चिह्नित किया , जिससे ग्राफक्यूएल एसपीक्यूआर को स्पष्ट हो गया कि लोडिंग एक बैच के साथ होनी चाहिए;
  
• रिटर्न प्रकार और संदर्भ पैरामीटर को एक सूची में बदल दिया, क्योंकि बैच के साथ काम करने से यह मान लिया जाता है कि कई ऑब्जेक्ट स्वीकार किए जाते हैं और वापस आ जाते हैं;
  
• एक बार में सभी आवश्यक उत्पादों के चयन को लागू करते हुए, विधि के शरीर को बदल दिया।
  

ये परिवर्तन हमारी N + 1 समस्या को हल करने के लिए पर्याप्त हैं। चार्ल्स प्रॉक्सी एप्लिकेशन विंडो अब उत्पाद सेवा के लिए एक अनुरोध दिखाती है, जो एक ही बार में तीन उत्पाद लौटाता है:

प्रभावी क्षेत्र के नमूने

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

यह बहुत अच्छा है कि उत्पाद सेवा का HTTP एपीआई पहले से ही एक ही संग्रह संसाधन के लिए शामिल पैरामीटर के माध्यम से इस सुविधा का समर्थन करता है :

 GET /products?ids=...?include=:field1,:field2,...,:fieldN 

बूटलोडर विधि के लिए, एनोटेशन के साथ टाइप सेट का एक पैरामीटर जोड़ें @GraphQLEnvironment। GraphQL SPQR समझता है कि इस मामले में कोड "अनुरोध" फ़ील्ड नामों की एक सूची है जो उत्पाद के लिए अनुरोध किया जाता है, और स्वचालित रूप से उन्हें पूरा करता है:

 @GraphQLQuery(name = "product") @Batched public List<Product> products(@GraphQLContext List<Item> items,                             @GraphQLEnvironment Set<String> fields) {   String productIds = items.stream()           .map(Item::getProductId)           .collect(Collectors.joining(","));   return http.getForObject(           "http://localhost:9090/products?ids={ids}&include={fields}",           Products.class,           productIds,           String.join(",", fields)   ).getProducts(); } 

अब हमारा नमूना वास्तव में प्रभावी है, एन + 1 समस्या से रहित है और केवल आवश्यक डेटा का उपयोग करता है:

"भारी" पूछताछ

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

 { user(name: "Vova Unicorn") {   friends {     name     friends {       name       friends {         name         friends {            name            ...         }       }     }   } } } 

5-6 घोंसले के स्तर पर, इस तरह के अनुरोध के पूर्ण कार्यान्वयन से दुनिया में सभी उपयोगकर्ताओं का चयन होगा। सर्वर निश्चित रूप से एक बैठक में इस तरह के कार्य से निपटने में सक्षम नहीं होगा और सबसे अधिक संभावना है कि यह "गिरावट" होगा।

ऐसी स्थितियों से खुद को बचाने के लिए कई उपाय करने चाहिए।

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

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

 { cart(id: 1) {   items {     product {       title     }     quantity   }   subTotal } } 

जाहिर है, इस तरह के अनुरोध की गहराई 4 है, क्योंकि सबसे लंबा रास्ता इसके अंदर है cart -> items -> product -> title।

यदि हम मानते हैं कि प्रत्येक फ़ील्ड का वजन 1 है, तो क्वेरी में 7 फ़ील्ड को ध्यान में रखते हुए, इसकी जटिलता भी है 7.

ग्राफ़क्यूएल जावा में, ऑब्जेक्ट बनाते समय अतिरिक्त इंस्ट्रूमेंटेशन को इंगित करके चेक का सुपरपोज़िशन प्राप्त किया जाता है GraphQL:

 GraphQL.newGraphQL(schema)       .instrumentation(new ChainedInstrumentation(Arrays.asList(               new MaxQueryComplexityInstrumentation(20),               new MaxQueryDepthInstrumentation(3)       )))       .build(); 

इंस्ट्रूमेंटेशन MaxQueryDepthInstrumentationअनुरोध की गहराई की जांच करता है और बहुत "गहन" अनुरोधों को लॉन्च करने की अनुमति नहीं देता है (इस मामले में, 3 से अधिक की गहराई के साथ)। किसी क्वेरी को निष्पादित करने से पहले

इंस्ट्रूमेंटेशन MaxQueryComplexityInstrumentationइसकी जटिलता की जाँच करता है। यदि यह संख्या निर्दिष्ट मान (20) से अधिक है, तो ऐसा अनुरोध अस्वीकार कर दिया गया है। आप प्रत्येक क्षेत्र के लिए वजन को फिर से परिभाषित कर सकते हैं, क्योंकि उनमें से कुछ स्पष्ट रूप से दूसरों की तुलना में "कठिन" मिलते हैं। उदाहरण के लिए, उत्पाद क्षेत्र को @GraphQLComplexity,ग्राफ़िकल एसपीक्यूआर में समर्थित एनोटेशन के माध्यम से जटिलता 10 सौंपा जा सकता है :

 @GraphQLQuery(name = "product") @GraphQLComplexity("10") public List<Product> products(...) 

यहां गहराई से जांच का एक उदाहरण है जब यह स्पष्ट रूप से निर्दिष्ट मूल्य से अधिक है:



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

हमने "सुरक्षा" उपायों की जाँच की, जो ग्राफ़िकल के लिए विशिष्ट है। हालांकि, एपीआई के प्रकार की परवाह किए बिना ध्यान देने योग्य कई तरकीबें हैं:

• थ्रॉटलिंग / रेट-लिमिटिंग - समय की प्रति यूनिट अनुरोधों की संख्या को सीमित करें
  
• टाइमआउट - अन्य सेवाओं, डेटाबेस, आदि के साथ संचालन के लिए समय सीमा;
  
• पृष्ठ पर अंक लगाना - pagination support।
  

डेटा का उत्परिवर्तन

अब तक, हम विशुद्ध रूप से डेटा सैंपलिंग पर विचार कर रहे हैं। लेकिन GraphQL आपको न केवल डेटा की प्राप्ति, बल्कि उनके परिवर्तन को व्यवस्थित करने की अनुमति देता है। इसके लिए एक तंत्र है । योजना में, इसके लिए एक विशेष स्थान आरक्षित है - क्षेत्र mutation:

 schema { query: EntryPoints, mutation: Mutations } 

उदाहरण के लिए, एक उत्पाद को टोकरी में जोड़ना निम्नलिखित उत्परिवर्तन के माध्यम से आयोजित किया जा सकता है:

 type Mutations {   addProductToCart(cartId: Long!,                    productId: String!,                    count: Int = 1): Cart } 

यह एक क्षेत्र को परिभाषित करने के समान है, क्योंकि एक उत्परिवर्तन में पैरामीटर और एक वापसी मूल्य भी होता है।

GraphQL SPQR का उपयोग कर सर्वर कोड में एक म्यूटेशन का कार्यान्वयन इस प्रकार है:

 @GraphQLMutation(name = "addProductToCart") public Cart addProductToCart(       @GraphQLArgument(name = "cartId") Long cartId,       @GraphQLArgument(name = "productId") String productId,       @GraphQLArgument(name = "quantity", defaultValue = "1") int quantity) {   return cartService.addProductToCart(cartId, productId, quantity); } 

बेशक, अधिकांश उपयोगी कार्य आंतरिक रूप से किया जाता है cartService। और इस इंटरलेयर विधि का कार्य इसे एपीआई के साथ जोड़ना है। जैसा कि डेटा सैंपलिंग के मामले में, एनोटेशन के लिए धन्यवाद, यह @GraphQL*समझना बहुत आसान है कि इस पद्धति की परिभाषा से कौन सा ग्राफक्यूएल स्कीमा उत्पन्न होता है।

GraphQL कंसोल में, अब आप हमारे टोकरी में 2 में एक विशिष्ट उत्पाद जोड़ने के लिए एक उत्परिवर्तन अनुरोध कर सकते हैं:

 mutation { addProductToCart(     cartId: 1,     productId: "59eb83c0040fa80b29938e3f",     quantity: 2) {   items {     product {       title     }     quantity     total   }   subTotal } } 

चूंकि म्यूटेशन का रिटर्न वैल्यू होता है, इसलिए सामान्य नियमों के अनुसार हमने उसी नियमों के अनुसार फ़ील्ड से अनुरोध किया है।

कई आगंतुक विकास टीमें सक्रिय रूप से ग्राफाका के साथ स्काला और संगरिया पुस्तकालय का उपयोग कर रही हैं, इस भाषा में ग्राफकलाइन का मुख्य कार्यान्वयन है।

HTML का प्रतिपादन करते समय, ग्राफ़िक्स में उपयोग की जाने वाली उपयोगी तकनीकों में से एक ग्राफक्लाइन प्रश्नों का समर्थन है। JSON को सीधे पेज कोड में जनरेट करने के लिए हम ऐसा करते हैं। यहां HTML टेम्पलेट भरने का एक उदाहरण दिया गया है:

 // Pre-rendered <html> <script data-embedded-graphiql> {   product(productId: $productId)     title     description     price     ...   } } </script> </html> 

और यहाँ उत्पादन है:

 // Rendered <html> <script> window.DATA = {   product: {          title: 'GraphQL Sticker',          description: 'High quality sticker',           price: '$2'           ... } } </script> </html> 

HTML रेंडरर और ग्राफकॉल सर्वर का ऐसा संयोजन हमें हमारे एपीआई को अधिकतम उपयोग करने और नियंत्रकों की एक अतिरिक्त परत नहीं बनाने देता है। इसके अलावा, यह तकनीक अक्सर प्रदर्शन के मामले में लाभप्रद साबित होती है, क्योंकि पृष्ठ लोड करने के बाद, जावास्क्रिप्ट एप्लिकेशन को पहले आवश्यक डेटा के लिए बैकएंड पर जाने की आवश्यकता नहीं है - यह पहले से ही पृष्ठ पर है।

ग्राफकॉल के नुकसान

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

• -, GraphQL . GraphQL , HTTP API. Cache-Control Last-Modified HTTP GraphQL API. , proxy gateways (Varnish, Fastly ). , GraphQL , , .
  
• GraphQL — . , API, , .
  
• GraphQL . .
  
• . GraphQL — . JSON XML, , , GraphQL, .
  
• GraphQL . , HTTP PUT POST -. , . GraphQL . .
  
• . , -: «delete» «kill», «annihilate» «terminate», . GraphQL API . HTTP DELETE .
  
• Joker 2016 . GraphQL . API- , , , HATEOAS, , « REST». , , GraphQL .
  

यह भी याद रखने योग्य है कि यदि आप HTTP एपीआई को अच्छी तरह से विकसित करने में सफल नहीं हुए हैं, तो आप सबसे अधिक संभावना ग्राफ़िकल एपीआई को विकसित करने में सक्षम नहीं होंगे। आखिर, किसी भी एपीआई के विकास में सबसे महत्वपूर्ण क्या है? आंतरिक डोमेन मॉडल को बाहरी एपीआई मॉडल से अलग करें। एप्लिकेशन के आंतरिक उपकरण के उपयोग के परिदृश्य के आधार पर API बनाएं। केवल आवश्यक न्यूनतम जानकारी खोलें, और सभी एक पंक्ति में नहीं। सही नाम चुनें। ग्राफ का सही वर्णन करें। HTTP API में एक रिसोर्स ग्राफ और GraphQL API में एक फील्ड ग्राफ होता है। दोनों ही मामलों में, यह ग्राफ गुणात्मक रूप से किया जाना चाहिए।

HTTP एपीआई दुनिया में विकल्प हैं, और जब आपको जटिल चयनों की आवश्यकता होती है तो आपको हमेशा ग्राफ़कॉक का उपयोग नहीं करना पड़ता है। उदाहरण के लिए, ओडटा मानक है, जो आंशिक रूप से विस्तार और चयन का समर्थन करता है, जैसे ग्राफक्यूएल, और HTTP के शीर्ष पर काम करता है। एक मानक JSON एपीआई है जो JSON के साथ काम करता है और हाइपरमीडिया और जटिल भ्रूण क्षमताओं का समर्थन करता है। LinkRest भी है, जिसके बारे में आप https://youtu.be/EsldBtrb1Qc "> जोकर 2017 पर एंड्रस एडमचिक की रिपोर्ट से अधिक जान सकते हैं ।

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

• https://philsturgeon.uk/api/2017/01/24/graphql-vs-rest-overview/
  
• https://blog.runscope.com/posts/you-might-not-need-graphql
  

अंत में सब्सक्रिप्शन और डिफर के बारे में

ग्राफिंक का मानक एपीआई पर एक दिलचस्प लाभ है। GraphQL में, सिंक्रोनस और एसिंक्रोनस उपयोग के मामले दोनों एक ही छत के नीचे बैठ सकते हैं।

हमने आपके माध्यम से डेटा प्राप्त करने query, सर्वर की स्थिति को बदलने पर विचार किया mutation, लेकिन एक और अच्छाई है। उदाहरण के लिए, सदस्यता को व्यवस्थित करने की क्षमता subscriptions।

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

 schema { query: Queries, mutation: Mutations, subscription: Subscriptions } type Subscriptions { productAdded(cartId: String!): Cart } 

ग्राहक निम्नलिखित अनुरोध के माध्यम से सदस्यता ले सकता है:

 subscription { productAdded(cart: 1) {   items {     product ...   }   subTotal } } 

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

 { "data": {   "productAdded": {     "items": [       { "product": …, "subTotal": … },       { "product": …, "subTotal": … },       { "product": …, "subTotal": … },       { "product": …, "subTotal": … }     ],     "subTotal": 289.33   } } } 

ग्राहक अब टोकरी को फिर से खोल सकता है, जरूरी नहीं कि पूरे पृष्ठ को फिर से तैयार किया जाए।

यह सुविधाजनक है क्योंकि सिंक्रोनस एपीआई (HTTP) और एसिंक्रोनस API (WebSocket) दोनों को रेखांकन के माध्यम से वर्णित किया जा सकता है।

अतुल्यकालिक संचार का उपयोग करने का एक और उदाहरण है, डेफर तंत्र । मुख्य विचार यह है कि ग्राहक यह चुनता है कि वह कौन सा डेटा तुरंत (सिंक्रोनस) प्राप्त करना चाहता है, और वे जिसे बाद में (अतुल्यकालिक) प्राप्त करने के लिए तैयार हैं। उदाहरण के लिए, इस तरह के अनुरोध के लिए:

 query { feedStories {   author { name }   message   comments @defer {     author { name }     message   } } } 

सर्वर पहले लेखक और प्रत्येक कहानी के लिए एक संदेश लौटाएगा:

 { "data": {   "feedStories": [     {       "author": …,       "message": …     },     {       "author": …,       "message": …     }   ] } } 

उसके बाद, सर्वर, टिप्पणियों पर डेटा प्राप्त कर रहा है, उन्हें ग्राहक को वेबसर्केट के माध्यम से अतुल्यकालिक रूप से वितरित करेगा, यह दर्शाता है कि उस पथ के लिए जिसमें इतिहास टिप्पणियां अब तैयार हैं:

 { "path": [ "feedStories", 0, "comments" ], "data": [   {     "author": …,     "message": …   } ] } 

नमूना स्रोत

इस रिपोर्ट को तैयार करने के लिए इस्तेमाल किया गया कोड GitHub पर पाया जा सकता है ।

हाल ही में, हमने JPoint 2019 की घोषणा की , जो 5-6 अप्रैल, 2019 को आयोजित किया जाएगा। आप हमारे हब से सम्मेलन से क्या उम्मीद कर सकते हैं, इसके बारे में अधिक जान सकते हैं । दिसंबर के पहले तक, अर्ली बर्ड टिकट अभी भी सबसे कम कीमत पर उपलब्ध हैं ।