पिछले लेख में , हमने ग्राफकॉक प्रकार प्रणाली में असुविधाजनक बिंदुओं की जांच की।
और अब हम उनमें से कुछ को हराने की कोशिश करेंगे। सभी रुचि रखते हैं, कृपया, बिल्ली के नीचे।

विभाजन संख्या उन समस्याओं से मेल खाती है जिनसे मैं निपटने में कामयाब रहा।

1.2 NON_NULL INPUT

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

और समस्या यह है कि यह खरोंच से आंशिक अद्यतन की अवधारणा को लागू करने की अनुमति नहीं देता है - REST वास्तुकला में HTTP PATCH विधि का एक एनालॉग। पिछली सामग्री पर टिप्पणियों में, मुझे "REST" सोच के लिए बहुत आलोचना की गई थी। मैं केवल यह कह सकता हूं कि CRUD वास्तुकला मुझे इसके लिए बाध्य करता है। और मैं REST के लाभों को देने के लिए तैयार नहीं था, केवल इसलिए कि "ऐसा न करें।" हां, और इस समस्या का हल मिल गया।

और इसलिए, समस्या पर वापस। जैसा कि हम सभी जानते हैं, रिकॉर्ड अपडेट करते समय CRUD स्क्रिप्ट इस तरह दिखाई देती है:

1. पीछे से एक रिकॉर्ड मिला।
2. संपादित रिकॉर्ड फ़ील्ड।
3. वापस करने के लिए एक रिकॉर्ड भेजा।

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

 input ExampleInput { foo: String! bar: String } 

तब जब इस मान के साथ ExampleInput का एक चर मैपिंग

 { "foo": "bla-bla-bla" } 

