ग्राफकॉल पर आधारित एपीआई का निर्माण करते समय डेटा के साथ काम करना

प्रस्तावना

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

GraphQL एक महान उपकरण है। मुझे लगता है कि कई लोग पहले से ही इसके फायदे जानते और समझते हैं। हालांकि, आपके ग्राफकॉल आधारित एपीआई का निर्माण करते समय कुछ बारीकियों के बारे में पता होना चाहिए।

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

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

आइए एक गैर-इष्टतम कार्यान्वयन के एक विशिष्ट उदाहरण को देखें (यदि यह खराब पढ़ा है तो एक अलग विंडो में चित्र खोलें):

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

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

निर्णय

यदि हम resolve() आने वाले तर्कों का विश्लेषण करते हैं, तो इस सर्वर व्यवहार को अनुकूलित करना संभव है:

 async resolve(source, args, context, info) { // ... } 

यह अंतिम तर्क, info , जो इस मामले में हमारे लिए विशेष रुचि है। हम दस्तावेज़ीकरण की ओर मुड़ते हैं और विस्तार से विश्लेषण करते हैं कि resolve() फ़ंक्शन और तर्क जिसमें हम रुचि रखते हैं:

 type GraphQLFieldResolveFn = ( source?: any, args?: {[argName: string]: any}, context?: any, info?: GraphQLResolveInfo ) => any type GraphQLResolveInfo = { fieldName: string, fieldNodes: Array<Field>, returnType: GraphQLOutputType, parentType: GraphQLCompositeType, schema: GraphQLSchema, fragments: { [fragmentName: string]: FragmentDefinition }, rootValue: any, operation: OperationDefinition, variableValues: { [variableName: string]: any }, } 

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

हम अपनी समस्या को हल करने के लिए GraphQLResolveInfo से क्या निकाल सकते हैं?

इसके सबसे दिलचस्प हिस्से हैं:

• fieldName उनके GraphQL स्कीमा का वर्तमान फ़ील्ड नाम है। यानी यह इस रिजॉल्वर के लिए स्कीमा में निर्दिष्ट फ़ील्ड नाम से मेल खाती है। यदि हम users क्षेत्र पर info वस्तु को पकड़ते हैं, जैसा कि ऊपर हमारे उदाहरण में है, तो यह "उपयोगकर्ता" है जो कि fieldName के मान के रूप में fieldName
• fieldNodes - उन नोड्स का संग्रह (सरणी) जो क्वेरी में आवश्यक थे। बस क्या आवश्यक है!
• fragments - अनुरोध के टुकड़े का एक संग्रह (मामले में अनुरोध खंडित था)। अंतिम डेटा फ़ील्ड पुनर्प्राप्त करने के लिए भी महत्वपूर्ण जानकारी।

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

इसलिए मैंने इसे ISC लाइसेंस के तहत एक ओपन सोर्स लाइब्रेरी के रूप में लिखने का फैसला किया। इसकी मदद से, आने वाले क्वेरी फ़ील्ड को पार्स करने का समाधान काफी सरल रूप से हल किया गया है, उदाहरण के लिए, इस तरह से हमारे मामले में:

 const { fieldsList } = require('graphql-fields-list'); // ... async resolve(source, args, context, info) { const requestedFields = fieldsList(info); return await database.query(`SELECT ${requestedFields.join(',')} FROM users`) } 

इस मामले में fieldsList(info) हमारे लिए सभी काम करता है और इस रिज़ॉल्वर के लिए बाल फ़ील्ड का "फ्लैट" सरणी लौटाता है, अर्थात्। हमारी अंतिम SQL क्वेरी इस तरह दिखाई देगी:

 SELECT id, name, phone FROM users; 

यदि हम आने वाले अनुरोध को इसमें बदलते हैं:

 query UserListQuery { users { id name phone email } } 

तब SQL क्वेरी में बदल जाएगा:

 SELECT id, name, phone, email FROM users; 

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

 import { GraphQLObjectType, GraphQLSchema, GraphQLString } from 'graphql'; import { connectionDefinitions, connectionArgs, nodeDefinitions, fromGlobalId, globalIdField, connectionFromArray, GraphQLResolveInfo, } from 'graphql-relay'; import { fieldsList } from 'graphql-fields-list'; export const { nodeInterface, nodeField } = nodeDefinitions(async (globalId: string) => { const { type, id } = fromGlobalId(globalId); let node: any = null; if (type === 'User') { node = await database.select(`SELECT id FROM user WHERE id="${id}"`); } return node; }); const User = new GraphQLObjectType({ name: 'User', interfaces: [nodeInterface], fields: { id: globalIdField('User', (user: any) => user.id), name: { type: GraphQLString }, email: { type: GraphQLString }, phone: { type: GraphQLString }, address: { type: GraphQLString }, } }); export const { connectionType: userConnection } = connectionDefinitions({ nodeType: User }); const Query = new GraphQLObjectType({ name: 'Query', fields: { node: nodeField, users: { type: userConnection, args: { ...connectionArgs }, async resolve( source: any, args: {[argName: string]: any}, context: any, info: GraphQLResolveInfo, ) { // TODO: implement }, }, }); export const schema = new GraphQLSchema({ query: Query }); 

इस मामले में, रिले से pageInfo स्कीम में edges , node , pageInfo और cursor नोड्स को जोड़ देगा, अर्थात। अब हमें अलग तरीके से अपने प्रश्नों को फिर से बनाना होगा (अब हम पेजेशन पर ध्यान नहीं देंगे):

 query UserListQuery { users { edges { node { id name phone email } } } } 

इसका मतलब है कि, resolve() users नोड पर लागू फ़ंक्शन को अब यह निर्धारित करना होगा कि कौन से फ़ील्ड स्वयं के लिए नहीं अनुरोध किए गए हैं, लेकिन इसके नेस्टेड चाइल्ड नोड node , जो हम देखते हैं, edges.node साथ users के सापेक्ष है। edges.node पथ।

fieldsList graphql-fields-list लाइब्रेरी से graphql-fields-list इस समस्या को हल करने में मदद करेगा, इसके लिए आपको इसके लिए संबंधित path विकल्प पास करना चाहिए। उदाहरण के लिए, यहाँ हमारे मामले में कार्यान्वयन है:

 async resolve( source: any, args: {[argName: string]: any}, context: any, info: GraphQLResolveInfo, ) { const fields = fieldsList(info, { path: 'edges.node' }); return connectionFromArray( await database.query(`SELECT ${fields.join(',')} FROM users`), args ); } 

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

 CREATE TABLE users ( id BIGINT PRIMARY KEY AUTO_INCREMENT, fullName VARCHAR(255), email VARCHAR(255), phoneNumber VARCHAR(15), address VARCHAR(255) ); 

इस स्थिति में, ग्राफ़ क्वेरी से फ़ील्ड्स को SQL क्वेरी में एम्बेड किए जाने से पहले नाम बदला जाना चाहिए। यदि आप इसे संबंधित transform विकल्प में नाम अनुवाद का नक्शा पास करते हैं, तो fieldsList मदद करेगा:

 async resolve( source: any, args: {[argName: string]: any}, context: any, info: GraphQLResolveInfo, ) { const fields = fieldsList(info, { path: 'edges.node', transform: { phone: 'phoneNumber', name: 'fullName' }, }); return connectionFromArray( await database.query(`SELECT ${fields.join(',')} FROM users`), args ); } 

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

 const { fieldsMap } = require(`graphql-fields-list`); // ... some resolver implementation on `users`: resolve(arc, args, ctx, info) { const map = fieldsMap(info); /* RESULT: { edges: { node: { id: false, name: false, phone: false, } } } */ } 

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

 const { fieldsMap } = require(`graphql-fields-list`); // ... some resolver implementation on `users`: resolve(arc, args, ctx, info) { const map = fieldsMap(info, 'edges.node'); /* RESULT: { id: false, name: false, phone: false, } */ } 

वर्तमान में कार्ड पर नामों का रूपांतरण समर्थित नहीं है और डेवलपर की दया पर बना हुआ है।

विखंडन का अनुरोध करें

GraphQL क्वेरी विखंडन का समर्थन करता है, उदाहरण के लिए, हम उपभोक्ता से ऐसी क्वेरी भेजने की उम्मीद कर सकते हैं (यहाँ हम मूल स्कीमा का उल्लेख करते हैं, थोड़ी दूर की बात है, लेकिन वाक्यविन्यास सही है):

 query UsersFragmentedQuery { users { id ...NamesFramgment ...ContactsFragment } } fragment NamesFragment on User { name } fragment AddressFragment on User { address } fragment ContactsFragment on User { phone email ...AddressFragment } 

आपको इस मामले में चिंता नहीं करनी चाहिए, और fieldsList(info) , और fieldsMap(info) इस मामले में अपेक्षित परिणाम लौटाएंगे, क्योंकि वे खंडों के अनुरोध की संभावना को ध्यान में रखते हैं। इसलिए, fieldsList(info) ['id', 'name', 'phone', 'email', 'address'] और fieldsMap(info) लौटाएगा:

 { id: false, name: false, phone: false, email: false, address: false } 

पुनश्च

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

UPD 1

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

 fieldsList(info, { withDirectives: false }) fieldsMap(info, null, false);