क्या ग्राफकॉल ने HTTP / 2 युग में प्रासंगिकता खो दी?

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



लगभग उसी समय, वुलकेन परियोजना के बारे में घोषणा की गई थी। इस संदेश में ये शब्द शामिल थे: "TL / DR: GraphQL जिसकी अब आपको आवश्यकता नहीं है!"। और अंत में, मार्क नॉटिंघम द्वारा एक महान लेख HTTP / 2 की शक्तिशाली विशेषताओं पर प्रकाशित किया गया था और उन सुविधाओं का क्या मतलब है जो एपीआई डिजाइन करते हैं। डारेल मिलर ने अपने ग्राहकों के साथ इस लेख का लिंक साझा किया ।

क्या हो रहा था मुझे ग्राफ़िकल और HTTP / 2 के बारे में सोचना चाहिए। यदि सब कुछ HTTP / 2 (और HTTP / 3) का उपयोग करके काम करना शुरू कर देता है, तो क्या इसका मतलब यह होगा कि हमारे पास ग्राफकॉल का उपयोग करने का कोई कारण नहीं है? मैं आज इसका पता लगाना चाहूंगा।

HTTP / 2 नवाचार

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

टीसीपी कनेक्शन खोलना एक महंगा ऑपरेशन है। HTTP / 1 का उपयोग करने वाले ग्राहक इसे अक्सर नहीं चलाते हैं। इस कारण से, सिस्टम पर बड़े अतिरिक्त भार के कारण, डेवलपर्स ने अक्सर विभिन्न तकनीकों का सहारा लेकर अनुरोधों की संख्या को सीमित करने की कोशिश की। यह, उदाहरण के लिए, बैच क्वेरीज़ को निष्पादित करना, क्वेरी भाषाओं का उपयोग करना, पेज कोड में CSS / JS कोड एम्बेड करना, व्यक्तिगत छवियों के बजाय स्प्राइट शीट का उपयोग करना, और इसी तरह। HTTP / 1.1 में। लगातार कनेक्शन और पाइपलाइन किए गए डेटा प्रसंस्करण का उपयोग करके इनमें से कुछ समस्याओं को हल करने का प्रयास किया गया था। इन दो तकनीकों ने ब्राउज़रों को एक ही कनेक्शन, कई अनुरोधों के भीतर और उनके उत्तर प्राप्त करने के लिए भेजने की अनुमति दी। ऐसी डेटा विनिमय योजना का नुकसान यह था कि यह कतार की शुरुआत ( हेड-ऑफ-लाइन ब्लॉकिंग ) को अवरुद्ध करने की समस्या के अधीन थी। यह समस्या इस तथ्य में व्यक्त की जाती है कि एक धीमी अनुरोध इसके बाद सभी अनुरोधों के प्रसंस्करण को धीमा कर सकता है। HTTP / 2 पर काम करने वाले विशेषज्ञों ने इस समस्या को हल करने के लिए अलग-अलग तरीके सुझाए। नए बाइनरी प्रोटोकॉल के साथ, HTTP / 2 एक नई डेटा डिलीवरी रणनीति पेश करता है। HTTP / 2 प्रोटोकॉल का उपयोग करने वाले सिस्टम के इंटरैक्शन के दौरान, एक एकल कनेक्शन खोला जाता है, जिसके फ्रेमवर्क में अनुरोधों और प्रतिक्रियाओं का बहुसंकेतन किया जाता है, जो फ्रेम के साथ काम करने के लिए डिज़ाइन किए गए एक नए बाइनरी स्तर का उपयोग करते हैं, जब प्रत्येक फ्रेम एक स्ट्रीम का हिस्सा होता है। इस तंत्र का उपयोग करके, क्लाइंट और सर्वर उन फ़्रेमों के बारे में जानकारी के आधार पर अनुरोध और प्रतिक्रिया प्रवाह को फिर से बना सकते हैं। यह HTTP / 2 को एक ही कनेक्शन में निष्पादित कई अनुरोधों के प्रसंस्करण का बहुत प्रभावी ढंग से समर्थन करने की अनुमति देता है।

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

तो, जबकि सब कुछ स्पष्ट है। लेकिन यह सब क्या करने के लिए GraphQL के साथ क्या करना है?

GraphQL: एक क्वेरी जो सभी समस्याओं को हल करती है

GraphQL तकनीक आंशिक रूप से इसके आकर्षण के कारण है कि यह डेवलपर्स को HTTP / 1 कनेक्शन के विशिष्ट नुकसान से निपटने में मदद करता है।

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


एक क्वेरी के भीतर कई संसाधनों को प्राप्त करने की क्षमता, ग्राफकॉल की ताकत में से एक है, जिसके लिए इस तकनीक के निर्माता अपने संभावित उपयोगकर्ताओं का ध्यान आकर्षित करते हैं।

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

शायद तथ्य यह है कि अब भी HTTP / 2 क्लाइंट और कुछ सर्वर एप्लिकेशन के शुरुआती दिन हैं?

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

ग्राफ़कॉक डेटा प्राप्त करने और प्रसारित करने के समय को कम करने या प्रेषित सूचना की मात्रा का अनुकूलन करने से अधिक है

यद्यपि डेटा प्राप्त करने और संचारित करने के समय को कम करना और प्रेषित जानकारी की मात्रा का अनुकूलन करना ग्राफ़िकल की ताकत है जिसके बारे में हम लगातार सुनते हैं, यह तकनीक हमें बहुत अधिक देती है।

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

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

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

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

क्लाइंट सिस्टम और ग्राफकैल विकास

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

GraphQL उल्लेखनीय विशेषताओं के साथ एक समग्र प्रणाली है

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

नेटवर्किंग अभी भी एक सीमित कारक है (या शायद यह हमेशा ऐसा ही होगा?)

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

जबकि HTTP / 2 निश्चित रूप से उच्च ग्रैन्युलैरिटी के साथ अनुरोधों के निष्पादन को प्रोत्साहित करता है, मुझे लगता है कि यहां कुछ ट्रेड-ऑफ किए जाने हैं।

क्या HTTP / 2 ग्राफकॉल की मदद कर सकता है?

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

query {   viewer {     name     posts(first: 100) @stream {       title     }   } } 

यह पता चला है कि हम अच्छी तरह से ग्राफकॉल के सर्वर-साइड एब्स्ट्रक्शन, इस तकनीक की डिक्लेक्टिव क्वेरी भाषा का उपयोग कर सकते हैं, और साथ ही साथ HTTP / 2 स्ट्रीम की क्षमताओं का उपयोग कर सकते हैं। मुझे लगता है कि वेब सॉकेट का उपयोग यहां किया जाता है। मुझे अभी भी यह पता लगाने की आवश्यकता है, लेकिन मुझे यकीन है कि कई पहले से ही ग्राफडाइन निर्देशों जैसे @defer , @stream और @live खोज कर रहे हैं।

परिणाम

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

प्रिय पाठकों! यदि आप ग्राफकॉल तकनीक का उपयोग करते हैं, तो कृपया हमें बताएं कि आपको इसके बारे में क्या पसंद नहीं है।