इस संरचना के साथ एक DTO पर:

 ExampleDTO { foo: String #   bar: ?String #   } 

हमें इस मान के साथ एक DTO ऑब्जेक्ट मिलता है:

 { foo: "bla-bla-bla", bar: null } 

और जब इस मान के साथ एक चर मैपिंग

 { "foo": "bla-bla-bla", "bar": null } 

हमें पिछली बार के समान मूल्य वाला DTO ऑब्जेक्ट मिलता है:

 { foo: "bla-bla-bla", bar: null } 

यही है, एन्ट्रापी होती है - हम इस बारे में जानकारी खो देते हैं कि क्षेत्र ग्राहक से प्रेषित किया गया था या नहीं।
इस मामले में, यह स्पष्ट नहीं है कि अंतिम ऑब्जेक्ट के क्षेत्र के साथ क्या करने की आवश्यकता है: इसे स्पर्श न करें क्योंकि क्लाइंट ने फ़ील्ड को पारित नहीं किया था, या इसे null करने के लिए सेट किया था क्योंकि क्लाइंट null ।

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

 $repository->find(42)->setFoo('bla-bla-lba'); 

यही है, मैं सचमुच एक इकाई संपत्ति के सेटर को नहीं छूता, जब तक कि मुझे इस संपत्ति के मूल्य को बदलने की आवश्यकता न हो। यदि आप इसे ग्राफकाइ स्कीमा में स्थानांतरित करते हैं, तो आपको निम्न परिणाम प्राप्त होंगे:

 type Mutation { entityRepository: EntityManager! } type EntityManager { update(id: ID!): PersitedEntity } type PersitedEntity { setFoo(foo: String!): String! setBar(foo: String): String } 

अब, यदि हम चाहें, तो हम setBar विधि को कॉल कर सकते हैं, और इसके मान को शून्य करने के लिए सेट कर सकते हैं, या इस पद्धति को नहीं छू सकते हैं, और फिर मूल्य को नहीं बदला जाएगा। इस प्रकार, partial update का एक अच्छा कार्यान्वयन सामने आता है। कुख्यात बाकी से PATCH से बदतर नहीं है।

पिछली सामग्री पर टिप्पणियों में, समरविंड ने पूछा: हमें partial update आवश्यकता क्यों है? मैं जवाब देता हूं: बहुत बड़े क्षेत्र हैं।

3. बहुरूपता

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

 #   AccountInput { login: "Acme", password: "***", subject: OrganiationInput { title: "Acme Inc" } } 

 #    AccountInput { login: "Acme", password: "***", subject: PersonInput { firstName: "Vasya", lastName: "Pupkin", } } 

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

विधि ० - माथा

पहली बात जो मन में आती है वह है इनपुट के परिवर्तनीय भाग का पृथक्करण:

 input AccountInput { login: String! password: Password! subjectOrganization: OrganiationInput subjectPerson: PersonInput } 

हम्म ... जब मुझे ऐसा कोड दिखाई देता है, तो मैं अक्सर जोसेफिन पावलोवना को याद करता हूं। यह मुझे शोभा नहीं देता।

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

तब हम कुछ कर सकते हैं:

 input AccountInput { login: String! password: Password! subject: SubjectSelectInput! } input SubjectSelectInput { id: ID! } type Mutation { createAccount( organization: OrganizationInput, person: PersonInput, account: AccountInput! ): Account! } 

या, जो और भी अधिक सुविधाजनक हो गया (क्यों यह अधिक सुविधाजनक है, मैं आपको बताऊंगा जब हम उपयोगकर्ता इंटरफेस की पीढ़ी को प्राप्त करते हैं), इसे विभिन्न तरीकों में विभाजित करें:

 type Mutation { createAccount(account: AccountInput!): Account! createOrganization(organization: OrganizationInput!): Organization! createPerson(person: PersonInput!) : Person! } 

फिर, हमें createAccount और createOrganization / createPerson को एक अनुरोध भेजना होगा
एक बैच। यह ध्यान देने योग्य है कि तब बैच के प्रसंस्करण को लेनदेन में लपेटा जाना चाहिए।

विधि 2 - मैजिक स्केलर
चाल यह है कि GraphQL में स्केलर न केवल Int , Sting , Float , आदि है। यह आम तौर पर कुछ भी है (ठीक है, जबकि JSON इसे संभाल सकता है, ज़ाहिर है)।
तो हम बस एक अदिश की घोषणा कर सकते हैं:

 scalar SubjectInput 

फिर, उस पर अपना हैंडलर लिखें, और यह स्टीम्ड नहीं है। तब हम चर क्षेत्रों को इनपुट में आसानी से पर्ची कर सकते हैं।

कौन सा तरीका चुनना है? मैं दोनों का उपयोग करता हूं, और अपने लिए एक नियम विकसित किया है:
यदि मूल इकाई बच्चे के लिए एक एग्रिगेट रूट है, तो मैं दूसरी विधि चुनता हूं, अन्यथा पहले वाला।

4. पीढ़ी।

यहां सब कुछ तुच्छ है और मुझे कोड पीढ़ी से बेहतर कुछ भी नहीं आता है। और रेल के बिना (रेल्ट / sdl पैकेज) मैं (या बल्कि, मैं बैसाखी के साथ भी ऐसा नहीं कर पाता)। चाल यह है कि रेल आपको दस्तावेज़-स्तरीय निर्देशों को परिभाषित करने की अनुमति देती है (कल्पना पत्र में निर्देशों के लिए ऐसी कोई स्थिति नहीं है)।

 directive @example on DOCUMENT 

अर्थात्, दस्तावेज़ को उस दस्तावेज़ के अलावा किसी अन्य चीज़ से नहीं जोड़ा जाता है जिसमें उन्हें बुलाया जाता है।

मैंने निम्नलिखित निर्देश पेश किए:

 directive @defineMacro(name: String!, template: String!) on DOCUMENT directive @macro(name: String!, arguments: [String]) on DOCUMENT 

मुझे लगता है कि किसी को मैक्रों के सार को समझाने की जरूरत नहीं है ...

अभी के लिए बस इतना ही। मुझे नहीं लगता है कि यह सामग्री अतीत की तरह अधिक शोर का कारण बनेगी। सभी समान, शीर्षक "सुंदर" था)

पिछले लेख की टिप्पणियों में, खब्रोवस्क निवासी पहुंच साझा करने के लिए डूब गए ... इसलिए अगला लेख प्राधिकरण के बारे में होगा।