हम 8base में ग्राफकॉइन का उपयोग क्यों करते हैं

दोस्तों, सभी को नमस्कार!

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

अपने बारे में कुछ शब्द: मैं 8base से VP ऑफ टेक्नोलॉजी हूं। हम ऐसे उपकरण विकसित करते हैं जो फ्रंट-एंड और मोबाइल डेवलपर्स को उच्च गुणवत्ता वाले व्यावसायिक अनुप्रयोगों को जल्दी से बनाने की अनुमति देते हैं।

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

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

आख़िर क्यों, ग्राफ़िकल?

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

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

GraphQL और REST की तुलना करें

चलो एक सरल उदाहरण के साथ GraphQL और REST की तुलना करें - एक ऑनलाइन ब्लॉग बनाना। एक अलग ब्लॉग लेख प्रदर्शित करते समय, हमें लेख की सामग्री, लेखक का अवतार और नाम, टिप्पणियों की एक सूची, साथ ही प्रत्येक टिप्पणीकार का अवतार और नाम दिखाने की आवश्यकता होती है।

REST का उपयोग करते समय, हमें निम्नलिखित API अनुरोधों की आवश्यकता होगी:

GET /articles/:id —   ; GET /users/:id —  URL    ; GET /articles/:id/comments —    (  -        ,      4); GET /users/:id    —  URL    . 

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

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

यहां एक ग्राफक्लाइन क्वेरी का एक उदाहरण दिया गया है जो एक बार में एक क्वेरी में सभी जानकारी लौटा देगा:



इस सुविधा को REST में लागू करने के लिए, बैकएंड डेवलपर्स को एक विशेष समापन बिंदु API बनाने की आवश्यकता होगी जो इस जानकारी को लौटाए। हालाँकि, संबंधित तालिकाओं से डेटा के प्रदर्शन के साथ इस तरह के प्रत्येक मामले के लिए एक ही बात करनी होगी, और साथ ही, एपीआई को अपडेट करते हुए जैसे ही सामने वाले को अतिरिक्त क्षेत्रों की आवश्यकता होगी।

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

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

व्यवहार में यह कैसा दिखता है

ग्राफकॉइन की कमियों में से एक इसका अधिक जटिल कार्यान्वयन है जो कि REST की तुलना में अधिक जटिल है। विभिन्न प्रकार के क्लाइंट अनुप्रयोगों के लिए सुविधाजनक रूप में डेटा प्रस्तुत करने के लिए बैकएंड पर बड़ी मात्रा में काम की आवश्यकता होती है। प्रत्येक डेटा प्रकार के लिए CRUD संचालन, लिंक, फ़िल्टर, सॉर्टिंग और पेजिनेशन को लागू करना काफी थकाऊ है। डेटा एक्सेस अधिकारों के रूप में ऐसी महत्वपूर्ण सुविधाओं को व्यवस्थित करना और डेटा ऑब्जेक्ट्स में फ़ाइलों को संलग्न करना भी इतना सरल नहीं है।

अब मैं दिखाऊंगा कि ग्राफकॉल का उपयोग हमारे कार्यान्वयन के उदाहरण पर क्या संभावनाएं देता है:

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

सारांश

आपका ध्यान के लिए धन्यवाद! मुझे ग्राफकॉल या इसके अनुभव, इसकी समस्याओं के अनुभव के बारे में आपकी राय सुनना अच्छा लगेगा, और मुझे सवालों के जवाब देने में भी खुशी होगी।

इसके अलावा, दोस्तों, शायद आपको हमारे स्टैक के बारे में तकनीकी लेखों की एक श्रृंखला को पढ़ने में रुचि होगी, या शायद कुछ और?

PS आप हमारे बैकएंड डेवलपर आंद्रेई गोरीनोव के भाषण से एक वीडियो में ग्राफकॉउन के फ़ायदे के बारे में जान सकते हैं।