GraphQL का एक संक्षिप्त दौरा

नमस्कार, हेब्र!


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

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



जब क्लाइंट और सर्वर अनुप्रयोगों के बीच नेटवर्क अनुरोधों की बात आती है, तो REST को अक्सर क्लाइंट और सर्वर दुनिया के बीच पुल के रूप में चुना जाता है। आरईएसटी में, सब कुछ "हमें उन संसाधनों की आवश्यकता है जो URL द्वारा सुलभ हैं।" आप HTTP GET का उपयोग करके एक संसाधन पढ़ सकते हैं, HTTP POST अनुरोध का उपयोग करके एक संसाधन बना सकते हैं, और HTTP PUT और DELETE अनुरोधों का उपयोग करके इसे अपडेट और हटा सकते हैं। इन ऑपरेशनों को CRUD (क्रिएट, रीड, अपडेट, डिलीट) कहा जाता है। संसाधन लेखकों, उपयोगकर्ताओं से प्राप्त किसी भी सामग्री या लेख से लिया जा सकता है। REST का उपयोग करते समय, डेटा ट्रांसफर प्रारूप हार्डकोड नहीं किया जाता है, लेकिन अक्सर JSON का उपयोग इस उद्देश्य के लिए किया जाता है। अंत में, REST URL और HTTP विधियों का उपयोग करके सामान्य HTTP प्रोटोकॉल पर अनुप्रयोगों के बीच संचार सक्षम करता है।

 //    REST GET https://api.domain.com/authors/7 //   JSON { "id": "7", "name": "Robin Wieruch", "avatarUrl": "https://domain.com/authors/7", "firstName": "Robin", "lastName": "Wieruch" } 

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

GraphQL क्या है?

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

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

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

 //  GraphQL author(id: "7") { id name avatarUrl articles(limit: 2) { name urlSlug } } //   GraphQL { "data": { "author": { "id": "7", "name": "Robin Wieruch", "avatarUrl": "https://domain.com/authors/7", "articles": [ { "name": "The Road to learn React", "urlSlug": "the-road-to-learn-react" }, { "name": "React Testing Tutorial", "urlSlug": "react-testing-tutorial" } ] } } } 

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

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

रेखांकन लाभ

एक आवेदन में ग्राफकॉल का उपयोग करने के मुख्य लाभ निम्नलिखित हैं।

घोषणात्मक डेटा नमूनाकरण

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

ग्राफकॉल के साथ काम करने पर कोई पुनः नमूना नहीं

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

ग्राफक के लिए प्रतिक्रिया, कोणीय, नोड, आदि।

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

GraphQL का उपयोग कौन करता है?

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

• गिटहब [१] [२]
• Shopify [1] [2]
• चहचहाना
• Coursera
• भौंकना
• Wordpress
• टी वह न्यूयॉर्क के समय
• संसार
• और अन्य ...

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

सत्य का एक स्रोत

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

ग्राफकॉक वर्तमान रुझानों का अनुसरण करता है

GraphQL अनुप्रयोग विकास में वर्तमान रुझानों का अनुसरण करता है। आपके पास बैकएंड पर केवल एक ही एप्लिकेशन हो सकता है, लेकिन अक्सर ऐसा होता है कि कई अलग-अलग क्लाइंट इस बैकेंड (वेब ​​क्लाइंट, मोबाइल डिवाइस, स्मार्ट घड़ियों ...) का उपयोग करते हैं और ये सभी बैकएंड एप्लिकेशन में संग्रहीत डेटा पर निर्भर करते हैं। इसलिए, GraphQL न केवल "दोनों दुनिया" दोस्त बनाने में मदद कर सकता है, बल्कि प्रत्येक प्रकार के क्लाइंट के लिए समर्पित एपीआई बनाने की आवश्यकता के बिना प्रत्येक क्लाइंट (संबंधित, उदाहरण के लिए, नेटवर्क का उपयोग करके, नेस्टेड डेटा संबंधों, केवल आवश्यक डेटा का चयन करके) को संतुष्ट करता है।

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

कैसे रेखांकन स्कीमा टाँके

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

आत्मनिरीक्षण ग्राफक्लाइन

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

दृढ़ता से टाइप किए गए ग्राफ़क

GraphQL एक अत्यधिक टाइप की जाने वाली क्वेरी भाषा है, जो GraphQL के लिए अर्थपूर्ण स्कीमा परिभाषा भाषा (SDL) में लिखी गई है। इस भाषा के समान ही फायदे हैं जैसे कि कोई भी दृढ़ता से टाइप की गई प्रोग्रामिंग भाषा। यह कम त्रुटि वाला है, संकलन समय पर मान्य किया जा सकता है और इसे समर्थन आईडीई / संपादक सुविधाओं जैसे कि ऑटोोकम्पिशन और इनपुट समर्थन के साथ एकीकरण के लिए गिना जा सकता है।

वर्जनिंग ग्राफ़िकल

GraphQL में ऐसे एपीआई संस्करण नहीं हैं जिनका उपयोग हम REST में करते हैं। REST में, समान API (उदा। Api.domain.com/v1/, api.domain.com/v2/) के कई संस्करणों की पेशकश करना सामान्य है, क्योंकि संसाधन या उनकी संरचना समय के साथ बदल सकती है। ग्राफकॉइन में, आप एपीआई को गैर-अनुशंसित लोगों के क्षेत्र स्तर पर अनुवाद कर सकते हैं। इसलिए, गैर-अनुशंसित फ़ील्ड तक पहुँचने पर क्लाइंट को एक चेतावनी मिलती है। कुछ समय बाद, गैर-अनुशंसित क्षेत्र को योजना से बाहर रखा जा सकता है, फिर कोई भी अधिक ग्राहक इसका उपयोग नहीं करेंगे। इस प्रकार, वर्जनलाइन एपीआई को वर्जनिंग की आवश्यकता के बिना विकसित किया जा सकता है।

बढ़ता ग्राफकॉल इकोसिस्टम

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

अगर मैं ग्राफकॉल पर स्विच करता हूं - क्या मैं ऑल-इन जाता हूं?

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

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

अगला, हम ग्राफकॉल के उपयोग से जुड़े कुछ नुकसानों पर चर्चा करते हैं।

ग्राफक्लाइन प्रश्न जटिलता

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

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

GraphQL में स्पीड लिमिट

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

रेखांकन कैशिंग

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

बाकी क्यों नहीं?

GraphQL – REST, . REST – GraphQL, REST?
REST URL , . «», id, , id. GraphQL , . , , , GraphQL , .

, REST. Airbnb. , . REST-, REST- . , , GraphQL API, GraphQL, (, ), (., ).

, GraphQL ; , , , . GraphQL – Facebook , -.

, , REST – . , GraphQL. , GraphQL, - .