GraphQL के बारे में सभी लेख आपको बताएंगे कि यह कितना अद्भुत है, लेकिन क्या इसके कोई नुकसान या कमियां हैं? धन्यवाद।
जवाबों:
नुकसान:
लेकिन, इनकी तुलना में ये अधिक हैं:
graphql-spring-boot-starterऔर graphql-java-toolsआरंभ करने के लिए। अपने स्कीमा को .graphqls संसाधन में बनाएँ और रिज़ॉल्वर कक्षाएं बनाएँ और आपका काम हो गया। एक कामकाजी परीक्षा का उदाहरण पाने के लिए और दौड़ने में लगभग 10 मिनट लगे।
मैंने किसी के लिए कुछ महत्वपूर्ण चिंताओं को पाया है जिसका उपयोग ग्राफकॉल पर विचार कर रहा हूं , और अब तक मुख्य बिंदु हैं:
अनिश्चितकालीन गहराई में क्वेरी : ग्राफक्लाइन अनिश्चित गहराई में क्वेरी नहीं कर सकती है, इसलिए यदि आपके पास एक पेड़ है और गहराई को जाने बिना एक शाखा वापस करना चाहते हैं, तो आपको कुछ पेजिनेशन करना होगा।
विशिष्ट प्रतिक्रिया संरचना : ग्राफक्लाइन में प्रतिक्रिया क्वेरी के आकार से मेल खाती है, इसलिए यदि आपको बहुत विशिष्ट संरचना में प्रतिक्रिया करने की आवश्यकता है, तो आपको प्रतिक्रिया को फिर से खोलने के लिए एक परिवर्तन परत जोड़ना होगा।
नेटवर्क स्तर पर कैश : आमतौर पर जिस तरह से ग्राफकॉइन का उपयोग HTTP (एक समापन बिंदु पर एक POST) में किया जाता है, उसके कारण नेटवर्क स्तर पर कैश कठिन हो जाता है। इसे हल करने का एक तरीका पर्सेंटेड क्वेरीज़ का उपयोग करना है।
फाइल अपलोडिंग को हैंडल करना: ग्राफकलाइन स्पेसिफिकेशन में फाइल अपलोड के बारे में कुछ भी नहीं है और म्यूटेशन तर्कों में फाइलों को स्वीकार नहीं करता है। इसे हल करने के लिए आप अन्य प्रकार के API (जैसे REST) का उपयोग करके फ़ाइलों को अपलोड कर सकते हैं और अपलोड की गई फ़ाइल के URL को GraphQL म्यूटेशन में पास कर सकते हैं, या फ़ाइल को निष्पादन संदर्भ में इंजेक्ट कर सकते हैं, इसलिए आपके पास रिज़ॉल्वर फ़ंक्शन के अंदर फ़ाइल होगी।
अप्रत्याशित निष्पादन : ग्राफकॉल की प्रकृति यह है कि आप जो भी फ़ील्ड चाहते हैं, उसे संयोजित कर सकते हैं लेकिन, यह लचीलापन मुफ़्त में नहीं है। कुछ चिंताएँ हैं जिन्हें जानना अच्छा है जैसे प्रदर्शन और N + 1 प्रश्न।
सुपर सिंपल एपीआई : यदि आपके पास एक ऐसी सेवा है जो वास्तव में सरल एपीआई को उजागर करती है, तो ग्राफक्यूएल केवल एक अतिरिक्त जटिलता जोड़ेगा, इसलिए एक साधारण रीस्ट एपीआई बेहतर हो सकता है।
यह सबसे बड़ी समस्या यह है कि मैं अगर तुम संबंधपरक डेटाबेस के साथ प्रयोग कर रहे हैं graphQL यानी के साथ देख के साथ है मिलती है ।
तथ्य यह है कि आप कुछ क्षेत्रों को अनुमति / अस्वीकार कर सकते हैं, गैर-तुच्छ (सरल नहीं) में मिलती है। जिससे अतिरिक्त प्रश्न उत्पन्न होते हैं।
इसके अलावा ग्राफिकल में नेस्टेड क्वेरीज सर्कुलर क्वेश्चन को लीड करती है और सर्वर को क्रैश कर सकती है । अतिरिक्त देखभाल करनी पड़ती है।
कॉल को सीमित करना मुश्किल हो जाता है coz अब उपयोगकर्ता एक कॉल में कई प्रश्नों को फायर कर सकता है।
TIP : जावास्क्रिप्ट / नोड के मामले में प्रश्नों की संख्या को कम करने के लिए facebook के dataloader का उपयोग करें
costअनुरोध करने के लिए पार्स और असाइन कर सकते हैं। यदि आप पूर्वनिर्धारित प्रश्नों का उपयोग कर रहे हैं, तो भी यह चिंता का विषय नहीं है, जहां ग्राहक केवल आईडी भेजता है।
यह हर साल बेहतर और बेहतर होता जा रहा है, और अब के लिए, ग्राफक्यूएल का समुदाय बढ़ रहा है, और इसके परिणामस्वरूप, बहुत सारी समस्याओं का बहुत अधिक समाधान है जो पहले अन्य उत्तरों में हाइलाइट किए गए थे। लेकिन स्वीकार करने के लिए क्या अभी भी कंपनियों को पकड़ रहा है सभी संसाधनों को ग्राफक्लाइन से फेंकने के लिए मैं कुछ मुद्दों और समाधानों की सूची बनाना चाहूंगा जिनके बाद अनसुलझी हैं।
लेकिन कुछ और मामले हैं जिन्हें नुकसान के रूप में गिना जा सकता है:
योग करने के लिए, ग्राफकॉल केवल विशिष्ट लक्ष्यों के लिए एक उपकरण है और निश्चित रूप से यह सभी समस्याओं के लिए एक चांदी की गोली नहीं है और निश्चित रूप से आरईएसटी के लिए एक प्रतिस्थापन नहीं है।
एक एकल समापन बिंदु और सभी डेटा को उजागर करना वास्तव में बहुत अच्छा है। मैं ग्राफ़िकल के लिए विचार करने के लिए नीचे दिए गए बिंदुओं को खोजता हूं:
इसके कार्यान्वयन के बाद पेशेवरों पर विचार करना चाहिए:
एक बार लागू होने के बाद तर्कों और कस्टम ऑर्डर का उपयोग करके शर्तों को जोड़ना आसान है
बहुत सारे कस्टम फ़िल्टर का उपयोग करें और उन सभी क्रियाओं से छुटकारा पाएं, जिन्हें बनाने की आवश्यकता है उदाहरण के लिए उपयोगकर्ता के पास आईडी, नाम इत्यादि तर्क के रूप में हो सकते हैं और फ़िल्टरिंग कर सकते हैं। इसके अतिरिक्त फ़िल्टर उपयोगकर्ताओं पर समूहों में भी लागू किए जा सकते हैं।
मुझे लगता है कि पल के लिए ग्राफक बैकएंड आर्किटेक्चर का हिस्सा होना चाहिए, फ़ाइल अपलोड के लिए आप अभी भी एक नियमित एपीआई हिट करते हैं